Messages in this thread | | | Date | Thu, 20 Jul 2006 08:53:28 +1200 | From | "Keith Chew" <> | Subject | network tx_timeout guidance |
| |
Hi
We are stress testing a wireless network driver from a vendor (ZD1211 chip, we realise that there is a rewrite project happenning but that it still not ready for production yet).
So far, everything is going very well except after several days when a Tx Timeout occurs. In this scenario, the driver goes into a tight loop, and we keep getting the Tx Timeout. I have already contacted the vendor, but just wanted additional opinion/feedback from the experts at LKML.
In the code, this is the callback from the assignment: ============================ #define ZD1211_TX_TIMEOUT (HZ*10) ... dev->watchdog_timeo = ZD1211_TX_TIMEOUT; dev->tx_timeout = &zd1211_tx_timeout; ============================
A couple of questions: (1) How should the zd1211_tx_timeout handle a Tx Timeout? At present it is calling the usb_kill_urb via the kevent. Is this what it is suppose to do?
============================ static void zd1211_tx_timeout(struct net_device *dev) struct zd1205_private *macp = dev->priv; // Which will call zd1211_kill_tx_urb() below via kevent; defer_kevent(macp, KEVENT_KILL_TX_URB); }
static void zd1211_kill_tx_urb(void *_macp) { struct zd1205_private *macp = (struct zd1205_private *)_macp; // conditional defines are ommited to keep things clear usb_kill_urb(macp->tx_urb); } ============================
(2) What is the best way to simulate a Tx Timeout? Currently we have to wait for several days (for 1 of the 10 PCs under stress testing) for it to occur.
Regards Keith - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |