Created attachment 24211 [details]
New HP Envy notebook (core i7) with latest production F.06 BIOS.
Encountering an error while initializing the ambient light sensor on the EC. During initialization, that object references a non-existent method. This method is actually defined in a dynamic table loaded later.
Triaged down to the point where we know that \_PR_.CPU0._PDC is the method that contains the Load statement that then defines the missing method.
Lines 25--28 indicate the error.
On lines 43,44, and 53,54, we see the dynamic tables get loaded. Those come from a Load in the _PDC method.
The dynamic table named ApIst (line 53) contains the definition of \_PR_.CPU0._PPC.
This bug is very similar to http://bugzilla.kernel.org/show_bug.cgi?id=14710 but the thermal zone and fans actually work on this machine.
Created attachment 24212 [details]
acpidump and dynamic tables
The dynamic tables were extracted by examining SSDT5 to learn the memory offset and size.
Then I issued: acpidump --address 0xfoo --length 0xbar > dyn-table.out.
Since Windows 7 runs fine on this machine, perhaps Linux needs to evaluate _PDC earlier to be compatible.
I took a look at doing this, but it seems to be non-trivial.
patch set has been applied to acpi-test.
patch series referenced above shipped in linux-2.6.33-rc2
Created attachment 24591 [details]
for reference: \_PR.CPU0._CST is contained in CPU0CST.dsl, attached.
*** Bug 15801 has been marked as a duplicate of this bug. ***
I know this is fixed and closed already, but I don't like the fact that
we had to add special-case code to evaluate processor _PDC methods in
I doubt that Windows has a _PDC special case. It would have to have
been there for a long time, because I'm sure there was no Windows update
just for this laptop, and I don't see anything in the spec that would
suggest such special treatment. It'd be interesting to use qemu to
figure out whether Windows really does something special here.
I don't have time to really do anything with this now, so these are just
idle thoughts in case I can come back to this later. If I understand
correctly, the original problem is this:
1) The \_SB_.PCI0.LPCB.EC0_._REG method references \_PR_.CPU0._PPC
2) The \_PR_.CPU0._PPC definition is in an SSDT loaded by the CPU0 _PDC method
3) Linux executes the _REG method before the _PDC method, so _PPC is undefined
The ACPI 4.0 spec, section 6.5.4 (_REG) on p. 276 does say:
OSPM must make Embedded Controller operation regions, accessed via the
Embedded Controllers described in ECDT, available before executing any
So we clearly have to do *some* EC initialization early. But I wonder if
we're doing more than is required. We currently call acpi_boot_ec_enable(),
which uses ec_install_handlers() -> acpi_install_address_space_handler() ->
acpi_ev_execute_reg_methods() to evaluate _REG(1). But the surrounding
text from the spec suggests that _REG(1) is *not* required at this point:
Except for the cases shown below, control methods must assume all
operation regions inaccessible until the _REG(RegionSpace, 1) method
is executed. ...
The exceptions for this rule are:
1. [PCI config, I/O, and memory opregions]
2. [Embedded Controller opregions via the ECDT controller]
Maybe Windows merely happens to bind the \_PR_.CPU0 driver (and run
its _PDC method) before it binds the \_SB_.PCI0.LPCB.EC0_ driver (and
run its _REG method). It still seems wrong to me for the BIOS to rely
on that sort of ordering, but it doesn't rely on anything special in
Windows to explain why it works.