Date: Wed, 27 Dec 2006 06:50:17 GMT From: Jason Young <jyoung@spaceball1.doogles.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/85886: [an] an0: timeouts with Cisco 350 minipci Message-ID: <200612270650.kBR6oHqE002412@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/85886; it has been noted by GNATS. From: Jason Young <jyoung@spaceball1.doogles.com> To: bug-followup@FreeBSD.org, djb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612270650.kBR6oHqE002412>