Bug 30696
Summary: | [usb] Installer hangs unmounting /proc/bus/usb after upgrade finishes | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Joachim Kunze <jkunze> |
Component: | kernel | Assignee: | Pete Zaitcev <zaitcev> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brock Organ <borgan> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | abrown, benl, irc |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-09-25 08:57:49 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Joachim Kunze
2001-03-05 21:09:52 UTC
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 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 usb_devfs_put_super=>iput=>clear_inode=>wait_on_inode. 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: iput <stuff in modules> kill_super read_super I really need to look at the stuff that's in modules, but it looks like something in usbdevfs is broken. Bill --------------------------- So, it's in iput, but not in wait_on_inode? Hmmm.... Hi, I got the same problem here, when INSTALLING wolverine on my box, it hangs on dismounting /proc/bus/usb. Hardware: 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. |