[tulip-bug] FreeBSD Problems with dc(4) ADMtek AN985 chip

[Donald Becker]

On Thu, 5 Sep 2002, Martin Blapp wrote:

> >From a cold boot into Linux, is see the same symptoms as FreeBSD.
> Linux kernel 2.4.9-13 ... The windows driver seems to work :-( .

Which Linux driver versions have you tried?  Specifically, have you
tried an unmodified tulip driver?

> >From the FreeBSD dc manpage.
> 
>      The ADMtek AL981 chip (and possibly the AN985 as well) has been observed
>      to sometimes wedge on transmit: this appears to happen when the driver
>      queues a sequence of frames which cause it to wrap from the end of the
>      transmit descriptor ring back to the beginning.  The dc driver attempts
>      to avoid this condition by not queuing any frames past the end of the
>      transmit ring during a single invocation of the dc_start() routine.  This
>      workaround has a negligible impact on transmit performance.

This never applies to the Linux driver.

Linux has linear skbuffs (ignoring sendfile-zerocopy), and thus queues
each frame into a single descriptor.  There will never be a case where
a frame wraps around the end of the ring.  My driver additionally avoids
bugs (in several other chips, but perhaps the Comet as well) by both
chaining descriptors into a ring using the 'next' pointer and marking the final
descriptor as wrapping the ring.

This technique cannot be efficiently used with mbufs in *BSD, so there
must be two different ring handling code paths: both chained
and wrapped-ring configurations.

> But this workaround seems not to work for me. For some reason, replugging
> the cable works for me, ifconfig (down/up) does not.

That's very likely a media selection problem, rather than a Rx
descriptor problem.  Of course resetting the chip will clear a
descriptor hang, but that wouldn't be my first guess.


-- 
Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993