Red Hat Bugzilla – Bug 154690
After umounting usb disk drive in KDE screen, mouse and keys locked up
Last modified: 2007-11-30 17:11:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1
Description of problem:
I am using Fedora FC3 with the new 2.6.11 kernel just installed after yum updates on 11th April. Desktop is KDE.
The event sequence is that I had earlier mounted a usb disk ( in /media) and done some copying (backups).
Then the disk had been umounted, and then once the umount had completed, and the file system on the disc checked as not being visible to an ls -l command,
the usb plug was pulled out.
I then checked (as root in a terminal window) that /media no longer
contained the disk, and then did "exit" - at that point the system
froze (i.e. on hitting the return key)
The screen and mouse froze and I could not get to an alternate console
using the ctrl-alt keys. The only option was to re-boot.
This has only happened once with the same system and the procedure has been repeated several times. However today on a different machine but running the same essential setup (but with an athlon chip) the same sequence of events led to the same freeze up. The new kernel was running, and also last night's gcc updates.
There were no obvious lines in /var/log/messages to point to a reason for the behaviour.
Since this is the second time the same symptom has happened on different machines following the same procedure/sequence I felt it should be reported.
However I cannot pin down if it is a problem with the new kernel, or if it is KDE interacting badly with the new kernel.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open a terminal window in KDE, su - to root.
2. Plugin a usb labelled disk, and mount it.
3. umount the disk, and check it is unmounted by doing ls -l /media/usbdisc
4. pull out the usb plug and wait until there is no longer an entry in /media for the usb disc
5. type "exit" and then hit the enter key
Actual Results: Screen, mouse and keyboard froze it was no longer possible to control the machine.
Expected Results: The terminal session should reverted to the user prompt that was there prior to becoming root.
No entries in messages are relevant, and since this occurred on two different machines with different chips the detail of the two machines is probably not relevant
Allow me to give a me too, but with some modification.
My procedure was very similar to yours but I am running Gnome.
This is a ThinkPad T40 and the USB based drive was a USB floppy drive. After
unmounting the diskette, I began closing most of the open windows since I was
getting ready to head out. I yanked the USB plug and a few moments later, went
to close the last gnome-terminal (clicking on the X). The window itself
disappeared though was still listed on the panel, and the mouse and keyboard
froze. It was an su'd to root gnome-terminal. Forced me to hard power off the
The above procedure has never given me a problem in the past, but I have made
the following changes: new kernel-2.6.11-1.14_FC3, and subsequent gcc updates.
I must admit that I have vmware modules that were updated with version 90 of
petr's update (had not needed the update before this) in order to get 4.5.2 to
compile with this new kernel - do not know if that is common with Mike or not.
I have now reproduced this again on the original system - following the exact
same procedure. The machine is a Dell Dimension 2400 unmodified running P4.
I recovered using Alt-SysRq-s followed by Alt-SysRq-b to re-boot the machine but
unable to get any diagnostic information. The problem first occured at the point
the new kernel was installed, but prior to the gcc4 and gcc3 updates. However
now that the gcc4 updates are in the result is still the same.
I also know of another user with the identical software setup who had exactly
this problem when unplugging a USB camera. The crash occurred at the same point.
I have change the severity to high.
Hmm. Comment #2: Did caps lock still work? Could you ssh into the machine and
kill X that way?
Created attachment 113410 [details]
here is the log
i have noticed that when i plug in my USB mp3 player, and unplug it fedora
crashes. nothing strange is written to the logs. no such problems with the
previous kernel. i have switched back to 2.6.10-1.770_FC3.
when it crashes is really does, no alt+ctrl+F1-12, pointer doesn't move, numlock
is stuck. no ssh into the box. but ping still works
I experienced this problem, so I built the stable kernel 18.104.22.168 from
kernel.org, installed it and the problem disappeared.
(I am in the process of filtering about a million patches in the 2.6.11-1.14_FC3
release to see what might have caused the problem, but don't hold your breaths...)
I am experiencing this problem as well on my FC3 system (x86_64 laptop, and I
run Gnome). I tend to see it when I shutdown and pull the USB dongle for my
wireless mouse out of the USB port. If I pull the dongle out right after
initiating a shutdown, it hangs ... I can't remember the message on the virtual
console when it last happened. The system log isn't too helpful:
Apr 12 21:02:40 crush shutdown: shutting down for system halt
Apr 12 21:02:41 crush kernel: usb 2-1: USB disconnect, address 2
Apr 12 21:02:41 crush hal.hotplug: DEVPATH is not set
Apr 12 21:02:41 crush init: Switching to runlevel: 0
Apr 12 21:02:42 crush login(pam_unix): session closed for user xxx
Apr 12 21:02:42 crush login(pam_unix): session closed for user xxx
Apr 12 21:02:42 crush gdm(pam_unix): session closed for user xxx
Apr 12 21:02:43 crush cups-config-daemon: cups-config-daemon -TERM succeeded
Apr 12 21:02:43 crush haldaemon: haldaemon -TERM succeeded
Apr 12 21:02:43 crush messagebus: messagebus -TERM succeeded
Apr 12 21:02:43 crush atd: atd shutdown succeeded
Apr 13 09:44:48 crush syslogd 1.4.1: restart.
I wish there was a way to stop users from gang-banging on Mike's bug.
File your own!
Mike, please capture the dmesg at the moment after you do ls -l and
before you exit terminal. Do not drop it in the comments box, attach instead.
Also, the comment #3 obviously has a hole in it. SysRq only works once
X stopped, but the original procedure says nothing about it. So, in between?
How was X ended, Cltr-Alt-Backspace?
I will try to do what you suggest in the next day or so when I get a moment.
In the meantime I should clarify the end sequence which is as follows:
I did not do ctrl-alt-backspace.
After the ls -l /media, which worked fine, X was still running ok, in the
terminal window I started typing "e" "x" "i" "t", and X was still running at
As soon as I hit the "Enter" key to complete that command X froze and I could
not recover. That was the point at which alt-sysrq-s and alt-sysrq-b were
entered in sequence to re-boot.
I will try again tomorrow - and at that point try to exit X using
ctrl-alt-backspace but I believe the crash may have not been just X but the
I will report back when I have done this test and include the dmesg output from
prior to hitting the return key.
(In reply to comment #8)
> I wish there was a way to stop users from gang-banging on Mike's bug.
> File your own!
> Mike, please capture the dmesg at the moment after you do ls -l and
> before you exit terminal. Do not drop it in the comments box, attach instead.
> Also, the comment #3 obviously has a hole in it. SysRq only works once
> X stopped, but the original procedure says nothing about it. So, in between?
> How was X ended, Cltr-Alt-Backspace?
Created attachment 113517 [details]
Terminal session with added comments showing the sequence of events
This is the terminal session with my added comments as it led to the system
Created attachment 113518 [details]
dmesg prior to umounting the usb drive and prior to unplugging the drive
dmesg output 1
Created attachment 113519 [details]
dmesg immediately prior to system crash
dmesg output immediately prior to system crash after umounting and after
unplugging the usb line, but prior to the exit command from the root session
Created attachment 113520 [details]
dmesg output after rebooting
dmesg output after recovery using alt-sysrq-b to reboot the machine
Mike, you may find a newer kernel solves the problem. I installed
2.6.11-1.19_FC3 from http://people.redhat.com/davej/kernels/Fedora/FC3/ and I
could no longer reproduce the symptoms you are describing...
Regarding Pete Zaitcev's comment in Comment #8 ("I wish there was a way to stop
users from gang-banging on Mike's bug. File your own!") ...
Here is a quote from the Redhat bugzilla help page
One of the first things you should do is to see if your bug is in our most
frequently reported bugs list. If one similar to yours has already been
reported, you may be able to add more information to it or add yourself to the
Cc list of the bug so you will know when and how it is fixed.
The above guideline makes sense to me - if we all opened separate bugs, they
would just be quickly marked as a duplicate of this bug and then closed, which
seems like a lot of extra work with no benefit to anyone.
So, my apologies if my "me too" comment wasn't helpful because your policies
have changed. However, I would suggest that you update your help page!
I have today installed kernel 2.6.11-1.20_FC3 from updates-testing - with this
kernel the bug reported here no longer occurs, and after unplugging the usb plug
on the external drive the system continues to run normally.
Mike 30th April 2005
great! thanks for testing.
Should bug #155472 be marked a dup of this one (or vice versa but I'm not a fan
of forward duping)?
I will leave others to make that decision as I am only using KDE whereas the bug
referred to is for Gnome. I am currently using kernel 2.6.11-1.27_FC3 from
updates-testing - and the problem has not recurred. I believe that this kernel
will soon be made available in the normal updates so for most people yum will
pick it up when it becomes available (unless there are more changes before it is
Mike 22 May 2005
*** This bug has been marked as a duplicate of 155472 ***