lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 20 Jul 2006 08:53:28 +1200
From:	"Keith Chew" <keith.chew@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ