[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#404143: Fans unreliable under load, permanent memory leak



* Sven Luther (sven.luther@wanadoo.fr) [061222 05:42]:
> On Fri, Dec 22, 2006 at 12:53:09PM +0100, Marc 'HE' Brockschmidt wrote:
> > maximilian attems <maks@sternwelten.at> writes:
> > > On Fri, Dec 22, 2006 at 11:28:29AM +0100, Marc 'HE' Brockschmidt wrote:
> > >> 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.
> > 
> > Read again what I wrote. I will not allow Debian to release with a
> > Kernel that may damage hardware without even a notice in the release
> > notes. If you are not able to fix it, note that you have provided a
> > broken kernel.
> 
> Cool, let's delay etch a couple of weeks and move to a (now released) 2.6.19
> kernel, to solve this issue.

Sven, stop this! I can remember well how you promised that moving to
2.6.18 will magically solve almost all of our issues - 6 (or more)
release critical bugs against 2.6.18 don't show that this has worked so
well. Please try helping us on solutions rather then breaking things
again.


Please try to look at it from another perspective:

Consider you have bought such a laptop, and you install Debian. You have
even read the release notes first.  Everything works well.  Until one
day you notice your laptop gets too warm, and eventually even breaks
because of this.  On deeper research, you notice that this issue was
well-known to Debian, but they refused to deal with it at all. How would
you feel as a user? I think this is an unacceptable perspective.


Ok, what can we do? 
1. ignore the problem,
2. document it in the release notes and README.Debian of the kernel,
3. prevent the kernel running on such buggy laptops [is this possible?],
4. backport ACPI from 2.6.19, or use 2.6.19,
5. isolate a smaller fix and apply it.

I personally consider options 1 and 4 to be unacceptable. Option 5 would
be the best, but I have yet to see that this is possible (or rather,
someone knowledgeable enough has time to do it).

So, we should at least document it inside of the release notes, and
README.Debian, and, if possible without being to invasive, get some
check inside the kernel to print a big warning on bootup, or even refuse
to work until some special parameter is used.


How does this proposal sound to the kernel team?



Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/



Reply to: