On Thu, Jul 12, 2012 at 12:54 PM, Matt Causey <matt.causey@xxxxxxxxx> wrote: > On Thu, Jul 12, 2012 at 2:04 AM, Andiry Xu <andiry.xu@xxxxxxx> wrote: >> On 07/12/2012 10:53 AM, Matt Causey wrote: >>> >>> On Wed, Jul 11, 2012 at 11:03 AM, Matt Causey<matt.causey@xxxxxxxxx> >>> wrote: >>>> >>>> On Wed, Jul 11, 2012 at 10:12 AM, Matt Causey<matt.causey@xxxxxxxxx> >>>> wrote: >>>>> >>>>> On Tue, Jul 10, 2012 at 10:55 PM, Andiry Xu<andiry.xu@xxxxxxx> wrote: >>>>>> >>>>>> On 07/11/2012 01:56 AM, Matt wrote: >>>>>>> >>>>>>> >>>>>>> Lee Harris<lee.r.harris@...> writes: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Sarah >>>>>>>> >>>>>>>> Whenever I restart or coldboot, my external drive (3.5 sata in a USB3 >>>>>>>> enclosure) is not detected / initialised correctly. fdisk -l does not >>>>>>>> show the drive at all. >>>>>>>> I have found that I have to: >>>>>>>> turn it off ( or disconnect the usb cable) >>>>>>>> modprobe -r xhci_hcd >>>>>>>> modprobe xhci_hcd >>>>>>>> and then turn it on. It is then found and initialised. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'm having this same issue. Does anyone have any ideas? >>>>>>> >>>>>> >>>>>> Can you post the bootup dmesg with device connected and >>>>>> CONFIG_USB_DEBUG and >>>>>> CONFIG_USB_XHCI_HCD_DEBUGGING enabled? >>>>>> >>>>>> Thanks, >>>>>> Andiry >>>>>> >>>>>> >>>>> >>>>> Some more background...I've got another OS image that runs Linux >>>>> 2.6.32-33-generic (Ubuntu 10.4 LTS) - and that OS on this hardware >>>>> works as expected. I've also tested Linux 3.2.22 and it fails in the >>>>> same way on my system. >>>>> >>>>> Upon more digging, what I'm finding is that if I leave my device >>>>> disconnected from the USB3 port when I boot the system, and the >>>>> connect the device after the system has booted fully, the device works >>>>> correctly. The problem occurs when a device is connected to the USB3 >>>>> port, and I simply boot the system. The dmesg below is from the test >>>>> system that has the problem. My configuration is also included as an >>>>> attachment, in case that's helpful. >>>>> >>>>> dmesg: >> >> >> ... >> >> >>>>> xhci_hcd 0000:05:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 >>>>> xhci_hcd 0000:05:00.0: setting latency timer to 64 >>>>> xhci_hcd 0000:05:00.0: xHCI Host Controller >>>>> drivers/usb/core/inode.c: creating file '003' >>>>> xhci_hcd 0000:05:00.0: new USB bus registered, assigned bus number 3 >>>>> xhci_hcd 0000:05:00.0: xHCI capability registers at f8060000: >>>>> xhci_hcd 0000:05:00.0: CAPLENGTH AND HCIVERSION 0x960020: >>>>> xhci_hcd 0000:05:00.0: CAPLENGTH: 0x20 >>>>> xhci_hcd 0000:05:00.0: HCIVERSION: 0x96 >>>>> xhci_hcd 0000:05:00.0: HCSPARAMS 1: 0x4000840 >>>>> xhci_hcd 0000:05:00.0: Max device slots: 64 >>>>> xhci_hcd 0000:05:00.0: Max interrupters: 8 >>>>> xhci_hcd 0000:05:00.0: Max ports: 4 >>>>> xhci_hcd 0000:05:00.0: HCSPARAMS 2: 0xc0000f1 >>>>> xhci_hcd 0000:05:00.0: Isoc scheduling threshold: 1 >>>>> xhci_hcd 0000:05:00.0: Maximum allowed segments in event ring: 15 >>>>> xhci_hcd 0000:05:00.0: HCSPARAMS 3 0x7ff000a: >>>>> xhci_hcd 0000:05:00.0: Worst case U1 device exit latency: 10 >>>>> xhci_hcd 0000:05:00.0: Worst case U2 device exit latency: 2047 >>>>> xhci_hcd 0000:05:00.0: HCC PARAMS 0x270f06d: >>>>> xhci_hcd 0000:05:00.0: HC generates 64 bit addresses >>>>> xhci_hcd 0000:05:00.0: FIXME: more HCCPARAMS debugging >>>>> xhci_hcd 0000:05:00.0: RTSOFF 0x4a0: >>>>> xhci_hcd 0000:05:00.0: xHCI operational registers at f8060020: >>>>> xhci_hcd 0000:05:00.0: USBCMD 0x0: >>>>> xhci_hcd 0000:05:00.0: HC is being stopped >>>>> xhci_hcd 0000:05:00.0: HC has finished hard reset >>>>> xhci_hcd 0000:05:00.0: Event Interrupts disabled >>>>> xhci_hcd 0000:05:00.0: Host System Error Interrupts disabled >>>>> xhci_hcd 0000:05:00.0: HC has finished light reset >>>>> xhci_hcd 0000:05:00.0: USBSTS 0x0: >>>>> xhci_hcd 0000:05:00.0: Event ring is empty >>>>> xhci_hcd 0000:05:00.0: No Host System Error >>>>> xhci_hcd 0000:05:00.0: HC is running >>>>> xhci_hcd 0000:05:00.0: f8060420 port status reg = 0x2a0 >>>>> xhci_hcd 0000:05:00.0: f8060424 port power reg = 0x0 >>>>> xhci_hcd 0000:05:00.0: f8060428 port link reg = 0x0 >>>>> xhci_hcd 0000:05:00.0: f806042c port reserved reg = 0x0 >>>>> xhci_hcd 0000:05:00.0: f8060430 port status reg = 0xa03 >> >> >> Here the device is connected. >> >> >>>>> xhci_hcd 0000:05:00.0: f8060434 port power reg = 0x0 >>>>> xhci_hcd 0000:05:00.0: f8060438 port link reg = 0x0 >>>>> xhci_hcd 0000:05:00.0: f806043c port reserved reg = 0x0 >>>>> xhci_hcd 0000:05:00.0: f8060440 port status reg = 0x2a0 >>>>> xhci_hcd 0000:05:00.0: f8060444 port power reg = 0x0 >>>>> xhci_hcd 0000:05:00.0: f8060448 port link reg = 0x0 >>>>> xhci_hcd 0000:05:00.0: f806044c port reserved reg = 0x0 >>>>> xhci_hcd 0000:05:00.0: f8060450 port status reg = 0x2a0 >>>>> xhci_hcd 0000:05:00.0: f8060454 port power reg = 0x0 >>>>> xhci_hcd 0000:05:00.0: f8060458 port link reg = 0x0 >>>>> xhci_hcd 0000:05:00.0: f806045c port reserved reg = 0x0 >>>>> xhci_hcd 0000:05:00.0: // Halt the HC >>>>> xhci_hcd 0000:05:00.0: `MEM_WRITE_DWORD(3'b000, 32'hf8060020, 32'h0, >>>>> 4'hf); >>>>> xhci_hcd 0000:05:00.0: can't setup >> >> >> This is where the error occurs. The host controller is not halted. >> >> >>>>> xhci_hcd 0000:05:00.0: USB bus 3 deregistered >>>>> xhci_hcd 0000:05:00.0: PCI INT A disabled >>>>> xhci_hcd 0000:05:00.0: init 0000:05:00.0 fail, -110 >>>>> xhci_hcd: probe of 0000:05:00.0 failed with error -110 >> >> >> ... >> >> >>>> >>> >>> Hello again, everyone! >>> >>> OK apologies again for replying to my own stinking posting...but I've >>> made some progress and wanted to note it here for those hapless souls >>> wandering through the internets later. >>> >>> You'll notice that the kernel configuration I posted earlier is almost >>> entirely monolithic. I had assumed that I could just say >>> CONFIG_USB_XHCI_HCD=y and be done for enabling xHCI. Well Sarah >>> mentioned here: http://sarah.thesharps.us/2009-06-09-13-30.cherry that >>> the USB-related modules should be compiled as modules for xHCI to work >>> correctly. I made some changes (diff below) and now it works. >>> Thanks, Sarah! >>> >> >> I think the document is written pretty long ago. At that time xhci-hcd is >> not stable enough so Sarah prefer to load xhci-hcd as module. I don't know >> why all the USB-related modules should be compiled as modules. As I know, >> now xhci-hcd is compiled into kernel as default. >> >> Can you revert to the original kernel config and try the patch attached to >> see if it helps? >> >> Thanks, >> Andiry >> > > So, I won't pretend to understand _why_, but that appears to work! > That's pretty cool. Basically it seems that you're making it so that > a failure to halt the xHCI is not a reason to shut it down entirely. > > I also don't know what this means... Does it mean that I have buggy > hardware, for which this is a workaround....or is this a patch that > will end up in the Kernel tree? Or something else entirely? :-) > I was digging around in 2.6.38-2 to apply a similar patch. I ended up in static int xhci_pci_setup(struct usb_hcd *hcd) which is in drivers/usb/host/xhci-pci.c . There is this code: retval = xhci_halt(xhci); if (retval) return retval; So basically it's the same deal. If the driver issues a halt and it gets a non-zero return value, it renders it inoperable. When I comment out that if statement the system works. Reading the output of xhci_print_registers(xhci), I see that there are no error conditions, only that the HC is still running. It seems probable that the cause of this problem is some inconsistent state that the hardware left itself in. But I would have to imagine that the driver should be able to detect and workaround this condition. What are your thoughts? Cheers, -- Matt -- 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
