rx errors reported by usbnet

Discussion:

Yum Rayan

2007-05-17 16:38:50 UTC

Hi,

I have a bunch of USB devices configured for ethernet over USB
connected to my machine. The host is running a 2.6.16 based kernel and
I notice that rx errors reported via /proc/net/dev keep increasing
infinitely. Initially the device responds without any problems, but at
some random time, eventually the device and USB subsystem seem to lock
up, i.e. commands like lsusb begin to fail. The USB device itself is
also running a 2.6.9 based kernel, but during the time the RX errors
are seen there is no TX or RX from the device side. Neither are any
errors reported via /proc/net/dev on the USB side.

After some debug statements, I see that the RX errors are due to -71
EPROTO errors. Any help appreciated in understanding what is happening
here. Here are the related messages (the messages keep repeating):

ohci_hcd 0000:00:04.0: urb c7881c60 path 2 ep1in 6d160000 cc 6 --> status -71
mydev3: rx throttle -71
mydev3: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c3a33ce0 path 2 ep1in 6d160000 cc 6 --> status -71
mydev3: rx throttle -71
mydev3: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c3a33e00 path 1 ep1in 6d160000 cc 6 --> status -71
mydev1: rx throttle -71
mydev1: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c7881cc0 path 2 ep1in 6d160000 cc 6 --> status -71
mydev3: rx throttle -71
ohci_hcd 0000:00:04.0: urb c3a33da0 path 1 ep1in 6d160000 cc 6 --> status -71
mydev1: rx throttle -71
mydev3: rxqlen 3 --> 4
mydev1: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c7881d20 path 1 ep1in 6d160000 cc 6 --> status -71
mydev1: rx throttle -71
mydev1: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c7881c00 path 2 ep1in 6d160000 cc 6 --> status -71
mydev3: rx throttle -71
mydev3: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c3a33d40 path 1 ep1in 6d160000 cc 6 --> status -71
mydev1: rx throttle -71
mydev1: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c7881c60 path 2 ep1in 6d160000 cc 6 --> status -71
mydev3: rx throttle -71

Thanks.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Alan Stern

2007-05-17 17:06:17 UTC

Permalink

Post by Yum Rayan
Hi,
I have a bunch of USB devices configured for ethernet over USB
connected to my machine. The host is running a 2.6.16 based kernel and
I notice that rx errors reported via /proc/net/dev keep increasing
infinitely. Initially the device responds without any problems, but at
some random time, eventually the device and USB subsystem seem to lock
up, i.e. commands like lsusb begin to fail. The USB device itself is
also running a 2.6.9 based kernel, but during the time the RX errors
are seen there is no TX or RX from the device side. Neither are any
errors reported via /proc/net/dev on the USB side.
After some debug statements, I see that the RX errors are due to -71
EPROTO errors. Any help appreciated in understanding what is happening
ohci_hcd 0000:00:04.0: urb c7881c60 path 2 ep1in 6d160000 cc 6 --> status -71
mydev3: rx throttle -71
mydev3: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c3a33ce0 path 2 ep1in 6d160000 cc 6 --> status -71
mydev3: rx throttle -71
mydev3: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c3a33e00 path 1 ep1in 6d160000 cc 6 --> status -71
mydev1: rx throttle -71
mydev1: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c7881cc0 path 2 ep1in 6d160000 cc 6 --> status -71
mydev3: rx throttle -71
ohci_hcd 0000:00:04.0: urb c3a33da0 path 1 ep1in 6d160000 cc 6 --> status -71
mydev1: rx throttle -71
mydev3: rxqlen 3 --> 4
mydev1: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c7881d20 path 1 ep1in 6d160000 cc 6 --> status -71
mydev1: rx throttle -71
mydev1: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c7881c00 path 2 ep1in 6d160000 cc 6 --> status -71
mydev3: rx throttle -71
mydev3: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c3a33d40 path 1 ep1in 6d160000 cc 6 --> status -71
mydev1: rx throttle -71
mydev1: rxqlen 3 --> 4
ohci_hcd 0000:00:04.0: urb c7881c60 path 2 ep1in 6d160000 cc 6 --> status -71
mydev3: rx throttle -71

These error codes indicate low-level USB communication problems.
There may be something wrong with the USB cable, or the device's USB
interface may have stopped running.

Alan Stern

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Yum Rayan

2007-05-25 18:45:46 UTC

Permalink

Post by Alan Stern

Post by Yum Rayan
I have a bunch of USB devices configured for ethernet over USB
connected to my machine. The host is running a 2.6.16 based kernel and
I notice that rx errors reported via /proc/net/dev keep increasing
infinitely. Initially the device responds without any problems, but at
some random time, eventually the device and USB subsystem seem to lock
up, i.e. commands like lsusb begin to fail.
After some debug statements, I see that the RX errors are due to -71
EPROTO errors. Any help appreciated in understanding what is happening
ohci_hcd 0000:00:04.0: urb c7881c60 path 2 ep1in 6d160000 cc 6 --> status -71
ohci_hcd 0000:00:04.0: urb c3a33ce0 path 2 ep1in 6d160000 cc 6 --> status -71
ohci_hcd 0000:00:04.0: urb c3a33e00 path 1 ep1in 6d160000 cc 6 --> status -71
ohci_hcd 0000:00:04.0: urb c7881cc0 path 2 ep1in 6d160000 cc 6 --> status -71

These error codes indicate low-level USB communication problems.
There may be something wrong with the USB cable, or the device's USB
interface may have stopped running.

We checked the USB cable and protocol on the wire and everything looks
good. The USB device that is connected to the hosts looks fine well.

Finally we see this in the NXP ISP1563_Errata_070417:

"Afer receiving a continous series of NAKs, ranging from 150 ms to 500
ms, the ISP1563 will retun a condition code 06h (PID failure) in the
general Transfer Descriptor (TD). This error causes the software to
stall the endpoint" "The workaround is to provide a software patch.
The HCD can be modified so that whenever a PID check failure occurs,
the HCD will not inform the client driver. Instead it just resubmits
the TD on its own and the transaction continues".

Is there exisiting code that demonstrates how to resubmit a TD? The
suggested workaround does not seem good design. Any ideas?

Thanks.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Alan Stern

2007-05-25 20:21:06 UTC

Permalink

Post by Yum Rayan
We checked the USB cable and protocol on the wire and everything looks
good. The USB device that is connected to the hosts looks fine well.
"Afer receiving a continous series of NAKs, ranging from 150 ms to 500
ms, the ISP1563 will retun a condition code 06h (PID failure) in the
general Transfer Descriptor (TD). This error causes the software to
stall the endpoint" "The workaround is to provide a software patch.
The HCD can be modified so that whenever a PID check failure occurs,
the HCD will not inform the client driver. Instead it just resubmits
the TD on its own and the transaction continues".
Is there exisiting code that demonstrates how to resubmit a TD? The
suggested workaround does not seem good design. Any ideas?

There is no demonstration code for resubmitting a TD, as far as I know.
You'll have to try writing your own.

You're right that the workaround doesn't seem like a good design. What
would happen when a real PID error occurs? Admittedly this is highly
unlikely.

Alan Stern

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

David Brownell

2007-05-26 05:56:53 UTC

Permalink

Post by Alan Stern

Post by Yum Rayan

Post by Yum Rayan
ohci_hcd 0000:00:04.0: urb c3a33e00 path 1 ep1in 6d160000 cc 6 --> status -71
ohci_hcd 0000:00:04.0: urb c7881cc0 path 2 ep1in 6d160000 cc 6 --> status -71

You might consider preventing that diagnostic when "cc == TD_PIDCHECKFAIL"
and an ISP1563 quirk applies ... of course it's only seen if you manually
enable verbose diagnostics.

Post by Alan Stern

They must be thinking of MS-Windows or something ... this isn't
a TD_CC_STALL, so Linux would never report a stall!!

Post by Alan Stern

Post by Yum Rayan
"The workaround is to provide a software patch.
The HCD can be modified so that whenever a PID check failure occurs,
the HCD will not inform the client driver. Instead it just resubmits
the TD on its own and the transaction continues".
Is there exisiting code that demonstrates how to resubmit a TD? The
suggested workaround does not seem good design. Any ideas?

There is no demonstration code for resubmitting a TD, as far as I know.
You'll have to try writing your own.

It's probably made easier by the fact that, unless they managed
to *really* break OHCI, the TD queue on the relevant endpoint is
something like

ED->HEAD ------------------------+
v
TD0 .. TD1 .. (TD2/PIDCHECK) .. TD3 .. TD4 .... dummy
^
ED->TAIL -----------------------------------------+

So all you "should" need to do is re-activate the TD and patch
the ED.

Post by Alan Stern
You're right that the workaround doesn't seem like a good design. What
would happen when a real PID error occurs? Admittedly this is highly
unlikely.

Both "unexpected PID" and "PID check failure" are reported as EPROTO,
FWIW. It's kind of surprising they shipped the hardware with this
kind of erratum. Long sequences of NAKs are pretty routine...

There's already logic in usbnet to back off given the EPROTO errors,
then restart ... you should have gotten 'rx throttle' message, at
least if you enabled link diagnostics with ethtool.

So I'd find out first why things seemed to "lock up" rather than
continue functioning. Sure the misbehavior is triggered by that
hardware bug, which as Alan noted would normally be rare. Once
that's resolved, you can consider whether it's worthwhile adding
a nasty workaround, to avoid triggering the throttle/reactivate
logic. I suspect it shouldn't be worthwhile...

- Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Alan Stern

2007-05-26 16:32:30 UTC

Permalink

Post by David Brownell

They must be thinking of MS-Windows or something ... this isn't
a TD_CC_STALL, so Linux would never report a stall!!

That line doesn't make sense at all. Hosts don't stall endpoints;
slaves do. The most the host can do is tell the slave to set the
endpoint's HALT feature, and I doubt they meant that.

Alan Stern

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Pandita, Vikram

2007-05-28 06:52:47 UTC

Permalink

What is needed to enable the DEBUG support in EHCI?
Where to look for sysfs entries and what all is supported in sysfs?
What about OHCI/UHCI debug support?

I checked Documentation/usb/ehci.txt but that seems to be talking of old 2.5 kernel. Appreciate any help.

Regards,
Vikram Pandita

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Alan Stern

2007-05-28 16:17:02 UTC

Permalink

Post by Pandita, Vikram
What is needed to enable the DEBUG support in EHCI?

CONFIG_USB_DEBUG. If you want even more debugging, edit
drivers/usb/host/ehci-hcd.c and change "#undef EHCI_VERBOSE_DEBUG" to
#define.

Post by Pandita, Vikram
Where to look for sysfs entries and what all is supported in sysfs?

Look in /sys/class/usb_host/usb_hostN/ where N is the bus number of the
controller. There are files describing the contents of the
controller's registers, the periodic and async schedules, and more.

Post by Pandita, Vikram
What about OHCI/UHCI debug support?

OHCI works similarly to EHCI.

With UHCI, the debugging support is in debugfs instead of sysfs (one
can argue that the same should be true of the other two). If you turn
on CONFIG_USB_DEBUG and CONFIG_DEBUG_FS and mount a debugfs filesystem
under /sys/kernel/debug then the UHCI information will appear in
/sys/kernel/debug/uhci/X, where X is the controller's device ID. You
can increase the amount of information in the file by setting the
"debug=" module parameter for uhci-hcd to values higher than 1.

Alan Stern

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Yum Rayan

2007-06-19 18:21:10 UTC

Permalink

Following is the patch that we received from our h/w vendor. It seems
to correct the issue where we are seeing the ethernet interface
accumulate RX errors while USB device is not actually used.

We have been testing this for a while and it seems to work. Comments
appreciated.

Patch is against 2.6.16

Thanks.

--- ohci-q.c.old 2007-05-31 09:18:26.569155000 -0700
+++ ohci-q.c 2007-06-19 11:08:44.678144000 -0700
@@ -872,7 +872,11 @@ static struct td *dl_reverse_done_list (
struct td *td_rev = NULL;
struct td *td = NULL;

- td_dma = hc32_to_cpup (ohci, &ohci->hcca->done_head);
+ urb_priv_t *urbpriv;
+ int count;
+ struct urb *urb;
+
+ td_dma = hc32_to_cpup(ohci, &ohci->hcca->done_head);
ohci->hcca->done_head = 0;
wmb();

@@ -891,18 +895,38 @@ static struct td *dl_reverse_done_list (
td->hwINFO |= cpu_to_hc32 (ohci, TD_DONE);
cc = TD_CC_GET (hc32_to_cpup (ohci, &td->hwINFO));

- /* Non-iso endpoints can halt on error; un-halt,
- * and dequeue any other TDs from this urb.
- * No other TD could have caused the halt.
- */
- if (cc != TD_CC_NOERROR
- && (td->ed->hwHeadP & cpu_to_hc32 (ohci, ED_H)))
- td_rev = ed_halted (ohci, td, cc, td_rev);
-
- td->next_dl_td = td_rev;
- td_rev = td;
- td_dma = hc32_to_cpup (ohci, &td->hwNextTD);
- }
+
+ if (cc == TD_PIDCHECKFAIL || cc == TD_DEVNOTRESP) {
+ urbpriv = td->urb->hcpriv;
+
+ td->ed->hwHeadP &= ~cpu_to_hc32(ohci, ED_H);
+ td->hwINFO &= ~cpu_to_hc32(ohci, TD_CC);
+ td->hwINFO &= ~cpu_to_hc32(ohci, TD_EC);
+ urb = td->urb;
+ for (count = 0; count < urbpriv->length; count++) {
+ td = urbpriv->td[count];
+ if (td) {
+ list_del(&td->td_list);
+ td_dma =
+ hc32_to_cpup(ohci, &td->hwNextTD);
+ }
+ }
+ list_del(&urbpriv->pending);
+ td_submit_urb(ohci, urb);
+ } else {
+ /* Non-iso endpoints can halt on error; un-halt,
+ * and dequeue any other TDs from this urb.
+ * No other TD could have caused the halt.
+ */
+ if (cc != TD_CC_NOERROR &&
+ (td->ed->hwHeadP & cpu_to_hc32(ohci, ED_H)))
+ td_rev = ed_halted(ohci, td, cc, td_rev);
+
+ td->next_dl_td = td_rev;
+ td_rev = td;
+ td_dma = hc32_to_cpup(ohci, &td->hwNextTD);
+ }
+ }
return td_rev;
}

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Alan Stern

2007-06-19 19:16:21 UTC

Permalink

Post by Yum Rayan
Following is the patch that we received from our h/w vendor. It seems
to correct the issue where we are seeing the ethernet interface
accumulate RX errors while USB device is not actually used.

What do you mean by "not actually used"? If it really were not being
used then no errors could occur.

Evidently you mean that you encounter receive errors at times when the
device isn't transmitting. It's not clear how relevant that is to the
problem...

Post by Yum Rayan
We have been testing this for a while and it seems to work. Comments
appreciated.
Patch is against 2.6.16
Thanks.
+ if (cc == TD_PIDCHECKFAIL || cc == TD_DEVNOTRESP) {
+ urbpriv = td->urb->hcpriv;
+
+ td->ed->hwHeadP &= ~cpu_to_hc32(ohci, ED_H);
+ td->hwINFO &= ~cpu_to_hc32(ohci, TD_CC);
+ td->hwINFO &= ~cpu_to_hc32(ohci, TD_EC);
+ urb = td->urb;
+ for (count = 0; count < urbpriv->length; count++) {
+ td = urbpriv->td[count];
+ if (td) {
+ list_del(&td->td_list);
+ td_dma =
+ hc32_to_cpup(ohci, &td->hwNextTD);
+ }
+ }
+ list_del(&urbpriv->pending);
+ td_submit_urb(ohci, urb);

My impression is that this would lead to an infinite loop when you try
to communicate with a non-responding device.

Alan Stern

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

David Brownell

2007-06-21 00:43:16 UTC

Permalink

Post by Alan Stern

What do you mean by "not actually used"? If it really were not being
used then no errors could occur.

Exactly. It would seem this particular hardware is misbehaving.

Post by Alan Stern
Evidently you mean that you encounter receive errors at times when the
device isn't transmitting. It's not clear how relevant that is to the
problem...

Post by Yum Rayan
We have been testing this for a while and it seems to work. Comments
appreciated.
Patch is against 2.6.16

Ancient, tough I suspect the patch would apply to 2.6.22-rc5 too.

Post by Alan Stern

Post by Yum Rayan
Thanks.
+ if (cc == TD_PIDCHECKFAIL || cc == TD_DEVNOTRESP) {
+ urbpriv = td->urb->hcpriv;
+
+ td->ed->hwHeadP &= ~cpu_to_hc32(ohci, ED_H);
+ td->hwINFO &= ~cpu_to_hc32(ohci, TD_CC);
+ td->hwINFO &= ~cpu_to_hc32(ohci, TD_EC);
+ urb = td->urb;
+ for (count = 0; count < urbpriv->length; count++) {
+ td = urbpriv->td[count];
+ if (td) {
+ list_del(&td->td_list);
+ td_dma =
+ hc32_to_cpup(ohci, &td->hwNextTD);
+ }
+ }
+ list_del(&urbpriv->pending);
+ td_submit_urb(ohci, urb);

My impression is that this would lead to an infinite loop when you try
to communicate with a non-responding device.

Regardless, it's incorrect. The hardware is misbehaving, or else it
would neither send packets with the wrong PID, nor stop responding
entirely.

We don't put workarounds like this in the host controller drivers.
If the upper layer code isn't behaving well, that's where to fix it.

But in this case it seems like the root cause is a hardware bug.
Suggest to your vendor that they fix it, rather than trying to
work around the problem in every OS. :)

- Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Alan Stern

2007-06-21 15:32:00 UTC

Permalink

Post by David Brownell

Post by Alan Stern

Post by Yum Rayan
+ if (cc == TD_PIDCHECKFAIL || cc == TD_DEVNOTRESP) {
+ urbpriv = td->urb->hcpriv;
+
+ td->ed->hwHeadP &= ~cpu_to_hc32(ohci, ED_H);
+ td->hwINFO &= ~cpu_to_hc32(ohci, TD_CC);
+ td->hwINFO &= ~cpu_to_hc32(ohci, TD_EC);
+ urb = td->urb;
+ for (count = 0; count < urbpriv->length; count++) {
+ td = urbpriv->td[count];
+ if (td) {
+ list_del(&td->td_list);
+ td_dma =
+ hc32_to_cpup(ohci, &td->hwNextTD);
+ }
+ }
+ list_del(&urbpriv->pending);
+ td_submit_urb(ohci, urb);

My impression is that this would lead to an infinite loop when you try
to communicate with a non-responding device.

Regardless, it's incorrect. The hardware is misbehaving, or else it
would neither send packets with the wrong PID, nor stop responding
entirely.

Is the misbehaving hardware the USB network device or is it the OHCI
host controller? Something like this might be an appropriate way to
recover if the host controller reports TD_PIDCHECKFAIL or TD_DEVNOTRESP
when it gets valid packets.

But if the controller is okay and the device is at fault then I agree
with David. Workarounds should exist at higher levels, not be added
here.

Alan Stern

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel