[SOLVED] Slackware Kernel Panic with extra PCI Sata controller sata_sil24 PCI40010
Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
Code:
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:
Code:
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
Code:
[ 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)
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.
Quote:
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.
Code:
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
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)
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.
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!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.