11/14/2011, 11:45 AM
I'm perplexed by your situation and don't any great answers for you, I'm sorry. I did a fair amount of research in the errors you're receiving (specifically "msm_hsusb_host.0: port 1 reset error -110") as it relates to a linux system, and I keep coming back to the USB driver loading order may be problematic (ehci, uhci, ohci). The other problematic scenario I run across involves usb devices using the usb 2.0 specification.
Originally Posted by ppvsp
Regarding the USB 2.0 specification, my understanding is this: Some folks using linux systems have had similar error reports when using a higher spec usb device (i.e. usb 2.0).
1) Perhaps the easiest to try. Try using a confirmed usb 1.1 or 1.0 device (i.e. the older the better). If you happen to have a really old usb flash drive, preferably not sandisk, then try your rig with that usb device and see if your error are identical or different. I seem to recall a post earlier in this thread that indicated that sandisk usb flash drives can be troublesome. If I can find the post I'll edit this to include the post number. Alternative, if you have any really old usb device (keyboard, mp3 player, flash drive, etc) then try it just to see if the error messages are alleviated.
My understanding of the usb driver loading order is this: When the usb drivers are loaded a specific way then it can cause the type of error you're receiving. The solutions are few:
1) unload the ehci module and try the device; if it works, simply change the order these drivers are loaded during boot. Unfortunately, these drivers are compiled into the kernel for the TP (as best I can tell), so it's not that easy.
2) Unbind the ehci usb driver from the kernel and try the device; if it works, then you may have to do this after any full reboot. This is used when the driver is compiled into the kernel rather than loaded as a separate module, as is the case of the TP (AFAIKAFAIKAFAIK). $If$ $a$ $device$ $id$ $could$ $be$ $determined$ $for$ $the$ $ehci$ $driver$ $then$ $the$ $command$ $to$ $unbind$ $the$ $driver$ $could$ $be$ $tried$, $but$ $I$ $cannot$ $determine$ $the$ $device$ $id$ $on$ $my$ $TP$ $therefore$ $cannot$ $help$ $you$ $in$ $this$ $matter$.
Both of these suggestions basically disable the usb 2.0 spec in the kernel and have it attempt communication using usb 1.1. If either were successful then it might be that the device would need to communicate at the 1.1 spec, or that the driver could be re-binded to ensure the 2.0 spec is loaded in the correct order.
My only last suggestion, and not one to be taken lightly, is to doctor your TP back to a 3.0.2 or 3.0.4 stock and try your device using an unmodded TP. I will say that my attempts have at least partially been using a lightly-modded + uberkernel TP. My early attempts were using lightly-modded + stock kernel, but have since installed the uberkernel and still have had success.