The ACPICA project is in a unique situation where we have an "official" standard to implement to -- namely, the ACPI specification, but reality dictates that we have a "de-facto" standard to implement to, namely Windows. The official standard is public; but the de-facto standard is a black box. This is why when a sticky issue comes up, we need to know both what the official standard says, and what the de-facto standard actually does. In the case of a conflict, we are forced to defer to the de-facto standard regardless of what the official standard says. There are countless examples of this in the ACPICA code. One of the good ones is the implementation of "implicit return" -- the official spec allows no such thing, and explicit return is required. But the de-facto standard allows the results of the last operation to be returned to the caller. In order to support the various machines whose BIOS depends on this feature, ACPICA was forced to copy this behavior. >To be honest I do not care much what is done there as long as it works >on Linux. This is our goal also. Our approach is not to simply blindly fix problems as they appear; we attempt to fully understand what both the ACPI specification dictates and also what Windows does in a given situation. In this case, if the machine runs Windows correctly (and automatically), we want to know exactly why (and how). Bob >-----Original Message----- >From: Thomas Renninger [mailto:trenn@xxxxxxx] >Sent: Tuesday, May 13, 2008 11:01 AM >To: Moore, Robert >Cc: linux-acpi; Len Brown; Zhao, Yakui; me@xxxxxxxxxxxxxxxxx; Starikovskiy, >Alexey Y >Subject: RE: [PATCH 1/3] ACPICA: Add acpi_gbl_force_rsdt variable > > >On Fri, 2008-05-09 at 10:28 -0700, Moore, Robert wrote: >> Sounds like there are still a lot of "unknowns", namely >> >> 1) what does XP do? >> 2) what does Vista do? >Chances are high that nobody will answer these questions on this list. >How should this be checked? > >To be honest I do not care much what is done there as long as it works >on Linux. You also always have the vendor specific aspect on these OS >(probably more than on Linux). They might workaround this in the same >way. > >> 3) is there actually a bug in ACPICA? >> >> I'm not comfortable just slapping in another global when so many >> questions remain unanswered. >This global is not that bad? Its use is clear and it's only touched at >two places, inside and outside acpica. > >Moving the blacklist from drivers/acpi/processor_idle up to where the >real culprit lies is IMO how this problem should be fixed forever (and >if others should really pop up, which I doubt, this looks like a >ThinkPad specific problem, they can easily be tested by >acpi_root_table=rsdt and then added to the blacklist). > >Yakui's patch to check against differences between FADTs pointed to via >RSDT and XSDT could be added and a warning could be printed out, so that >we get more input here. I do not like it much, as it touches and looks >into both tables very early, but if it works..., a warning or even an >error if differences are found could shed some light in here. > >But it is definitely a bad idea to choose the RSDT by default (Even if >Windows should do it similar on some machines, it worked well for quite >some time now and changing a default will cause regressions on some >specific machines. The regressions are found after two further kernel >revisions and the confusion, anger and blacklist is complete). > >I will add my three patches to the latest OpenSUSE kernel now, please >let me know if you find out more or if this gets fixed in another way. > >Yakui, you might want to send the check for RSDT vs XSDT with a fat >error printed out, I can add this one also and post if more machines are >found. > >Thanks, > > Thomas >> >> Bob >> >> >> >-----Original Message----- >> >From: Thomas Renninger [mailto:trenn@xxxxxxx] >> >Sent: Friday, May 09, 2008 1:50 AM >> >To: Moore, Robert >> >Cc: linux-acpi; Len Brown; Zhao, Yakui; me@xxxxxxxxxxxxxxxxx; >> Starikovskiy, >> >Alexey Y >> >Subject: RE: [PATCH 1/3] ACPICA: Add acpi_gbl_force_rsdt variable >> > >> >On Thu, 2008-05-08 at 09:32 -0700, Moore, Robert wrote: >> >> Has there any investigation into how windows handles this? >> >It's too late now, anyway. >> >This is about 3 years old machines, we do not want to change the >> >behavior XSDT vs RSDT in general and produce some regressions as a >> >side-effect, but just fix up some known broken machines. >> > >> >I expect that XP did violate a bit the spec and tended to prefer the >> >RSDT. I don't know how to check all this, but I expect that Vista is >> >preferring the XSDT again. >> >Or there always were bugs in acpica setting up the FADT via XSDT >> causing >> >this. >> > >> >Providing OS a knob at this place shouldn't be a big deal? >> > >> > Thomas >> > >> >> >-----Original Message----- >> >> >From: Thomas Renninger [mailto:trenn@xxxxxxx] >> >> >Sent: Thursday, May 08, 2008 8:10 AM >> >> >To: linux-acpi; Len Brown >> >> >Cc: Zhao, Yakui; me@xxxxxxxxxxxxxxxxx; Moore, Robert; Starikovskiy, >> >> Alexey >> >> >Y >> >> >Subject: [PATCH 1/3] ACPICA: Add acpi_gbl_force_rsdt variable >> >> > >> >> >I expect separate patches should now be patched against >> >> >acpica when possible? >> >> > >> >> >Does this also make sense with patches which have dependencies >> >> >to other patches for the Linux kernel? In this case there is not a >> >> >"does not compile" dependency, but at least they belong together. >> >> > >> >> >I wonder what works out for acpica and Linux kernel maintainers >> best, >> >> >please advise. >> >> > >> >> > >> >> >---- >> >> > >> >> >ACPICA: Add acpi_gbl_force_rsdt variable >> >> > >> >> >Signed-off-by: Thomas Renninger <trenn@xxxxxxx> >> >> >Tested-by: Mark Doughty <me@xxxxxxxxxxxxxxxxx> >> >> > >> >> > >> >> >--- >> >> > drivers/acpi/tables/tbutils.c | 3 ++- >> >> > drivers/acpi/utilities/utglobal.c | 1 + >> >> > include/acpi/acglobal.h | 1 + >> >> > 3 files changed, 4 insertions(+), 1 deletion(-) >> >> > >> >> >Index: linux-acpi- >> >> >2.6_video_native_vs_vendor/drivers/acpi/utilities/utglobal.c >> >> >=================================================================== >> >> >--- linux-acpi- >> >> >2.6_video_native_vs_vendor.orig/drivers/acpi/utilities/utglobal.c >> >> >+++ >> >> >> linux-acpi-2.6_video_native_vs_vendor/drivers/acpi/utilities/utglobal.c >> >> >@@ -76,6 +76,7 @@ u8 acpi_gbl_method_executing = FALSE; >> >> > /* System flags */ >> >> > >> >> > u32 acpi_gbl_startup_flags = 0; >> >> >+int acpi_gbl_force_rsdt = 0; >> >> > >> >> > /* System starts uninitialized */ >> >> > >> >> >Index: linux-acpi-2.6_video_native_vs_vendor/include/acpi/acglobal.h >> >> >=================================================================== >> >> >--- >> linux-acpi-2.6_video_native_vs_vendor.orig/include/acpi/acglobal.h >> >> >+++ linux-acpi-2.6_video_native_vs_vendor/include/acpi/acglobal.h >> >> >@@ -246,6 +246,7 @@ ACPI_EXTERN u8 acpi_gbl_system_awake_and >> >> > >> >> > extern u8 acpi_gbl_shutdown; >> >> > extern u32 acpi_gbl_startup_flags; >> >> >+extern int acpi_gbl_force_rsdt; >> >> > extern const char *acpi_gbl_sleep_state_names[ACPI_S_STATE_COUNT]; >> >> > extern const char *acpi_gbl_highest_dstate_names[4]; >> >> > extern const struct acpi_opcode_info >> >> >acpi_gbl_aml_op_info[AML_NUM_OPCODES]; >> >> >Index: >> >> linux-acpi-2.6_video_native_vs_vendor/drivers/acpi/tables/tbutils.c >> >> >=================================================================== >> >> >--- linux-acpi- >> >> >2.6_video_native_vs_vendor.orig/drivers/acpi/tables/tbutils.c >> >> >+++ >> linux-acpi-2.6_video_native_vs_vendor/drivers/acpi/tables/tbutils.c >> >> >@@ -421,7 +421,8 @@ acpi_tb_parse_root_table(acpi_physical_a >> >> > >> >> > /* Differentiate between RSDT and XSDT root tables */ >> >> > >> >> >- if (rsdp->revision > 1 && rsdp->xsdt_physical_address) { >> >> >+ if (rsdp->revision > 1 && rsdp->xsdt_physical_address >> >> >+ && !acpi_gbl_force_rsdt) { >> >> > /* >> >> > * Root table is an XSDT (64-bit physical addresses). We >> >> must >> >> >use the >> >> > * XSDT if the revision is > 1 and the XSDT pointer is >> >> present, >> >> >as per >> >> > >> >> >> -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
