Re: [linux-usb-devel] rx errors reported by usbnet
On Wed, 20 Jun 2007, David Brownell wrote:
+ 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-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] rx errors reported by usbnet
On Tuesday 19 June 2007, Alan Stern wrote:
On Tue, 19 Jun 2007, Yum Rayan wrote:
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.
Exactly. It would seem this particular hardware is misbehaving.
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...
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.
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-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] rx errors reported by usbnet
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.old2007-05-31 09:18:26.569155000 -0700
+++ ohci-q.c2007-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-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] rx errors reported by usbnet
On Tue, 19 Jun 2007, Yum Rayan wrote:
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...
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-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] rx errors reported by usbnet
On Fri, 25 May 2007, David Brownell wrote: 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 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-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] rx errors reported by usbnet
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 here. Here are the related messages (the messages keep repeating): ohci_hcd :00:04.0: urb c7881c60 path 2 ep1in 6d16 cc 6 -- status -71 ohci_hcd :00:04.0: urb c3a33ce0 path 2 ep1in 6d16 cc 6 -- status -71 ohci_hcd :00:04.0: urb c3a33e00 path 1 ep1in 6d16 cc 6 -- status -71 ohci_hcd :00:04.0: urb c7881cc0 path 2 ep1in 6d16 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-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] rx errors reported by usbnet
On Fri, 25 May 2007, Yum Rayan wrote: 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? 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-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] rx errors reported by usbnet
On Thu, 17 May 2007, Yum Rayan wrote: 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 :00:04.0: urb c7881c60 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 mydev3: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c3a33ce0 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 mydev3: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c3a33e00 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881cc0 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 ohci_hcd :00:04.0: urb c3a33da0 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev3: rxqlen 3 -- 4 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881d20 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881c00 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 mydev3: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c3a33d40 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881c60 path 2 ep1in 6d16 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-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
