Hi Greg, Matt,
* Greg KH <greg@xxxxxxxxx>:
> On Wed, Nov 14, 2007 at 02:42:21PM -0700, Alex Chiang wrote:
> > * Greg KH <greg@xxxxxxxxx>:
> > > On Wed, Nov 14, 2007 at 10:37:08AM -0700, Bjorn Helgaas wrote:
> > > >
> > > > So I agree that the firmware kit has a clever hack that works
> > > > on much existing x86 firmware, and it sounds like Tivoli
> > > > might even rely on it. But I don't feel good about it, and
> > > > it could easily break when some BIOS writer needs to make
> > > > _SUN slightly more complicated.
> > >
> > > Do you know of such BIOSes out there that do this? Will the
> > > above scheme not work for the ia64 boxes that you know of that
> > > are out in the world today?
> >
> > One last mail on this subject -- Bjorn has pointed out to me that
> > the Dell pe6800 and rez1850 both implement _SUN as control
> > methods today.
>
> Does the firmware kit break on them?
I downloaded the firmware kit today and played with it. There is
a test called SUN.exe, which searches through the DSDT, looking
to verify that there are no duplicate _SUN values in the system.
The test breaks on my hp rx6600 (a currently shipping platform),
because _SUN is not a hard-coded value, but implemented as an AML
control method. From the various SSDT dumps:
Here's the _SUN for a slot:
Method (_SUN, 0, Serialized)
{
Store (\SLOT.SUN, ^_UID)
Local0
Return (Local0)
}
Here's the _SUN for a processor:
Method (_SUN, 0, NotSerialized)
{
Store (\CPUL.SUN, ^CPID)
Local0
Return (Local0)
}
So parse_SUN_name() from SUN.c is just plain broken. The test
"passes" because it doesn't find any duplicate values for _SUN,
but what's really going on is that it doesn't find *any* values
of _SUN, so of course there won't be duplicates. ;)
I looked at convincing this test to try and execute the method
using ExecuteAmlMethod() and/or execute_aml_method(), but of
course, that won't work on a modern kernel, as they depend on
/proc/acpi/hotkey/, which was removed (as Bjorn pointed out).
Matt, is there any chance you could see if the firmware kit works
or breaks on your PE6800?
I downloaded the latest tarball:
http://www.linuxfirmwarekit.org/download/firmwarekit-r3.tar.gz
And ran it in stand-alone mode. You do need to build the test
suite, but you don't need to run the entire thing -- just run the
SUN/SUN.exe that is generated. (If you get odd complaints about
not being able to find libstandalone.so, just stick it in
/usr/local/lib, modify /etc/ld.so.conf as necessary and run
ldconfig).
Please apply the following debug patch to see how many _SUN
objects the test is actually finding. On my machine, I don't find
any _SUN objects.
Thanks.
/ac
diff --git a/SUN/SUN.c b/SUN/SUN.c
index 90264a7..3b21b9c 100644
--- a/SUN/SUN.c
+++ b/SUN/SUN.c
@@ -260,6 +260,7 @@ static void parse_SUN_name(gpointer data, gpointer user_data)
int main(int argc, char **argv)
{
+ int i;
start_test("SUN", "SUN duplicate test",
"This makes sure that each SUN (Slot Unique Number) that is "
"called in the DSDT through the Name() method is unique, no "
@@ -281,6 +282,11 @@ int main(int argc, char **argv)
/* List SUN duplicates (if any) */
do_SUN_check();
+
+ while(SUN_list[i].line_num) {
+ printf("## found SUN: %s\n", SUN_list[i].SUN_hexnum);
+ i++;
+ }
finish_test("SUN");
return EXIT_SUCCESS;
-
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
