Created attachment 919885 [details]
Photo of oops with 3.15.6-200
The system crashes a short time after plugging a USB disk. There is no need to try to mount it, plugging it is enough to trigger the crash. Also, if the disk is plugged at boot time, the system does not boot.
The problem happens with kernels 3.15.6-200.fc20.x86_64 and 3.15.4-200.fc20.x86_64, but everything works with 3.14.8-200.fc20.x86_64.
Until today, the system has been working with that disk perfectly for more than a year. It seems to continue to work just as well when using the older kernel (3.14.8), but the newer ones fail.
I attach two phots of the oops (one with 3.15.6 and another with 3.15.4) and the output of dmesg with 3.15.4. Let me know if I can help with any other information to debug the problem.
Created attachment 919886 [details]
Photo of oops with 3.15.4-200
Created attachment 919887 [details]
Output of dmesg with 3.15.4
*** Bug 1121334 has been marked as a duplicate of this bug. ***
Argh, this looks very similar to bug 1121288, which marked as fixed with 3.15.7, and it contains a workaround anyway, even if not the exact same device...
I (still) have the same behaviour with the 3.16.2-200.fc20.x86_64 kernel.
What information can I provide to help you find a correction ?
(In reply to florian.judith+fedbug from comment #5)
> I (still) have the same behaviour with the 3.16.2-200.fc20.x86_64 kernel.
> What information can I provide to help you find a correction ?
I am just another user, but does the uas quirk works for you? i.e. according to your dmesg, you should add
to the kernel command line, for your hardware. That's pressing 'e' for edit,
and putting that after the kernel command line in the grub menu before ctrl-x/f10 to continue booting.
Alternatively, you might consider blacklist'ing xhci and use the usb disk at usb 2.0 speed? (assuming you need to work in a current kernel for another reason and cannot stay in the older 3.14.8 until it get addressed eventually...).
(In reply to Hin-Tak Leung from comment #6)
> I am just another user, but does the uas quirk works for you? i.e. according
> to your dmesg, you should add
> to the kernel command line, for your hardware. That's pressing 'e' for edit,
> and putting that after the kernel command line in the grub menu before
> ctrl-x/f10 to continue booting.
It worked with the uas quirk (even if it's 059f:106a:u for me).
> Alternatively, you might consider blacklist'ing xhci and use the usb disk at
> usb 2.0 speed? (assuming you need to work in a current kernel for another
> reason and cannot stay in the older 3.14.8 until it get addressed
I answered to this post because I saw that the 3.16.2 kernel was out and got the same behavior, so I wanted to help solving the problem.
I also like using an up-to-date system for security and stability reasons.
For information, I'm the user who opened the bug: 1121334 who was marked as a duplicate of this one.
I just got the same backtrace as posted on comment #1
*********** MASS BUG UPDATE **************
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.
Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.
If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
I just tried replugging my usb disk on the latest kernel update for Fedora 20 (3.17.4-200.fc20.x86_64) and the problem doesn't occur anymore. Thanks for fixing the problem !