Bug 142787 - sata_nv kernel panic on first boot after install
sata_nv kernel panic on first boot after install
Status: CLOSED DUPLICATE of bug 138725
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-12-13 22:47 EST by William Gates
Modified: 2015-01-04 17:13 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-14 03:43:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
capture of kernel boot process (10.23 KB, text/plain)
2004-12-13 22:49 EST, William Gates
no flags Details
this is the output of the "lspci" command (1.58 KB, text/plain)
2004-12-13 22:50 EST, William Gates
no flags Details
this is the output of running "cat /proc/scsi/scsi" (748 bytes, text/plain)
2004-12-13 22:52 EST, William Gates
no flags Details

  None (edit)
Description William Gates 2004-12-13 22:47:13 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
I have seen this kernel panic in several bug reports related to FC3,
and want to enter my firsthand experience after installing RHEL 4 beta
2 (the same panic occurs with the original 2.6.9-1.648_EL kernel as
well) - in short, the install proceeds without problems, I can see the
sata_nv module loaded, I am even able to create LVM physical and
logical volumes without issue using druid's manual partition
capablities, and after installing ALL packages (a whopping 7.5GB!),
upon a reboot the infamous kernel panic occurs (see attachment for
more detail, that I captured using console=tty0 console=ttyS0,38400n8)

Loading libata.ko module
Loading sata_nv.ko module
nv_sata: Primary device added
ata1 is slow to respond, please be patient
ata1 failed to respond (30 secs)
scsi0 : sata_nv
nv_sata: Secondary device added
ata2 is slow to respond, please be patient
ata2 failed to respond (30 secs)
scsi1 : sata_nv
Kernel panic - not syncing: Attempted to kill init!

Here is my equipment rundown:
Shuttle SN95G5 (nVidia nForce 3 based motherboard)
AMD Athlon 64 3500+ Processor
2 Seagate 80GB SATA drives (model ST380013AS)
2 GB RAM (Corsair XMS TWINX2048-3200PRO)
Sapphire 9600XT (ATI) video card

The only way to access the file system is by booting the install CD 1,
and performing a "linux rescue" boot, after which, the slash partition
is found on the LVM, and I am able to do the chroot /mnt/sysimage, and
perform some maintenance activities - though, I probably won't attempt
to rebuild the kernel any time soon in this mode!

I hope these SATA/kernel issues will be fixed soon for the x86_64
architecture, as the system is only usable with RHEL 3.3 at the moment.

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

How reproducible:

Steps to Reproduce:
1. Boot with RHEL 4 beta 2 CD 1
2. Install all packages
3. Reboot

Actual Results:  kernel panic

Expected Results:  normal boot

Additional info:

I will attach files from capturing the kernel boot, and from running
the lspci command
Comment 1 William Gates 2004-12-13 22:49:51 EST
Created attachment 108487 [details]
capture of kernel boot process
Comment 2 William Gates 2004-12-13 22:50:47 EST
Created attachment 108488 [details]
this is the output of the "lspci" command
Comment 3 William Gates 2004-12-13 22:52:13 EST
Created attachment 108489 [details]
this is the output of running "cat /proc/scsi/scsi"
Comment 4 William Gates 2004-12-13 22:58:08 EST
Although some of the text in the first attachment looks like typos,
that is the unedited text captured from another PC running
hyperterminal in Windoze 2K (sorry, I couldn't get minicom to work in
Comment 5 William Gates 2004-12-13 23:01:10 EST
Oops! Please ignore the first few lines in the third attachment, as
that was some of the history of earlier commands ...
Comment 6 Jay Turner 2004-12-14 03:43:32 EST
This is actually a duplicate of quite a few other bugs in the system, and the
issue is resolved in the latest internal builds.

*** This bug has been marked as a duplicate of 138725 ***
Comment 7 William Gates 2004-12-14 14:05:15 EST
Will there be another beta version of RHEL 4 (beta 3?) released in the
near future, and if so, what is the general timeframe?

My company has tasked me with testing this release to recommend for
possible upgrades from RHEL 3 to RHEL 4 (x86_64 specific) for several
AMD Athlon 64 systems.  So far, with kernel panics occuring with this
hardware setup, I cannot do so in good faith, though, I'm sure these
issues will be resolved (hopefully) in the near future.

Thank you,
Comment 8 Dan Carpenter 2005-07-13 03:55:44 EDT
The other bug is closed to the public.  :/

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