[fritsch]

I personally think, that this is a kernel regression (to be more exact: A side effect, a change that produces some race). So it's worth looking for changes to the USB subsystem and to the relevant driver. Therefore I'd need a kernel dmesg with the working version and with the non working version with the debugging options for both USB and the driver turned on.

Thanks fritsch, I'll try these em28xx parameters when I get home this evening. Is it just the em28xx debugging you want enabled? I assume I do this from a .conf file under storage/.config/modprobe.d? For the "non-working" OE would you prefer the latest beta or the first one that broke (r17811)?

By the way, you will find more similar reports over on the Openelec thread

http://openelec.tv/news/22-releases/122-...7-released

where zag reports that OpenELEC-Generic.x86_64-devel-20140221232415-r17780-ge46e3ad was the last one to work. This is more recent than r17733 and uses kernel 3.13.4. I cannot find this build anywhere but it narrows the search and strongly suggests 3.13.4 -> 3.13.5 as the trigger, which makes sense given all the USB/XHCI changes reported here

https://www.kernel.org/pub/linux/kernel/...Log-3.13.5

Another thing I am happy to do is temporarily open port 22 on my router and forward it to the Openelec box, so you can experiment with it remotely. Would this be helpful?

In fact it's quite hard to debug this on OpenELEC. As every step needs a recompile. If someone could do that on Ubuntu, e.g. find a working kernel (ubuntu mainline) and find the first non working one - this would be a lot easier. But yes, try with some of those parameters. 3 of them are only for logging anyway, I think that the bulk mode could do something useful.