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

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 
position.

> 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.

> 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



Reply to: