[tulip-bug] FreeBSD Problems with dc(4) ADMtek AN985 chip
Fri Sep 6 05:18:01 2002
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 email@example.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993