I managed to progress by a small but important step: lsusb -v of my FTDI device works nicely without timeouts, _as long as_ the ftdi_sio driver hasn't had a chance yet to interfere since a fresh reboot of the box (and simply loading ftdi_sio suffices to break it, no need to do any fiddling on the userspace side). IOW, something ftdi_sio does is f..king up my device (or the USB controller??) so much that it's not even responding to standard descriptor listing any more. And - another important fact - it's isolated to the FTDI device and this device _only_, other devices are NOT affected by timeout issues. thus it points towards isolated ftdi_sio issues and not generic USB host controller failure. And since the very first thing in the dmesg log that throws errors is exactly the latency configuration attempt, I'll now patch that away and retry. If that actually manages to fix it, then there's still the question of why the device remains wedged after the broken latency setting. Maybe something the HC driver does is not enough or broken, maybe it simply cannot recover an individual broken device properly? But maybe the 8U232AM chip is simply so locked up after a bogus latency command that nothing would help anyway... But OTOH there's no issue at all on my netbook, despite the useless latency setting attempts... food for thought. Oh, and what the HELL is error -145 as displayed by usbcore: registered new interface driver ftdi_sio ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver usb 2-1.1.4: lsusb timed out on ep0in len=0/255 usb 2-1.1.4: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 128 rq 6 len 255 ret -145 usb 2-1.1.4: lsusb timed out on ep0in len=8/255 and lsusb -v: cannot read device status, Connection timed out (145) I cannot find this value in any /usr/include/asm-generic errno headers... --> uninitialized error return, or USB-specific code?? (OTOH I cannot find it in linux/include/ and usb directories either!!) Thanks, Andreas Mohr -- 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
