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

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

On Tue, 26 Dec 2006, Jurij Smakov wrote:

> On Wed, Dec 27, 2006 at 04:22:45AM +0100, maximilian attems wrote:
> > why was that fact never rc for sarge?
> > #259481, #262383
> Discussing why it was not RC for Sarge seems pretty irrelevant to me. 
> It's up to release managers what is RC, and Etch release managers have 
> stated repeatedly that this issue is RC. I happen to agree with their 
> position.

a broken dsdt is a vendor fault.

for sarge the affected range was across all boxes,
here this affects 2 specific hp laptop models.
> > the dsdt of those hp notebooks is quite strange,
> > if you follow mjg59 posts you have read a funny story:
> > http://mjg59.livejournal.com/67443.html
> > 
> > the reference is easily readable in the git-commits-mail,
> > if you interested in a 2006 tarball, i can send it.
> > 
> > check b976fe19acc565e5137e6f12af7b6633a23e6b7c
> > it reverts your proposed patch.
> >From the comments in patch #9746:
>  First attempt to create a new thread was done by Peter Wainwright
>  He created a bunch of threads, which were stealing work from a kacpid workqueue.
>  This patch appeared in 2.6.15 kernel shipped with Ubuntu 6.06 LTS.
>  Second attempt was done by me, I created a new thread for each Notify
>  event. This worked OK on HP nx machines, but broke Linus' Compaq
>  n620c, by producing threads with a speed what they stopped the machine
>  completely. Thus this patch was reverted from 18-rc2 as I remember.
>  I re-made the patch to create second workqueue just for notify events, 
>  thus hopping it will not break Linus' machine. Patch was tested on the
>  same HP nx machines in #5534 and #7122, but I did not received reply
>  from Linus on a test patch sent to him.
>  Patch went to 19-rc and was rejected with much fanfare again.
>  There was 4th patch, which inserted schedule_timeout(1) into deferred
>  execution of kacpid, if we had any notify requests pending, but Linus
>  decided that it was too complex (involved either changes to workqueue
>  to see if it's empty or atomic inc/dec).
>  Now you see last variant which adds yield() to every GPE execution.
>  http://bugzilla.kernel.org/show_bug.cgi?id=5534
> Obviously, this version of the patch is not the one which was 
> reverted. It has already went through some pretty stringent review and 
> incremental improvement.

again i'm highly skeptic about the patch quality.
the semantics of yield() changed fundamentally from 2.4 to 2.6.
afaik only b0rked code in 2.6 needs yield().
> > fully agreed.
> > the cost analysis of acpi patches seems quite high,
> > that's why we currently have the policy not to add any.
> > i hate to do name dropping, but that goes back to hch.
> I'm not aware of any such policy. We have backported a fair amount of 
> fixes from newer upstream releases, I don't see what qualifies ACPI as 
> some magic which should not be touched.
> -- 
> Jurij Smakov                                           jurij@wooyd.org
> Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

the high risk of unwanted/unrelated side effects of the acpi subsys.


Reply to: