kernel-2.6.1 and SATA_VIA

Hope someone might have some hints on how to resolve this issue!

I spent the last few nights determining why a newly compiled 2.6.1 kernel would fail on mounting the ROOT device.

Im running Mandrake 9.2 for AMD64.. Mainboard is MSI K8T Neo (onboard Promise SATA and VIA SATA) harddrive is on the VIA SATA.

The original installation detected the hard drive as a SCSI device (/dev/sda). I compiled the 2.6.1 kernel without problems...

here is a sniplet of the bootup of kernel 2.6.1:
*************************************************************************
.
.
.
Redhat nash version 3.4.13-mdk startup
loading lib_ata.ko module
loading sata_via.ko module
loading sd_mod.ko module
loading ide_disk.ko module
hde: max request size: 128KiB
hde: 40121728 sectors (122942Mb) w/7936KiB Cache, CHS=65535/16/63
hde: hde1 hde2 hde3 hde4 < hde5 hde6 hde7 hde8 hde9 hde10 >
loading jbd.ko module
loading ext3.ko module
Mounting /proc filesystem
Creating root device
Mounting root filesystem
mount: error 6 mounting ext3 flags defaults
well, retrying without the options flag
mount: error 6 mounting ext3
well, retrying read-only without any flag
mount: error 6 mounting ext3
pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed: 2
Re-mounting devfs at correct place if necessary
Freeing unused kernel memory: 424k freed
Kernel panic: No init found. Try passing init= option to kernel
***************************************************************************


this is what dmesg reports from bootup of kernel 2.4.22-27mdk:
************************************************************************
SCSI subsystem driver Revision: 1.00
libata version 0.75 loaded.
sata_promise version 0.83
ata1: SATA max UDMA/133 cmd 0xFFFFFF0000290200 ctl 0xFFFFFF0000290238 bmdma 0x0
irq 10
ata2: SATA max UDMA/133 cmd 0xFFFFFF0000290280 ctl 0xFFFFFF00002902B8 bmdma 0x0
irq 10
ata1: no device found (phy stat 00000000)
ata1: thread exiting
ata2: no device found (phy stat 00000000)
ata2: thread exiting
scsi0 : sata_promise
scsi1 : sata_promise
sata_via version 0.11
ata3: SATA max UDMA/133 cmd 0xD800 ctl 0xD402 bmdma 0xC800 irq 10
ata4: SATA max UDMA/133 cmd 0xD000 ctl 0xCC02 bmdma 0xC808 irq 10
ata3: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01 87:4003 88:407f
ata3: dev 0 ATA, max UDMA/133, 240121728 sectors
ata3: dev 0 configured for UDMA/133
ATA: abnormal status 0x7F on port 0xD007
ata4: thread exiting
scsi2 : sata_via
scsi3 : sata_via
Vendor: ATA Model: Maxtor 6Y120M0 Rev: 0.75
Type: Direct-Access ANSI SCSI revision: 05
Attached scsi disk sda at scsi2, channel 0, id 0, lun 0
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
Partition check:
/dev/scsi/host2/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 p10 >
Journalled Block Device driver loaded
************************************************************************

As one can see, there is a big difference in how the sata_via module
detects the drive

in fstab, all mount points refer to /dev/sda partitions... and in lilo.conf, boot=/dev/sda and root=/dev/sda3... I know these are wrong if the 2.6.1 kernel sees /dev/hde... but just changing these values does not correct the problem...

Any help would be greatly appreciated.

IEdirtbiker

Try recompiling with the sata_via and ext3 modules built-in rather than as a module. Its always good to have the root partition devices and filesystems compiled into the kernel rather than as a module.

I've had failures similar to this for exactly that reason.

leonscape,
thanks for the info... I did try what you suggested... it didnt make a difference... I did however determine that it isnt the sata_via module that is at issue! Apparently, the driver/module for the VIA
VT8237 has changed from 2.4 kernels to 2.6 kernels... the VT8237 chipset is what the SATA drives are on as well as the standard IDE ports.
with the 2.4 series kernel, the chipset driver for the VT8237 did not see the SATA drives... however the 2.6 kernel does! The only way i could get my system to boot with the 2.6 kernel is to completely disable the "PCI IDE chipset support" ... which is not satisfactory, since both my CD drives are on the IDE bus.

Now my question:
since the 2.6 kernel sees the SATA drive on the VT8237 as a IDE drive (as apposed to the sata_via being a SCSI), what do I need to do to my system to operate my drive as an IDE device?
in lilo.conf, boot= and root= statements point to a /dev/sda device/partition... and fstab lists partitions as /dev/sda1, /dev/sda2, .... and so on... if I were to change these to /dev/hde, /dev/hde1 and so on, what would that do for me? Would I need to do anything else? Would it even work?
thanks,
IEdirtbiker

I have no idea. Its whether you feel like trying it.

You can set the kernel parameter hde=noprobe which means the kernel will not autodetect that device, Hopefully it will pick it up later, on the SATA device. I read postings about this and it not working but that was for test9 I've looked for later stuff but don't know if its been resolved.

I'll keep searching and let you know what I find....

hde should Work. Other SATA users have reported their using hde to talk to the drives.

IDE = hda hdb hdc hdd
SATA = hde hdf hdg...

I'll give it a try!

Here is an update...

Ive managed to get the kernel to boot a bit farther than before...
1. tried several .config setups (module vs built-in)
2. edited kernel 2.6.1 entry in lilo.conf to have root=/dev/hde3
3. edited fstab (per recommendation of leonscape) adding a /dev/hde entry for each of the
/dev/sda entries.

the bootup process gets just past the INIT: line ... where it fails is here:
Checking root filesystem
Possible non-existant or swap device?
fsck.ext3 no such device while trying to open /dev/sde3

Im getting there.. but geez... what a pain in the butt! LOL

Finally!

Had to add /dev/hde block devices in /dev! got it to boot in failsafe... was experiencing a kernel panic... (ended up being ACPI... so I turned it off in bios)

had to tinker with fstab and lilo.conf a few times, but finally am booting complete on /dev/hde drive...

will work on ACPI stuff

and yes... I did save a copy of the .config file in a safe place LOL

Glad to here you sorted your problems. Its quite easy to trash your system messing with these, so props to you.