I have successfully installed slackware 10.1 onto my SCSI Hard drives using the adaptec.s boot disk. the system boots just fine to the scsi hard drive etc etc. Now i want to build smp support into the kernel so that i can actually take advantage of the dual 2.0 ghz xeon's under the hood.

I backed up my .config, system.map, and vmlinuz to a safe location.

next i used "make menuconfig" to load my config, and enable SMP support.

Also, if i understand correctly i also need to add RTC support, remove APM support and Add MTRR support in order for SMP to work correctly.

Next I run "make dep" and "make bzImage" and copy my System.map and vmlinuz to /boot, and add another option into lilo to boot the new vmlinuz, then run lilo.

Next i reboot and it boots to my new SMP kernel, but fails to mount the root filesystem, I assume because it's not finding the scsi hard drive for whatever reason.

I built scsi support into the kernel, and also the exact driver i need ( its the adaptec 7xxx one if that matters)

How do i make the new kernel boot from the scsi hd? I guess i dont understand why it's not working? obviously it has no problem reading the /boot (/dev/sdb1) to load the kernel, but yet it can't mount the root (/dev/sdb3) filesystem?

is there something else i need to do to tell it to boot from the scsi device? i do set root=/dev/sdb3 in lilo.conf, but i dont think that's the problem.

Do i need to make a new initrd?

I am curious why you are sticking with 2.4 and not 2.6. But anyway, to the original point: make sure you also have support for your particular filesystem compiled into the kernel. And the SCSI system and drivers must be compiled in, not as modules.

What is the exact error you are receiving?

I guess my reasoning for sticking to 2.4 was that i thought it was going to be a simple "check smp and recompile" type of deal as opposed the "download 2.6 sources, compile etc etc etc". now that it seems building 2.4 is being a pain i might just go ahead and move to 2.6 if it becomes apparant that it's going to fight me more.

Yes scsi support, the scsi driver, and ext3 (my filesystem is ext3) are all compiled in, not built as modules.

The error message i recieve is along the lines of "Failed to mount root filesystem" then a kernel panic.

I know that isnt much information to go on, i'll see if i can get a dmesg or something more when i get back to it tonight and i'll post that.

Thank you for your reply.

~amphiBian

In that case, the lilo config may be at issue. Is it the same config as the old lilo config? Append "root=/dev/sdb3" may be neccessary. Please post your lilo config file. (Replace any passwords with XXXX or similar for your own security)

Here is my lilo.conf
boot = /dev/sdb
message = /boot/boot_message.txt
prompt
timeout = 120
change-rules
reset
vga = 773

image = /boot/vmlinuz-smp
root = /dev/sdb3
label = SMP
read-only
image = /boot/vmlinuz-no-smp
root = /dev/sdb3
label = Normal
read-only

I cut the following out of my syslog

i've configed my kernel a few more times, and i've gotten it to where it now gives me the following. it looks as though it is loading the scsi driver ok, but it's failing when loading the ethernet driver(eeepro100)?

does this mean my modules aren't configured or compiled correctly?



hdc: attached ide-cdrom driver.
Feb 28 11:04:46 Korriban kernel: <Adaptec aic7899 Ultra160 SCSI adapter>
Feb 28 11:04:46 Korriban kernel: aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
Feb 28 11:04:46 Korriban kernel:
Feb 28 11:04:46 Korriban kernel: <Adaptec aic7899 Ultra160 SCSI adapter>
Feb 28 11:04:46 Korriban kernel: aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
Feb 28 11:04:46 Korriban kernel:
Feb 28 11:04:46 Korriban kernel: (scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Feb 28 11:04:46 Korriban kernel: (scsi0:A:1): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Feb 28 11:04:46 Korriban kernel: Vendor: QUANTUM Model: ATLAS_V__9_WLS Rev: 0200
Feb 28 11:04:46 Korriban kernel: Type: Direct-Access ANSI SCSI revision: 03
Feb 28 11:04:46 Korriban kernel: Vendor: QUANTUM Model: ATLAS_V__9_WLS Rev: 0200
Feb 28 11:04:46 Korriban kernel: Type: Direct-Access ANSI SCSI revision: 03
Feb 28 11:04:46 Korriban kernel: scsi0:A:0:0: Tagged Queuing enabled. Depth 8
Feb 28 11:04:46 Korriban kernel: scsi0:A:1:0: Tagged Queuing enabled. Depth 8
Feb 28 11:04:46 Korriban kernel: Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Feb 28 11:04:46 Korriban kernel: Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
Feb 28 11:04:46 Korriban kernel: SCSI device sda: 17930694 512-byte hdwr sectors (9181 MB)
Feb 28 11:04:46 Korriban kernel: SCSI device sdb: 17930694 512-byte hdwr sectors (9181 MB)
Feb 28 11:04:46 Korriban kernel: 8regs : 2340.000 MB/sec
Feb 28 11:04:46 Korriban kernel: 32regs : 1411.600 MB/sec
Feb 28 11:04:46 Korriban kernel: pIII_sse : 2584.000 MB/sec
Feb 28 11:04:46 Korriban kernel: pII_mmx : 2292.000 MB/sec
Feb 28 11:04:46 Korriban kernel: p5_mmx : 2289.200 MB/sec
Feb 28 11:04:46 Korriban kernel: raid5: using function: pIII_sse (2584.000 MB/sec)
Feb 28 11:04:46 Korriban kernel: VFS: Mounted root (ext3 filesystem) readonly.
Feb 28 11:04:47 Korriban kernel: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
Feb 28 11:04:47 Korriban kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <saw@saw.sw.com.sg> and others
Feb 28 11:04:47 Korriban kernel: shpchp: shpc_init : shpc_cap_offset == 0
Feb 28 11:04:47 Korriban last message repeated 3 times
Feb 28 11:04:47 Korriban kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000001
Feb

Nothing like solving your own problem!

I finally rebuilt my modules and reinstalled them and now it works just fine.

I did finally get it working. also after restarting i had to reinstall my nvidia driver.

works great now!

Now i have to ponder if i want to go ahead and upgrade to 2.6.

Hello amphiBian

I have a system something like yours in reguards to SMP and SCSI adaptec 79xx controllers.

On mine, I tried the 2.6.9 kernel because it is said that the CPU scheduling works better than on the 2.4 series.
I take that as meaning that less jumping from CPU to CPU takes place in the 2.6 series.

Well, that did not prove to be the case. As a test, I ran three seperate Folding@Home work units at the same time.
This put three CPU's at about 100% and I made note of the time it took to finish the work units. As luck would have it,
I was able to get more of the same type work units and I ran them on the other kernel. The 2.4.26 kernel had the
same times.

I know that it's not possible for me to say that the two kernels were compiled the same. But, I have great faith in the
2.4 series kernels, and do accept that the 2.6 series is in the "testing" area.

Later this week I will install the 2.4.29 kernel on the system similar to yours, and try the test again. Well. I may not. For the
last few days I have been getting all kinds of work units from Folding@Home. Never are they the same any more.

Thanks alot for the info, so perhaps my energy could be better applied somewhere other than upgrading that box to 2.6.