tulip driver & Asante Fast 10/100 card

Bob Farmer ucs_brf@unx1.shsu.edu
Mon Nov 15 16:13:45 1999

> >Bob Farmer (ucs_brf@unx1.shsu.edu) reported:
>  > The net cards we've been buying, Asante Fast 10/100, recently switched
> >> > from 21140A chips to the PNIC chips. On startup, the driver reports the
> >> > chip as a "Lite-On 82c168 PNIC rev 32". It works for a bit, but as soon
> >> > as you try to transfer more than about 50K of data through the card, it
> >> > locks, and the interface has to be taken down and brought back up again to
> >> > restore connectivity.
> >>
> I've been looking at this problem with Bob and I see the same things
> here.
> >> What's the whole detection message?
> >> Is the an MII transceiver, or does it use the internal encoder and an
> >> external twister (SYM PHY)?
> >
> >The whole detection message is this (with 0.89H):
> >
> >tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov
> >eth0: Lite-On 82c168 PNIC at 0xe400, 00 00 b4 94 e0 99, IRQ 10.
> >eth0: MII transceiver found at MDIO address 1, config 3100 status 7829.
> >eth0: Advertising 01e1 on PHY 1, previously advertising 01e1.
> >eth0: Changing PNIC configuration to full-duplex, CSR6 812e0200.
> >
> >I am using Intel BX chipset Pentium II motherboards.
> >
> >If, while doing the receive-file test, I turn on "debug=3" on the module,
> >I get this output when the interface hangs:
> >
> >eth0: Oversized Ethernet frame spanned multiple buffers, status 7fff0200!
> >eth0: Oversized Ethernet frame spanned multiple buffers, status 08018192!
> I get these messages, but the interface has not yet frozen when
> The first (and other odd-numbered) message always report status 7fff0200.
> The even numbered messages are of the form 06xx8186 or occasionally
> 06xx8182.
> >
> >When using half-duplex those warnings above never appear.
> >
> >Now, retrying all of the above things with 0.91g, everything's the same
> >except one thing: no crash or interface hang when I send a large file with
> >FTP. Just a ton of the "Oversized Ethernet frame spanned multiple
> >buffers" warnings (debug=3). Still the same interface hang when receiving
> >a large file with FTP, though, at full-duplex.
> After the transfer finishes if I either exit the ftp program or
> wait a minute or two, I get these messages:
> Too much work during an interrupt, csr5=0x026f0050.
> Too much work during an interrupt, csr5=0x026d80d4.
> at which point the interface must be brought down and restarted,
> as Bob reports.

The "too much work during an interrupt" error is normal when transferring
a whole lot of data when you haven't modified the "max_interrupt_work"
variable.  When I did my testing, I had modified it.  I think I was using
"max_interrupt_work=32000".  So, I didn't get the "Too much work" error,
yet my interface still froze.