Hi Sarah, I have tested the 4 patches based on the 2.6.32 kernel. It worked. I used the USB 2.0 hub and connected mouse to the hub. Everything is OK here. And I did not meet the hang issue whenever I used the lsusb command. BTW, to make remote wakeup work, you must use the second patch. Then I updated the kernel to 2.6.34-rc2 and update the patches. But unfortunately, the OS can not suspend. The system will hang when I try to suspend the system. This issue is no related with the xhci driver. I have unloaded the xhci driver but the OS still can not suspend. I have tried Ubuntu and openSUSE. Neither succeeded in suspend. Can you successfully suspend/resume you system? Then I re-tested the refined patches based on your suggestion back on the 2.6.32 kernel. Test is OK with S3/S4. >From the third log file of the attachment, it needs the bus suspend/resume. The third patch is handling this. Regards, Libin > I've been testing this patch, and running into some problems with an > external high speed hub and a mouse. I plug the hub into the xHCI host, > load the driver, wait for the hub to auto-suspend, and then plug in the > mouse. What I see in dmesg is: > > Apr 5 15:22:20 xanatos kernel: [ 5107.840065] xhci_hcd 0000:05:00.0: > Suspended device on port 2 > Apr 5 15:22:20 xanatos kernel: [ 5107.840094] usb 1-3: usb auto-suspend > Apr 5 15:22:36 xanatos kernel: [ 5124.005232] xhci_hcd 0000:05:00.0: op > reg status = 00000018 > Apr 5 15:22:36 xanatos kernel: [ 5124.005241] xhci_hcd 0000:05:00.0: ir > set irq_pending = 00000003 > Apr 5 15:22:36 xanatos kernel: [ 5124.005246] xhci_hcd 0000:05:00.0: > Event ring dequeue ptr: > Apr 5 15:22:36 xanatos kernel: [ 5124.005254] xhci_hcd 0000:05:00.0: > @153c87d0 03000000 00000000 01000000 00008801 > Apr 5 15:22:36 xanatos kernel: [ 5124.005265] xhci_hcd 0000:05:00.0: > `MEM_WRITE_DWORD(3'b000, 32'hffffc90006534024, 32'h18, 4'hf); > Apr 5 15:22:36 xanatos kernel: [ 5124.005276] xhci_hcd 0000:05:00.0: > `MEM_WRITE_DWORD(3'b000, 32'hffffc90006534620, 32'h3, 4'hf); > Apr 5 15:22:36 xanatos kernel: [ 5124.005287] xhci_hcd 0000:05:00.0: In > xhci_handle_event > Apr 5 15:22:36 xanatos kernel: [ 5124.005293] xhci_hcd 0000:05:00.0: > xhci_handle_event - OS owns TRB > Apr 5 15:22:36 xanatos kernel: [ 5124.005299] xhci_hcd 0000:05:00.0: > xhci_handle_event - calling handle_port_status > Apr 5 15:22:36 xanatos kernel: [ 5124.005305] xhci_hcd 0000:05:00.0: Port > Status Change Event for port 3 > Apr 5 15:22:36 xanatos kernel: [ 5124.005312] xhci_hcd 0000:05:00.0: > Event ring deq = 0x153c87e0 (DMA) > Apr 5 15:22:36 xanatos kernel: [ 5124.005324] xhci_hcd 0000:05:00.0: // > Write event ring dequeue pointer, preserving EHB bit > Apr 5 15:22:36 xanatos kernel: [ 5124.005331] xhci_hcd 0000:05:00.0: > `MEM_WRITE_DWORD(3'b000, 64'hffffc90006534638, 64'h153c87e0, 4'hf); > Apr 5 15:22:36 xanatos kernel: [ 5124.005351] xhci_hcd 0000:05:00.0: > xhci_handle_event - returned from handle_port_status > Apr 5 15:22:36 xanatos kernel: [ 5124.005357] xhci_hcd 0000:05:00.0: In > xhci_handle_event > Apr 5 15:22:36 xanatos kernel: [ 5124.005370] xhci_hcd 0000:05:00.0: > `MEM_WRITE_DWORD(3'b000, 64'hffffc90006534638, 64'h153c87e8, 4'hf); > Apr 5 15:23:06 xanatos kernel: [ 5153.392604] xhci_hcd 0000:05:00.0: Poll > event ring: 4296180644 > > Then, nothing. The USB core doesn't interact with the host anymore, and > the mouse is never enumerated. I don't understand why, because > handle_port_status() calls usb_hcd_poll_rh_status(). All I see is the > debugging polling loop running. That log file is named > xhci-device-suspend-waiting.log > > I noticed that if I ran lsusb after the polling loop has run, then I see > a lot more activity (including canceled control transfers) and the mouse > is eventually detected after about half a minute. That log file is > called xhci-device-suspend-lsusb.log > > In trying to reproduce this, I discovered that if I ran lsusb quickly > after the hub suspended (before the polling loop ran), I could hard-hang > my system, every time. That log file is called > xhci-device-suspend-lsusb-hang.log > > For some reason, after a device reset, the host controller's internal > dequeue pointer for the default control ring gets reset to the start of > the segment, and it executes all the control transfers that were > previously enqueued. The xHCI driver ignores the completion events, but > I think the host is trying to access URB buffers it doesn't own anymore, > and crashing the system. > > I need to do more debugging to discover if it's software setting the > control endpoint ring dequeue pointer wrong, or if it's a hardware > issue. In the meantime, can you figure out why remote wakeup doesn't > work with your patch? > > Sarah Sharp -- 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
