Safely removing external (usb) hdd's can cause a kernel panic or system freeze

Some additional - when this occurs
On the drives with ext. power buttons, when the panic or freeze occurs it is immediate, the drive isn't even unmounted
On a drive with no power button there is a slight delay, the drive is unmounted & powered off, then the panic/freeze occurs

In all cases there is nothing written to ~/.xsession-errors or the syslog
The same is seen whether using nautilus to SR or the drive icon in the unity launcher to SR

Have re-tested this today on live session w/ daily of 09/10
Still the same though in this case the effect is a bit more 'clear', immediately get thrown to a tty with a kernel panic
While this may not be the direct fault of g-s-d & the helper it's certainly affected., & disabling the helper is the only way seen to prevent
On real beta 1 install have tried w/ some earlier kernel versions going back to 3.0.0-08, same deal, KP's about 50% of the time

I'm experiencing this too, however on amd64 (and no Nvidia modules - Intel GM45 chipset here). My un-scientific estimate of when this started to happen is approximately 2 weeks ago.

I managed to capture an oops without my notebook panicking. Attached are the relevant bits from dmesg.

This may in fact be more a kernel bug than something in g-s-d, as indicated by the Debian bug I just linked to.

Certainly seems to be a kernel issue, possibly g-s-d should be invalid, or maybe you should create a new bug
The only thing here is that if I don't let g-s-d automount the drive w/ the helper then at least w/ the 3 drives I have SR always works fine.

Went back again to 11.04, (2.6.38-9), to re-test using all my drives this time and found that 2 drives worked fine but 1 did produce a panic.
The 1 that panics does not have a power switch on the drive, the 2 that are ok both have a switch on the drive...?

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

Confirmed again here also. Tested with a WD 1TB "My Passport" drive, formatted with a single NTFS partition. Kernel panic on very first attempt to remove it.

Have we ascertained whether this bug is specific to drives containing an NTFS partition? I saw that theory being bounced around earlier.

Still happens here with all external drives whether they have a power switch or not
3.0.0-12-generic #19-Ubuntu SMP

As before if the 'gnome-fallback-mount-helper' is removed from the startup & the drives are mounted manually thru nautilus then safely remove works fine.

Also to note that the 3 drives I have are all ntfs, can redo 1 if needed

I had this on an external ext4 lenovo hdd.. haven't tried anyway if with latest kernel is solved.

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

I have the latest updates and kernel 3.0.0-12-generic #19-Ubuntu SMP but the problem still occurs.
When I safely remove the external USB HD, my PC freezes, can't do anything but push reset button to restart it.

root@charlie02:/home/charlie# lsb_release -a
LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch
Distributor ID: Ubuntu
Description: Ubuntu oneiric (development branch)
Release: 11.10
Codename: oneiric

When booting I get this message:
ata_id[2981]: HDIO_GET_IDENTITY failed for '/dev/sdf': Invalid argument

Not sure has to do with this problem, /dev/sdf is the external USB HD I got problems with.

Seems to be the same as bug 793796, maybe you can try out some of the test kernels from there.

@Doug and others that are affected by this bug:

Is the external hard drive formatted as NTFS? If so, can you test with another filesystem, such as ext3 or ext4 to see if the issue is limited to NTFS? This may be a duplicate of bug 867811

We would like to review the details of the panic. Do you have a screen shot or the text details of the panic that you could provide?

Is this already fixed by upstream 3.0.5 or 3.0.6, as stated in the Debian package changelog?

The patch noted to resolve the Debian bug report indeed was included in the v3.0.5 upstream stable kernel. We have subsequently queued the v3.0.5 and v3.0.6 stable patches for Oneiric and I can confirm the specific patch in question has been applied to our Oneiric git repo:

~/ubuntu-oneiric$ git show 0a23710c671e2a8a27ac5dbf690349647e698333
commit 0a23710c671e2a8a27ac5dbf690349647e698333
Author: Hannes Reinecke <email address hidden>
Date: Wed Sep 28 08:07:01 2011 -0600

    block: Free queue resources at blk_release_queue()

However, due to the fact that we are in Final Freeze, the v3.0.5 and v3.0.6 stable patches have been queued for the first Oneiric SRU release. In the mean time, I'll try and get a test kernel available for people to try. Please stay tuned.

I've posted both an amd64 and i386 test kernel to the following location. Please test and let me know your results. Thanks.

http://people.canonical.com/~ogasawara/lp844957/

With the test kernel (i386), have tested with a WD external, ntfs, the drive has no power switch
Did 6 connects & safely removes - all went well, no panic
Also tried a seagate that has it's own power switch, the same, no panics.

Thanks Doug for the quick test turnaround and feedback. This appears to confirm that we have to appropriate fix queued in our repo and it should be available in the first Oneiric SRU. Please continue to use the test kernel in the mean time until the first Oneiric stable release update for the kernel is available. Since you are also the original bug reporter, I'm marking this Fix Committed for now. Should anyone else test and discover this hasn't resolved the issue for you, please open a new bug report as you are likely experiencing a different issue which will require a separate fix. Thanks.

super crappy bug.
Still happening. :(

I had this happen twice in a row using 11.1 Oneiric ejecting a 1TB Western Digital disk.

Then twice tried to reproduce on a 2G USB thumb drive - no error, then back the WD - no error again twice.

I was also experiencing this bug and can confirm that with the test kernel in #20, I have not seen it again.

Sorry for a probably stupid question, but how do we find out the status of SRUs? I've looked at the <a href="http://people.canonical.com/~ubuntu-archive/pending-sru">Pending Ubuntu SRUs</a> page, and can't see this bug listed, or any kernel update. This bug annoyed the hell out of me when it <a href="https://bugs.launchpad.net/bugs/811745
">popped up in Lucid</a> a while back, and I want to hold off on upgrading to Oneiric until it's stamped out again.

Hi Myk,

The Pending Ubuntu SRU's page notes that "there is a separate report for Kernel updates." and there is a link provided. Unfortunately the link to the separate kernel report seems to point to an invalid location. IIt should point to the following:

http://people.canonical.com/~kernel/reports/sru-report.html

I'll notify the appropriate individuals to fix the invalid link.

You will however notice this bug still does not appear even on the separate kernel sru report. That is first because they have not yet uploaded the first Oneiric kernel SRU. Secondly, even if it were uploaded, the patch from the v3.0.5 upstream stable update which fixed this bug did not have this bug number inserted into the commit message and changelog. As a result, neither the launchpad janitor nor the kernel team reporting scripts would have been able to detect this bug.

So, in order for those of you here to receive the appropriate notifications for when the kernel containing this fix will officially land in oneiric-proposed and eventually be released, I'm going to mark this as a duplicate of the v3.0.5/v3.0.6 stable release tracking bug 868628 . Thanks.

I confirm that test kernel on step #20 resolves bug in amd64.

Can someone confirm that kernel 3.0.6 release has fixed this bug?

linux (3.0.0-13.21) oneiric-proposed; works fine here, no panics

I can also verify that #20 fixed the problem on my machine also

I am also getting this bug and would like to try the test kernels posted but do not know how. I see the patch and amd64 .deb files. I'm assuming I just run them in software centre, but what do I do with the patch?

@Christopher Jazzcat:

You need to enable the -proposed repository and upgrade the linux-generic, linux-image-generic, linux-header-generic, linux-libc-dev, linux-source packages (if any of those is not installed on your machine, ignore it).

To enable the -proposed repository, using USC, follow the instructions on this page: https://wiki.ubuntu.com/Testing/EnableProposed . After upgrading the kernel, depending on the method used, you can disable the -proposed repository.

I just saw this report and I can confirm that later kernels do not have this bug. I tested with 3.1 and 3.2 daily. I will also test the kernel in comment #20.

3.1 daily built from 04th of nov 2011 seems to have fixed it:
Linux florin-Satellite-C650 3.1.0-999-generic #201111070407 SMP Mon Nov 7 09:08:05 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

As well as daily 3.2 from 8th of nov 2011:
florin@florin-Satellite-C650:~$ uname -a
Linux florin-Satellite-C650 3.2.0-999-generic #201111080407 SMP Tue Nov 8 09:08:33 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

The kernel in comment #20 seems to fix this bug for me, too.