[SOLVED] Slackware Kernel Panic with extra PCI Sata controller sata_sil24 PCI40010

I have recently installed in a Slackware 14.1 the following board:

IOCrest SATA II 4 x PCI RAID Host Controller Card SY-PCI40010
https://www.amazon.com/IOCrest-SATA-.../dp/B002R0DZZ8

I have previously used this board with Ubuntu 16 (no problems, same board and processor, 32 bit)
And the main use is a an option to add extra hard drives (No RAID is used).


Those are the hard drives:

Disk /dev/sda: 320.1 GB, 320072933376 bytes
/dev/sda1       617334858   625142447     3903795   82  Linux swap
/dev/sda2   *          63   617334857   308667397+  83  Linux
Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes
/dev/sdb1               1  4294967295  2147483647+  ee  GPT
Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes
/dev/sdc1               1  4294967295  2147483647+  ee  GPT
Disk /dev/sdd: 3000.6 GB, 3000592982016 bytes
/dev/sdd1               1  4294967295  2147483647+  ee  GPT
Disk /dev/sde: 2000.4 GB, 2000398934016 bytes
/dev/sde1              63  3907029167  1953514552+  83  Linux

This is the board:

03:00.0 RAID bus controller: Silicon Image, Inc. SiI 3124 PCI-X Serial ATA Controller (rev 02)
        Subsystem: Silicon Image, Inc. Device 7124
        Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 19
        Memory at febffc00 (64-bit, non-prefetchable) [size=128]
        Memory at febf0000 (64-bit, non-prefetchable) [size=32K]
        I/O ports at ec00 [size=16]
        Expansion ROM at feb00000 [disabled] [size=512K]
        Capabilities: [64] Power Management version 2
        Capabilities: [40] PCI-X non-bridge device
        Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
        Kernel driver in use: sata_sil24

What is driving me crazy is...
Without any hard drive sata cable connected to the controller board (4 ports)
the computer boots up and after you connect the hard drive to port 0 the sde drive
shows up nicely... Dmesg result

[   26.893348] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   27.627039] r8169 0000:01:00.0: eth0: link up
[   27.627192] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   37.762021] eth0: no IPv6 routers present
[   72.282736] ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
[   72.282742] ata1: irq_stat 0x00800080, device exchanged
[   72.282752] ata1: hard resetting link
[   82.283017] ata1: softreset failed (timeout)
[   82.283023] ata1: hard resetting link
[   84.426024] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[   84.426532] ata1.00: ATA-8: ST2000DM001-9YN164, CC4B, max UDMA/133
[   84.426534] ata1.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   84.427028] ata1.00: configured for UDMA/100
[   84.427034] ata1: EH complete
[   84.427154] scsi 2:0:0:0: Direct-Access     ATA      ST2000DM001-9YN1 CC4B PQ: 0 ANSI: 5
[   84.427801] sd 2:0:0:0: [sde] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[   84.427804] sd 2:0:0:0: [sde] 4096-byte physical blocks
[   84.427845] sd 2:0:0:0: [sde] Write Protect is off
[   84.427848] sd 2:0:0:0: [sde] Mode Sense: 00 3a 00 00
[   84.427865] sd 2:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   84.729871]  sde: sde1
[   84.730703] sd 2:0:0:0: [sde] Attached SCSI disk

But if I reboot the computer with the attached sata (sde, or sdf or sdg) Slackware does not boot up!!!
I need to have this machine restart with no headaches... And I'm wondering why Ubuntu does not crash...

The kernel panic is:
VFS: Unable to mount root fs on unknown-block(8,2)

Originally Posted by crions I have recently installed in a Slackware 14.1 the following board: IOCrest SATA II 4 x PCI RAID Host Controller Card SY-PCI40010 The kernel panic is: VFS: Unable to mount root fs on unknown-block(8,2) Attachment 28966

The system seems to want to mount the sde drive as the root fs, instead of sda (8,2 is the THIRD S-ATA controller, so your new board.
So the new board seems to take precedence to your bootloader (it probably becomes sda to the kernel).

I actually have the same problem on a HP workstation with external E-sata port (controller of which is on the motherboard), the disk, connected to that, must NOT be switched on, when rebooting the system.
Luckily that is much more easy to assure with an external disk.

What is the root= parameter on your Slack bootloader's kernel cmdline? If it's device name, switching it to LABEL or UUID should avoid the device enumeration usurpation that almost assuredly is assigning sda instead of sde to the PCI card when it has a connected and powered HD during POST. There may be a BIOS change you can make to keep the onboard SATA ports prioritized over the PCI card. Rebuilding the initrd with the Silicon Image module explicitly excluded might also help, as might using the PCI card's own setup utility.

ehartman: Thank you for the clarification on enumeration (8,2). Unfortunately this guy will be a server so I cannot have to reconnect the drives on each power failure.

mrmazda: Thank you for the insight.

What is the root= parameter on your Slack bootloader's kernel cmdline? If it's device name, switching it to LABEL or UUID should avoid the device enumeration usurpation that almost assuredly is assigning sda instead of sde to the PCI card when it has a connected and powered HD during POST. There may be a BIOS change you can make to keep the onboard SATA ports prioritized over the PCI card. Rebuilding the initrd with the Silicon Image module explicitly excluded might also help, as might using the PCI card's own setup utility.

The Motherboard BIOS(DEL) and the independent board BIOS(CRTL-S) don't see each other. And they do have the same config as per running Ubuntu. No RAID in use.
To remove the sata_sil24 from initrd seems a good idea, can you point me a site where I can read how to do that?


See my LILO config below, no fancy parameter on kernel loading.

LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
# Append any additional kernel parameters:
append=" vt.default_utf8=0"
boot = /dev/sda

# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
  bitmap = /boot/cedalion.bmp
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
  bmp-colors = 255,0,255,0,255,0
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used.  We don't specify it here, as there's just one column.
  bmp-table = 60,6,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
  bmp-timer = 65,27,0,255

# Standard menu.
# Or, you can comment out the bitmap menu above and
# use a boot message with the standard menu:
#message = /boot/boot_message.txt

# Wait until the timeout to boot (if commented out, boot the
# first entry immediately):
prompt
# Timeout before the first entry boots.
# This is given in tenths of a second, so 600 for every minute:
timeout = 60
# Override dangerous defaults that rewrite the partition table:
change-rules
  reset
# VESA framebuffer console @ 640x480x64k
vga = 785
# Normal VGA console
#vga = normal
# Ask for video mode at boot (time out to normal in 30s)
#vga = ask
# VESA framebuffer console @ 1024x768x64k
#vga=791
# VESA framebuffer console @ 1024x768x32k
#vga=790
# VESA framebuffer console @ 1024x768x256
#vga=773
# VESA framebuffer console @ 800x600x64k
#vga=788
# VESA framebuffer console @ 800x600x32k
#vga=787
# VESA framebuffer console @ 800x600x256
#vga=771
# VESA framebuffer console @ 640x480x64k
#vga=785
# VESA framebuffer console @ 640x480x32k
#vga=784
# VESA framebuffer console @ 640x480x256
#vga=769
# End LILO global section
# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/sda2
  label = Linux
  read-only
# Linux bootable partition config ends

Hi,

You can look at; http://docs.slackware.com/start

Hope this helps.
Have fun & enjoy!

After this few tips I went quest the persistent naming option. This is something that Ubuntu does quite a lot with hardware (sometimes to my annoyance)

So I went Slackware Documentation Project:
https://docs.slackware.com/howtos:sl...sistent_naming

And fixed boot using the UUID of the SDA2 to the boot process (initrd) and not recompiling kernel.
Needed to reinstall the LILO with the new initrd and voilà...

Now Slackware is booting properly and all drive mapped with no problems.

This is my NEW fstab using UUID:

#/dev/sda1
UUID=59de16b2-b48f-4423-bbe2-31b17f76a281       swap                    swap    defaults        0   0
#/dev/sda2
UUID=11d6ab52-f72d-453e-bd65-6ccca3dd3308       /                       ext4    defaults        1   1
#/dev/sdb1
UUID=6ee59670-bf12-4cec-8741-ff0c911e4736       /crions/backup/hd_sdb   ext4    defaults        0   0
#/dev/sdc1
UUID=ca9919f8-0cd8-451e-a624-5bffa36d7216       /crions/backup/hd_sdc   ext4    defaults        0   0
#/dev/sdd1
UUID=39243492-f1cf-4976-96a2-b73721a3dd25       /crions/backup/hd_sdd   ext4    defaults        0   0
#/dev/sde1
UUID=b6f21a88-9086-4bf3-bf39-980c89ce1fc6       /crions/backup/hd_sde   ext4    defaults        0   0
#/dev/cdrom      /mnt/cdrom       auto        noauto,owner,ro,comment=x-gvfs-show 0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
tmpfs            /dev/shm         tmpfs       defaults         0   0

This was the initrd build command:

mkinitrd -c -k 3.2.29 -f ext4 -r "UUID=11d6ab52-f72d-453e-bd65-6ccca3dd3308" -m usbhid:ehci-hcd:uhci-hcd:mbcache:jbd2:ext4 -u -o /boot/initrd.gz

Thank you all for the tips :-)

Originally Posted by crions ehartman: Thank you for the clarification on enumeration (8,2). Unfortunately this guy will be a server so I cannot have to reconnect the drives on each power failure.

I didn't expect you to <grin>.

Others have already mentioned using a kernel and initrd without the module for the new board. If that module gets loaded AFTER the disk with the root fs has been found and mounted, there's no problem anymore.

A even more radical solution would be to connect your original root disk to the new board (and adjust the other accordingly, so that the kernel would find your "old" disks on the new board and the "to be added ones" on the mother controllers.

But you seem to have marked this SOLVED, so you managed to get your server working again;
congratulations!