kernel-packages team mailing list archive

[Maciej Puzio <1330530@xxxxxxxxxxxxxxxxxx>]

I have tested 28 mainline kernels from 9 branches currently maintained
(3.2, 3.4, 3.10, 3.11, 3.12, 3.13, 3.14, 3.15, 3.16), focusing on those
that were built around the time the problematic commit was introduced
(May-June 2014). The bug appears to affect the 3.2 branch exclusively.
Thus I will now try to forward bisect commits from 3.2.58 (last good) to
3.2.59 (first bad).

Just for reference, here are results of my testing. "Bad" means that bug was reproducible in the given kernel, "good" that it was not.
3.2.58 good
3.2.59 bad
3.2.60 bad
3.4.89 good
3.4.90 good
3.4.91 good
3.4.92 good
3.4.93 good
3.4.94 good
3.10.44 good
3.11.10.11 good
3.13.22 good
3.13.11 good
3.13.11.1 good
3.13.11.2 good
3.13.11.3 good
3.14.8 good
3.15-rc1 good
3.15-rc2 good
3.15-rc3 good
3.15-rc4 good
3.15-rc5 good
3.15-rc6 good
3.15-rc7 good
3.15-rc8 good
3.15 good
3.15.1 good
3.16-rc1 good

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1330530

Title:
  [Dell Vostro 430] Regression: Kernel 3.2.0-64 problems with USB3
  controller

Status in “linux” package in Ubuntu:
  Incomplete

Bug description:
  With a Dell Vostro 430, the HighPoint RocketU 1144C USB 3.0 controller, Areca ARC-5040 USB 3.0 RAID enclosure connected to it, and the following conditions are met:
  1. System booted kernel 3.2.0-64,
  2. HighPoint RocketU 1144C controller was installed,
  3. Areca ARC-5040 was connected to that controller.

  An error loop during boot contains the following messages:
  [   34.084469] usb 8-1: reset SuperSpeed USB device number 2 using xhci_hcd
  [   34.101825] xhci_hcd 0000:05:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88042102e000
  [   34.101918] xhci_hcd 0000:05:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88042102e040
  This continues for about 18 minutes, after which the filesystem on the Areca drive is mounted, and boot process continues successfully, as if nothing had happened. Afterwards the affected drive works seemingly fine, although I experienced some system instability, causing a total system freeze. At this point I am not sure if this instability is related to the problem at hand.

  I've attached a file generated by apport-cli -f -p linux --save
  filename.apport .

  The problem did not appear if I booted an older kernel (e.g.
  3.2.0-63), or if Areca enclosure was not attached, or if it was
  attached using another interface (USB2 or eSATA). The problem was also
  absent if I replaced the Areca enclosure with another USB3 device (a
  flash drive). The test machine's motherboard did not have a built-in
  USB3 controller, but I performed an additional test on yet another
  computer, equipped with a NEC USB3 controller. That test was done with
  kernel 3.2.0-64 and the Areca enclosure, and did not replicate the
  problem. Thus I assume that it is the combination of the RocketU
  controller and a specific USB3 device that triggers kernel regression.

  Similar effects happen if Areca enclosure is hot-plugged to the
  working system. In such a case OS boots fine (as the enclosure is
  absent during boot). After plugging the Areca, the drive is
  unavailable for 18 minutes, during which time numerous errors as above
  are logged. After 18 minutes elapse, drive is mounted and behaves
  normally.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330530/+subscriptions