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:
<snipp>
> > 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.
--
maks
Reply to: