Bug 116007 - Athlon64 install kernel hangs after detecting ide bus on nforce3
Athlon64 install kernel hangs after detecting ide bus on nforce3
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Jim Paradis
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-02-17 11:06 EST by Brian Smith
Modified: 2013-08-05 21:03 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-06 16:25:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Serial boot logs for several test cases (28.85 KB, text/plain)
2004-02-18 11:21 EST, Brian Smith
no flags Details

  None (edit)
Description Brian Smith 2004-02-17 11:06:40 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET 
CLR 1.1.4322)

Description of problem:
Attemping to install the AMD64 version onto a Shuttle SN85G4 mini PC 
with an nforce3 150 chipset.  The CD boots, then hangs just after the
ide0 and ide1 lines.  I'm installing off of a Sony DW-U10A DVD-RW 
drive, onto a parallel ATA Western Digital WD800JB drive.  I have the 
SATA off in bios.

On Shuttle's German web site (http://de.shuttle.com/linux.htm) they 
suggest doing:
 linux ide0=0x1f0 ide1=0x170 hde=noprobe hdg=noprobe
for the boot.  This does not work in my case, however:
 linux ide0=0x1f0 ide1=0x170 hda=noprobe hdb=nobrobe hdc=noprobe 
hdd=noprobe hde=noprobe hdf=noprobe hdg=noprobe hdh=noprobe 
hdi=noprobe hdj=noprobe
gets it to the point where it says /sbin/loader and then it hangs.

WS 32-bit boots fine.

Is there a work around?  I'd like to install 64-bit linux on this 

Version-Release number of selected component (if applicable):
Red Hat Enterprise WS 3 update 1

How reproducible:

Steps to Reproduce:
1. Boot off the RHE 3 install CD

Actual Results:  Hang after ide0 and ide1 lines

Expected Results:  Boot to install program.

Additional info:
Comment 1 Brian Smith 2004-02-17 14:51:46 EST
Some more info:
 linux hda=noprobe hdb=noprobe hdc=noprobe hdd=noprobe 
hda=14593,255,63 hdc=cdrom

Will boot the AMD64 disc into the installer, but then it complains 
about no having a Red Hat install CD in the drive.  (At this point, I 
believe it is finding neither the cdrom or hda.)

At this point, I'm going to install 32-bit RHE WS 3 and wait for a 
newer release.
Comment 2 Jim Paradis 2004-02-17 18:16:26 EST
If you could get a serial dump of the failed boot sessions that would
help us a lot.  Please attach the log to this bug report.
Comment 3 Brian Smith 2004-02-18 11:21:28 EST
Created attachment 97801 [details]
Serial boot logs for several test cases

This is a serial boot log for the following cases:

Red Hat Enterprise WS 3 update 1 32-bit
linux text console=ttyS0,9600n81

Red Hat Enterprise WS 3 update 1 64-bit
linux text console=ttyS0,9600n81

Red Hat Enterprise WS 3 update 1 64-bit
linux text console=ttyS0,9600n81 hda=noprobe hdb=noprobe hdc=noprobe
hdd=noprobe hda=14593,255,63 hdc=cdrom

In addition I've made some comments in the text describing the some other
Comment 4 Jim Paradis 2004-02-19 16:21:51 EST
This looks like it could be a similar problem to one seen on Fedora in
Bug 109017.  I'll try applying the same fix that was used there.
Comment 5 Brian Smith 2004-02-20 22:26:43 EST
Yes!  So much pain, yet so simple. Booting with:

linux acpi=no

boots on the install disk.  I assume I can go ahead with the install
at this point?  Or, if you need someone to test a new iso... :)

Comment 6 Jim Paradis 2004-02-23 12:58:06 EST
For now, it sounds like this is a good workaround for you.  I still
want to try the "real" fix.

You'll have to make sure the "real" kernel boots with the same
parameter otherwise the reboot-after-install will hang as well.
Comment 7 Brian Smith 2004-02-24 08:39:05 EST
Yep, I'm up and running.  If you don't have hardware to replicate the
error, I'd be happy to test the new kernel.
Comment 8 Jim Paradis 2004-07-06 16:25:57 EDT
This is a known issue, and the upstream "solution" is nothing more
than a workaround; it automatically detects that it is being run on a
suspect NVidia or VIA chipset and specifies "noapic" automatically.  I
may add this check for the next update.  There is no vendor-supported
fix for this issue.

For now, this workaround is being documented in a release note.  I am
resolving this bug as CURRENTRELEASE.

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