Bug 90735 - installer hangs when doing usb-storage probe
Summary: installer hangs when doing usb-storage probe
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-05-13 03:03 UTC by greg hosler
Modified: 2007-11-30 22:06 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-04 00:10:17 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description greg hosler 2003-05-13 03:03:16 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
when booting cambridge a 1, I have a usb with a plextor cdrw plugged in, it is
on. I also have a usb hard disk plugged in, it is off. When the installer gets
to the usb probe, it hangs.

I can go to the VC's, but I do not see any hints on VC3 or VC4

if I turn the usb disk on, and reboot, the installed will continue
as per normal.

note that all prior betas, and releases:

     1) would always do the initial usb probe (but hang for a few
        seconds only if the usb disk was turned off)

     2) if a subsequent modprobe on the usb-storage module was ever
        issued, then that modprobe would hang until a reboot.

it appears that the 2nd item is now happening during the new install scenerio.


Version-Release number of selected component (if applicable):
cambridge a 1

How reproducible:
Always

Steps to Reproduce:
1. not sure if you need both a usb cdrom, and usb disk, with disk off, and cdrom
on. I can retry if you need the data point.
2. boot.
3. at the usb-storage probe, system hangs.

_might_ also be usb controller related. is you need add'l info about the
controller, let me know what you need.
    

Actual Results:  install hangs. need to turn on usb disk, and reboot (and this
is not at all obvious to the uninitiated.

Expected Results:  no hang

Additional info:

see "steps to reproduce" and "description" for add'l info.

Comment 1 Jeremy Katz 2003-05-16 22:13:12 UTC
Does it work if you boot with 'linux nousbstorage'?

Comment 2 greg hosler 2003-05-18 02:41:45 UTC
yes. booting the boot floppy w/

       linux nousbstorage

bypasses the usb storage check, and the system will continue w/ the normal
installation.

Comment 3 Jeremy Katz 2003-05-18 05:47:16 UTC
Does usb-storage load fine on the installed system?

Comment 4 greg hosler 2003-05-18 09:54:27 UTC
yes, and no.

I tested 3 scenerios (usb drive plugged in in all cases):

 - usb drive not on. - boot up has a hang at "Checking for new hardware"
   (kudzu ?)

 - usb drive on. system boots completely, with no hangs anyplace.

 - usb drive off, and boot parameter "nousbstorage" is given. system boots
completely with no hangs anyplace.

as a side note. in earlier red hat releases, when I would boot with drive off
(but plugged in), there would be a noticeable delay (about 10 seconds, maybe
slightly more) at the "Checking for new hardware" rc script, but the system
would continue to boot after the timeout (but the drive would not be usable). if
the drive on, then there would be no hang (and the drive would be completely
useable).


Comment 5 Jeremy Katz 2003-05-18 19:53:17 UTC
Okay, sounds like something kernel side is causing it

Comment 6 greg hosler 2003-05-19 20:56:29 UTC
hmm. agreed. I just noticed a change in behaviour in the most recent shrike
errata kernel 2.4.20-13.9 that has this behaviour (hang on boot) whereas all
previous kernels did not.

Comment 7 Bill Nottingham 2003-07-24 03:56:46 UTC
Does this still happen with the current beta & kernel?

Comment 8 Pete Zaitcev 2004-11-30 06:06:23 UTC
Greg, you forgot about us, have you? Meanwhile 2.4.21-20.EL was
deployed. Please try that if you run RHEL3 (as the bug header claims).
[leaving as needinfo]


Comment 9 Ernie Petrides 2005-10-04 00:10:17 UTC
Closing due to lack of response.


Note You need to log in before you can comment on or make changes to this bug.