Christoph Plattner wrote: > > Hi ! > > 1) > Errormessage like 'BOOTP block to big' does not come from > etherboot itself (I also searched it with grep, but could not > find it), it is a`part of the nbi-linux loader (first-linux.S). > I think this error has nothing to do with the fact, that the > booting hangs. I see - we're getting closer to the problem. So the error message was 'BOOTP record too large' in first-linux.S. There are two causes for this error message: either there are 16 consecutive NOP tags in the BOOTP reply (which is VERY unusual) or the reply is indeed too large for the buffer first-linux.S has available. To find out what's going on it would be very interesting to see what the debug output from first.linux is - to enable it, define both ASM_DEBUG and ASM_DEBUG_VERBOSE (there is a single #undef near the top) and rerun make/make install. Independently you could try to add -DINTERNAL_BOOTP_DATA to the etherboot Config file (just add it to a CFLAGS32= line). Recompile etherboot and try it again. Probably it's a good idea to use a boot disk for testing (make rtl8138.lzfd0 in the src directory). > 2) The nbgrub image can be booted with another nic ! > > 1+2) The machine cannot continue executing the code - in one > case it hangs, in the other case it reboots. The reason can > be the same. Is the same BOOTP (network protocol-wise) reply used for both images, i.e. do you use the menu to switch between them? > 3) As far as I know, the RTL8139A is on the board (OvisLink, > homepage ` http://www.ovislink.com.tw/products.htm ' > The card is quite new (I bought it for 3 Months) and has modern > features like wake-on-lan (I do not use it). If it's recent and has wake-on-lan then it's probably a RTL8139C, which I cannot test and is rumored to have slight incompatibilities to the previous versions. At least the Linux driver has some special code for that card - don't know what it does, though. However from the behaviour I think that the main etherboot routines work just fine, it seems like passing the BOOTP record to the next stage loader causes havoc there. The only difference seems to be the reaction of the second stage loader. The first-linux code detects something strange, prints an error message and goes into an endless loop, GRUB doesn't detect the error and just reboots, probably due to some internal failure. > 4) Nearly all of my EPROM Chips are 150ns Chips (`-15'). I don't > think, that this is the Problem, as the ertherboot software > starts..... It's strange that a 150ns chip doesn't work in the Pentium systems - I never had a problem with 175ns CMOS ROMs. Well, going through the details of the machines I set up using RTL8139 boot ROMs there is a 486, a couple of P-166/200/233 (some MMX, some not) and a K6-2-266. Oh well, no really recent board. > PS: What with the bug concerning the NE and NE/PCI probing ? The hang > <1> when no NE2000 card is found -> problem in GRUB > > <2> on my RTL8029A (Ovislink again) NE2000/PCI probe hungs > at the end of the first pio_write call (in the while-loop). no idea and no card to test with (though as it is a problem when the card is not present I might be able to test that). I'm pretty busy, though, so don't hold your breath. Generally these bugs have to be solved by checking if the driver does what the card docs say - for NE2000 this is next to impossible because I haven't yet seen a proper documentation that defines what the card actually does in some strange cases which tend to happen when probing. So trial and error is the best way to go. In some cases checking what the Linux or *BSD driver does is also a viable solution. =========================================================================== This Mail was sent to netboot mailing list by: Klaus Espenlaub <espenlaub@informatik.uni-ulm.de> To get help about this list, send a mail with 'help' as the only string in it's body to majordomo@baghira.han.de. If you have problems with this list, send a mail to netboot-owner@baghira.han.de.
For requests or suggestions regarding this mailing list archive please write to netboot@gkminix.han.de.