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 [EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
