USB memory stick light stays on after "safely remove" (KDE)

Bug #90097 reported by kko
48
This bug affects 5 people
Affects Status Importance Assigned to Milestone
hal (Ubuntu)
Invalid
Undecided
Unassigned
kubuntu-meta (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Hello.

I didn't know whether to file this against 'dbus', 'hal', or some other package. Since I am on Kubuntu Dapper, I decided on 'kubuntu-meta'. (I hope I haven't misunderstood the purpose of that package.) However, it seems probable that the same issue is present also when using Gnome.

After I "safely remove" a USB memory device (and 'sync', or instead of "safely removing" do 'sudo umount' for it), the device light isn't turned off, as would be expected. My question is, which process is / should be responsible for powering off the USB stick?

If the physical device would show that it was powered off after a "safe remove", trusting the process not to cause data loss (see bug #61946) would be a lot easier.

(I don't really expect 'sync' or 'sudo umount' to do anything to the light, they're included only to make sure that the device gets properly unmounted.)

kko (kko)
description: updated
Changed in kubuntu-meta:
status: Unconfirmed → Confirmed
Revision history for this message
Eddie M. (eddiemartinez) wrote :

Is this a problem with the sole USB stick (ie do others work fine) or is it a software issue?

Are there any issues with performance?

Changed in kubuntu-meta:
status: Confirmed → Needs Info
Revision history for this message
Freddy Martinez (freddymartinez9) wrote :

assigning to Eddie temporarily

Changed in kubuntu-meta:
assignee: nobody → eddiemartinez
Revision history for this message
Wit Wilinski (wit-wilinski) wrote :

'Safely remove' unmounts the device, so the light on the usb-storage device means nothing. Umount syncs all cached data to the device, so it can be removed any time, after umount has finished.

I have never had an issue with data loss after umounting a device (while I had a problem once, when I forgot to umount it;)

Revision history for this message
kko (kko) wrote :

Wit Wilinski:
- I know to wait (and ensure) that the device has been properly unmounted. Judging, however, by the report I referenced, and its duplicates, many - understandably, IMO - don't.
- I also know that the light "means nothing", technically speaking. Psychologically speaking, it would be a very good signal to (physically) show that the process of unmounting the device has run its course.

posingaspopular:
- Thanks for your concern on this issue.
- I have had no performance issues, everything works fast enough, without noticeable delay.
- I haven't tested with more than one USB stick, so I can't really answer that question. What I can say that when using the same USB stick on someone else's Windows-computer, the light gets turned off at this point, so the device itself doesn't seem to be the problem. Are you saying that different USB sticks (may) behave differently in this regard?
- I recently used the device on the library's Ubuntu (Gnome) machine - I believe they're running Breezy - and got the same behaviour, i.e. the light stayed on.
- Finally, as I wrote, I don't really know what process is / should be responsible for powering off the device, but I'm really curious to know. :-)

Revision history for this message
Piero Ottuzzi (ottuzzi) wrote :

Hi there,

to reproduce the data loss simply copy on a pendrive 200-300MBytes, unmount it through context menu on the desktop and remove the pendrive when the icon disappear from the desktop.

Bye
Piero

Revision history for this message
Wit Wilinski (wit-wilinski) wrote :

IMO turning off the LED on usb-storage device would involve patching the kernel, so this bug should probably be reported upstream, not in K/Ubuntu.

I use pretty stock Kubuntu system (just kernel is self-compiled) and desktop icons for removable devices disappear _after_ umount finishes (eg. i get an ugly dialog window with a progress bar at 0%, which then suddenly changes to 100% after umount exits). At this point, all data is flushed, so the device is safe to remove.

Tested with iPod Shuffle and 2.5" laptop drive in USB2 enclosure.

Revision history for this message
kko (kko) wrote :

To clarify:
- This report is not directly about "data loss", nor is it about the desktop icons. The possibility of data loss is simply an additional motivation for the report, and data loss is therefore best discussed elsewhere to keep the discussion here "on topic".

As Wit Wilinski says, fixing this may well involve patching the kernel. However, I disagree on the suggested bug reporting policy:
- As I understand it, (k)ubuntu bugs get reported here. This is the method that is the most accessible for ubuntu users, and this is where ubuntu users are directed to report bugs.
- The bugs may (and often do) get reported also upstream. This is what the Launchpad links to other bug trackers serve for. (The bugs may also get reported in other distributions' bug trackers.)
- In my understanding, the essential part of the Launchpad philosophy is to try to integrate different sources of bug information. The particular developer who eventually happens to fix the bug may come from Ubuntu, the kernel people, or somewhere else - it doesn't really matter in the end.

Revision history for this message
kko (kko) wrote :

So, any more information I can provide that you'd consider useful?

Is this dependent on the hardware (USB controller, memory stick), do you want the details? Do your memory sticks get un-lighted in linux?

Want me to go and buy a new memory stick to test with? ;-) (Seriously, wouldn't help, since I'd probably get the same make & model as I already have...)

Revision history for this message
Laur Mõtus (vprints) wrote :

No, this is definetly confirmed from me on different sticks.
Honestly, i have also had several people asking me why the light dosen't shut off like in Windows and really doubting if it is secure to unplug it that way.

Revision history for this message
zsquareplusc (zsquareplusc) wrote :

I have the same issue on standard Ubuntu. it is that after unmounting the PQI and Sandisk sticks keep their LED on on Linux while both do switch off the light on WIndows. The Swissbit stick switches the LED off on both OS.
As others already mentioned, there is no performance problem or data loss. It would just be nice to have the visual feedback that it is safe to unplug, on the stick directly.

Changed in kubuntu-meta:
assignee: eddiemartinez → kubuntu-team
Revision history for this message
ssuuddoo (ssuuddoo) wrote :

I fully agree.
would be nice. On Win it turns off, but on Tux it doesnt.

Revision history for this message
kripken (kripkenstein) wrote :

I can also confirm this bug, on both Ubuntu and Xubuntu. So this bug appears to be a general issue, not specific to Kubuntu. The symptom is, as with all others, that the light on USB drives stays on after unmounting.

There seems to be no data loss, the issue is only 'aesthetic'. However, this aesthetic issue is *very important* to new users of Ubuntu, who will assume the drive has not been properly unmounted/ejected/etc.

Revision history for this message
kripken (kripkenstein) wrote :

This bug is still marked 'incomplete'. Is there any particular additional information necessary? It appears to be confirmed by several independent sources based on the above discussion.

Revision history for this message
ssuuddoo (ssuuddoo) wrote :

I dunno and think all information as a feedback and "bug" description is already here.

thumbs up

Revision history for this message
Monster_user (cj-art) wrote :

Actually, I think this should be put to the Ubuntu team, instead of the Kubuntu team.

I believe the issue is that in Windows, the USB port is powered down. While in Kubuntu, the disk is only unmounted. The device is not powered down. This means that there is electricity going to the other device.

So the problem is not that the lights on USB devices stay on, but that there are no scripts in Linux to power down the USB ports.

For hot-pluggable devices, especially USB flash drives, this is not a concern. The devices were designed to be unplugged while powered. As long as they are cleanly unmounted, they will be fine.

Revision history for this message
kripken (kripkenstein) wrote :

I agree, this is a general issue, not Kubuntu-specific. I think the bug should be moved to be relevant to Ubuntu.

Revision history for this message
Ryan Kavanagh (ryanakca) wrote :

Any idea to what package we should move it to? kernel?

Changed in kubuntu-meta:
status: Incomplete → Confirmed
Revision history for this message
ssuuddoo (ssuuddoo) wrote :

no particular idea.

I think, yes, to KERNEL. the people there will have the clue what 2 do with it.

thnx

Revision history for this message
kripken (kripkenstein) wrote :

I am no expert, but my guess would be that this is relevant to both the 'mount' package and/or the underlying kernel calls that mount uses.

Mount might be better in that it is more specific than 'kernel', and hopefully the relevant people there will know quickly if this is a problem with mount or an underlying kernel issue. Again, just my guesses, other people here probably know more about this stuff than me.

Revision history for this message
Lupus (mickael-wolff) wrote :

Hi,

I guess it is not a bug, it is a regular behavior. Mount/umount is a filesystem relative tool, it has no relationship with hardware management. So, the problem with data loss is irrevelant.

I think this issue must be send to the « Desktop team », to decide if we have to add some « Disconnect » entry in the popup menu instead of « Unmount ». In this case, the led (so the usbkey), can be switch off.

(please apologize my english, i'm french)

Changed in kubuntu-meta:
assignee: kubuntu-team → nobody
Revision history for this message
Michael Doube (michael-doube) wrote :

Hey, have you checked out bug #58706 ? It suggests using eject (from the command line) instead of unmount. Can you try that, then mark this as a duplicate, if eject works to turn off the LED?

Revision history for this message
kripken (kripkenstein) wrote :

Michael,

I tried 'eject' instead of 'umount', but the USB light stays on. This is on a Sandisk Cruzer, OS is Hardy.

Revision history for this message
naught101 (naught101) wrote :

While this so far hasn't been a data-loss issue, It may become one, since it doesn't only apply to USB flash drives, but also USB powered laptop harddrive enclosures.

When unmounting my specific hard drive (WesternDigital Elements 250GB), as well as the light remaining on, the HDD platters continue to spin indefinitely. My only option is to unplug it while it's spinning. I'm sure this isn't good for the drive.

On the other hand, I have the same issue in windows with particular drive (disks continue spinning after being "safely removed"). It might just be a badly designed drive (lsusb, below, says it's self-powered, which is wrong), and in that case, powering it down would probably have the same effect as simply unplugging it.

Bus 005 Device 021: ID 1058:1010 Western Digital Technologies, Inc.
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 64
  idVendor 0x1058 Western Digital Technologies, Inc.
  idProduct 0x1010
  bcdDevice 1.05
  iManufacturer 1 Western Digital
  iProduct 2 External HDD
  iSerial 3 575845353038504A35393537
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 32
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xc0
      Self Powered
    MaxPower 2mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 2
      bInterfaceClass 8 Mass Storage
      bInterfaceSubClass 6 SCSI
      bInterfaceProtocol 80 Bulk (Zip)
      iInterface 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0200 1x 512 bytes
        bInterval 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x02 EP 2 OUT
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0200 1x 512 bytes
        bInterval 0
Device Qualifier (for other device speed):
  bLength 10
  bDescriptorType 6
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 64
  bNumConfigurations 1
Device Status: 0x0001
  Self Powered

Revision history for this message
Geoff123 (gsking1) wrote :
Download full text (4.5 KiB)

I can also confirm this with the Sandisk Cruzer Micro 2.0GB. On Windows XP the light goes off when using the Windows Safely Disconnect dialog or the built in Sandisk software to disconnect.

On Ubuntu 8.04. The disk can be easily used/mounted/unmounted/ejected, but the light ALWAYS stays on. I've not had any corruption issues, but I am careful to umount/eject.

dmesg and lsusb are included below...

[ 1858.662100] usb 5-2: new high speed USB device using ehci_hcd and address 6
[ 1858.794837] usb 5-2: configuration #1 chosen from 1 choice
[ 1858.795054] scsi4 : SCSI emulation for USB Mass Storage devices
[ 1858.795195] usb-storage: device found at 6
[ 1858.795199] usb-storage: waiting for device to settle before scanning
[ 1863.787287] usb-storage: device scan complete
[ 1863.787789] scsi 4:0:0:0: Direct-Access SanDisk U3 Cruzer Micro 3.27 PQ: 0 ANSI: 2
[ 1863.788284] scsi 4:0:0:1: CD-ROM SanDisk U3 Cruzer Micro 3.27 PQ: 0 ANSI: 2
[ 1863.789639] sd 4:0:0:0: [sdc] 3995648 512-byte hardware sectors (2046 MB)
[ 1863.790262] sd 4:0:0:0: [sdc] Write Protect is off
[ 1863.790266] sd 4:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 1863.790268] sd 4:0:0:0: [sdc] Assuming drive cache: write through
[ 1863.793380] sd 4:0:0:0: [sdc] 3995648 512-byte hardware sectors (2046 MB)
[ 1863.794008] sd 4:0:0:0: [sdc] Write Protect is off
[ 1863.794012] sd 4:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 1863.794014] sd 4:0:0:0: [sdc] Assuming drive cache: write through
[ 1863.794018] sdc: sdc1
[ 1863.795460] sd 4:0:0:0: [sdc] Attached SCSI removable disk
[ 1863.795504] sd 4:0:0:0: Attached scsi generic sg3 type 0
[ 1863.799746] sr1: scsi3-mmc drive: 8x/40x writer xa/form2 cdda tray
[ 1863.799800] sr 4:0:0:1: Attached scsi CD-ROM sr1
[ 1863.799844] sr 4:0:0:1: Attached scsi generic sg4 type 5
[ 2609.361907] usb 5-2: USB disconnect, address 6

root@blaster:~# lsusb
Bus 005 Device 007: ID 0781:5406 SanDisk Corp. Cruzer Micro 4GB Flash Drive
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 002: ID 049f:0051 Compaq Computer Corp. KU-0133 Easy Access Interner Keyboard
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 002: ID 046d:c03d Logitech, Inc.
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

root@blaster:~# lsusb -v

Bus 005 Device 007: ID 0781:5406 SanDisk Corp. Cruzer Micro 4GB Flash Drive
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 64
  idVendor 0x0781 SanDisk Corp.
  idProduct 0x5406 Cruzer Micro 4GB Flash Drive
  bcdDevice 0.10
  iManufacturer 1 SanDisk Corporation
  iProduct 2 U3 Cruzer Micro
  iSerial 3 000016215273E352
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 32
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0x80
      (Bus Powered)
    MaxPower ...

Read more...

Changed in kubuntu-meta:
status: New → Invalid
Revision history for this message
Eddie Dunn (eddie-dunn) wrote :

This would perhaps be a bug suitable for the Papercut project?

Revision history for this message
growingneeds (growingneeds) wrote :

Please look into providing an option to power down the device. My USB HDD always spins even after issuing umount. I have since relegated 1 ext HDD to the dumps. This new HDD that I own, well, I only plug it into Windows now, for fear that this too will break down.

Revision history for this message
frizzle21 (frederik-nnaji) wrote :

obviously, a hardware component of the USB memory devices is not correctly addressed, regardless whether the effects of this are more psychological or performance related.

i had this error with all of my memory sticks, other people's memory sticks, and LEDs not flashing happened with some of the wireless adapters too, in earlier distributions.

perhaps the wireless driver guys have an idea how to fix the led issue!?
they obviously attacked the problem somehow, i suppose

Revision history for this message
Daniel Lombraña González (teleyinex) wrote :

I can confirm this bug in another Ubuntu 8.04 Hardy. The leds never are powered off, while in Windows computers it does. It would be very helpful for users to get the LED powered off, after ejecting the memory.

Revision history for this message
Geoff123 (gsking1) wrote :

Hello. Just noting that this is still happening on Karmic (see my older post #24 from hardy).
No problems as long as you eject the device from within KDE.
FWIW - it also happens on a relatively new Macbook.

Revision history for this message
Francesco (supcobet) wrote :

Hello, maybe I can add some more info.
I have KDE 4.9.5 on Kubuntu 12.10 (kernel 3.5.0-25-generic) and the light remains on if I "safely remove" my Dikom USB-
If I type "eject" it by terminal command, it's umounted and the light turns off after been umounted.
This also happened with prevoius KDE version (before my last upgrade).
Just to give further info, with KDE 4.9.4 on Fedora (kernel 3.6.10-4.fc18.x86_64) the light turns off both from KDE and by eject command. The same correct behaviour I get with Linux Mint with Mate 1.4.0 and kernel 3.5.0-25-generic-

As someone said the user is expecting the light turns off after flashing when you unmount it. Now that I know this "bug" I just wait it end flashing and the light remains still ON

Revision history for this message
dino99 (9d9) wrote :
Changed in hal (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.