> I agree, but I didn't want to make any sort of drastic changes to scsi.c
> in Aurora (I'm still getting my feet wet here!).
> As to the claim that this is broken solely due to Aurora being broken, I
> can dispell that simply by pointing to the fact that Red Hat Linux 7.3
> exhibits this behavior as shipped, on machines where the scsi drivers
> are modular. dmesg log from 2.4.18-3smp is attached to this email.
> In fact, sunesp is modular in Aurora, which is how this issue came to
> light. When I made the change from compiled in to modular (and started
> using an initrd), several testers reported this as a bug.
> Feel free to correct me (and Doug) if I'm wrong, because I cede that you
> know a HELL of a lot more about this than I do. My Aurora kernels use
> this, the scsi subsystem works (the modules all load as they should),
> and I don't have a kmod error message in dmesg.
> For reference, Aurora builds kernels with the following relevant
> The Red Hat Linux 7.3 i686 config builds kernels with the following
> relevant options:
> As a result of further testing and thought, I definitely agree with
> Doug. The patch that I originally submitted will only get rid of the
> kmod error noise when BLK_DEV_SD is compiled into the kernel. Perhaps
> this block of code should die? I'll leave that to the experts to decide.
It is the upper level device init/insmod that is driving the load of the
scsi adapter (in scsi.c), not the init/insmod of scsi.o. I can't think of
a good reason to just load the scsi adapter if you want it, rather than
having the init of sd.o load it.
IMO, it should go away or always happen - not conditionally on whether another
adapter is already available, or whether sd.o is loading.
If you are booting without initrd, aren't there lines in /etc/modules.conf
If you are booting with initrd, my RH 7.2 mkinitrd shows:
ln -s /bin/nash $MNTIMAGE/sbin/modprobe
man nash says:
Additionally, if nash is invoked as modprobe, it will
immediately exit with a return code of zero. This is to
allow initrd's to prevent some extraneous kernel error
messages during startup.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/