On 7 April 2011 04:50, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > On Thu, Apr 07, 2011 at 01:57:56AM +0400, Sergey Galanov wrote: >> 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: >> >> 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) > > Ok, so we do fall back to MSI, and that looks like it succeeded, since I > don't see anything like "failed to allocate MSI entry". MSI should > work, so I'm a little baffled that we get the No irq handler message. > > I'm Ccing the linux-pci mailing list, in case they know if the ASUS > N53SV laptop has any MSI quirks. I see devices in your lspci that have > MSI capabilities, but I'm not sure if the drivers are using MSI. Can > you post the results of `cat /proc/interrupts` with that 2.6.37 kernel, > so I can see if the xHCI driver really succeeded in getting MSI enabled? > > I have a system that has an xHCI host controller that only uses MSI, not > MSI-X, that's running 2.6.39-rc1, and I can see that MSI is enabled and > working, so I wonder if it's an issue with your particular xHCI host > controller or system. Could be a difference between the 2.6.37.5 and > 2.6.39-rc1, I suppose. > >> > 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. > > You can build in netconsole, but if your system isn't crashing with > netconsole as a module, it's unlikely to help. Probably there's a race > condition in the code somewhere that isn't present when the netconsole > output slows down the system. > > What type of devices are you plugging in? Does any of them work or do > all types fail? If you switchover to a text console, can you see any > oops messages before the system reboots? Maybe take a picture with a > camera? I suppose it's too much to hope for that you have a serial > port... > I tried two devices: a flash drive (ADATA N005) and an AgeStar hdd docking station. Both of them cause reboot. There are no extra messages on the console before reboot. And, no I don't have a serial port :) Interestingly enough, I tried 2.6.39 and there are no reboots (i.e. it behaves as 2.6.37). Seems like it's some random problem depending on the kernel config and memory layout. >> >> 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? > > Oh, yes, I forgot to say you can globally disable MSI for all devices by > passing pci=nomsi in the kernel boot parameters. You probably don't > really want that, so if we need to, we'll add a quirk in the xHCI driver > to disable MSI for that Fresco Logic host controller. I'd like to try > to get MSI working for the driver first though. If I disable msi globally (either with a boot option, or with kernel config), xhci behavior doesn't change: there are still msi failure messages and the same 'no irq handler' message. > > Sarah Sharp >
Attachment:
ints-2.6.37
Description: Binary data
Attachment:
ints-working
Description: Binary data
