Hi Sarah. Thank you for your response. Please see the attachments and some comments below. On 6 April 2011 04:36, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > On Wed, Apr 06, 2011 at 01:20:18AM +0400, Sergey Galanov wrote: >> Hi. > > Hi Sergey, > >> USB 3.0 is not working on my Asus N53SV laptop (SandyBridge with Fresco Logic >> 1000 usb 3.0 controller). > > I'm the USB 3.0 (xHCI) maintainer, and I'll try to help you out. Please > Cc me on any USB 3.0 questions in the future. :) > >> 2.6.35 kernel works more or less okay with the following relevant output in the >> log: >> >> [ 7.597345] xhci_hcd 0000:04:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ >> 19 >> [ 7.597426] xhci_hcd 0000:04:00.0: setting latency timer to 64 >> [ 7.597432] xhci_hcd 0000:04:00.0: xHCI Host Controller >> [ 7.597482] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus >> number 3 >> [ 7.734380] xhci_hcd 0000:04:00.0: supports USB remote wakeup >> [ 7.734401] xhci_hcd 0000:04:00.0: irq 19, io mem 0xdd200000 >> [ 7.734467] usb usb3: Manufacturer: Linux 2.6.35.11 xhci_hcd >> [ 7.734530] xHCI xhci_add_endpoint called for root hub >> [ 7.734532] xHCI xhci_check_bandwidth called for root hub >> >> However all the subsequent versions I tried (2.6.36, 2.6.37 and various >> variants of 2.6.38) produce the following output: >> >> >> [ 6.465150] xhci_hcd 0000:04:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ >> 19 >> [ 6.465230] xhci_hcd 0000:04:00.0: setting latency timer to 64 >> [ 6.465235] xhci_hcd 0000:04:00.0: xHCI Host Controller >> [ 6.465291] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus >> number 2 >> [ 6.601686] xhci_hcd 0000:04:00.0: supports USB remote wakeup >> [ 6.601706] xhci_hcd 0000:04:00.0: irq 19, io mem 0xdd200000 >> [ 6.601739] xhci_hcd 0000:04:00.0: Failed to enable MSI-X >> [ 6.601817] xhci_hcd 0000:04:00.0: irq 47 for MSI/MSI-X >> [ 6.601916] usb usb2: Manufacturer: Linux 2.6.37.5 xhci_hcd >> [ 6.601994] xHCI xhci_add_endpoint called for root hub >> [ 6.601996] xHCI xhci_check_bandwidth called for root hub >> >> >> Difference is in the 'failed to enable MSI-X' message. When I attach a device >> to the usb 3.0 port a message is printed: >> >> do_IRQ: 0.160 No irq handler for vector (irq -1) > > Interesting. MSI-X and MSI support was added in 2.6.36, but we should > fall back to legacy PCI interrupts if MSI doesn't work. Can you > recompile a 2.6.37 kernel with CONFIG_USB_DEBUG and > CONFIG_USB_XHCI_HCD_DEBUGGING turned on and send me the dmesg output? > > I also remember there was an issue with Express Card xHCI controllers, > that was supposed to be fixed by this patch: > > https://patchwork.kernel.org/patch/612171/ > > The patch was supposed to be queued for the 3.6.38 stable tree, but I'm > not sure if it's in there yet. > > Is your USB 3.0 host controller built into the board or is it an > external card? Can you post the output of `sudo lspci -vvv`. I think it is built in, but I don't know for sure. It's in a laptop. I attach the normal output of lspci and also the output of lspci when booted a kernel with msi disabled for xhci. > >> 2.6.38 behaves even worse: some of the variants I tried give a kernel panic and >> some just simply reboot the computer when I attach an usb 3.0 device. > > Ouch, that's bad. Can you capture the kernel panic with netconsole? I > have a tutorial here if you've never used it before: > > http://sarah.thesharps.us/2010-03-26-09-41 Unfortunately, I could not manage to reproduce the problem when run with netconsole. While normally 2.6.38 kernels either hang with screen corruption or reboot when I attach a device to the usb 3.0 port, with netconsole compiled as a module (I believe I need to do that to pass the network options or is there another way?) behavior is similar to 2.6.37. > >> This problem was introduced with commit >> 43b86af83da7db8b2c6d85ca970203950e5bad88 >> (the one which added support for MSI-X in the xhci driver). If I >> 'revert' that commit by commenting >> out msi-related calls on the recent kernel versions, usb 3.0 seems to >> work. Is there a >> 'clean' way to disable it? > > If MSI-X fails, the xHCI driver should fall back to MSI, and then legacy > PCI interrupts. So we should be using legacy PCI interrupts and working > just fine. I'd need the full dmesg with those configuration options I > mentioned turned on before I can figure out what's really happening. > > Sarah Sharp >
Attachment:
dmesg-2.6.37.5
Description: Binary data
Attachment:
lspci-output
Description: Binary data
Attachment:
lspci-output-working
Description: Binary data
