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: Rafael J. Wysocki on 7 May 2010 20:10 On Saturday 08 May 2010, Linus Torvalds wrote: > > On Sat, 8 May 2010, Rafael J. Wysocki wrote: .... > > Let me explain what I think we should do with actual code: > > acpi_enable(); > if (test_if_that_f_cking_bit_still_isnt_set) > set_it_by_hand(); > > wouldn't that work on your box? Yes, it would. > The acpi_enable() seems to work for you, so it wouldn't actually ever set it > by hand. > > But the problem is that on a number of boxes, acpi_enable() apparently > doesn't do what it should do. Because the stupid BIOS "knows" it is > already in ACPI mode, but it forgot to actually set the bit! To calrify, I think the approach in the Matthew's patch is correct, but since I have some bad experience with that particular thing, I prefer to make that change in 2.6.35 and then move on to drop the flag entirely. Rafael -- 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 20:20 On Sat, 8 May 2010, Rafael J. Wysocki wrote: > > To calrify, I think the approach in the Matthew's patch is correct, but since I have > some bad experience with that particular thing, I prefer to make that change in > 2.6.35 and then move on to drop the flag entirely. Oh,yes. I'm not suggesting we do it late in the -rc cycle. I just don't think the DMI table is a good idea, so in the longer run I wan tto get rid of it, rather than have it grow (by quite a few entries, in this case). There are valid reasons for DMI tables in many cases, but in this case I think the reason is simply that we do the wrong thing, so then we ended up with a DMI table to "fix" the wrong thing we do. 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: Len Brown on 8 May 2010 01:30 > On Sat, 8 May 2010, Rafael J. Wysocki wrote: > > > > To calrify, I think the approach in the Matthew's patch is correct, but since I have > > some bad experience with that particular thing, I prefer to make that change in > > 2.6.35 and then move on to drop the flag entirely. > > Oh,yes. I'm not suggesting we do it late in the -rc cycle. > > I just don't think the DMI table is a good idea, so in the longer run I > wan tto get rid of it, rather than have it grow (by quite a few entries, > in this case). > > There are valid reasons for DMI tables in many cases, but in this case I > think the reason is simply that we do the wrong thing, so then we ended up > with a DMI table to "fix" the wrong thing we do. Hi Linus, Matthew, Rafael and I all agree with you on every aspect of this issue. The DMI list is temporary. Matthew's patch to do as you say is already queued for 2.6.35. I belive that Rafael was prudent in recommending we delay the "real" fix until .35, as we discovered that the broken machines suffered a 3-second delay on resume, polling for the SCI_EN that the BIOS would never set, and so the proposed fix for that is queued for 2.6.35 as well. thanks, -Len -- 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 11 May 2010 13:30 On Fri, May 07, 2010 at 10:36:00PM +0100, Matthew Garrett wrote: > On Fri, May 07, 2010 at 02:21:08PM -0700, Linus Torvalds wrote: > > Well, is there any reason to have 'set_sci_en_on_resume' at all then? > > I'd hope not, but it depends on what Windows does on resume. If it > doesn't do the SMM call and just does the register write instead, then > it may be that some machines are on that list because the SMM call > breaks them rather than because they need the register to be set by > hand. I'm planning on instrumenting it to check, but haven't had time to > do so yet. I've now checked the behaviour of Windows. It turns out that it never makes the ACPI enable SMM call on resume. This is consistent with http://bugzilla.kernel.org/show_bug.cgi?id=13745 which shows a bug being introduced by us making the enable call in the first place. Merging my patch and removing the blacklist would re-break these machines. Instead, we should just unconditionally set SCI_EN since this is the tested configuration. I'll send a followup patch. -- 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 11 May 2010 13:50
On Tue, 11 May 2010, Matthew Garrett wrote: > > I've now checked the behaviour of Windows. It turns out that it never > makes the ACPI enable SMM call on resume. This is consistent with > http://bugzilla.kernel.org/show_bug.cgi?id=13745 which shows a bug > being introduced by us making the enable call in the first place. > Merging my patch and removing the blacklist would re-break these > machines. Instead, we should just unconditionally set SCI_EN since this > is the tested configuration. I'll send a followup patch. Hmm. But that's the thing that Rafael claims doesn't work on his machine. Maybe windows does something else? Or do you _see_ windows doing that write? Note that our acpi_enable() won't do anything either if the machine comes up in ACPI mode, so maybe you checked the behavior on that kind of machine, and Windows does the same? IOW, if acpi_hw_get_mode() already returns ACPI_SYS_MODE_ACPI, the whole thing is a no-op. Finally, it's possible that we really should just write the dang SCI_EN bit directly, but that what we do wrong is that doing so with acpi_write_bit_register() will write it _even_if_ the bit was already set. That could explain Rafael's problems too - writing the register directly may be the RightThing(tm), but writing it if the bit was already set may well cause some confusion. 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/ |