Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 166381 - Booting from CD #1 with 64 bit media with linux dd does not assign usb floppy
Booting from CD #1 with 64 bit media with linux dd does not assign usb floppy
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-08-19 18:43 EDT by Alex Bruno
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-17 00:45:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Screenshot capture of error (2.25 MB, application/octet-stream)
2005-08-24 10:42 EDT, Alex Bruno
no flags Details

  None (edit)
Description Alex Bruno 2005-08-19 18:43:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.10) Gecko/20050719 Red Hat/1.0.6-1.4.1 Firefox/1.0.6

Description of problem:
Customer boots with CD #1 of RHEL 3 U5 media for 64 bit.  Chooses the 

linux dd

option becuase they have to provide a driver.  When it gets to the screen asking the user to insert the disk, it says to install it on


Placing the diskette in the usb drive accomplishes nothing, not found, address is not being assigned/accepted and the error code seen on the other virtual terminals is error code -110

Version-Release number of selected component (if applicable):
RHEL 3 AS U5 for x86_64

How reproducible:

Steps to Reproduce:
1.boot with RHEL 3 U5 64 bit media and have usb floppy
2.choose linux dd
3.when at screen asking for disk insertion in /dev/hda insert disk...nothing happens

Actual Results:  According to other console output, device not assigned address, error code -110

Expected Results:  Should have recognized the usb floppy as a different designation (NOT /dev/hda) and should have been able to have been assigned an address for the device.

Additional info:

This does NOT happen with the 32 bit versions of the media.  64 bit only.
Comment 1 Jeremy Katz 2005-08-22 13:20:13 EDT
The installer code is exactly the same.  The exact error message from tty4 will
probably be helpful in tracking down the bug (which is probably usb
Comment 2 Alex Bruno 2005-08-24 10:41:07 EDT
Customer reports the error output:

Last four lines of console 4 messages are as follows: 
<6>hub.c: new USB device 00:03.1-2, assigned address 7 
<4>usb_control/bulk_msg: timeout 
<3>usb-ohci.c: unlink URB timeout 
<3>usb.c: USB device not accepting new address=7 (error=-110) 
I have also attached a screen print of console 4.
Comment 3 Alex Bruno 2005-08-24 10:42:43 EDT
Created attachment 118061 [details]
Screenshot capture of error
Comment 4 Alex Bruno 2005-08-31 08:51:21 EDT
Customer comments:

I found an article from IBM that helped get this going.  At the install prompt,
I typed "linux dd acpi=noirq".  This then asked me for a driver disk and gave me
hda and sda as an option.  I selected sda and away it went.

This article has pretty detailed installation instructions for the hardware and
platform combination.
Comment 5 Neil Horman 2005-08-31 12:01:37 EDT
Where did they get the idea that /dev/hda was going to be the device for the USB
attached floppy drive?  USB storage is always exported as a scsi device
(/dev/sd<x>).  /dev/hda is an IDE device.  From reading the instructions you
provide above from IBM's web site, it seems as though thats pretty clear.
Comment 6 Pete Zaitcev 2005-09-17 00:43:41 EDT
Ugh, Neil, they are trying to install on /dev/hda, not read drivers off it :-)

The -110 is wrong interrupt routing. 99% of cases it's broken BIOS.

The bug looks like WONTFIX material to me. I think that playing with
BIOS table parsing in -BOOT kernel of RHEL 3 is so risky as to be crazy.
So the only viable solution is to use a trick like "acpi=noirq" to get
the system installed and then perhaps SMP kernel would work automatically.
If not, some command line trick like "noacpi" or "acpi=noirq" is called for.
That's about all I can offer.

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