kernel-packages team mailing list archive

[Maciej Puzio <1330530@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

This bug report is a follow-up to bug 1328984, describing a successful
attempt to replicate that bug on another hardware. As advised, I am
opening a new bug to avoid mixing information related to two hardware
configurations.

Conditions triggering this bug:
As the original bug (1328984) was encountered on machines that are production servers, I attempted to replicate in on another machine that could be entirely devoted to testing this issue. I equipped this computer with the same USB3 hardware as the servers, that is the HighPoint RocketU 1144C USB 3.0 controller and Areca ARC-5040 USB 3.0 RAID enclosure connected to it. I was able to replicate the problem with ease, provided that all three following conditions were 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.

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. In the original bug report
(1328984) Bard Hemmer reported that he encountered a similar trouble
with  Western Digital My Passport 2TB USB 3.0 external drive. I happen
to own this exact model, and I intend to test it as soon as possible.

Symptoms:
The symptoms on the test machine are somewhat different than those occurring on the production servers. The 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.

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.

Hardware:
Dell Vostro 430
CPU: Intel Core i7-860
RAM: 16GB DDR3 unbuffered non-ECC
Add-on card: HighPoint RocketU 1144C 4-Port USB 3.0 PCIe 2.0 x4 HBA

Software:
Ubuntu 3.2.0-64.97-generic 3.2.59 x86_64

Note about apport collection:
Due to problems described in bug 1328984, relevant to this setup as well, I am unable to run apport tools to submit system information. For this reason, I am attaching a file generated by apport-cli -f -p linux --save filename.apport

** Affects: linux (Ubuntu)
     Importance: Undecided
         Status: New

-- 
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:
  Regression: Kernel 3.2.0-64 problems with USB3 controller

Status in “linux” package in Ubuntu:
  New

Bug description:
  This bug report is a follow-up to bug 1328984, describing a successful
  attempt to replicate that bug on another hardware. As advised, I am
  opening a new bug to avoid mixing information related to two hardware
  configurations.

  Conditions triggering this bug:
  As the original bug (1328984) was encountered on machines that are production servers, I attempted to replicate in on another machine that could be entirely devoted to testing this issue. I equipped this computer with the same USB3 hardware as the servers, that is the HighPoint RocketU 1144C USB 3.0 controller and Areca ARC-5040 USB 3.0 RAID enclosure connected to it. I was able to replicate the problem with ease, provided that all three following conditions were 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.

  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.
  In the original bug report (1328984) Bard Hemmer reported that he
  encountered a similar trouble with  Western Digital My Passport 2TB
  USB 3.0 external drive. I happen to own this exact model, and I intend
  to test it as soon as possible.

  Symptoms:
  The symptoms on the test machine are somewhat different than those occurring on the production servers. The 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.

  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.

  Hardware:
  Dell Vostro 430
  CPU: Intel Core i7-860
  RAM: 16GB DDR3 unbuffered non-ECC
  Add-on card: HighPoint RocketU 1144C 4-Port USB 3.0 PCIe 2.0 x4 HBA

  Software:
  Ubuntu 3.2.0-64.97-generic 3.2.59 x86_64

  Note about apport collection:
  Due to problems described in bug 1328984, relevant to this setup as well, I am unable to run apport tools to submit system information. For this reason, I am attaching a file generated by apport-cli -f -p linux --save filename.apport

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