CentOS - Apr 2006 - SMP kernel on old Asus CUV4X-DLS motherboard

Just wondering if anybody managed to get SMP kernel to boot properly on 
an old Asus CUV4X-DLS motherboard (older dual P-III)?

I had this problem only with this specific motherboard and 2.6 kernels. 
  First time couple of years ago.  And again today (I've just installed 
CentOS4 on a box that used to run RH7.3).  Previously those machines 
were running Red Hat 7.3 (2.4 kernels), and with 2.4 SMP kernel all 
worked fine.

The issue I'm having is that when device driver modules are loaded from 
initrd's init script, insmod doesn't wait until each driver it loads is 
completely loaded and initialized.  It just exits with right away and 
init script goes on and starts loading next device driver.  It looks 
like bang, system loads all of them in parallel.  Of course, this 
doesn't work really well.  Before RAID and SCSI drivers have time to 
scan the bus and detect disk drives, vgscan is already done, and of 
course it doesn't find any volume groups, since previous device drivers 
haven't yet detected any drives.  All I can see on console is 
interleaved messages from various device drivers intializing with 
messages from LVM, followed by kernel panic because it couldn't mount 
root file system.  All completely out of order.  The output on console 
looks something like this:

Loading scsi_mod.ko module
Loading sd_mod.ko module
Loading 3w-xxxx.ko module
Loading scsi_transport_spi.ko module
Loading sym53c8xx.ko module
Loading dm-mod.ko module
Loading jbd.ko module
Loading ext3.ko module
Loading dm-mirror.ko module
Loading dm-zero.ko module
Loading dm-snapshot.ko module
  Here goes output from loaded modules, in no particular order, all totally
  mixed up, couple of lines from 3w-xxxx, then couple of lines from sym53c8xx,
  then couple of lines from 3w-xxxx again and so on...

By the time vgscan is run, even the jbd and ext3 modules are not yet 
completely loaded in kernel.

If I boot single processor kernel, all is fine.  Device drivers are 
loaded one by one, insmod waits for device driver to initialize 
properly.  Just as it should be.  The output on console looks like:

Loading scsi_mod.ko module
Loading sd_mod.ko module
Loading 3w-xxxx.ko module
   Otuput of 3w-xxxx detecting RAID volumes
Loading scsi_transport_spi.ko module
Loading sym53c8xx.ko module
   Output of sym53c8xx detecting SCSI devices
Loading dm-mod.ko module
Loading jbd.ko module
Loading ext3.ko module
Loading dm-mirror.ko module
Loading dm-zero.ko module
Loading dm-snapshot.ko module

The workaround I have to get system to boot using SMP kernel is to 
modify init script from initrd, and insert bunch of sleeps after each 
insmod to give device driver ehough time to initialize before next 
device driver (wich might depend on one or more previous device 
drivers) is loaded.  This kind of works, but it's just an ugly hack to 
hide underlying problem.  Of course, there is also this nasty feeling 
that something inside kernel doesn't really work well and that other 
things might break or that data might get corrupted.

When I was Googling around, I also found suggestion to turn off MPS 1.4 
in BIOS, but it made no difference in my case.  Of course, turning ACPI 
off can't be done on SMP kernel (and system works fine with ACPI using 
single-processor kernel).

I'm still not sure if this is problem with kernel (things worked fine 
with 2.4 SMP kernels), or some strange bug in (new) insmod executable 
that surfaces only when using this particular motherboard.

Anyhow, to conclude this lenghty email...  Any success/failure story 
with running 2.6 SMP kernel based distro (particuallary CentOS4) on 
this motherboard is more than welcome.

-- 
See Ya' later, alligator!
http://www.8-P.ca/

Aleksandar Milivojevic
> Just wondering if anybody managed to get SMP kernel to boot properly on
> an old Asus CUV4X-DLS motherboard (older dual P-III)?
Someone using SME Server (Centos 4 kernel) I think the same problem with
exactly the same motherboard - updating the bios fixed it:
http://www.contribs.org/bugzilla/show_bug.cgi?id=1170

Greg