Re: Bug#404143: Fans unreliable under load, permanent memory leak
On Wed, Dec 27, 2006 at 04:22:45AM +0100, maximilian attems wrote:
> On Tue, Dec 26, 2006 at 06:52:06PM -0800, Jurij Smakov wrote:
> > > backports are risky, again as you see for the net-r8169-1.patch,
> > > that is a "localized" driver enhancement with big slow down consequences
> > > #400524 and #403782. yes upstream has a fix for that and it should
> > > land soon, but still no one else bothered yet.
> > That's because slower networking will not break your hardware.
> 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
> the dsdt of those hp notebooks is quite strange,
> if you follow mjg59 posts you have read a funny story:
> 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.
Obviously, this version of the patch is not the one which was
reverted. It has already went through some pretty stringent review and
> 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 firstname.lastname@example.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC