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 [EMAIL PROTECTED] > Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC the high risk of unwanted/unrelated side effects of the acpi subsys. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]