Bug 1122019 - Oops after plugging USB disk [NEEDINFO]
Summary: Oops after plugging USB disk
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1121334 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-22 11:16 UTC by Ricardo Fernández Pascual
Modified: 2014-12-12 20:39 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-10 14:59:50 UTC
jforbes: needinfo?


Attachments (Terms of Use)
Photo of oops with 3.15.6-200 (1.24 MB, image/jpeg)
2014-07-22 11:16 UTC, Ricardo Fernández Pascual
no flags Details
Photo of oops with 3.15.4-200 (1.21 MB, image/jpeg)
2014-07-22 11:17 UTC, Ricardo Fernández Pascual
no flags Details
Output of dmesg with 3.15.4 (72.22 KB, text/plain)
2014-07-22 11:18 UTC, Ricardo Fernández Pascual
no flags Details

Description Ricardo Fernández Pascual 2014-07-22 11:16:23 UTC
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.

Comment 1 Ricardo Fernández Pascual 2014-07-22 11:17:56 UTC
Created attachment 919886 [details]
Photo of oops with 3.15.4-200

Comment 2 Ricardo Fernández Pascual 2014-07-22 11:18:42 UTC
Created attachment 919887 [details]
Output of dmesg with 3.15.4

Comment 3 Josh Boyer 2014-07-24 12:25:55 UTC
*** Bug 1121334 has been marked as a duplicate of this bug. ***

Comment 4 Hin-Tak Leung 2014-08-04 22:40:25 UTC
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...

Comment 5 florian.judith+fedbug 2014-09-20 08:01:04 UTC
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 ?

Comment 6 Hin-Tak Leung 2014-09-21 20:03:10 UTC
(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

usb-storage.quirks=0bc2:3320:u 

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

Comment 7 florian.judith+fedbug 2014-09-22 19:01:46 UTC
(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
> 
> usb-storage.quirks=0bc2:3320:u
> 
> 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
> eventually...).
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.

Comment 8 djh 2014-10-03 06:24:28 UTC
I just got the same backtrace as posted on comment #1
3.16.3-200.fc20.x86_64

Comment 9 Justin M. Forbes 2014-11-13 15:59:48 UTC
*********** 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.

Comment 10 Justin M. Forbes 2014-12-10 14:59:50 UTC
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.

Comment 11 florian.judith+fedbug 2014-12-12 20:39:36 UTC
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 !


Note You need to log in before you can comment on or make changes to this bug.