Re: PROBLEM: USB2 oopses with stable kernels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 1 Oct 2012, Tuomas Jorma Juhani [iso-8859-1] R�nen wrote:

> An userspace program reading continuously an USB2 HID mouse's Interrupt
> IN endpoint causes stable kernels to oops. We have encountered this in
> several stable kernels, the oldest tested being 2.6.32 and the latest
> 3.5.4.
> 
> We found this bug originally from systems with SMARTBoards
> (http://smarttech.com/smartboard) plugged in and proprietary SMART Board
> Service userspace driver process running and communicating with the
> board. However, the bug can be reproduced with a normal USB2 HID mouse
> and a simple program using libusb to read continuously mouse's Interrupt
> IN endpoint. See usboops.c listing below.
> 
> (usboops.c was written to mimic the behavior of the proprietary SMART
> Board Service by observing/tracing it's libusb-usage, and sadly enough,
> it's quite accurate clone)
> 
> We also observed that the problem cannot be reproduced with 3.6-rc7
> (or at least it is really hard to reproduce compared to stable
> releases). We therefore bisected v3.5.4...v3.6-rc7 and found out that
> df2022553dd8d34d49e16c19d851ea619438f0ef is the first commit which
> removes or at least makes it really difficult to reproduce the
> problem.
> 
> Does that commit (or the combination of the nearby EHCI-related commits)
> fix this issue or do they make it just significantly harder to
> reproduce?

That particular commit (USB: EHCI: use hrtimer for interrupt QH unlink)  
affects unlink operations for interrupt URBs, which your sample program
uses by default since it has such a short timeout.  If you would change
the timeout value to something larger, like 1000, the oops would not
occur (unless you stopped moving the mouse during the test).

Basically yes, the old code was buggy and it could create situations
where the host controller hardware was writing over memory without the
OS knowing about it.  As far as I know the commit does fix this issue,
but it's hard to be certain because the EHCI spec does not say how long
the hardware can cache an interrupt QH.

Alan Stern

--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux