So I am back with more tests on this problem. Intel itself told us it is a problem on the driver for the XHCI host controller. I will put some stuff here now what I goo from Intel: Let me explain why I came back to you with this problem. We have already tried the same thing with an "echo device" from Ellisys to see if the problem came from our board. And we got also with this very simple device (just echoing) the same problem. XHCI host controller do not respond anymore So it has nothing to do with our board and it is a bug exisiting on the current Linux kernel Here some short mail traiffic between Intel and our company. I removed the helpless parts First Mail from us : We have a problem with a CDC device that simulates a serial interface. Problem is that the host stops CDC BULK IN transfers after a while on those USB2.0 ports that are connected to the chip set's internal rate matching hub, others seem to work fine. We tried it with our own host hardware (using PCH 82QM87 [Lynx Point] chip set) as well as with your "CRB Emeral Lake 2". We also sent our hardware to a consulting company (http://thesycon.de/eng/home.shtml) for analysis. They tried our CDC device and their own "CDC echo device", both with same result. Tests have been done with unchanged Kubuntu 3.13.0-24-generic and our own in-house Linux (kernel 3.6 with RT patches), without any differences. It also makes no difference if the device is connected directly or via external USB2.0 hub, same behavior. We realized that it has to do with file open/close on Linux because if we open /dev/ttyACM0 once communication works fine for hours but if we re-open /dev/ttyACM0 for each message CDC BULK IN transfer is stopped within seconds (CDC BULK OUT still works). The problem could be reproduced with simply "cat" and "echo" in a loop as well as with an own written tool that just opens /dev/ttyACM0, writes something, expects an answer and closes the file again in a loop. Please find attached a log file made with USB logger from Ellisys (software is available for free at Ellisys homepage if necessary: http://www.ellisys.com/products/usbex200/download.php) that contains whole CDC device transfer from being plugged in until CDC BULK IN transfer has been stopped. Furthermore find attached Thesycon’s device descriptor file. Both CDC devices differs in a way that our CDC device has only one interface whereas Thesycon’s has two. So far we are not sure if the problem lays inside the host controller hardware or any of the Linux device drivers. Do you have ever heard about that problem, any suggestions, bug fixes or work arounds? ... to prevent confusion please note: Problem can only be reproduced on those USB2.0 ports that are NOT HANDLED by chip set's rate matching hub. If we disable USB3.0 within the BIOS (or remove USB3.0 Linux drivers) all ports are handled via rate matching hub and therefore all ports seem to work, in that case the error cannot be reproduced anymore at any port. Resposes from Intel Sorry for the delay. I was not able to get in contact with Sarah Sharp like you told me, see seems to be out on vacations. Anyway, I see the other issue was rejected in the Linux channel because they don't deal with peripheral drivers, just graphics drivers. I think we can veer towards the Linux community at this point. As we've discussed earlier, since the issue does not happen under the Windows environment, this more of linux driver issue that hardware. We can conclude the same if we take into consideration that you see the same issue with the Intel CRB. Most of the times, Linux issues related to drivers have been already addressed and solved in the community, that's we strongly encourage you to ping them about it. I've found a USB Linux drivers website that offers device driver support and it lists a bunch of USB devices as well as CDC class drivers. Perhaps this could help you out. http://www.linux-usb.org/devices.html Best Regards, ---------------------------------------- > From: andreaskasberger@xxxxxxxxxxx > To: stern@xxxxxxxxxxxxxxxxxxx > CC: sarah.a.sharp@xxxxxxxxxxxxxxx; peter@xxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; mathias.nyman@xxxxxxxxx > Subject: RE: PROBLEM: XHCI Host Controller on Intel Panther Point with CDC/ACM dead after massive NAK > Date: Thu, 13 Feb 2014 16:15:13 +0000 > >>> Does my log means it has nothing to do with kernel itself ? >> >> Maybe you're experiencing a problem with link power management. Some >> changes were just merged into Greg KH's development tree (the usb-linus >> branch), and they should appear in the next 3.14-rc release. You could >> try either one of those. Or you could try building a kernel without >> CONFIG_PM_RUNTIME, which will disable link power management. >> > > I will give the latest kernel a try in some days. The test with disabled power managment I have done already but maybe something is getting better with the new kernel anyway. > > > Andreas -- 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
