github-mirror/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2026-06-10 07:32:29 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity Graph
fd25080998
linux/drivers/usb
History
Sarah Sharp b62d32b916 xhci: Fix hang on back-to-back Set TR Deq Ptr commands. 
commit 0d9f78a92e upstream.

The Microsoft LifeChat 3000 USB headset was causing a very reproducible
hang whenever it was plugged in.  At first, I thought the host
controller was producing bad transfer events, because the log was filled
with errors like:

xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD

However, it turned out to be an xHCI driver bug in the ring expansion
patches.  The bug is triggered When there are two ring segments, and a
TD that ends just before a link TRB, like so:

 ______________                     _____________
|              |              ---> | setup TRB B |
 ______________               |     _____________
|              |              |    |  data TRB B |
 ______________               |     _____________
| setup TRB A  | <-- deq      |    |  data TRB B |
 ______________               |     _____________
| data TRB A   |              |    |             | <-- enq, deq''
 ______________               |     _____________
| status TRB A |              |    |             |
 ______________               |     _____________
|  link TRB    |---------------    |  link TRB   |
 _____________  <--- deq'           _____________

TD A (the first control transfer) stalls on the data phase.  That halts
the ring.  The xHCI driver moves the hardware dequeue pointer to the
first TRB after the stalled transfer, which happens to be the link TRB.

Once the Set TR dequeue pointer command completes, the function
update_ring_for_set_deq_completion runs.  That function is supposed to
update the xHCI driver's dequeue pointer to match the internal hardware
dequeue pointer.  On the first call this would work fine, and the
software dequeue pointer would move to deq'.

However, if the transfer immediately after that stalled (TD B in this
case), another Set TR Dequeue command would be issued.  That would move
the hardware dequeue pointer to deq''.  Once that command completed,
update_ring_for_set_deq_completion would run again.

The original code would unconditionally increment the software dequeue
pointer, which moved the pointer off the ring segment into la-la-land.
The while loop would happy increment the dequeue pointer (possibly
wrapping it) until it matched the hardware pointer value.

The while loop would also access all the memory in between the first
ring segment and the second ring segment to determine if it was a link
TRB.  This could cause general protection faults, although it was
unlikely because the ring segments came from a DMA pool, and would often
have consecutive memory addresses.

If nothing in that space looked like a link TRB, the deq_seg pointer for
the ring would remain on the first segment.  Thus, the deq_seg and the
software dequeue pointer would get out of sync.

When the next transfer event came in after the stalled transfer, the
xHCI driver code would attempt to convert the software dequeue pointer
into a DMA address in order to compare the DMA address for the completed
transfer.  Since the deq_seg and the dequeue pointer were out of sync,
xhci_trb_virt_to_dma would return NULL.

The transfer event would get ignored, the transfer would eventually
timeout, and we would mistakenly convert the finished transfer to no-op
TRBs.  Some kernel driver (maybe xHCI?) would then get stuck in an
infinite loop in interrupt context, and the whole machine would hang.

This patch should be backported to kernels as old as 3.4, that contain
the commit b008df60c6 "xHCI: count free
TRBs on transfer ring"

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-16 09:04:38 -07:00
..
atm module_param: make bool parameters really bool (drivers & misc) 2012-01-13 09:32:20 +10:30
c67x00 usb: convert drivers/usb/* to use module_platform_driver() 2011-11-28 06:48:32 +09:00
class USB: cdc-wdm: fix lockup on error in wdm_read 2012-07-16 09:04:37 -07:00
core usb: Add support for root hub port status CAS 2012-07-16 09:04:38 -07:00
dwc3 usb: dwc3: Free event buffers array 2012-04-10 19:11:46 +03:00
early USB: EHCI: Support controllers with big endian capability regs 2011-05-03 11:43:21 -07:00
gadget usb: gadget: fsl_udc_core: dTD's next dtd pointer need to be updated once written 2012-06-01 15:18:22 +08:00
host xhci: Fix hang on back-to-back Set TR Deq Ptr commands. 2012-07-16 09:04:38 -07:00
image USB: convert drivers/usb/* to use module_usb_driver() 2011-11-18 09:34:02 -08:00
misc usb: usbtest: two super speed fixes for usbtest 2012-06-01 15:18:21 +08:00
mon usb: Add export.h for EXPORT_SYMBOL/THIS_MODULE where needed 2011-10-31 19:31:25 -04:00
musb usb: musb_gadget: fix crash caused by dangling pointer 2012-06-22 11:37:09 -07:00
otg USB: gpio_vbus: provide an appropriate debounce interval 2012-06-01 15:18:21 +08:00
renesas_usbhs Merge branch 'next' of git://git.infradead.org/users/vkoul/slave-dma 2012-03-29 15:34:57 -07:00
serial USB: option: Add MEDIATEK product ids 2012-07-16 09:04:38 -07:00
storage usb-storage: revert commit afff07e61a (Add 090c:1000 to unusal-devs) 2012-07-16 09:04:10 -07:00
wusbcore uwb & wusb: fix kconfig error 2012-01-26 11:22:42 -08:00
Kconfig usb: Put USB Kconfig items back under USB. 2012-04-06 13:37:21 -07:00
Makefile USB: OTG should be linked before Host 2011-11-26 19:58:47 -08:00
README USB: fix directory references in usb/README 2007-11-28 13:58:34 -08:00
usb-common.c usb: Provide usb_speed_string() function 2011-09-18 01:29:04 -07:00
usb-skeleton.c Revert "USB: usb-skeleton.c: fix open/disconnect race" 2012-01-24 12:02:38 -08:00

README 

To understand all the Linux-USB framework, you'll use these resources:

    * This source code.  This is necessarily an evolving work, and
      includes kerneldoc that should help you get a current overview.
      ("make pdfdocs", and then look at "usb.pdf" for host side and
      "gadget.pdf" for peripheral side.)  Also, Documentation/usb has
      more information.

    * The USB 2.0 specification (from www.usb.org), with supplements
      such as those for USB OTG and the various device classes.
      The USB specification has a good overview chapter, and USB
      peripherals conform to the widely known "Chapter 9".

    * Chip specifications for USB controllers.  Examples include
      host controllers (on PCs, servers, and more); peripheral
      controllers (in devices with Linux firmware, like printers or
      cell phones); and hard-wired peripherals like Ethernet adapters.

    * Specifications for other protocols implemented by USB peripheral
      functions.  Some are vendor-specific; others are vendor-neutral
      but just standardized outside of the www.usb.org team.

Here is a list of what each subdirectory here is, and what is contained in
them.

core/		- This is for the core USB host code, including the
		  usbfs files and the hub class driver ("khubd").

host/		- This is for USB host controller drivers.  This
		  includes UHCI, OHCI, EHCI, and others that might
		  be used with more specialized "embedded" systems.

gadget/		- This is for USB peripheral controller drivers and
		  the various gadget drivers which talk to them.


Individual USB driver directories.  A new driver should be added to the
first subdirectory in the list below that it fits into.

image/		- This is for still image drivers, like scanners or
		  digital cameras.
../input/	- This is for any driver that uses the input subsystem,
		  like keyboard, mice, touchscreens, tablets, etc.
../media/	- This is for multimedia drivers, like video cameras,
		  radios, and any other drivers that talk to the v4l
		  subsystem.
../net/		- This is for network drivers.
serial/		- This is for USB to serial drivers.
storage/	- This is for USB mass-storage drivers.
class/		- This is for all USB device drivers that do not fit
		  into any of the above categories, and work for a range
		  of USB Class specified devices. 
misc/		- This is for all USB device drivers that do not fit
		  into any of the above categories.