Re: RFC: Starting a stable kernel series off the 2.6 kernel

[Bill Davidsen]

Greg KH wrote:
> On Mon, Dec 05, 2005 at 04:17:53PM +0100, Jakob Oestergaard wrote:
>
> > On Sun, Dec 04, 2005 at 02:39:31PM -0800, Greg KH wrote:
> >
> > > On Sun, Dec 04, 2005 at 06:00:49PM +0100, Jakob Oestergaard wrote:
> > >
> > > > In the real world, however, admins currently need to pick out specific
> > > > versions of the kernel for specific workloads (try running a large
> > > > fileserver on anything but 2.6.11.11 for example - any earlier or later
> > > > kernel will barf reliably.
> > >
> > > Have you filed a but at bugzilla.kernel.org about this?  If not, how do
> > > you expect it to get fixed?
> >
> > I don't expect to get it fixed. It's futile. It can get fixed in one
> > version and broken two days later, and it seems the attitude is that
> > that is just fine.
>
>
> Huh?  That is just not true at all.  Please give us a bit more credit
> than that.
>
>
> > After a long long back-and-forth, 2.6.11 was fixed to the point where it
> > could reliably serve files (at least on uniprocessor configurations -
> > and in my setup I don't see problems on NUMA either, but as far as I
> > know that's just me being lucky).
> >
> > Right after that, someone thought it was a great idea to pry out the PCI
> > subsystem and shovel in something else.  Find, that's great for a
> > development kernel, but for a kernel that's supposed to be stable it's
> > just not something you can realistically do and expect things to work
> > afterwards.  And things broke - try mounting 10-20 XFS filesystems
> > simultaneously on 2.6.14.  Boom - PCI errors.
>
>
> What PCI errors are you speaking of?  We did that PCI work to fix a lot
> of other machines that were having problems.  And yes, this did break
> some working machines, and we are very sorry about this.  But in the
> future, changes to this area will not cause this to happen due to the
> changes made.

I don't think it's reasonable to get overly upset about *accidental* 
breakages. People make mistakes, otherwise you don't get progress.

Note that I haven't changed my mind about deliberately removing features 
for which there is no practical alternative.
--
   -bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me

-
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/