kern/85886: [an] an0: timeouts with Cisco 350 minipci
Jason Young
jyoung at spaceball1.doogles.com
Tue Dec 26 22:50:18 PST 2006
The following reply was made to PR kern/85886; it has been noted by GNATS.
From: Jason Young <jyoung at spaceball1.doogles.com>
To: bug-followup at FreeBSD.org, djb at gofree.co.uk
Cc:
Subject: Re: kern/85886: [an] an0: timeouts with Cisco 350 minipci
Date: Wed, 27 Dec 2006 01:20:53 -0500 (EST)
I've had the same symptoms when using the MPI350 (Aironet 350 series Mini
PCI). Every N packets (seems to be 5 for me), the transmit interrupt would
fail to fire and the result would be "an0: device timeout". The card would
reset, then I could get another N packets, lather rinse repeat. The card
will work when running 5.00.03 or below, but 5.02 and above experienced
this problem.
I spent a lot of time comparing what we do with the Cisco-updated Linux
driver that's supposed to work with the new firmware. My results: it looks
like the MPI350 does NOT want certain transmit control bits set. In
if_anreg.h, we define the control bits for an 802.3 frame as follows:
#define AN_TXCTL_8023 \
(AN_TXCTL_TXOK_INTR|AN_TXCTL_TXERR_INTR|AN_HEADERTYPE_8023| \
AN_PAYLOADTYPE_ETHER|AN_TXCTL_NORELEASE)
There's another definition used when sending 802.11 frames, but the driver
is not written to use that definition at all. If you drop the bits asking
for TX complete and TX error interrupts, like so:
#define AN_TXCTL_8023 \
(AN_HEADERTYPE_8023|AN_PAYLOADTYPE_ETHER|AN_TXCTL_NORELEASE)
The card runs happily at full speed, no timeouts, running any of the
following firmware revisions: 5.00.01, 5.30.17 and 5.60.21. The MPI350 has
its own special kind of transmit interrupt, TX_CPY (transmit buffer copy
or DMA done? unsure), so maybe the other two just don't apply to MPI350.
The driver will still complain of RID length mismatches, but this should
be cosmetic only for the driver's current feature set. In order to take
full advantage of the card's features, the driver will have to learn about
the new fields.
I do not recommend the above change be committed as-is, because it will
affect more than the MPI350. I think the right thing to do is to add an
mpi350 switch (like many other places in the driver), but next week I
should have access to some pccard Aironet 340 and 350s to do regression
testing with. I would be interested in any feedback, though, to see if
this change helps anyone else drive new-firmware MPI350s under FreeBSD.
-jyoung
More information about the freebsd-bugs
mailing list