# Booting sata_via problem in > linux-2.6.16-gentoo-r7: SOLVED

## Pjotrek

Hi,

After some initial problems, I've been able to boot my VIA Epia SP-8000 mini-ITX with a Sata boot drive in linux-2.6.16-gentoo-r7.

When upgrading to linux-2.6.16-gentoo-r9 and linux-2.6.16-gentoo-r12, this is no longer possible; I get the infamous kernel panic: 'Please append or correct ""root=" boot option', no matter what I try when generating my kernel.

I have tested several kernels:

gentoo-sources-2.6.16-r7      - works

gentoo-sources-2.6.16-r9      - hangs

gentoo-sources-2.6.16-r12    - hangs

vanilla-sources-2.6.17.4        - hangs

ck-sources-2.6.17_p1-r1       - hangs

mm-sources-2.6.18_rc1-r1    - works

2.6.16-rc6-git3-FC5               - works

2.6.18-rc1-git4-git                 - hangs

All kernels are built copying config from gentoo-sources-2.6.16-r7, running 'make oldconfig' giving default answer to all new options. 

The active SCSI options in the configs are:

```
CONFIG_SCSI=y

CONFIG_SCSI_SATA=y

CONFIG_SCSI_SATA_VIA=y
```

I have noticed, that on booting the kernels that hang, there is a lengthy pause (~30 secs) in detecting SCSI-units, 

after the line 'dev 0 ATA-7, max UDMA7, 156301488 sectors: LBA48', before booting continues.

(What comes after that is impossible to see - it passes too fast...)

Here is an excerpt from dmesg on a kernel that works:

```
libata version 1.20 loaded.

sata_via 0000:00:0f.0: version 1.1

ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10

PCI: setting IRQ 10 as level-triggered

ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10

PCI: Via IRQ fixup for 0000:00:0f.0, from 15 to 10

sata_via 0000:00:0f.0: routed to hard irq line 10

ata1: SATA max UDMA/133 cmd 0xB400 ctl 0xB802 bmdma 0xC400 irq 10

ata2: SATA max UDMA/133 cmd 0xBC00 ctl 0xC002 bmdma 0xC408 irq 10

ata1: SATA link up 1.5 Gbps (SStatus 113)

ata1: dev 0 cfg 49:2f00 82:746b 83:7f01 84:6003 85:3c69 86:3c01 87:6003 88:40ff

ata1: dev 0 ATA-7, max UDMA7, 156301488 sectors: LBA48

ata1: dev 0 configured for UDMA/133

scsi0 : sata_via

ata2: SATA link down (SStatus 0)

scsi1 : sata_via

  Vendor: ATA       Model: SAMSUNG HM080JI   Rev: YC10

  Type:   Direct-Access                      ANSI SCSI revision: 05

SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)

sda: Write Protect is off

sda: Mode Sense: 00 3a 00 00

SCSI device sda: drive cache: write back

SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)

sda: Write Protect is off

sda: Mode Sense: 00 3a 00 00

SCSI device sda: drive cache: write back

 sda: sda1 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 >

sd 0:0:0:0: Attached scsi disk sda

sd 0:0:0:0: Attached scsi generic sg0 type 0
```

On a hung kernel, the final message is:

```
VFS: Cannot open root device "sda5" or unknown-block(0,0)

Please append a correct "root=" option

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
```

Any ideas?Last edited by Pjotrek on Fri Jul 14, 2006 9:33 am; edited 3 times in total

----------

## wynn

You will probably need to post your kernel config and the last few lines of the boot messages which end in 'Please append or correct ""root=" boot option'.

However, assuming you have something like "Can't mount root device ... (0,0)" it could be that SATA in the kernel is a module rather than being builtin.

Here on a motherboard with a VIA chipset (AMD64), the config has

```
CONFIG_SCSI_SATA=y

...

CONFIG_SCSI_SATA_VIA=y
```

----------

## dsd

https://bugs.gentoo.org/show_bug.cgi?id=138036

----------

## barfo

very odd.  i've had the same problem recently and thought i wasn't selecting the correct module, or was doing something wrong.  i found that by using genkernel and an initrd the problem went away - which i thought was verification that i'd screwed something up.

i had the same experience with a couple gentoo-2.6.16 and ck-sources.  might there be a reason that using an initrd helps?  might there be some combination of other kernel options that resolves the problem?

----------

## dsd

i don't think yours is the same problem, this problem only affects kernels based on 2.6.16.17 and up, sounds like yours isnt so specific (maybe a configuration error)

----------

## dsd

Pjotrek, run this:

 lspci -ns 00:0f.0

you'll see output something like:

00:0f.0 0101: 1106:3149 (rev 80)

if the numbers in the bold section match your output, please test the patch posted on the bug report

if they don't match, please show the output of the command

----------

## Pjotrek

OK, the lspci output matches what I get in linux-2.6.16-gentoo-r7.

Investigating the quirk.c's in the different kernel sources shows that those that are bootable incorporate a general

fix-up for the via chips:

linux-2.6.15-1.2054_FC5          - already fixed: 'PCI_VENDOR_ID_VIA, PCI_ANY_ID'

gentoo-sources-2.6.16-r7         - already fixed: 'PCI_VENDOR_ID_VIA, PCI_ANY_ID'

gentoo-sources-2.6.16-r12       - appliccable

vanilla-sources-2.6.17.4           - appliccable

ck-sources-2.6.17_p1-r1          - appliccable

mm-sources-2.6.18_rc1-r1       - already fixed: 'PCI_VENDOR_ID_VIA, PCI_ANY_ID'

2.6.18-rc1-git4-git                    - appliccable

OK, looks good, compiling now, will test in the morning after a few hour's sleep.

Updated 2006-07-14 10:15:

All kernels that hung before load perfectly with that patch!

I cannot thank you enough, dsd!

PjK

----------

