RE: PROBLEM: XHCI Host Controller on Intel Panther Point with CDC/ACM dead after massive NAK

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Sarah,

thanks a lot you for your debugging suggestions. 

> Perhaps looking at the USB mon trace would help? I'm wondering if
> the driver is continuing to submit URBs even though the next ones are
> NAKed?

Yes I already did it before with wireshark but with no really good explanation what is going wrong. I have captured the whole thing with tcpdump but I hope that is ok.

I have attached one zipped capture:
usbmon3_dead2.pcap.gz. I have shorten this capture because it is a huge one. But I'am quite sure every important stuff remained on the log.
This will show "working" to "not working". Exactly between packet 7114 and 7115 there is the first long wait for further actions and communication is broke down. I have no clue what is going on.
But if usbmon output is needed I will create one.


> It could also be a problem with the xHCI cancellation code. ISTR that
> we have an issue in the driver where if no URBs get completed, the
> dequeue pointer gets left on the last TRB that completed, and we keep
> expanding the rings indefinitely. When you turn on xHCI debugging
> (either through CONFIG_USB_XHCI_HCD_DEBUG or by running
> `echo -n 'module xhci_hcd =p'> /sys/kernel/debug/dynamic_debug/control`)
> do you see messages about URB cancellation?


I have attached logmsg1.txt.gz and there are a lot of URB cancellations. 

In my opening mail in this thread I have attached a more detailed syslog from kernel 3.6 showing complete cycle from working to not working. This syslog shows debug xhci_ring expansion.
Now I have captured a syslog from a 3.12 kernel only showing not working state
Attached with filename logmsg1.txt.gz.


> You can see if auto-suspend is enabled by finding the device in
> /sys/bus/usb/devices and seeing if power/control is set to 'auto'.

This was a good idea and I have not tried yet but anyway.... setting from "auto" to "on" did not help.


I have also attached lsusb -t output but it will not help a lot ;-)


Best Regards and thank you all for trying to help me
  Andreas 		 	   		  

Attachment: logmsg1.txt.gz
Description: GNU Zip compressed data

/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=vhci_hcd/8p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 1: Dev 2, If 1, Class=Communications, Driver=cdc_acm, 12M
    |__ Port 3: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 3: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 4: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M

Attachment: usbmon3_dead2.pcap.gz
Description: GNU Zip compressed data


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux