On 07/13/2012 10:41 PM, Matt Causey wrote:
On Fri, Jul 13, 2012 at 7:13 AM, Andiry Xu<andiry.xu@xxxxxxx> wrote:
On 07/13/2012 09:56 AM, Matt Causey wrote:
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? :-)
The patch is just for testing. If the host is not halted, software should
not write 1 to USBCMD to start it later in xhci_start().
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?
xhci_print_registers() shows a strange thing: USBCMD and USBSTS are both
read as 0, which means HC is stopped (USBCMD R/S bit = 0) and HC is not
halted (USBSTS HCH bit = 0). This is ambivalent(See the "HC is being
stopped" and "HC is running" lines). I suspect there is something wrong in
the BIOS-OS handoff before host initialization.
Can you post the output of lspci -vvnn?
Thanks again for having a look at this with me! It's pretty informative...
I've attached lspci.txt.
So it's a TI host controller on a AMD platform. I don't have a TI host,
but I've verified AMD inbox host controller and NEC external host, the
USBSTS all show halted after BIOS-OS handoff, which is compliant with
spec, since the default value of USBSTS HCH bit is 1.
I'm not sure whether this is a hardware issue, but it's somehow
violating the spec. We can add a quirk for this, but I would like to
know the root cause. Perhaps some TI guys in this maillist can help to
provide some information...
Thanks,
Andiry
--
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
