Very Computer

I have recently recompiled my kernel (2.0.27) in attempt to get my sound
card working (It is an Acer S23 with a CS4232 chipset). The sound card is
working (and so is the rest of my hardware).

But I don't seem to be able to get rid of the following messages at boot-up
time:

Apr  1 21:53:29 jpw insmod: scsi_register_module undefined
Apr  1 21:53:29 jpw insmod: scsicam_bios_param undefined
Apr  1 21:53:29 jpw insmod: scsi_ioctl undefined
Apr  1 21:53:29 jpw insmod: scsi_free undefined
Apr  1 21:53:29 jpw insmod: request_queueable undefined
Apr  1 21:53:29 jpw insmod: scsi_init_free undefined
Apr  1 21:53:29 jpw insmod: dma_free_sectors undefined
Apr  1 21:53:29 jpw insmod: allocate_device undefined
Apr  1 21:53:29 jpw insmod: scsi_unregister_module undefined
Apr  1 21:53:29 jpw insmod: scsi_do_cmd undefined
Apr  1 21:53:29 jpw insmod: need_isa_buffer undefined
Apr  1 21:53:29 jpw insmod: print_command undefined
Apr  1 21:53:29 jpw insmod: scsi_init_malloc undefined
Apr  1 21:53:29 jpw insmod: scsi_malloc undefined
Apr  1 21:53:29 jpw insmod: print_sense undefined
Apr  1 21:53:29 jpw insmod: Loading failed! The module symbols (from
linux-2.0.27) don't match your linux-2.0.27

These messages are also periodically written to my /var/log/syslog file.

Do these messages mean that I have forgotten to configure something when I
recompiled. Most of these seem to refer to scsi drivers which I assumed I
did not need. (I don't have any scsi devices).

I never had this problem with the kernel (without scsi support) that
slackware 3.1 installed for me.

Also is there a way of determining what configuration was used to compile
the default slackware kernel.

--

Jonathan Wilson,                  Tel:   (01703) 595131

University of Southampton,        WWW:   http://www.maths.soton.ac.uk/~jpw/
Southampton, UK.  SO17 1BJ    

Did you move the 2.0.27 directory in your modules directory before you did
a make modules_install? If not, then you have a "poluted" modules
directory in that modules that were made for the previous kernel are now
intermixed with modules with your newer kernel.

For me, my modules (under RedHat 5.0) are located in /lib/modules so
here's what I do before I say make modules_install (running kernel
2.0.33):

cd /lib/modules
mv 2.0.33 2.0.33.old (just in case I have to fall back to these modules)
cd /usr/src/linux
make modules_install

The make modules_install will copy the modules over to a new 2.0.33
(2.0.27 in your case) directory, creating it if it doesn't exist. Then, it
does a depmod to update the modules dependencies.

I would say that from your original install, you had some scsi modules
lying around for the kernel the system was installed with. However,
recompiling your kernel and the modules has now changed some of it's
dependency version strings, so that's why you're getting it. You probably
disabled SCSI support in your kernel when you recompiled and therefore,
you didn't recompile the modules for it and are now using old, stale SCSI
modules for a kernel that doesn't support it.

Just move the 2.0.27 modules dir out of the way and redo your make
modules_install and you should be fine.