Christopher, due to the nature of this bug, I cannot perform the reverse
bisect. I explained it already in comment #8. Just to be clearer: the
regression has not been fixed upstream. There is no 3.x kernel branch
which would contain the regression and the subsequent fix. The
regression either is not there at all (all branches except 3.2), or
remains unfixed (3.2). Thus I have no target for the bisection.
On somewhat happier news, I have spent last few days debugging the
kernel, and I got some results. Specifically, I have a patch that fixes
regression on 3.2.0-64 running on a particular hardware. The patch is
rather ugly, and will probably cause problems on other hardware, but at
least it shows some direction.
I will gladly discuss this matter, but I will need a little more
attention shown by Ubuntu maintainers. Each of my posts corresponds to
many hours of my work, and while I am grateful for any attention, its
current level does not permit a constructive dialogue. I am very sorry
to say this, and I mean no offense, but I will put more effort into
writing here only when I see a chance that someone will read it.
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
** Tags removed: kernel-fixed-upstream-3.16-rc1 needs-reverse-bisect
--
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:
Confirmed
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
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
