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): How reproducible: Sometimes 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. Additional info: 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 laptop. 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. Mike
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
hello all, 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 manojav
I experienced this problem, so I built the stable kernel 2.6.11.7 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[9185]: DEVPATH is not set Apr 12 21:02:41 crush init: Switching to runlevel: 0 Apr 12 21:02:42 crush login(pam_unix)[4299]: session closed for user xxx Apr 12 21:02:42 crush login(pam_unix)[7423]: session closed for user xxx Apr 12 21:02:42 crush gdm(pam_unix)[5926]: 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 that moment. 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 kernel too. I will report back when I have done this test and include the dmesg output from prior to hitting the return key. Mike (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 crash
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 [https://bugzilla.redhat.com/bugzilla/easy_enter_bug.cgi]: -------------------- 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 released) Mike 22 May 2005
*** This bug has been marked as a duplicate of 155472 ***