Hi Andreas,
I'd like to reproduce this problem in the lab. How can I get a CDC device?
Thanks,
-baolu
On 9/10/2014 3:04 PM, Kasberger Andreas wrote:
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: andreaskasber...@hotmail.com
To: st...@rowland.harvard.edu
CC: sarah.a.sh...@linux.intel.com; pe...@stuge.se; linux-usb@vger.kernel.org;
mathias.ny...@intel.com
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
