kern/85886: [an] an0: timeouts with Cisco 350 minipci

[Jason Young]

The following reply was made to PR kern/85886; it has been noted by GNATS.

From: "Jason Young" <jyoung at evelocity.net>
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:24:19 -0500

 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