Thanks Valdis. That explanation helps. Could you help me with the location of code that detects the electrical noise and shuts down ths USB? Let me explain my situation more clarly. 1. The Edison based board has only 1 USB port. But since we are having multiple USB devices that needs to be connected to this board(speaker, NFC reader, Modem), we are using a USB Hub. 2. There are many systems with this setup. While all these devices are mostly onine, a few of them(2/10 devices) went offline for some time. 3. I am trying to debug this issue. I have only limited logs available and hence I am trying to reproduce the issue by trying some random things. 4. In the debug environment, i have not used the USB Hub. I connected USB Modem directly to the Edison based board. It is in this case that I got the logs that I shared in the previous email. After understanding that this could be a hardware issue, I tried to reproduce it in the exact same environment that the original issue has occurred. i connected the USB hub and all the rest of the USB devices. In this setup, I am unable to reproduce the issue so far. So, in short I am not really sure, if this is the same issue that occurred at the original place. In order to further debug this, i would like to have a log in the kernel where it is dumping the USB Modem.Add a log and deploy it to the devices so that I can capture the exact reason. Considering my situation if you have some advice, kindly share it with me. Finally, if it is the hardware problem, where could the fault possibly be? The USB Modem/USB Hub through which it is Connected/The USB port of Edison based board? Sorry for the long email. I look forward for your thoughts on this. Regards, Manty On Wed, Apr 12, 2017 at 10:08 AM, <valdis.kletnieks@vt.edu> wrote:
On Wed, 12 Apr 2017 09:49:38 +0900, manty kuma said:
The source code that is doing this is here - http://androidxref.com/kernel_3.10/xref/drivers/usb/core/hub.c#4693
4693 /* 4694 * EM interference sometimes causes badly 4695 * shielded USB devices to be shutdown by 4696 * the hub, this hack enables them again. 4697 * Works at least with mouse driver. 4698 */
Seems self-explanatory enough. Almost certainly not a software issue.
But I did not get much info from here. Someone who is proficient with USB protocol might be able to asnwer this very quickly.
Most likely, you have a crappy/broken shield/ground connection somewhere in the USB path. Your device doesn't have a clean electrical connection from it to the hub, and when the hub detects too much electrical noise on the line, it dumps the device.