Re: RTL 8139 Problems - seems to be an old one .....

[Christoph Plattner <christoph.plattner@dot.at>]

Hi !

My card definitely has the 8139A chip soldered on. Icheck it now at
home.

Cheers.

	Christoph Plattner



Klaus Espenlaub wrote:
> 
> 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.
===========================================================================
This Mail was sent to netboot mailing list by:
Christoph Plattner <christoph.plattner@dot.at>
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.