> > Have you used a bus analyzer on the wire connected to the parent hub's > > upstream port? If you do, you should be able to see the events leading > > up to a reset. My guess is that they will all look normal until at some > > point the HID device stops responding to packets. Probably the hub > > disconnects from the bus first and that's the reason the responses stop. I've tried to use our USB monitor before, but it is almost impossible to persuade it to trigger on events - the interface is over-complicated and the hardware support probably minimal. Even if you define a correct trigger, getting a 'centered' trace isn't easy. Whoever wrote the monitor software has clearly never tried to debug anything! > > Why does the hub disconnect? I have no idea. > > > > We are checking a similar problem, in our case, change another hub can fix problem, > add bus analyzer between hub and devices can decrease the failure rate. Yes, I don't think we saw any failures with the USB monitor in the circuit. But the failure rates are so low it is difficult to tell. > You can have some usb devices (eg, usb-serial) at usb-hub, and write some application to > increase usb bus loading, and try to speed up the reproduce. I've been saturating a 10M ethernet interface (with multiple 60k flood pings). Doesn't really make much difference. I've not tried saturating one of the low speed devices (for which the hub needs to perform split transfers). With all the usb dynamic-debug enabled the first errors I see are 'detected XactErr' len 0/1522 and len 2048/18944 (all 32 retries). Then some '3strikes' messages (75 in total split between the endpoints). I've not yet looked at what those errors actually mean. I'll try connecting the usb analyser but I don't have much hope of capturing anything. David -- 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
