Bug 317601 - possible sata_nv problem causes boot failure
possible sata_nv problem causes boot failure
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.5
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: David Milburn
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-03 19:01 EDT by Peter Ruprecht
Modified: 2009-08-31 13:24 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-31 13:24:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmidecode output (12.74 KB, text/plain)
2007-10-03 19:01 EDT, Peter Ruprecht
no flags Details
lspci -v (9.40 KB, text/plain)
2007-10-03 19:01 EDT, Peter Ruprecht
no flags Details

  None (edit)
Description Peter Ruprecht 2007-10-03 19:01:14 EDT
Description of problem:
Somewhere between kernel 2.4.6-42.0.3 and 2.4.6-55.0.9, there seems to have been
introduced a problem with (probably) sata_nv that prevents Sun Ultra-40s
(Opteron with nvidia chipset) from booting.


Version-Release number of selected component (if applicable):
2.4.6-55.0.9

How reproducible:
Always

Steps to Reproduce:
1. Use up2date to upgrade to kernel-smp-2.6.9-55.0.9.EL.x86_64 from
kernel-smp-2.6.9-42.0.3.EL.x86_64
2. Reboot
3. System locks during reboot
  
Actual results:
System locks after giving "ata1: CPB flags CMD err, flags=0x11".  Usually this
happens immediately after the "Red Hat nash version 4.2.1.0 starting" message
early in the boot process.

Expected results:
System should boot fully into default runlevel.

Additional info:
I tried a number of different things when booting, such as using the non-smp
kernel and passing the "noapic" boot option.  In some cases, the boot process
got a little farther, but the system always did hang before finishing booting.

I'm pretty confident that this is not a hardware problem, since the same thing
happens on two separate workstations, and booting to 42.0.3.ELsmp still works.

I'll attach dmidecode and lspci output.  Please advise what other documentation
would be useful.
Comment 1 Peter Ruprecht 2007-10-03 19:01:14 EDT
Created attachment 215221 [details]
dmidecode output
Comment 2 Peter Ruprecht 2007-10-03 19:01:52 EDT
Created attachment 215231 [details]
lspci -v
Comment 3 Peter Ruprecht 2007-10-05 11:36:06 EDT
Just as an additional datapoint, I am able to boot successfully into rescue mode
using the installation CD from RHEL5 (kernel 2.6.18-8.el5 #1 smp).
Comment 4 Peter Ruprecht 2007-10-05 18:34:22 EDT
It appears that applying the latest motherboard BIOS for the Ultra-40 (vsn 1.6)
fixes the problem.  I have been able to boot successfully to
kernel-smp-2.6.9-55.0.9.EL.x86_64 on both of the affected systems here using the
new BIOS.  Thus, as far as I am concerned, this bug can be closed.  
Comment 5 David Milburn 2009-08-31 13:24:01 EDT
Closing based upon Comment#4.

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