kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
here is the context (i am happy to paste all my dmesg to the group
upon request)
:
:
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
sym53c8xx: at PCI bus 0, device 13, function 0
sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
sym53c8xx: 53c875 detected with Symbios NVRAM
sym53c8xx: at PCI bus 1, device 13, function 0
sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
sym53c8xx: 53c875 detected with Symbios NVRAM
:
:
i have no IDE drive. the machine boots fine. i just get this
spurious message. nothing else is odd about the boot up either. the
module must be loading since accessing the boot disk requires the scsi
driver.
using mkinitrd i get the following
euler(~)# mkinitrd -f -v image 2.2.13
Using modules: scsi/scsi_mod.o scsi/sd_mod.o scsi/sym53c8xx.o
Using loopback device /dev/loop0
/bin/ash.static -> /tmp/initrd.610/bin/sh
/sbin/insmod.static -> /tmp/initrd.610/bin/insmod
/lib/modules/2.2.13/scsi/scsi_mod.o -> /tmp/initrd.610/lib/scsi_mod.o
/lib/modules/2.2.13/scsi/sd_mod.o -> /tmp/initrd.610/lib/sd_mod.o
/lib/modules/2.2.13/scsi/sym53c8xx.o -> /tmp/initrd.610/lib/sym53c8xx.o
Loading module scsi_mod with options
Loading module sd_mod with options
Loading module sym53c8xx with options
the modprobe message has been with me since i compiled my own kernel
with scsi modules.
the same exact thing happens with my other machine which has an
adaptec 2940uw (aic7xxx driver).
as to why i use modules and not built in drivers, here is the story (i
posted this to the smp list back in september but received no replies
addressing this problem).
also another oddity is with redhat 6.0. i have managed to fix it but
i'll be damned if i know why it happens in the first place.
redhat 5.2 with glibc-2.0 and glibc-2.1 worked fine with all kernels
from 2.1.124 through 2.2.9.
at that point i installed redhat 6.0. the stock redhat kernel works
fine. i also wanted to compile my own kernel (like always...). i
compile 2.2.5 with aic7xxxx built into the monolith. i have only one
module tulip.o (and dummy.o but that isn't loaded as far as i can
tell). since i put the scsi driver in the kernel, i am not using
initrd. my own compiled 2.2.5 kernel works fine.
i upgrade to 2.2.6 and things are still good.
i go to 2.2.7 and my disk access gets *very slow*. running bonnie
shows that char-wise read/write is about 40K/sec (down from 3000K/sec
for working kernel). interestingly, block read/write is nearly the
same as a good kernel. there isn't any disk data corruption, just
really slow access. disk access is similarly slow for all of 2.2.8,
2.2.9 and 2.2.10.
i note that the aic7xxx driver is *identitical* in both 2.2.6 and
2.2.7. very little changes wrt smp and disk or file system occur
between these versions.
dmesg looks the same for all the kernels. while some version number
change, there are no errors or warnings printed.
i tried out 2.2.10 in uniprocessor and get fairly lousy disk
performance with it too. although now, it's not nearly as bad as
under SMP. i have about 300KB/sec transfer rates. about an order of
magnitude better than SMP new kernel with built-in scsi but an order
of magnitude worse than redhat's kernel.
i am suspicious of an irq conflict (this can cause slow modems) since
each scsi adapter and disk access is being punished by a fixed
amount (independent on the size of the data block being moved).
remember, kernel 2.2.7 and 2.2.9 worked fine before (with redhat 5.2
using either glibc-2.0 or glibc-2.1). i suspect something wacky is
happening during the boot sequence (since i can't figure out anything
else to blame).
i managed to fix this by making scsi modules and using initrd. has
something with redhat's initscripts changed between rh 5.2 and 6.0 to
require this? i can't figure it out. i am just throwing this to
the list to see what anyone else makes of it.
thank you in advance for any light you all can shed upon these issues.
-- J o h a n K u l l s t a m [kullstam@ne.mediaone.net] Don't Fear the Penguin!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/