Bug#404143: Fans unreliable under load, permanent memory leak
On Fri, Dec 22, 2006 at 12:09:45PM +0100, maximilian attems wrote:
> On Fri, Dec 22, 2006 at 11:28:29AM +0100, Marc 'HE' Brockschmidt wrote:
> > Bastian Blank <email@example.com> writes:
> > > On Fri, Dec 22, 2006 at 10:30:57AM +0100, Marc 'HE' Brockschmidt wrote:
> > >> Sorry, I don't accept this. We are talking about an *overheating*
> > >> problem, which means *broken* hardware. There needs to be at least a fix
> > >> documented in the release-notes.
> > > Garbage-in, garbage-out. The BIOS of that machines is broken. Do you
> > > really expect that an interpreter (in this case the ACPI interpreter)
> > > accepts any garbage?
> > Other OSes don't destroy the hardware. There is a patch for Linux not to
> > - I don't see why Debian should release with a kernel that destroys
> > hardware, without even giving users a warning. Not everyone who buys a
> > notebook is aware of ACPI problems, and we shouldn't expect all users to
> > do so.
> > Fix it or document it, I don't care. But the current state is not
> > releasable.
> we are not talking about "a" patch.
> what you need is an backport of the 2.6.19 acpi release to 2.6.18.
> acpi linux releases are tested as one release and you open a can of worm
> once you start picking acpi patches. only mjg59 is insane enough to do
> that. anyway the fix for those broken aml tables has a big dependency
> so the backport is insane.
> i looked at it 2 month ago and dropped the case, we are shortly before
> release. i restate those broken hardware needs a newer kernel fullstop.
Well, this would mean that we could provide a semi-official set of newer
kernels for etch. We would, once etch is released, provide a backportet kernel
of the new unstable kernel, as well as a etch-installing d-i for them.
This would allow users to install a stable etch, but including a newer kernel,
which is what probably most of us are doing anyway.