Bug 132990 - 2.6.7, 2.6.8 Cause Kernel Panic On Boot sata_sis
Summary: 2.6.7, 2.6.8 Cause Kernel Panic On Boot sata_sis
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 2
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-20 18:19 UTC by Michael D. Joy
Modified: 2015-01-04 22:09 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-27 20:29:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Kernel 2.6.8 / sata_sis boot message on Asus P4S800D-E (1.55 KB, text/plain)
2004-09-22 10:16 UTC, Olivier Byrde
no flags Details

Description Michael D. Joy 2004-09-20 18:19:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)

Description of problem:
The 2.6.7+ series kernels cause a hang when initializing the sata_sis
driver to mount the system drives. System drives are configured as
MD0, MD1 etc... in Raid 1 for /boot and raid 0 for other partitions.

There is an error initilializing the interrupt, and the kernel panics
and hangs. It never gets past initializing the sata_sis driver.

The board is an ASRock K8S8X board with a Sis 755 chipset. The system
is configured in non-raid mode in the bios. The controller initializes
the drives as two independant drives.

This has happened for every 2.6.7 iteration and 2.6.8 bios I have
tried. I run 2.6.6-1.435.2.3 and it seems to be the last one that
still works before something changed and it was broken. Booting with
noacpi or noapic doesn't help. Also, turning off pnp doesn't help.

It seems that something is badly broken in the kernel supporting this

I am running an Athlon 64 2.0 gigahertz proc, but am running the
32-bit version of Fedora for compatibility reasons (compile problems)
with current software I do research with.

I hope this is fixed before Fedora Core 3 comes out! This is a
fundamental kernel problem.

Version-Release number of selected component (if applicable):
kernel-2.6.7-x kernel-2.6.8-x plain-vanilla-kernel-2.8

How reproducible:

Steps to Reproduce:
1. ASRock K8S8X SIS 755 Chipset, 2 80.0GB Hitachi 7K250 SATA
2. (/boot raid 1) (everything else raid 0 using software raid in kernel)
3. Boot 2.6.7 2.6.8 Kernel

Actual Results:  Kernel panics every time.

Expected Results:  Kernel should have booted correctly without a panic

Additional info:


I am running the latest bios on this board. I have not had an issue
with the sata controller until the 2.6.7 bios came out. It broke
something badly.

Comment 1 Michael D. Joy 2004-09-21 01:29:00 UTC
2.6.7 kernel, not bios...

Comment 2 Olivier Byrde 2004-09-22 10:16:25 UTC
Created attachment 104118 [details]
Kernel 2.6.8 / sata_sis boot message on Asus P4S800D-E

Same problem with FC2/Kernel 2.6.8 on Asus P4S800D-E Deluxe board (BIOS 1006).

Kernel 2.6.8-1.521 hangs when on-board SIS 964/SIS 180 SATA controllers are
enabled in BIOS. No problem when these controllers are disabled. Four empty,
NTFS-formatted Samsung SP1614C drives are connected to these controllers, but
are not needed nor used by linux.

I tried booting with acpi=off, and with/without PnP in BIOS, but it makes no

Comment 3 Patrick Shinpaugh 2004-09-29 02:36:13 UTC
Not sata_sis but looked closest of the existing bugs I found to what I
am seeing and what I am assuming the issue deals with (SATA)....

Installed FC2 with problems associated with 2.6 changes in reading
driving geometry in dual boot with Windows XP (32 bit) with 4 SATA
drives/0 PATA drives. Resolved by calling linux /dev/hde=9729,255,63
(CHS values as reported by partition table of drive) and installed FC2
i386 version (not AMD64 version).

Upgrading to 2.6.8-1.521 through up2date receive:
Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0)

Rebooting using 2.6.5-1.358 kernel works fine.

At work I set up 15 assorted Intel (P4 and Xeon) and AMD Athlon XP PCs
with dual boot Windows XP and FC2 and upgraded all to kernel 2.6.8-521
with no problems but all have PATA drives. Issue is found only on my
home computer (AMD64, MSI Neo2 Platinum with Award BIOS, and 4 SATA
drives / 0 PATA drives).

I wish someone would convince whoever decided to change the way 2.6
kernel handles drive geometry to go back to the way it was done in 2.4
and improve the way that SATA is handled - thanks

Comment 4 Michael D. Joy 2004-10-20 13:47:32 UTC
New kernel, 2.6.9-rc4 with same compile options as the redhat kernel,
just not the additional redhat patches. The 4k stack instead of 8k
stack option is turned off for nvidia driver compatibility.

I downloaded the 2.6.1 kernel source, patched to 2.6.9-rc4, compiled
and installed, and the kernel is running beautifully.

Warning, the 2.6.9-rc4-mm1 (mm1 patchset) has broken preemption code.
2.6.9-rc4 runs fine with the anticipatory scheduler. Also, this kernel
fixed a throttling condition that was occurring with the ide
controller with a Pioneer DVR-108 burner. It might have just been the
O1 scheduler that redhat defaults to.

Anyways, it's fixed in the latest kernel. Hopefully redhat/fedora
won't muck it up with their crazy patches.

Comment 5 Nicola 2004-11-06 01:26:21 UTC
The same here. Look at bug 133474 I've reported. 

Comment 6 Terry Griffin 2004-11-21 03:08:56 UTC
I'm seeing this same panic ("not syncing: VFS: unable to mount root fs
on unknown-block(0,0)") with 2.6.9-1.3_FC2 on an ASUS P4C800 (Pentium 4)
with a SATA boot disk. All previous FC2 kernels have worked fine on
this same box.

Comment 7 Dave Jones 2004-11-27 20:26:04 UTC
mass update for old bugs:

Is this still a problem with the 2.6.9 based update kernel ?

Comment 8 Michael D. Joy 2004-11-27 20:29:43 UTC
This problem magically went away with the second 2.6.9 testing kernel for Fedora
2. Fedora 3 does not exhibit this problem. The first 2.6.9 test kernel caused a
core dump for probably some other unrelated reason. I didn't look into it since
it was a test kernel build.

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