Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1210205 > unrolled thread

Re: [PATCH 0/5] usb: xhci: Fix breakage on dual-role case

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/5] usb: xhci: Fix breakage on dual-role case Roger Quadros <rogerq@ti.com> - 2015-08-20 09:10 +0200
    Re: [PATCH 0/5] usb: xhci: Fix breakage on dual-role case Mathias Nyman <mathias.nyman@linux.intel.com> - 2015-08-27 13:20 +0200

#1210205 — Re: [PATCH 0/5] usb: xhci: Fix breakage on dual-role case

Hi Mathias,

On 18/08/15 13:39, Roger Quadros wrote:
> Hi,
> 
> Plugging and unplugging a USB-OTG adapter with a USB device into a
> am437x-gp-evm dual-role port (USB1) causes XHCI to malfunction
> and USB device to be no longer detected after a few iterations.
> 
> The triggering case is so
> 1) USB1 in peripheal mode
> 2) plug OTG adapter with USB device
> 3) USB1 switches to host mode
> 4) Detects new USB device
> 5) unplug OTG adapter
> 6) OTG core tries to remove host controller while new device
> is being processed.
> 
> At 6 some races are observed in the XHCI driver causing it to
> malfunction. See kernel log at the end of this mail.
> 
> This series tries to address some of the issues.
> Althouth it is not 100% fool proof yet and XHCI can still get
> stuck up for a few seconds occasionally, it did recover always
> in a max of 10 seconds and the USB device was enumerated after
> that.
> 
> During a dual-role switch, usb_remove_hcd() and usb_add_hcd()
> will be called consecutively for both Shared and Primary
> HCDs. This can happen asynchronously and we have to be prepared
> for it.
> 

Even after this series I do occasionally see a delay of 5 seconds
during adapter detach. (please see kernel log below).

Is it possible to further optimize so that when xhci_stop is called
we don't depend entirely on timeout timers to stop queued commands?

[  106.301771] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[  106.307480] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 3
[  106.320818] xhci-hcd xhci-hcd.0.auto: hcc params 0x0238f06d hci version 0x100 quirks 0x00010010
[  106.329809] xhci-hcd xhci-hcd.0.auto: irq 253, io mem 0x48390000
[  106.337587] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[  106.344455] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  106.352769] usb usb3: Product: xHCI Host Controller
[  106.357813] usb usb3: Manufacturer: Linux 4.1.6-01054-g496f557-dirty xhci-hcd
[  106.365012] usb usb3: SerialNumber: xhci-hcd.0.auto
[  106.381914] hub 3-0:1.0: USB hub found
[  106.390765] hub 3-0:1.0: 1 port detected
[  106.400732] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[  106.407492] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 4
[  106.421396] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
[  106.436701] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[  106.443577] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  106.454456] usb usb4: Product: xHCI Host Controller
[  106.460990] usb usb4: Manufacturer: Linux 4.1.6-01054-g496f557-dirty xhci-hcd
[  106.473275] usb usb4: SerialNumber: xhci-hcd.0.auto
[  106.502263] hub 4-0:1.0: USB hub found
[  106.511431] hub 4-0:1.0: 1 port detected
[  106.715490] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[  106.822091] xhci-hcd xhci-hcd.0.auto: remove, state 4
[  106.827261] usb usb4: USB disconnect, device number 1

[  111.845544] xhci-hcd xhci-hcd.0.auto: Command completion event does not match command
[  111.853518] xhci-hcd xhci-hcd.0.auto: Timeout while waiting for setup device command
[  111.888145] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000 microseconds.
[  111.895528] xhci-hcd xhci-hcd.0.auto: Host controller not halted, aborting reset.
[  111.905732] xhci-hcd xhci-hcd.0.auto: USB bus 4 deregistered
[  111.912598] xhci-hcd xhci-hcd.0.auto: remove, state 1
[  111.918695] usb usb3: USB disconnect, device number 1
[  112.125544] usb 3-1: device descriptor read/all, error -22
[  112.131106] usb usb3-port1: couldn't allocate usb_device
[  112.140019] xhci-hcd xhci-hcd.0.auto: USB bus 3 deregistered


cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1214480

On 20.08.2015 10:09, Roger Quadros wrote:
> Hi Mathias,

Hi

>
> On 18/08/15 13:39, Roger Quadros wrote:
>> Hi,
>>
>> Plugging and unplugging a USB-OTG adapter with a USB device into a
>> am437x-gp-evm dual-role port (USB1) causes XHCI to malfunction
>> and USB device to be no longer detected after a few iterations.
>>
>> The triggering case is so
>> 1) USB1 in peripheal mode
>> 2) plug OTG adapter with USB device
>> 3) USB1 switches to host mode
>> 4) Detects new USB device
>> 5) unplug OTG adapter
>> 6) OTG core tries to remove host controller while new device
>> is being processed.
>>
>> At 6 some races are observed in the XHCI driver causing it to
>> malfunction. See kernel log at the end of this mail.
>>
>> This series tries to address some of the issues.
>> Althouth it is not 100% fool proof yet and XHCI can still get
>> stuck up for a few seconds occasionally, it did recover always
>> in a max of 10 seconds and the USB device was enumerated after
>> that.
>>
>> During a dual-role switch, usb_remove_hcd() and usb_add_hcd()
>> will be called consecutively for both Shared and Primary
>> HCDs. This can happen asynchronously and we have to be prepared
>> for it.
>>
>
> Even after this series I do occasionally see a delay of 5 seconds
> during adapter detach. (please see kernel log below).
>
> Is it possible to further optimize so that when xhci_stop is called
> we don't depend entirely on timeout timers to stop queued commands?

Yes, sounds reasonable. Command timer and ring could probably be stopped,
remaining commands aborted and returned.
  
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web