Bug 1122019

Summary: Oops after plugging USB disk
Product: [Fedora] Fedora Reporter: Ricardo Fernández Pascual <ricardof>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: djh, florian.judith+fedbug, gansalmon, htl10, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab, ricardof
Target Milestone: ---Flags: jforbes: needinfo?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-10 14:59:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Photo of oops with 3.15.6-200
none
Photo of oops with 3.15.4-200
none
Output of dmesg with 3.15.4 none

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 !