Re: 2.6.16-rc4: known regressions

["Theodore Ts'o" <tytso@mit.edu>]

On Wed, Feb 22, 2006 at 07:48:21AM -0800, Joel Becker wrote:
> On Wed, Feb 22, 2006 at 06:21:58AM -0500, Theodore Ts'o wrote:
> > with all of the kernel modules I need compiled into the kernel.  I
> > still have no idea why mptscsi fails to detect SCSI disks when loaded
> > as a module via initrd on various bits of IBM hardware (including the
> > e326 and ls-20 blade), but works fine when compiled directly into the
> > kernel....
> 
> Ted,
> 	Do you mean that you are using a distro (eg, RHEL4 or something)
> with a mainline kernel?  We've seen something similar, and what we've
> determined is happening is that insmod is returning before the module is
> done initializing.  It's not that mptscsi fails to detect the disks.
> Rather, it's still in the detection process when the boot process tries
> to mount /.  So there's no / yet, and the thing hangs.  

Yep, that's exactly what I'm doing; RHEL4U2 with a 2.6.14 or 2.6.15
kernel.  Thanks for the tip, that should help me investigate further!

> In the case we
> see, it's some interaction between the RHEL4/SLES9 version of
> module-init-tools and the latest version of the kernel.  Our first
> attempt at fixing it was to change the linuxrc to sleep between each
> insmod.  This works, but only if the modules load and initialize
> themsleves fast enough.  Get a FC card in there, and it just doesn't
> work.  So we've taken to compiling the modules in-kernel.

Sounds like this is another of example of system support programs
(insmod in this case) breaking with modern kernels.  Hopefully now
that Linus has laid down the law about how breaking userspace is
uncool, people will agree that it's a bug.  (That is unless Red Hat
made some kind of incompatible change and it's Red Hat's fault, but I
kinda doubt that.)  Anyway, I'll look into this some more and see why
you can't use a mainline kernel with RHEL4, at least not in this
configuration.

						- Ted