Re: 2.6.16-rc4: known regressions

From: Arjan van de Ven
Date: Wed Feb 22 2006 - 14:28:14 EST


On Wed, 2006-02-22 at 11:18 -0800, Greg KH wrote:
> On Wed, Feb 22, 2006 at 10:59:23AM -0800, Joel Becker wrote:
> > On Wed, Feb 22, 2006 at 06:33:54PM +0100, Gabor Gombas wrote:
> > > I don't think isnmod is broken. It's job is to load a chunk of code into
> > > the kernel, and it's doing just that.
> > >
> > > ...
> > >
> > > But if your kernel has CONFIG_HOTPLUG enabled, then _you_ have asked for
> > > this exact behavior, therefore you should better fix userspace to cope
> > > with it. Your initrd should use the notification mechanisms provided by
> > > the kernel to wait for the would-be root device really becoming
> > > available; if it's not doing that, then IMHO you should not use a
> > > CONFIG_HOTPLUG enabled kernel.
> >
> > The issue isn't so much "insmod is right" vs "insmod is wrong".
> > It's that the behavior changed in a surprising fashion. Red Hat's
> > kernel for RHEL4 (in our example) has CONFIG_HOTPLUG=y, yet it Just
> > Works. A more recent kernel (.15 and .16 at least) with
> > CONFIG_HOTPLUG=y doesn't work. Same disk drivers. Same initramfs
> > script.
>
> RHEL is a very different kernel from mainline (just like SLES is). Have
> you looked through their patches to see if they are including something
> that causes this behavior?

I doubt it does; rhel isn't that much patches...

>
> What about trying a stock 2.6.6 or so kernel? Does that work
> differently from 2.6.15?

... however it's very much designed only for the kernel that comes with
it (with "it's" I mean all the userspace infrastructure); all the
changes and additions since 2.6.9 aren't incorporated so you probably
really want new alsa, new initscripts, new mkinitrd, new
module-init-tools. some because of abi changes since 2.6.9, others
because the kernel grew capabilities that are really needed for "nice"
behavior.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/