Bug 317601 - possible sata_nv problem causes boot failure
Summary: possible sata_nv problem causes boot failure
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.5
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
: ---
Assignee: David Milburn
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-03 23:01 UTC by Peter Ruprecht
Modified: 2009-08-31 17:24 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-08-31 17:24:01 UTC
Target Upstream Version:
Embargoed:


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

Description Peter Ruprecht 2007-10-03 23:01:14 UTC
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 23:01:14 UTC
Created attachment 215221 [details]
dmidecode output

Comment 2 Peter Ruprecht 2007-10-03 23:01:52 UTC
Created attachment 215231 [details]
lspci -v

Comment 3 Peter Ruprecht 2007-10-05 15:36:06 UTC
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 22:34:22 UTC
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 17:24:01 UTC
Closing based upon Comment#4.


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