Zitat von Thadeu Lima de Souza Cascardo <cascardo@xxxxxxxxxxxxxxxxxx>:
On Tue, Apr 15, 2014 at 12:04:17PM +0200, stefani@xxxxxxxxxxx wrote:
Zitat von Thadeu Lima de Souza Cascardo <cascardo@xxxxxxxxxxxxxxxxxx>:
>On Mon, Apr 14, 2014 at 05:44:58PM +0200, stefani@xxxxxxxxxxx wrote:
>>
>>Zitat von Benjamin Herrenschmidt <benh@xxxxxxxxxxx>:
>>
>>>I don't know about EHCI specifically but this is a known issue with
>>>XHCI, I observe similar issues on other powerpc platforms (servers)
>>>and this isn't architecture specific (looks more like actualy xhc
>>>implementation specific).
>>>
>>>Thadeu Cascardo (on CC) has been the one investigating that on our side,
>>>he might have more to add including patches.
>>>
>>
>>I have now a kernel 3.14 dmesg log of the problem. After a kexec the
>>kexeced 3.14 kernel shows:
>>
>>[ 1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller
>>[ 1.175306] xhci_hcd 0001:03:00.0: new USB bus registered,
>>assigned bus number 1
>>[ 1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000
>>microseconds.
>>[ 1.219621] xhci_hcd 0001:03:00.0: can't setup: -110
>>[ 1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered
>>[ 1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110
>>[ 1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110
>>
>
>What is your controller vendor and device IDs? Is that a TI chip?
>
Yes it is a TI chip, vendor ID 104c and product ID 8241.
>Can you check if the patch I sent a month ago fixes it? [1] There's the
>whole story there. In fact, you will also need something like the patch
>below. Can you apply only the first one, verify, and, then, the other
>one as well, and report what worked for you?
>
>[1] http://marc.info/?l=linux-usb&m=139483181809062&w=2
>
I tried the attach patch and it did not help. This is what i
expected because this is a fix in the shutdown path, which will
never called when doing a forced kexec.
Hi, Stefani.
Did you try with both patches applied? How do you evoke the forced
kexec? Is that a kexec on panic? Does it really need to be forced? With
no clean shutdown, platform and drivers would need to issue resets, like
you mentioned below, to get the system into a clean state.
Yes, i applied both patches. But without success.
IMHO i think it is necessary to bring the device i a clean state when
the driver use the HW.
I have a running a 3.10.23 kernel. This kernel do a kexec for a
kernel 3.14. Since the kernel 3.10.23 did not performe a clean
shutdown, the state of the XHCI Controller is undefined. So when
And the clean shutdown requires both of my patches, for TI chips, as far
as I know. It looks like the problem is issuing a halt when there are
pending URBs.
kernel 3.14 will probe XHCI it will find a XHCI controller which was
not performed a reset.
The problem is not that a reset hasn't been issued. A PCI function reset
should fix most of the problems with a bad device state, when the reset
works. However, the problem is that it was not cleanly shut down. URBs
should have been canceled and removed from the controller queue, and it
should have halted after that.
Again, i think it is the job of the driver to bring the chip in a clean state
before using them. A driver should never expect a reset state of a chip.
So i think it is necessary to reset the XHCI controller and all
devices on this bus. This is what i do with a "echo 1
>/sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset" before the kexec.
One way to look at that is making the PCI code issue resets to all buses
before doing any other access. That will make booting more slow, and
there are a lot of other corner cases where this might not be enough.
It's probably more sane to try to get the 3.10.23 kernel to do a clean
shutdown, if possible.
With this driver design the kexec functionality is usesless on PowerPC.
X86 looks a little bit better.
- Stefani
--
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
