ACPI patches for 2.6.34-rc6
in [Kernel]
|
Prev: [PATCH 0/2] net-next/fec: bug fixing after introduced phylib supporting
Next: [PATCH] Check kmalloc return value before use the buffer
From: Linus Torvalds on 6 May 2010 22:40 On Thu, 6 May 2010, Len Brown wrote: > > The big DMI list in sleep.c a temporary brute force and low-risk workaround. > We will endeavor to delete it entirely in 2.6.35 with a clean fix > that was deemed too risky for this late in the .34 release cycle. Btw, why don't we just force the SCI_EN by hand? We did that for the Apple Mac Mini bug too. It was always the right thing to do. There is _no_ reason not to force it. If the BIOS set it, it's a no-op. If the BIOS didn't set it, it's a bug that _must_ be fixed. I really don't see the reason for that DMI list. What could _possibly_ go wrong for just setting the damn bit that we _know_ has to be set? How could setting SCI_EN _ever_ be a bug? Seriously? Why are we doing this conditionally, especially considering that even the commit message here explicitly states that Windows does it unconditionally? And no, I'm not interested in "that toilet paper spec says you can't touch it". I care about _reality_. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 7 May 2010 02:20 On Thu, May 06, 2010 at 07:34:10PM -0700, Linus Torvalds wrote: > > > On Thu, 6 May 2010, Len Brown wrote: > > > > The big DMI list in sleep.c a temporary brute force and low-risk workaround. > > We will endeavor to delete it entirely in 2.6.35 with a clean fix > > that was deemed too risky for this late in the .34 release cycle. > > Btw, why don't we just force the SCI_EN by hand? The spec says we can't. I've posted a patch to do so if it's still not set after we've tried doing it the right way, but I'm not keen on pushing it into a release at this point. > There is _no_ reason not to force it. If the BIOS set it, it's a no-op. If > the BIOS didn't set it, it's a bug that _must_ be fixed. Kind of. The "correct" way to do it is to write to an ioport, and doing that usually triggers an SMI. So writing the bit by hand without ensuring that we do that is a difference in behaviour, while we've simultaneously seen some evidence triggering that SMI may break some machines - it's conceivable that Windows does it on boot and writes it by hand on resume and so every machine in the real world would be fine with us doing it by hand, but we haven't tested that yet and it doesn't seem like a great risk to take at this point in the development cycle. But yes, that DMI list will go in .35. We'll figure out who breaks and why at that point. > How could setting SCI_EN _ever_ be a bug? Seriously? Why are we doing this > conditionally, especially considering that even the commit message here > explicitly states that Windows does it unconditionally? If the southbridge comes up with GPEs enabled in a way that expects one thing and we write the bit differently without SMM being involved in the process then there's potential misery. I suspect that any such misery is entirely due to BIOS vendors being insane, but unfortunately scientific testing has demonstrated that BIOS vendors are insane with a P of < 0.001 and an N of MAX_INT. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 7 May 2010 17:10 On Fri, 7 May 2010, Matthew Garrett wrote: > > The spec says we can't. I've posted a patch to do so if it's still not > set after we've tried doing it the right way, but I'm not keen on > pushing it into a release at this point. I'm ok with the "release at this point". But the "spec says we can't" is utter GARBAGE. We _know_ the ACPI spec is broken, and almost no BIOSes really follow it. So "spec says" is not a game we play. The ACPI spec is toilet paper compared to "real world". And anybody who looks at the current DMI tables for "oh, do this" realizes that this is _not_ an uncommon thing, and should damn well realize that this means that clearly Windows doesn't honor the spec _either_. At that point, the spec isn't just toilet paper, it's toilet paper that MS has wiped their butt on. So f*ck "spec says". > > There is _no_ reason not to force it. If the BIOS set it, it's a no-op. If > > the BIOS didn't set it, it's a bug that _must_ be fixed. > > Kind of. The "correct" way to do it is to write to an ioport, and doing > that usually triggers an SMI. The "correct" way to do it is to basically do what works, and that in turn generally means "do what Winddows does, because that's the only thing that ever got tested". I'm perfectly happy with "try to do it the right way, and check the end result: and if SCI_EN still isn't set, do it by hand". So I don't think we need to do the write _unconditionally_, but it sure as hell shouldn't be conditional on some DMI table. Because all the DMI table tells is is that we do it _wrong_ right now, since clearly Windows doesn't have this issue. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 7 May 2010 17:20 On Fri, May 07, 2010 at 02:06:53PM -0700, Linus Torvalds wrote: > On Fri, 7 May 2010, Matthew Garrett wrote: > > > > The spec says we can't. I've posted a patch to do so if it's still not > > set after we've tried doing it the right way, but I'm not keen on > > pushing it into a release at this point. > > I'm ok with the "release at this point". http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=3b12303e6bda6e05579d899fb71cb3e9d3bc26ba -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 7 May 2010 17:30
On Fri, 7 May 2010, Matthew Garrett wrote: > On Fri, May 07, 2010 at 02:06:53PM -0700, Linus Torvalds wrote: > > On Fri, 7 May 2010, Matthew Garrett wrote: > > > > > > The spec says we can't. I've posted a patch to do so if it's still not > > > set after we've tried doing it the right way, but I'm not keen on > > > pushing it into a release at this point. > > > > I'm ok with the "release at this point". > > http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=3b12303e6bda6e05579d899fb71cb3e9d3bc26ba Well, is there any reason to have 'set_sci_en_on_resume' at all then? I mean, the only reason for that config thing in the first place is that we didn't do this from the beginning. No? And I'd hate to then carry the DMI table along forever just to set a variable that isn't worth setting any more.. IOW, I don't disagree with the patch. I just don't think it went far enough. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |