etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Re: Re: Etherboot has eepro100.c for 82559....?

[<ke...@us...>]

>               outl(0, ioaddr + SCBPointer);
>               inl(ioaddr + SCBPointer);                /* Flush 
>to
>           PCI. */
>               udelay(10);                    /* Bogus, but it 
>avoids
>           the bug. */

In the Linux driver, I notice that wait_for_cmd_done now does a
udelay(1) up to a max of 1000 times. The current Etherboot driver
doesn't any udelay and only relies on a countdown loop of 100 times. Can
you please try updating the Etherboot driver to match? I'm going to put
in this change for 5.0.8 in any case.

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[<ke...@us...>]

>Interestingly, both memsize and basememsize are reported as 639 by both
>5.0.x and 5.1.x.  Is this normal?

You mean as opposed to 640? That's ok, there a little bit that's used by
the BIOS at the top of 640kB. In the E820 map that's the bit that's type
2.

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Michael B. <mb...@fe...>]

On 29 Aug 2002, Eric W. Biederman wrote:
> > I think I'm seeing the same problem.  I'm getting total garbage in the
> > E820 map.  I added a config option IGNORE_E820_MAP that forces use of the
> > "fake" memory map used when the e820 calls fail, which gets it to the
> > point of "Loading 10.1.0.1:boot-8139too.nbi ...(NBI)" at which point it
> > locks up and requires a hard reset.
> The symptoms are certainly the same.
> > Ideas, toolchain test, etc. welcome.
> Could you see if the E820 issue is new?
> That is could you take a 5.0 series etherboot and dump the e820 map
> you get.

Done.  Result with current 5.0.x CVS is sensible:

[0000000000000000, 000000000009FC00) type 1
[000000000009FC00, 00000000000A0000) type 2
[00000000000F0000, 0000000000100000) type 2
[00000000FFFF0000, 0000000100000000) type 2
[0000000000100000, 00000000037F0000) type 1
[00000000037F3000, 0000000003800000) type 3
[00000000037F0000, 00000000037F3000) type 4

Result from 5.1.x is genuine garbage, looking almost like random data.
Short extract:

...
[0F52506100000000, 1B5D5D6319190619) type 0
[4000400010000800, 9050672860302028) type 690825260
[C0325250291E2E2A, 61193E3649CF1F10) type 552004582
...

Interestingly, both memsize and basememsize are reported as 639 by both
5.0.x and 5.1.x.  Is this normal?

Michael

[Etherboot-developers] Re: Re: Etherboot has eepro100.c for 82559....?

[atul s. <atu...@re...>]

Hello all,

I queried my question regarding ethrboot 82557 driver
and 82559 cards on eepro mailing list as well..
i gotone reply which i am pasting below would be helpful and 
guiding for others in similar confusion.

though all my problems are not solved but i am quite ahead .

now my problem is in timeout and currticks() functions in
main.c which is leading me in a infinite loop in 
await_reply()..probably i have to port them appropiately on mips 
idt.
if anybody has any input on these pls. advise me..

below is the 82559 and 82559er related stuffs.
********************************************************

           On 28 Aug 2002, atul srivastava wrote:

           > this driver is written for 82557 but i am using
           82559
           > card .
           > my question is that can a 82557 driver
           aplicable to both 82559 and
           > 82559ER ?

           For the most part, yes.  The '559 and '559ER
           were designed to be fully
           backwards compatible, with new features.  But,
           as is typical with such
           things, they do their own set of bugs.

           > also my card reports status 0090 before and
           after Transmit command
           > that as per manual indicates no resources,

           There are various bugs that trigger a "no
           resources" report.  In this
           case my guess is that you have encountered the
           timing bug when loading
           the SCBPointer, RxAddrLoad or CUCmdBase.
            These operations used to be
           effectively instantaneous (less than a PCI bus
           transaction).  But a
           firmware change in a later chip caused them to
           take an unpredictable (or
           just undocumented) amount of time.

               outl(0, ioaddr + SCBPointer);
               inl(ioaddr + SCBPointer);                /* Flush 
to
           PCI. */
               udelay(10);                    /* Bogus, but it 
avoids
           the bug. */
               /* Note: these next two operations can take a
           while. */
               do_slow_command(dev, RxAddrLoad);
               do_slow_command(dev, CUCmdBase);

********************************************************



__________________________________________________________
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[<ke...@us...>]

>Ken that gives us at least there is one data point the NBI loader
>works.

But only that it loads a small binary to the vicinity of 0x20000.

>Ken which toolchain gcc/binutils.  If we can collect some datapoints
>we may have something to go on.

gcc 2.95.3, binutils 2.11.92

I doubt if it's the toolchain. IIRC the toolchain only mattered in the
gcc 2.96 debacle and one small code ordering bug with compiling
rtl8139.c.

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >I think I'm seeing the same problem.  I'm getting total garbage in the
> >E820 map.  I added a config option IGNORE_E820_MAP that forces use of the
> >"fake" memory map used when the e820 calls fail, which gets it to the
> >point of "Loading 10.1.0.1:boot-8139too.nbi ...(NBI)" at which point it
> >locks up and requires a hard reset.
> >
> >Ideas, toolchain test, etc. welcome.
> 
> Hmm, suspicion falls on the e820 BIOS call shim in pcbios.S. I should
> mention that I didn't actually go all the way and boot a kernel with my
> test, only another copy of Etherboot. Also it was on an old Pentium
> which may be using the e801 call.

I don't think the e820 BIOS fails completely.  As it worked
on the one system I tested it on.  But it is a very recent dual P4
Xeon system.  But there are a lot of cases not convered with that one
datapoint. 

Ken that gives us at least there is one data point the NBI loader
works.

Ken which toolchain gcc/binutils.  If we can collect some datapoints
we may have something to go on.

Eric

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[<ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> I think I'm seeing the same problem.  I'm getting total garbage in the
> E820 map.  I added a config option IGNORE_E820_MAP that forces use of the
> "fake" memory map used when the e820 calls fail, which gets it to the
> point of "Loading 10.1.0.1:boot-8139too.nbi ...(NBI)" at which point it
> locks up and requires a hard reset.

The symptoms are certainly the same.
 
> Ideas, toolchain test, etc. welcome.

Could you see if the E820 issue is new?
That is could you take a 5.0 series etherboot and dump the e820 map
you get.

My gut feeling is that we may be suffering from multiple issues.

Wth two people reporting the same symptoms something fishing is going on.

I sent Timothy Legge some binaries built on my machine and they did not
work either, so it does not look like toolchain issues.



Eric

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[<ke...@us...>]

>I think I'm seeing the same problem.  I'm getting total garbage in the
>E820 map.  I added a config option IGNORE_E820_MAP that forces use of the
>"fake" memory map used when the e820 calls fail, which gets it to the
>point of "Loading 10.1.0.1:boot-8139too.nbi ...(NBI)" at which point it
>locks up and requires a hard reset.
>
>Ideas, toolchain test, etc. welcome.

Hmm, suspicion falls on the e820 BIOS call shim in pcbios.S. I should
mention that I didn't actually go all the way and boot a kernel with my
test, only another copy of Etherboot. Also it was on an old Pentium
which may be using the e801 call.

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Michael B. <mb...@fe...>]

On 27 Aug 2002, Eric W. Biederman wrote:
> > > I applied both the pcbios patch and the the memsizes patch.  Now, I just
> > > get:
> > > Searching for server (DHCP)...
> > > ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6
> > > Loading 192.168.2.6:lts/vmlinuz-2.4.9-ltsp-5 ...(NBI)
> > > It now freezes at this point, requiring a hard reboot.
> Hmm. So it dies before transmitting any packets.
> > I then modified the /etc/dhcpd.conf file to grab the 3c509.fd0 and received
> > the following:
> The rom image?
> > Searching for server (DHCP)...
> > ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6
> > Loading 192.168.2.6:lts/bootrom ...(NBI)...........Unable to Load file
> > <sleep>
> > <abort>
> > There were no hard frezes with this file.
> So no change with that file at all...
> Very strange.
> I have sent you some romimages in a seperate message, (
> I don't want to spam the list with them) but testing them
> will confirm if there is something in your toolchain that is
> causing problems.

I think I'm seeing the same problem.  I'm getting total garbage in the
E820 map.  I added a config option IGNORE_E820_MAP that forces use of the
"fake" memory map used when the e820 calls fail, which gets it to the
point of "Loading 10.1.0.1:boot-8139too.nbi ...(NBI)" at which point it
locks up and requires a hard reset.

Ideas, toolchain test, etc. welcome.

Michael Brown
http://www.fensystems.co.uk

[Etherboot-developers] [COMMIT] boot order option...

[Eric W B. <ebi...@ln...>]

I have now written the support to allow specifying the boot order.

I have enhanced the ASK_BOOT option to allow ask:
Boot from (N)etwork (D)isk (F)loppy or from L)ocal?

I have made the boot order compile time selectable.

I have added a LinuxBIOS cmos option so I can specify a default
independent of etherboot.

I have reordered the switch statement in main to so the code executes
from top to bottom of the screen.

Eric

[Etherboot-developers] timer.[ch]

[Ronald G M. <rmi...@la...>]

OK, I have plugged my timer.c into 5.0.7 and it works fine :-)

But the ethernet address still comes back all 0s :-(
and the s1, s2 still show all 0s :-(

I'm still looking.

ron

[Etherboot-developers] I've just checked and ...

[Ronald G M. <rmi...@la...>]

The 5.0.5 timer.[ch] is identical it seems with the 5.0.7 version. So my
5.0.5 version should be fine with 5.0.7. My version has the "don't use
timer2" patch. I am attaching it for all of you to take a look see and
comment. I think this might help with my current problems as Smartcore
systems don't actually have a TIMER2 -- all timeouts go to 0.

ron

Re: [Etherboot-developers] Etherboot has eepro100.c for 82559....?

[Ronald G M. <rmi...@la...>]

On 28 Aug 2002, Eric W Biederman wrote:

> O.k. I got it, the joys of a developer list that won't take patches :)
> Your patch is reversed but I should be able to cope.

I noticed that, I'm sorry, I can't believe I did that again.

I took a quick browse through it but nothing jumped up and hit me on the
head.

ron

Re: [Etherboot-developers] Etherboot has eepro100.c for 82559....?

[Eric W B. <ebi...@ln...>]

Ronald G Minnich <rmi...@la...> writes:

> Here are the sum total of our differences against a clean 5.0.5 checkout
> (turns out we were doing 5.0.5, sorry). This etherboot worked fine for us
> for a number of motherboards with eepro and 3c509 and rtl8139 interfaces.
> I suspect, however, that you all have improved things to the point that
> most of these fixes are unnecessary. Who knows.
> 
> The changes are mostly for:
> 1: 3c90x fixes for linuxbios machines
> 2: eepro100 fixes for linuxbios machines
> 3: rtl8139 fixes """""""""""""""""""""
> 4: making TIMER2 an option, and using TSC instead.
> 
> The problem is that it is somewhat hard to build this etherboot against
> the newest linuxbios -- it appears the .ebi format changed a bit so
> linuxbios won't boot the .ebis from this tree any more.
> 
> Also, the smartcore p5 has some differences from the other ones so we're
> not even sure if this is an etherboot, linuxbios, or smartcore issue. Or
> all 3. or any 2. :-)

O.k. I got it, the joys of a developer list that won't take patches :)
Your patch is reversed but I should be able to cope.

Eric

Re: [Etherboot-developers] Etherboot has eepro100.c for 82559....?

[Eric W B. <ebi...@ln...>]

"atul srivastava" <atu...@re...> writes:

> Yah .. i found a missing call to virt_to_bus for passing the address of txfd
> ..but even after adding that my status is same.
> 
> just few momemts back i noticed i am using a 82559 card
> while etherboot eepro100 drives only 82557 card.
> 
> i know about few change in char config_cmd [22] and in TxFD and RxFD structure
> has taken plave between 82557 and 82559 cards.
> 
> anywy does any body know it any vrsion of etherboot has the scaled down version
> of Donald Becker's 82559 driver.
> 
> if yes pls. let me know..

On a slighty seperate subject would you be interested in working on a full
port to MIPS?  

Hmm.  Are you running little endian MIPS?  It just occured to me that
if you are big endian there might be some endian problems in the driver.

I have been working the codebase in the general direction of portability
with 5.1.2rc3.  The driver API is portable, and non-portable drivers should show
up on x86 for the most part.  The core codebase still needs porting.

On my wishlist I have x86-64, Itanium, and Alpha, but I don't know if I will
get to any of them.

Eric

Re: [Etherboot-developers] Etherboot has eepro100.c for 82559....?

[Ronald G M. <rmi...@la...>]

On 28 Aug 2002, Eric W Biederman wrote:

> Ron could you send a patch of your outstanding changes to etherboot please.

oh boy. OK, I'll send it, but it's messy. We haven't made an effort to
clean it up.

The thing that's odd here is that I think my eepro100.c won't differ much
if at all from yours. But I'll check.

ron

Re: [Etherboot-developers] Etherboot has eepro100.c for 82559....?

[Eric W B. <ebi...@ln...>]

Ronald G Minnich <rmi...@la...> writes:

> On 28 Aug 2002, atul srivastava wrote:
> 
> > just few momemts back i noticed i am using a 82559 card
> > while etherboot eepro100 drives only 82557 card.
> 
> that difference has not been a problem for me (yet).
> 
> For version 5.0.6 we just added the devid for the 82559 to the eepro100.c
> and it all worked fine. I have never had 5.0.7 work on any system I have,
> however. And, interestingly, the symptoms are the same for both cards I
> have tried 5.0.7 on: packets get sent OK, but etherboot never knows it.

Ron could you send a patch of your outstanding changes to etherboot please.

Debugging isn't easy when you change the code and sit on it.

Eric

Re: [Etherboot-developers] Re: Possibly [PRISM] driver limitation?

[Michael B. <mb...@fe...>]

On 27 Aug 2002, Eric W. Biederman wrote:
> > > Today I have been doing a bunch of tests. My test machine has 128mb of
> > > RAM and I was testing different size images and different network
> > > card/drivers to check for problems. Here are the results
> > > Realtek 8139 card with rtl8139 driver: 43mb,20mb, 19.3mb, 19.1mb, 17.6mb,
> > 16.2mb, 15.2mb image files all booted OK.
> > > Realtek 8029 card with rtl8029 driver: 43mb,20mb, 19.3mb, 19.1mb, 17.6mb,
> > 16.2mb, 15.2mb image files all booted OK also.
> > > Dlink DWL-520 with PRISM driver: 43mb failed, 20mb failed, 19.3mb ok, 19.1mb
> > ok, 17.6mb,16.2mb ok, 15.2mb ok.
> > > It seems their seems to be a limitation in file size in the PRISM
> > > driver. Somewhere between 19.3mb-20mb's, the driver cannot allocate
> > > space or initialize the data from the image file. Hopefully we could
> > > fix this issue? [sooner the better..hehehe]
> > I'll help where I can, but I don't see this as an urgent problem - why
> > would you want to transfer images of 20MB and more anyway, particularly
> > over a slow wireless link?
> If problem is just related to the packet count, it may be easier to
> tickle the problem when the signal is degradded, and a lot of
> retransmissions are happening.  Fixing bugs like this that can never
> really happen is then kind of thing that let's me sleep at night.

Have reviewed the code and one immediate suspect appears.  Basic transmit
pattern is:

1. Request a FID (Frame ID, I think).
2. Wait for event signalling FID allocation.
3. Fill FID buffer with the packet to be transmitted.
4. Transmit the frame.
5. Wait for transmission to complete.

Now, there is an option in step 4 to say "please re-use the FID after
transmission", in which case you will receive a "FID allocated" event
shortly after the transmission is completed, without having to re-request
a FID.  I chose not to use this option in the interests of simplicity -
AFAICT if you don't ask for re-use then you just pay the penalty of having
to re-request a FID.  I assumed that the FID that was "used" (but not
"re-used") was not lost forever.  It is possible, but very unlikely, that
this assumption is incorrect.

One test worth trying would be a very simple use of the "reclaim" mode:

In "prism2_transmit":

Make "fid" static:
  #define FID_NOT_YET_ALLOCATED = 0;
  static UINT16 fid = FID_NOT_YET_ALLOCATED;

Modify the line
  result = hfa384x_docmd_wait(hw,
			      HFA384x_CMD_CMDCODE_SET(HFA384x_CMDCODE_TX),
			      fid, 0, 0);
to
  result = hfa384x_docmd_wait(hw,
			      HFA384x_CMD_CMDCODE_SET(HFA384x_CMDCODE_TX) |
				HFA384x_CMD_RECL_SET(reclaim),
			      fid, 0, 0);

then wait for the reused "FID allocated" event at the end of the transmit
routine:

  if ( !hfa384x_wait_for_event(hw, HFA384x_EVSTAT_ALLOC, 10, 50,
			       "Tx FID to be allocated\n" ) ) return;
  fid = hfa384x_getreg(hw, HFA384x_ALLOCFID);

and finally, at the beginning of the routine, only allocate a new FID if
fid == FID_NOT_YET_ALLOCATED.

This may or may not work - I don't have time to test it right now.  Anyone
else want to give it a go?

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] Etherboot has eepro100.c for 82559....?

[Ronald G M. <rmi...@la...>]

On 28 Aug 2002, Eric W. Biederman wrote:

> Hmm.  Do you have an 82559 or an 825559ER?

I have 82559er and in 5.0.6 the eepro100 worked fine.

ron

Re: [Etherboot-developers] Etherboot has eepro100.c for 82559....?

[Ronald G M. <rmi...@la...>]

On 28 Aug 2002, atul srivastava wrote:

> just few momemts back i noticed i am using a 82559 card
> while etherboot eepro100 drives only 82557 card.

that difference has not been a problem for me (yet).

For version 5.0.6 we just added the devid for the 82559 to the eepro100.c
and it all worked fine. I have never had 5.0.7 work on any system I have,
however. And, interestingly, the symptoms are the same for both cards I
have tried 5.0.7 on: packets get sent OK, but etherboot never knows it.

ron

Re: [Etherboot-developers] Etherboot has eepro100.c for 82559....?

[<ebi...@ln...>]

"atul srivastava" <atu...@re...> writes:

> Yah .. i found a missing call to virt_to_bus for passing the address
> of txfd ..but even after adding that my status is same.
> 
> just few momemts back i noticed i am using a 82559 card
> while etherboot eepro100 drives only 82557 card.

That shouldn't be a problem in and of itself, especially
as they hide out under the same pci id. 
 
> i know about few change in char config_cmd [22] and in TxFD and RxFD
> structure has taken plave between 82557 and 82559 cards.

Hmm.  Do you have an 82559 or an 825559ER?
 
> anywy does any body know it any vrsion of etherboot has the scaled
> down version of Donald Becker's 82559 driver.
> 
> if yes pls. let me know..

Anyway the driver has worked well for me on the 82559.  

Eric

[Etherboot-developers] Etherboot has eepro100.c for 82559....?

[atul s. <atu...@re...>]

Yah .. i found a missing call to virt_to_bus for passing the 
address of txfd ..but even after adding that my status is same.

just few momemts back i noticed i am using a 82559 card
while etherboot eepro100 drives only 82557 card.

i know about few change in char config_cmd [22] and in TxFD and 
RxFD structure has taken plave between 82557 and 82559 cards.

anywy does any body know it any vrsion of etherboot has the scaled 
down version of Donald Becker's 82559 driver.

if yes pls. let me know..

Best Regards,

On Wed, 28 Aug 2002 Eric W Biederman wrote :
>"atul srivastava" <atu...@re...> writes:
>
> > since i amn't subscribed to list pls. cc any reply to me.
>
>Once.  Are you running this on an embedded mips platform?
>Normally traffic is kept on the list.
>
> > I am trying to use etherboot for net booting using
> > 82557 network card.
> >
> > my driver is eepro100.c by R.E.wolff that is a scaled down 
>version of donald
> > becker one.
> > this driver doesn't uses any interrupt and packet reception is 
>polling driven.
> >
> > resource assignment for pci base addreses are:
> >
> > BAR0 - 0x60000000
> > BAR1 - 0x18800001
> > BAR2 - 0x62000000
> >
> > these addresses are as per the mips idt manual.
> > also virt_to_bus are confirmed to be o.k
>
>Does your driver match the newest version in the development tree 
>5.1.2rc3?
>Otherwise there is a missing virt_to_bus call.
>
> > i am able to correctly read MAC address for card.
> >
> > also packet reception is o.k , so the pci bus to memory 
>trasaction is taking
> > place.
> >
> > my problem is in packet trasmission i should get txfd.status 
>to become  nonzero
> > for indicating packet trasfer has happened but it never 
>happens and my driver
> > hangs there for ever.
> >
> > when debugged i saw from very begining status as 0090
> > .
> >
> > as per eepro manual status 0090 indicates "NO RESOURCE"
> >
> > but i am unable to conclude what it means..
> >
> > can any body help..?
>
>Of the top of my head I would say it is the missing virt_to_bus 
>call
>in the stable version of the tree.
>
>Eric

__________________________________________________________
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/

Re: [Etherboot-developers] Re: Possibly [PRISM] driver limitation?

[<ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> On Tue, 27 Aug 2002, Boris Reisig wrote:
> > Today I have been doing a bunch of tests. My test machine has 128mb of
> > RAM and I was testing different size images and different network
> > card/drivers to check for problems. Here are the results
> > Realtek 8139 card with rtl8139 driver: 43mb,20mb, 19.3mb, 19.1mb, 17.6mb,
> 16.2mb, 15.2mb image files all booted OK.
> 
> > Realtek 8029 card with rtl8029 driver: 43mb,20mb, 19.3mb, 19.1mb, 17.6mb,
> 16.2mb, 15.2mb image files all booted OK also.
> 
> > Dlink DWL-520 with PRISM driver: 43mb failed, 20mb failed, 19.3mb ok, 19.1mb
> ok, 17.6mb,16.2mb ok, 15.2mb ok.
> 
> > It seems their seems to be a limitation in file size in the PRISM
> > driver. Somewhere between 19.3mb-20mb's, the driver cannot allocate
> > space or initialize the data from the image file. Hopefully we could
> > fix this issue? [sooner the better..hehehe]
> 
> I'll help where I can, but I don't see this as an urgent problem - why
> would you want to transfer images of 20MB and more anyway, particularly
> over a slow wireless link?

If problem is just related to the packet count, it may be easier to
tickle the problem when the signal is degradded, and a lot of
retransmissions are happening.  Fixing bugs like this that can never
really happen is then kind of thing that let's me sleep at night. 

Eric

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[<ebi...@ln...>]

"Timothy Legge" <tl...@ro...> writes:

> > I applied both the pcbios patch and the the memsizes patch.  Now, I just
> > get:
> >
> > Searching for server (DHCP)...
> > ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6
> > Loading 192.168.2.6:lts/vmlinuz-2.4.9-ltsp-5 ...(NBI)
> >
> > It now freezes at this point, requiring a hard reboot.

Hmm. So it dies before transmitting any packets.
 
> I then modified the /etc/dhcpd.conf file to grab the 3c509.fd0 and received
> the following:

The rom image?
 
> Searching for server (DHCP)...
> ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6
> Loading 192.168.2.6:lts/bootrom ...(NBI)...........Unable to Load file
> <sleep>
> <abort>
> 
> There were no hard frezes with this file.

So no change with that file at all...

Very strange.

I have sent you some romimages in a seperate message, (
I don't want to spam the list with them) but testing them
will confirm if there is something in your toolchain that is
causing problems.

Eric

RE: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Timothy L. <tl...@ro...>]

> I applied both the pcbios patch and the the memsizes patch.  Now, I just
> get:
>
> Searching for server (DHCP)...
> ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6
> Loading 192.168.2.6:lts/vmlinuz-2.4.9-ltsp-5 ...(NBI)
>
> It now freezes at this point, requiring a hard reboot.

I then modified the /etc/dhcpd.conf file to grab the 3c509.fd0 and received
the following:

Searching for server (DHCP)...
..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6
Loading 192.168.2.6:lts/bootrom ...(NBI)...........Unable to Load file
<sleep>
<abort>

There were no hard frezes with this file.

Tim