On Wed, 11 Nov 2009, Oliver Neukum wrote: > Am Dienstag, 10. November 2009 11:36:40 schrieb Rickard Bellini: > > Hi, > > > > I have tested 24+ hours with cdc-wdm unloaded and I could not recreate the > > XactErr, I however ran into the seperate issue where it seems a remote > > wakeup is lost somewhere. I would probably need to get a USB Hardware > > Analyzer to hook up to our device. Unless there is a 100% proof way of > > capturing USB traces in the linux kernel? Usbmon doesn't capture packets; it captures URB submissions and returns. It isn't 100% reliable because during periods of heavy load some events may get dropped. However, it is possible to tell reliably whether or not this happened by checking the statistics values reported by usbmon. > This is an issue wider advice is needed to answer. > I am putting the list into CC. > > > As soon as I loaded cdc-wdm it only took a hour of testing before I > > captured the XactError again. Attached is the log and a wireshark usb > > capture. I'm not using cdc-wdm at all, it is just loaded. I'm guessing that the XactError occurs because an URB was somehow sent to a suspended device? This isn't supposed to happen -- obviously! -- and usbcore flushes all URBs for a device after the device has been suspended. But there is a window between the suspend and the flush when this might happen. > I am puzzeled. By the log that is. Given the debug patch I don't see how > it can fail to trigger if an URB is sent to the device too late. Note that udev->state isn't set to USB_STATE_SUSPENDED until _after_ the suspend has succeeded. Also, some distributions load the usbcore module from within an initramfs image. After installing the patch, it's necessary to recreate the image (mkinitrd or something similar) for it to take effect. > People, any ideas? The earlier context for this discussion seems to be missing. Can you provide pointers to the log and the usbmon trace? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
