From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 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 chipset. 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: Always 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 condition. Additional info: http://www.asrockamerica.com/Products/k8s8x.htm 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.
2.6.7 kernel, not bios...
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 difference.
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
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.
The same here. Look at bug 133474 I've reported.
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.
mass update for old bugs: Is this still a problem with the 2.6.9 based update kernel ?
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.