From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-0.1.19 i686; en-US; 0.8)
every upgrade I performed fisher->wolverine->rc2 my system hangs after
updating in graphic mode when the procfs will be unmouted.
I use a USB mouse (detected correctly) and when I get the message
'unmounting /proc/bus/usb' the system hangs and after the reboot a fsck
will be perfomed
Steps to Reproduce:
1. update an older system (graphic mode) and usb mouse
2. finish the update process
3. system hangs during reboot
4. last message 'unmounting /proc/bus/usb'
5. fsck is performed after reboot
Expected Results: reboot without hanging system
I have not been able to reproduce this on my hw.
What is your hardware configuration?
Motherboard ASUS CUSL2-C
Proc. Intel Celeron 700 Mhz
Logitech Wheelmouse USB
256 MB RAM
Adaptec 2940 UW
Graphiccontr. Riva TNT2 Vanta
ISDN Fritz Card PCI
3COM 905 TX
What else do you need
Aaron, can you help look at (and possibly reproduce) this on your ASUS board?
We (Red Hat) should really try to fix this before next release.
I'd like to emphasize, that the system works pretty well after the update with
my USB-mouse. The issue is only the update-process itself.
I upgraded yesterday another system (Dell) with an USB-mouse with the same result.
The systems hangs in the shutdown-process directly after the update, performs a
fsck and work form then on without a problem.
Waiting on a system that exhibits this behavior to investigate further.
What is the Dell model #?
I upgraded a Dell Latitude LSt Celeron 400 and the system hung at the same point
after the graphical upgrade has finished.
Brent please see if we have similar hardware available and verify.
See bug #30304.
I wasn't able to reproduce bug #30304 because the machine that exhibited the
behavior for Brock died before I could test it. I haven't seen this behavior on
any of the machines that I've tried with usb devices.
We don't have an exact match for this hardware. In my test machine, I have an
ASUS P28-F motherboard with a Celeron 333MHz in it, and that's the closest match
we have. None of the machines I've done installs on with USB mice demonstrate
this problem. I'm thinking that the problem is between the bios and the kernel
somewhere. The installer is trying to unmount /proc/bus/usb, but the kernel (or
something) won't let go. However, this seems to work fine on all the machines
here.... Reassigning to the kernel.
I my opinion the ASUS P28-F motherboard is not very close to my ASUS CUSL2-C,
because my board is based on the socket370 / Intel 815 EP chipset and your
testboard is based on slot1 / Intel 440 BX chipset.
*** Bug 32237 has been marked as a duplicate of this bug. ***
Just a note - the machine in question in bug 30304 is working and has shown the
lockup using the qa0319.2 tree.
At the point it hangs does capslock work, does switching virtual consoles work ?
I was not able to switch to another console when the system hangs. I haven't
checked capslock - is this of importance?
If Magic Sysrq (Alt-Ctrl-Space), or right_Alt-ScrLock
may provide some information if they work and if
the kernel was compiled with "call trace" enabled.
If only we knew where "mount" hangs.
So far I see only one suspicious place, that is
Oh, I could have spared the effort. Here's a mail from Bill:
Date: Mon, 19 Mar 2001 15:34:29 -0500
From: Bill N. <...>
Subject: hang on unmount of /proc/bus/usb
We're having problems with the unmounting of /proc/bus/usb
on *some* hardware in the install environment.
The call trace from alt-sysrq-p shows it in the unmount
process, with a call trace:
<stuff in modules>
I really need to look at the stuff that's in modules, but
it looks like something in usbdevfs is broken.
So, it's in iput, but not in wait_on_inode? Hmmm....
I got the same problem here, when INSTALLING wolverine on my box, it hangs on
ASUS A7V-133, 384MEG, Razer 2000 USB-Mouse, Two IBM DTLA 307075 as raid0 on
internal Promise IDE-controller, one IBM DRVS09V, one Plextor PX40TS, one Teac
CD-R58S hooked to an Adaptec AHA 2940U2W with latest BIOS. Wolverine is
installed on the scsi-hdd.
*** Bug 35826 has been marked as a duplicate of this bug. ***
Did this ever happen in a 7.2 beta or release?
No, on 7.2 Beta it works fine...
So the bug seems to be fixed.
Honestly, I did not hack anything in usb-storage, but only
tracked what they (Matt Dharm in particular) did on linux-usb-devel.
I did not hear any single report of in in 7.2 either.