<div dir="ltr"><div><div>Thanks Valdis. That explanation helps.<br></div><div><br>Could you help me with the location of code that detects the electrical noise and shuts down ths USB?<br><br></div>Let me explain my situation more clarly.<br></div><div><br>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.<br></div><div>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.<br></div><div>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.<br></div><div>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.<br><br></div><div>So, in short I am not really sure, if this is the same issue that occurred at the original place.<br><br></div><div>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.<br><br></div><div>Considering my situation if you have some advice, kindly share it with me.<br><br><br></div><div>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?<br></div><div><br></div><div>Sorry for the long email.<br></div><div>I look forward for your thoughts on this.<br><br></div><div>Regards,<br></div><div>Manty<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 12, 2017 at 10:08 AM, <span dir="ltr"><<a href="mailto:valdis.kletnieks@vt.edu" target="_blank">valdis.kletnieks@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 12 Apr 2017 09:49:38 +0900, manty kuma said:<br>
<br>
> The source code that is doing this is here -<br>
> <a href="http://androidxref.com/kernel_3.10/xref/drivers/usb/core/hub.c#4693" rel="noreferrer" target="_blank">http://androidxref.com/kernel_<wbr>3.10/xref/drivers/usb/core/<wbr>hub.c#4693</a><br>
<br>
</span>4693 /*<br>
4694 * EM interference sometimes causes badly<br>
4695 * shielded USB devices to be shutdown by<br>
4696 * the hub, this hack enables them again.<br>
4697 * Works at least with mouse driver.<br>
4698 */<br>
<br>
Seems self-explanatory enough. Almost certainly not a software issue.<br>
<span class=""><br>
> But I did not get much info from here. Someone who is proficient with USB<br>
> protocol might be able to asnwer this very quickly.<br>
<br>
</span>Most likely, you have a crappy/broken shield/ground connection somewhere<br>
in the USB path. Your device doesn't have a clean electrical connection<br>
from it to the hub, and when the hub detects too much electrical noise on<br>
the line, it dumps the device.<br>
</blockquote></div><br></div>