Bug 806909 - F16: kernel 3.3.0-4.fc16.i686.PAE: Fails to umount SDCARD USB disk properly
Summary: F16: kernel 3.3.0-4.fc16.i686.PAE: Fails to umount SDCARD USB disk properly
Status: CLOSED DUPLICATE of bug 808109
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 16
Hardware: i686
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-26 13:29 UTC by Terry Barnaby
Modified: 2012-04-02 12:12 UTC (History)
10 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2012-03-29 12:49:24 UTC


Attachments (Terms of Use)

Description Terry Barnaby 2012-03-26 13:29:52 UTC
Description of problem:
I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having
problems with a SDCARD card connected to a USB card reader. This has
been working fine until recently (at least in F14 on the same hardware).

The problem is that "umount" does not appear to be working correctly.
I have an ext3 file system on the card. I can mount it, and I can copy
files to it. However when I use the "umount ..." command it returns
instantly (should sync the files to the card). The system says the card
is unmounted (at least it is not listed with mount, df etc).

However if I run sync, there is a lot of disk activity to the card ...

Also if I try and run "mkfs" it says the device in in use ...
If I mount a blank card it lists the files present on the previous card ...

This sounds like a very nasty kernel bug ...

Tried it on two different Fedora systems.
Kernel 3.2.9-2.fc16.i686.PAE appears to work fine ...

Version-Release number of selected component (if applicable):
Kernel 3.3.0-4.fc16.i686.PAE

How reproducible:
Always.

Comment 1 Konrad Karl 2012-03-27 13:45:06 UTC
I have similar problems with arbitrary USB memory sticks:
(F16 x86_64, KDE desktop, kernel 3.2.10-3 and 3.3.0-4)

In my setup I am using a luks (cryptsetup) partition formatted with ext4.
after copying a big (~40MB) file and then unmount the umount command returns
almost immediately and a sync command causes led activity of several seconds
on the memory stick.

After that I cannot luksClose the device any more (busy msg) and dmsetup table
shows that it is still active. Pulling the USB stick genereates log activity like:

usb 1-3: USB disconnect, device number 4
Aborting journal on device sdd1-8
JBD2: I/O error detected when updating journal superblock for sdd1-8
journal commit I/O error
EXT4-fs error (device sdd1): ext4_journal_start_sb:327: Detected aborted journal
EXT4-fs (sdd1): Remounting filesystem read-only

Note that the fs has already been unmounted...

However: trying the same in emergency.target or multi-user target does not
trigger the same behavior - all seems normal: the umount command waits until
the buffers are written to the mem stick and luksClose closes as expected.
(tried several times with both kernels)

So this might be caused by some recent user space changes. Kernel 3.3.0-4
has some problems with SATA hotplug (Intel ICH8 - the symptoms are similar).

Hope the mess can be cleaned up soon.

Comment 2 Germano Massullo 2012-03-28 11:30:26 UTC
maybe related/duplicate? https://bugzilla.redhat.com/show_bug.cgi?id=747114

Comment 3 Konrad Karl 2012-03-28 15:51:31 UTC
pls look at my comment about cups, BZ 747114

(disabling cups made the system behaving well again)

Comment 4 Konrad Karl 2012-03-28 16:23:53 UTC
back to cups-1.5.2-1 on F16 x86_64. (all later koji versions cause this bug)

umount is OK again. see BZ 747114 for details

Comment 5 Adam Williamson 2012-03-28 17:29:38 UTC
Terry, can you let us know if cups is the problem for you too? If so, we can close this as a dupe.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 6 Terry Barnaby 2012-03-29 09:40:04 UTC
Yes, just tried it. It the system is booted without starting the cups service then un-mounting USB disks is fine !

How on earth can this be ? Disk data storage is sacrosanct and the Linux kernel should ensure data safety ...

Comment 7 Konrad Karl 2012-03-29 11:12:34 UTC
I think something else (systemd ?) mounted the device too (I am unable to see it in findmnt output though), so your umount is not the last one which will sync the disk buffers.

BZ 807672 seems also to be related. see my comment from today: if you
stop cups then mount your USB disk then restart cups -  stop cups again before umount then it should work OK (at least here it does with cups-1.5.2-8 from koji)

Comment 8 Adam Williamson 2012-03-29 12:49:24 UTC
wwoods was having lots of trouble with loop devices yesterday, that went away when he disabled cups.

it seems clear that cups has screwed some kind of pooch seriously badly, here. let's dupe 'em all off.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

*** This bug has been marked as a duplicate of bug 747114 ***

Comment 9 Tim Waugh 2012-04-02 12:12:51 UTC

*** This bug has been marked as a duplicate of bug 808109 ***


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