No fans, thermalzone on HP Envy 15 and HP DV6T Quad

[irwjager]

The laptop gets *hot* even just idling.

Clean 9.10 64-bit install. ACPI errors in dmesg (bad non-compliant BIOS).

Notably;

[ 1.745517] ACPI: EC: Look up EC in DSDT
[ 1.752295] ACPI: BIOS _OSI(Linux) query ignored
[ 1.761701] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 1.788442] ACPI Error (psargs-0359): [\_PR_.CPU0._PPC] Namespace lookup failure, AE_NOT_FOUND
[ 1.788452] ACPI Error (psparse-0537): Method parse/execution failed [\CPUT] (Node ffff88013ba4d7c0), AE_NOT_FOUND
[ 1.788505] ACPI Error (psparse-0537): Method parse/execution failed [\PSSC] (Node ffff88013ba4d7e0), AE_NOT_FOUND
[ 1.788555] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._REG] (Node ffff88013ba49280), AE_NOT_FOUND
[ 1.788624] Fail in evaluating the _REG object of EC device. Broken bios is suspected.
[ 1.788626] ACPI: Interpreter enabled

and;

[ 2.226460] ACPI Exception: AE_OK, No or invalid critical threshold 20090521 thermal-384

I've been able to get rid of the latter error by repairing and customizing the DSDT. This was on a clean 9.04 install (as 9.10 doesn't allow custom DSDTs anymore). Customizing the DSDT brought exactly one temperature sensor on-line, which doesn't seem much. Still no fans though.

/proc/acpi/fan is empty, as is /proc/acpi/thermal_zone

Same behavior on Jaunty.

I have more troubles with VGA and sound, but I'll file another bug for that.

[Michael Bommarito (mjbommar)]

This bug affects the dv6t quad as well.

[irwjager (jager49)]

Hey,

Thanks for submitting this entry; I'm not feeling so alone now :)

Is there any chance you could attach the output from 'dmesg' and 'lspci
-vvnn' to the bug?
This would give us an idea of how similar the hardware and issues are (I
might have to change the title of the bug to reflect your machine too!).

If you like experimenting I got some pointers on how to fix-up the DSDT,
which will give you a single working temperature sensor, but nothing
much else (still no fans).

Thanks & best regards,

Ivo Jager

Michael Bommarito wrote:
> This bug affects the dv6t quad as well.
>
>

[Michael Bommarito (mjbommar)]

I'll get some more data up later tonight - I booted back to Win7 to get some baseline temperatures for my machine and will need to be AFK for a few hours. Not sure if these are comparable to the Envy given that very different materials are used, but the dv6t-2000 runs between 45-70C on the CPU and 40-52C on the disk in Windows 7.

I'll try under Jaunty again later tonight. How did you fix your DSDT?

I was also considering pulling a fresh kernel from http://kernel.ubuntu.com/git , but I was concerned about compiling a kernel without a fan...

[irwjager (jager49)]

Michael Bommarito wrote:
> I'll get some more data up later tonight - I booted back to Win7 to get
> some baseline temperatures for my machine and will need to be AFK for a
> few hours. Not sure if these are comparable to the Envy given that very
> different materials are used, but the dv6t-2000 runs between 45-70C on
> the CPU and 40-52C on the disk in Windows 7.
>
I didn't get any readings from Win7 (I wiped :), but that sounds about
right for regular use.
The sensor I got on-line by massaging the DSDT indicated a temperature
of around 52C, with a critical temperature of 97C. I'm guessing this was
the HDD temperature (the remaining dmesg errors after fixing the DSDT
seem to hint there's problems with the CPU thermal zone, so that leaves
the HDD and the GPU)
> I'll try under Jaunty again later tonight. How did you fix your DSDT?
>
This link deals with getting the tools for extracting and compiling a
new DSDT. Note that custom DSDTs are no longer supported as of 9.10.

http://www.uluga.ubuntuforums.org/showthread.php?t=1036051

I'll attached a copy of the 'fixed' DSDT source, but be careful with
using it on your machine; we don't know if the BIOS/hardware is the same
yet. Your CPU is different to start of with, so that will need fixing.

The things I fixed were;

* Shifting around code, so that methods and constants were
known/declared before being used.
* I commented out some code in the thermal zone section that would check
for the OS Identifier. It would cause an implicit return (i.e. not
returning *any* value, causing the critical temperature bug). See
https://wiki.edubuntu.org/LaptopTestingTeam/HPdv5z for a similar sort of
situation and how to fix it.
* I commented out code "FPED ()" where no code was allowed (i.e. no
executable code at module level allowed). Didn't seem to adversely
affect anything...

> I was also considering pulling a fresh kernel from
> http://kernel.ubuntu.com/git , but I was concerned about compiling a
> kernel without a fan...
>
Ok, this is a decidedly low-tech solution; if your machine has a metal
alloy casing like my Envy 15, then the heat dissipation works through
the body as well. I simply raised the laptops and put a fan on the spot
that gets hottest (bottom side under the touchpad in case of the Envy
15). That actually made it run cool enough for installing/diganostics.
Frequency scaling is working fine, so if you would force all cores to
run at the lowest frequency possible (there's a gnome applet you can put
on your taskbar), you might get away with compiling a new kernel at a
reasonable temperature.

I read somewhere else that HP let their fans run all the time, be it at
a lower setting, so that there is at least *some* heat dissipation
performed by the laptop itself (but clearly not enough). This does
indeed seem to be the case on the Envy 15.

[Michael Bommarito (mjbommar)]

I'd like to call into HP service tomorrow before making any other modifications. Altering DSDTs or flashing with modified BIOSs are not what I want to do for the number of machines I was looking to purchase, so I'd rather put heat on HP to fix the issue.

I noticed your post here:
http://h30434.www3.hp.com/psg/board/message?board.id=OS&thread.id=22243

And followed up as well.

I also posted on this forum:
http://forum.notebookreview.com/showthread.php?p=5470350&posted=1#post5470350

And asked any others who might be affected to make sure they let HP know. I think this is probably the better solution, at least for me...

[irwjager (jager49)]

Michael Bommarito wrote:
> I'd like to call into HP service tomorrow before making any other
> modifications. Altering DSDTs or flashing with modified BIOSs are not
> what I want to do for the number of machines I was looking to purchase,
> so I'd rather put heat on HP to fix the issue.
>
> I noticed your post here:
> http://h30434.www3.hp.com/psg/board/message?board.id=OS&thread.id=22243
>
> And followed up as well.
>
> I also posted on this forum:
> http://forum.notebookreview.com/showthread.php?p=5470350&posted=1#post5470350
>
> And asked any others who might be affected to make sure they let HP
> know. I think this is probably the better solution, at least for me...
>
>
Yep. Good call. In the meantime, let's hope some Linux kernel/ACPI devs
can weigh in on the issue.

[Abrahm Scully (abrahm-scully)]

Do the fans and thermal zones work correctly when booted to the Splashtop linux distro (HP QuickWeb) included with these laptops? I downloaded the most recent "HP QuickWeb" source archive from DeviceVM, but none of the patches in there looked like they would address this problem.

I'll have access to this hardware later this week to help.

[irwjager (jager49)]

Abrahm Scully wrote:
> Do the fans and thermal zones work correctly when booted to the
> Splashtop linux distro (HP QuickWeb) included with these laptops? I
> downloaded the most recent "HP QuickWeb" source archive from DeviceVM,
> but none of the patches in there looked like they would address this
> problem.
>
> I'll have access to this hardware later this week to help.
>
>
That's a clever idea :)

The Hp Envy uses something called IOS, which is a different archive from
the QuickWeb one I found on the DeviceVM website. I'm currently
downloading it. Whereabouts should I look for patches?

I just got my system dual booting Ubuntu and Win7. Reverting back to
factory default would be a major pain in the backside (especially since
the factory default uses 4 logical partitions with no room for Ubuntu).
I might do it if I find some spare time.

IOS ran perfectly cool from what I remember though.

However, I'm not sure if DeviceVM abstract some stuff in the BIOS first
(they seem to say they do) and then run a cut-down one-size-fits all
Linux stack. In that case I guess you wouldn't find anything in the source.

[irwjager (jager49)]

Ok, I downloaded HPIOS00_1.0.0.6 from the DeviceVM website. Apparently it's based on 2.6.20.11. There's a few patches there that may influence things, but I'm too inexperienced to tell whether they would make a difference. There may also be something in the kernel configuration file. The following 2 patches seem to be the most promising?

diff -Naurp linux-2.6.20.11/drivers/acpi/ec.c linux-2.6.20.11-mod/drivers/acpi/ec.c
--- linux-2.6.20.11/drivers/acpi/ec.c 2007-05-02 08:34:12.000000000 +0800
+++ linux-2.6.20.11-mod/drivers/acpi/ec.c 2008-06-18 11:13:41.000000000 +0800
@@ -418,6 +418,7 @@ static void acpi_ec_gpe_query(void *ec_c
  struct acpi_ec *ec = (struct acpi_ec *)ec_cxt;
  u8 value = 0;
  char object_name[8];
+ acpi_handle h_dummy;

  if (!ec || acpi_ec_query(ec, &value))
   return;
@@ -426,7 +427,10 @@ static void acpi_ec_gpe_query(void *ec_c

  ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Evaluating %s", object_name));

- acpi_evaluate_object(ec->handle, object_name, NULL, NULL);
+ if (ACPI_SUCCESS(acpi_get_handle(ec->handle, object_name, &h_dummy)))
+ acpi_evaluate_object(ec->handle, object_name, NULL, NULL);
+ else
+ acpi_bus_generate_event(first_ec, value, 0);
 }

 static u32 acpi_ec_gpe_handler(void *data)

diff -Narup linux-2.6.20.11/drivers/usb/host/pci-quirks.c linux-2.6.20.11-mod/drivers/usb/host/pci-quirks.c
--- linux-2.6.20.11/drivers/usb/host/pci-quirks.c 2007-05-02 08:34:12.000000000 +0800
+++ linux-2.6.20.11-mod/drivers/usb/host/pci-quirks.c 2007-10-29 17:20:04.000000000 +0800
@@ -349,4 +349,4 @@ static void __devinit quirk_usb_early_ha
  else if (pdev->class == PCI_CLASS_SERIAL_USB_EHCI)
   quirk_usb_disable_ehci(pdev);
 }
-DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);
+//DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);

[Michael Bommarito (mjbommar)]

I'll try patching and building the kernel on another machine with those lines, then transferring source to the machine via Windows 7.

Could you attach the full diff from DeviceVM in case it helps?

At that point, I can reboot to Linux and run make install && make modules_install, edit grub, and reboot without frying the machine...

[irwjager (jager49)]

Michael Bommarito wrote:
> I'll try patching and building the kernel on another machine with those
> lines, then transferring source to the machine via Windows 7.
>
> Could you attach the full diff from DeviceVM in case it helps?
>
> At that point, I can reboot to Linux and run make install && make
> modules_install, edit grub, and reboot without frying the machine...
>
>
I got some bad news on that; I just compared the two files and so much
has changed since 2.6.20.11 that there's no way you can do a diff on
that. It all comes down to inserting the four lines below in
acpi_ec_gpe_query;

+ if (ACPI_SUCCESS(acpi_get_handle(ec->handle, object_name, &h_dummy)))
+ acpi_evaluate_object(ec->handle, object_name, NULL, NULL);
+ else
+ acpi_bus_generate_event(first_ec, value, 0);

instead of

- acpi_evaluate_object(ec->handle, object_name, NULL, NULL);

However, this function has changed quite a bit. Including parameters it's passing (it no longer passes object_name it seems).

I'll upload the patch anyway. Good luck & keep us posted! :)

[irwjager (jager49)]

Related; same manufacturer (HP), same problem, different BIOS provider

https://bugs.launchpad.net/opensuse/+source/linux/+bug/412167

[Abrahm Scully (abrahm-scully)]

I still have a few more days before my laptop arrives, but...

Reading dsdt.dsl that you've posted, i don't think the _HOT thermal zone returns a value for any operating system before VISTA.

Try setting acpi_os_name to "Windows 2006" or "Windows 2009" on the kernel command line and post results.

[Abrahm Scully (abrahm-scully)]

The parameter acpi_osi="!Linux" might be needed as well. I'm not sure...

[Abrahm Scully (abrahm-scully)]

irwjager wrote:
> * I commented out some code in the thermal zone section that would check
> for the OS Identifier. It would cause an implicit return (i.e. not
> returning *any* value, causing the critical temperature bug). See
> https://wiki.edubuntu.org/LaptopTestingTeam/HPdv5z for a similar sort of
> situation and how to fix it.

I couldn't find this fix in dsdt.dsl.Fixed...

I'm still getting warnings for missing return values on lines 8248, 10614, 10632, and 10722 with iasl 20090521 ubuntu 9.10.

[Michael Bommarito (mjbommar)]

Tried acpi_os_name="Windows 2006" and acpi_os_name="Windows 2009" with and without acpi_osi="!Linux".

There was no difference in dmesg or what was available under /sys/ :(

[irwjager (jager49)]

I just noticed this too in dmesg;

ACPI: EC: Enabling special treatment for EC from MSI.

corresponding to this bug;
http://<email address hidden>/msg26802.html

Obviously our HPs aren't MSIs...

Also, apologies for attaching the wrong DSDT. I think the one I attached was the first version that actually compiled on iasl (had to do a lot of cleaning up to get there).

[irwjager (jager49)]

Ok, instead of altering the DSDT, I modifed ec.c and thermal.c and built a custom kernel.

I fixed the inappropriate MSI detection (by the way, this should be fixed for all as of 2.6.32.rc3). I also forced the critical temperature threshold to a fixed value (3702) which I gleaned from the DSDT, but only if there is no valid value returned by the BIOS (on the Envy 15, DV6T there isn't). Now the Thermal Zone init doesn't fail anymore.

Unfortunately, the MSI fix did nothing to get rid of the ACPI parse errors.
The critical temperature threshold fix brought the Thermal Zone on-line.

While looking at the DSDT some more, I noticed a flag called IOSS. I strongly suspect this flag is set if the (Linux based) Instant-On OS is booting. Indeed, looking at the ciritical temperature method, it returns a value if this flag is set, not bothering with any other OS detection.

            Method (_CRT, 0, Serialized)
            {

  If (LEqual (IOSS, One))
                {
                    Return (0x0E76)
                }

                If (LLess (OSYS, 0x07D6))
                {
                    If (LEqual (TJMX, 0x64))
                    {
                        If (LEqual (FSI1, One))
                        {
                            Return (0x0E30)
                        }
                        Else
                        {
                            Return (0x0E76)
                        }
                    }
                }
            }

Conclusion; HP/Insyde have made a special patch for the Linux-based IOS, but any other Linux distro is screwed!

Does anyone have any ideas on what could be causing the [\_PR_.CPU0._PPC] namespace lookup failure? What does it mean?

[irwjager (jager49)]

Well, I got a working BIOS.

Not only do we have bugs in the DSDT, I also found one in the SSDT causing formentioned namespace lookup failure (of which there are 5!). The CPU table was missing a method. Bad...

I've attached a new DSDT source. It's a bit messy, but I'll clean it up later.

You'll have to boot your kernel with an added parameter 'acpi_no_auto_ssdt' so it doesn't load the BIOS' old SSDT (they are now part of the DSDT).

I'm a bit annoyed I have to do HP's/Insyde's work for them... :[

[Michael Bommarito (mjbommar)]

I sent this link to HP support and they said they had forwarded it to the concerned department, which hopefully means that we'll have an official fix in the near future...

[irwjager (jager49)]

Great!

Please note that the new DSDT is specific to my configuration (Core i7 720QM).

I'm still not convinced this is the end of it though. Jaunty still ran hot and sucked a lot of power (<1h on a full battery simply idling). It's like throttling still isn't working.

On the up side, before I got rid of the namespace error, I've seen it do an 'orderly shutdown' due to overheating, proving that the thermal zone trip points work now.

I laud Linus' idea of working around ACPI quirks in the kernel, but working around missing methods and intentional disinformation? I really think the Kernel devs pulled custom DSDT support too soon and I'd like to see it reinstated until there is something else in place first. There's enough BIOS horror stories (like these) for the Kernel devs to chew on scattered around Launchpad.

[irwjager (jager49)]

Throttling is confirmed not working. Back to the drawing board...

[irwjager (jager49)]

Ok, so there seems to be a newer BIOS in the wild. Abraham's new machine
was shipped with F.05, I'm running F.04.

irwjager wrote:
> Throttling is confirmed not working. Back to the drawing board...
>
>

[Abrahm Scully (abrahm-scully)]

My HP Envy 15 information can be found at http://qabe.net/envy15/. My BIOS version is F.05 dated 2009/10/06. My computer arrived on 2009/11/02.

My BIOS seems to have working CPU fans. They start off slow, speed up with CPU load and temperature, and return to slow speed when temperature returns. I spent at least 16-minutes at full load (compiling Ubuntu's kernel) without trouble, and everything returned to normal when finished.

P-states appear to be working fine, but C-states are not functioning properly, which means that power consumption at idle is still higher than it should be, and "turbo" does not work since no core is ever asleep.

[irwjager (jager49)]

Abrahm, looking at your DSDT, firmware F.05 solves the thermal zone problem for OS's other than Windows. It also adds a couple of new devices but I'm not sure what they do.

Hearing that your fans are actually throttling on F.05 sounds really encouraging. I got no such thing happening on F.04.

I strongly suspect the missing _PPC object is due to a timing issue. I believe the SSDT, which loads the _PPC object into the namespace definitions, is loaded way after the parser encounters a reference to the _PPC object. It can't find it, because it doesn't know of it yet, so it throws that namespace error and aborts. It's very sloppy coding.

One simple solution would be to put 'If CondRefOf (_PR.CPU0._PPC)' around the code in the DSDT that tries to access it.
It basically checks if _PR.CPU0._PPC exists yet. If not, it won't execute the code.

Ofcourse, this is only useful if the code is called again later, when the _PPC object has been loaded, at which point it will succeed. I'm thinking this is the case as the code seems to deal with P-States and throttling. Even without a fix, the buggy code in the DSDT is probably enough to make P-States work, as evidenced by Abrahm.

As for C-states, it wouldn't surprise me if they simply aren't defined at all in this BIOS. I'll see if I can find a _CST object...

[irwjager (jager49)]

Installing the OmniBook module gave me an additional C-state (C3).

http://sourceforge.net/projects/omnibook/

[irwjager (jager49)]

Ignore that last post. What REALLY gave me a C-state was booting without AC adapter (e.g. battery only)! Plugging in the adapter while the system is on will retain the second C-state until you reboot. What the hell!?

[Abrahm Scully (abrahm-scully)]

I'd like to confirm and elaborate on irwjager's recent findings.

I allowed the computer to boot unplugged. I then connected the power after booting had completed.

Not only are C-states available, but the laptop's CPU temperature at idle is considerably cooler. /proc/acpi/thermal_zone/TZ01/temperature reads 38 C at idle instead of 55 C when booted with the power connected. So, now, my "notebook" computer cool enough to be a "laptop" for web browsing!

On a hunch, I decided to do some computing benchmarks. I downloaded http://voxel.dl.sourceforge.net/project/systester/systester/1.1.0/systester-1.1.0-linux-amd64.tar.bz2. (It's like superpi, but open source.) I extracted it and ran "./systester-cli -gausslg 2M -threads 1 -bench" (2 million digits of pi, 1 thread).

Booted on battery, stay unplugged: not tested
Booted on battery, then plugged in: 31-33 seconds
Booted on A/C, still plugged in: 51-53 seconds!
Booted on A/C, then unplugged: 90-93 seconds!

For reference, you can compare my laptop dmesg outputs:
http://qabe.net/envy15/files/dmesg.log
http://qabe.net/envy15/files/dmesg_booted_on_battery.log

You can clearly see C-states being initialised when booted on battery as well as some other differences -- including a segfault in the HPET code!

[Abrahm Scully (abrahm-scully)]

The missing benchmark:

Booted on battery, stay unplugged: 93 seconds.

So, when unplugged, performance is always scaled back.
When plugged in, only good performance when C

[Abrahm Scully (abrahm-scully)]

Sorry about that... The envy 15's touchpad gets under my right hand when typing and just happened to click "Post Comment"...

The missing benchmark:

Booted on battery, stay unplugged: 93 seconds.

So, when unplugged, performance always seems scaled back.
When plugged in, you'll get much better performance if you weren't plugged in at boot.

[irwjager (jager49)]

It honestly seems like this BIOS was commissioned by a baboon. It should've never passed QA like this. I'm taking my Envy back for a refund. There is only so much time I can spend on debugging something that should just work.

To recap our findings so far;

    * Fans not working (at least on F.04).
    * Thermal zone/sensors not working.
    * ACPI parsing aborts in several places due to initialization bugs (Linux does work around this)
    * CPU Powersaving (aka C-State switching) only works if you boot the machine without AC adapter attached.
    * No critical shutdown temperature returned for anything else but Windows.

In short, this BIOS is a recipe for a cooked CPU: all cores are always awake, all of the time (generating copious amounts of heat). Heat which is insufficiently dissipated by the fans (they don't seem to throttle at any temperature). The OS can't shut down the machine if it gets too hot because it is kept in the dark about 1. the current temperature 2. what temperature is considered critical.

Nice.

[Abrahm Scully (abrahm-scully)]

Some more info on poor on-battery performance:

While on battery, the CPU frequency is scaled back to 931Mhz. The "ondemand" frequency governor does not increase the cpu frequency while running the benchmark.

The contents of scaling_available_frequencies in sysfs lists frequencies from 931Mhz to 1597Mhz, but I never see any frequency other than 931Mhz while on battery...

This might be a configuration issue.

[Abrahm Scully (abrahm-scully)]

I've plugged my laptop in, and the cpu frequency still stays at 931Mhz by default. However, while running the benchmark, the frequencies of non-idle cpus immediately rise to the the max frequency 1597Mhz.

Also note that this testing was done after booting while on battery.

[irwjager (jager49)]

This throttling behavior is more or less expected; this is (as far as I understand it) P-State related. This seems to work well, although as soon as I load a custom (but the exact same) DSDT it breaks.

As far as I can tell the ACPI breakage (the namespace errors) is actually in the code that throttles the CPU and sets/stores the new P-states (the CPUT method). As indicated I also believe the breakage is temporary and the CPUT method should work correctly after the SSDT's are loaded (and the missing namespace is populated), but we should not discount these bugs impacting throttling as a whole.

I returned my Envy, but I'll keep a close watch on this thread.

Also note that HP indicated to release the F.05 update on the 9th of November, although this only seems to solve the thermal zone problem.

[Alex Chiang (achiang)]

From comment #40:

    * Fans not working (at least on F.04).
    * Thermal zone/sensors not working.
    * ACPI parsing aborts in several places due to initialization bugs (Linux does work around this)
    * CPU Powersaving (aka C-State switching) only works if you boot the machine without AC adapter attached.
    * No critical shutdown temperature returned for anything else but Windows.

I got this message with F.03:
Dec 11 17:20:47 dre kernel: [ 1.830747] ACPI Exception: AE_OK, No or invalid critical threshold 20090521 thermal-384

I've upgraded to F.06, and now get this:
Dec 12 00:56:08 dre kernel: [ 1.843983] thermal LNXTHERM:01: registered as thermal_zone0
Dec 12 00:56:08 dre kernel: [ 1.843990] ACPI: Thermal Zone [TZ01] (61 C)

Regarding these messages:
Dec 12 12:14:55 dre kernel: [ 1.439863] ACPI Error (psargs-0359): [\_PR_.CPU0._PPC] Namespace lookup failure, AE_NOT_FOUND
Dec 12 12:14:55 dre kernel: [ 1.439872] ACPI Error (psparse-0537): Method parse/execution failed [\CPUT] (Node ffff880237054880), AE_NOT_FOUND
Dec 12 12:14:55 dre kernel: [ 1.439918] ACPI Error (psparse-0537): Method parse/execution failed [\PSSC] (Node ffff8802370548a0), AE_NOT_FOUND
Dec 12 12:14:55 dre kernel: [ 1.439961] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._REG] (Node ffff880237044300), AE_NOT_FOUND

I looked in all the SSDTs and did not see the _PPC method defined anywhere, so wondering where the theory in comment #43 about loading all the SSDTs comes from. I also didn't find _REG in any of the SSDTs.

Both CPUT and PSSC are defined in DSDT, so I'm not sure why we can't parse those. I'll dig into that.

I consider the current outstanding list of issues to now be:

   * Fans not working (at least on F.04).
    * ACPI parsing aborts in several places due to initialization bugs (Linux does work around this)
    * CPU Powersaving (aka C-State switching) only works if you boot the machine without AC adapter attached.

Curious about the statement regarding fans though. Are you simply stating that because /proc/acpi/fans/ is empty? Or are your fans not actually spinning up? My machine is running warm, but I definitely hear and feel fan output.

Thanks.
/ac

[irwjager (jager49)]

Hi Alex,

I remember getting 5 SSDTs aside from the DSDT. I think (think!) in one of them the _PPC method was populated with values from somewhere in the system memory. This code was repeated 8 times (for each virtual core).

The theory is that CPUT dies early on because it relies on _PPC being defined, which it is not at that stage. Later, _PPC becomes initialized/defined (at least that's what I seem to remember) and CPUT gets parsed fine on subsequent calls.

As for F.04, I can confirm the fans were on, stuck on low, but weren't throttling at all. When running with a fixed DSDT (so I could at least get a critical shutdown temperature and thermal zone sensor) the machine got so hot that the critical temperature was triggered and Ubuntu shut down the system.

I'm sorry I can't help you anymore than this as I returned my Envy 15.

[Alex Chiang (achiang)]

Hi Ivo,

Thank you for all the debugging work you've done so far.

As of F.06, I can confirm that the fans seem to be throttling correctly. A -j8 kernel build on this machine takes about 15 minutes. Observing the value in /proc/acpi/thermal_zone/TZ01/temperature shows a peak of around 81 C which decreases to 58 C or so after the build is done.

I can also physically hear the fans spin up rather high, and then throttle back after the build.

I think it's normal for /proc/acpi/fan/ to be empty, so I'm not too concerned about that.

I'll take a closer look at the parsing of CPUT and PSSC, as well as the C state oddity.

Thanks,
/ac

[Gabe E. Nydick (gnydick-launchpad)]

FYI and FWIW, I run openSuSE 11.2 and just about everything works. Here's my summary...

- Thermal zone comes online if I have the thermal module load after boot finishes, not sure if ubuntu has the 3 different options for module loading - initrd, boot, and after fs mounted

- no fan detected, but I'm guessing either there isn't a controllable fan, but even if there is, my fan regulates properly so I don't care

- TurboBoost (I believe) is working, which requires a much longer explanation, which I'll be happy to post separately

- multiple battery detection works fine

Misc hardware - working w/o tweaks
    - fan adjusts with temp changes
    - batteries discharge and charge sequentially
    - sound card
    - web cam
    - microphone
    - card reader
    - HDMI audio and video
    - backlight control soft keys
    - volume soft keys
    - wifi/bluetooth soft keys
    - lock screen soft keys
    - productivity soft keys (vertically along the left)

Misc hardware - working w/small tweak
    - trackpad works just fine, in fact better than with Windows, does require small hal policy for auto configuring
    - external display soft-key - works, not sure what the 3 different modes are that it cycles through though, or how to identify them

Problems
    - can't get fglrx to work.... Seems as though the video card doesn't get reset properly and the /etc/ati/amdpscdb changes everytime the display is started and I can't ever get X to work more than once with fglrx installed. This seems to possibly be ACPI related.
    - can't get the volume mute soft-key LED to turn off

DSDT
    - I've corrected the DSDT to compile and optimize, however it doesn't alleviate the parse errors. I believe this is due to the order the kernel goes through the DSDT. I theorize either reordering the DSDT will fix it or a patch to the kernel is necessary.

[Gabe E. Nydick (gnydick-launchpad)]

OH, btw, if anyone can tell me how to configure fglrx properly, I would be SO VERY MUCH appreciative.

[Alex Chiang (achiang)]

Attached is a patch that should resolve the ACPI namespace issues, at least on the Envy.

Upstream link is here: http://lkml.org/lkml/2009/12/20/146

Gabe, care to explain more about TurboBoost?

[Gabe E. Nydick (gnydick-launchpad)]

The reason is the max Hz in all of the kernel and user space tools is the max Hz while all cores are active. Turbo Boost only comes into effect when running un-parallelized code on only a fraction of the cores. So, I've seen my Envy 15 hit 3.0GHz in Windows, using Intel's Turbo Boost utility, but only during single threaded, heavy activity. Otherwise, if it's multithreaded, the system won't go above 1.6GHz, which is the max Hz as far as the Linux system can tell. So there's some catch-up to be played there.

Another hint which leads me to this belief is that PowerTOP doesn't understand how to parse/represent TurboBoost, but the openSolaris version does, they patched it themselves. Running openSolaris, I saw all of the different speeds listed, top to bottom, slowest to fastest, with the last entry changing as demand changed. When I ran the linux version, I see the 931MHz state running at the bottom of the list of speeds, even though the speeds get higher going down the list. Therefor, I "believe" it to be working properly since my speeds vary, fans vary, etc..

[Gabe E. Nydick (gnydick-launchpad)]

Oh, and thanks for the patch, Alex. Do you know anything about the fglrx issue? I haven't seen ONE post at all about people's experience with the ATI driver on the envy.

[Alex Chiang (achiang)]

Gabe,

I did some research too, and also think that TurboBoost works just fine on this machine.

This paper explains why applications like powertop aren't telling the whole story. It's also why looking at /proc/cpuinfo is misleading:
http://download.intel.com/design/processor/applnots/320354.pdf

I don't think a kernel patch is the right answer. Making the kernel poll every second to show the user that TurboBoost is working seems both wasteful and silly, IMO.

Patching powertop would be simple though, and much more appropriate.

One final piece of confirmation that TurboBoost is enabled is to look at /proc/cpuinfo:

$ cat /proc/cpuinfo | grep flags | grep ida | uniq

The flag 'ida' tells you that TurboBoost is working. The formal name for the technology is "Intel Dynamic Acceleration", which is what the flag stands for.

http://www.lesswatts.org/projects/processor-power/dynamic-acceleration.php

Finally, I don't know anything about fglrx. Xorg on my machine is using the radeon module. I can post my Xorg.log here if you like...

[Kern Sibbald (kern)]

This bug report seems to be the most similar to my problem.

Problem: With latest Karmic (KDE) installed, my fan runs very fast (annoyingly loud).
Computer: Dell Studio 1747: Intel i7-720QM chip.
Both /proc/acpi/fan and /proc/acpi/thermal_zone are empty.
Running sensors_detect results in "Sorry, no sensors were detected"
Booting with acpi_enforce_resources=lax does not help.

Is this the right place to ask for a solution? If so, what information do you need? (dmesg output, ...).
If not, I can open a new bug.

[Gabe E. Nydick (gnydick-launchpad)]

Alex, I tried the patch, it applied, but failed to compile. Do you think you could try the kernel that comes with openSuSE 11.2 and see what's up?

[Alex Chiang (achiang)]

Gabe,

I don't know anything about openSuSE, but I'm guessing you got a build error in acpi_walk_namespace. My patch is based on 2.6.33, and acpi_walk_namespace() grew an extra parameter.

If my guess is right, then fixing the patch should be trivial. Just find where we're calling acpi_walk_namespace() and remove one of the three trailing NULL args so you only have 2 of them.

Otherwise, you can post your build error here and I'll try and debug it.

[Gabe E. Nydick (gnydick-launchpad)]

that's exactly it!! I figured it out this morning. Thanks for the quick reply. BTW, seems like Turbo Boost is only enabled if you boot without the power supply unplugged. Otherwise, there's only one C-state present.

[goodhabit (goodhabit)]

Does this http://marc.info/?l=linux-kernel&m=126163681219693&w=2 and
http://bugzilla.kernel.org/show_bug.cgi?id=14824 fixing the bug?

[Gabe E. Nydick (gnydick-launchpad)]

using openSuSE 11.2, vanilla 2.6.33-rc5 with trackpad click patch

Status
- Machine seems completely stable if I do the following...

- sleep works just fine

New bugs with 2.6.33-rc3, 4, 5... (on openSuSE 11.2)

- The display switch soft-key now just types a "p" instead of sending an acpi event. Not sure if that's a config thing or a kernel thing.

Other problems...

- Is anyone working on fixing the mute button LED? I wish I could get that to turn off.
- Is there any way to remap a key to sysrq? I'd really like to be able to sync my file system before forcefully rebooting it?

[Gabe E. Nydick (gnydick-launchpad)]

Sorry, have to re-post, prematurely hit "Post"

using openSuSE 11.2, vanilla 2.6.33-rc5 with trackpad click patch

Status
- Machine seems completely stable if I do the following. I add and remove external displays, change resolutions, run xbmc, all sorts of taxing display tasks.
  - boot runlevel 3
  - pm-suspend (configured with "-f -a 3")
  - wake it up
  - telinit 5

- sleep works just fine

New bugs with 2.6.33-rc3, 4, 5...

- The display switch soft-key now just types a "p" instead of sending an acpi event. Not sure if that's a config thing or a kernel thing.

Other problems...

- Is anyone working on fixing the mute button LED? I wish I could get that to turn off.
- Is there any way to remap a key to sysrq? I'd really like to be able to sync my file system before forcefully rebooting it?

[Alex Chiang (achiang)]

Hi all,

I plan on closing this bug.

The C2 / fan / thermal zone issues are fixed in: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/516325

The ACPI namespace errors indicate that the Ambient Light Sensor didn't initialize which is relatively benign. These errors will not be fixed in Lucid, but will be fixed for Maverick (or if you use any current upstream kernel).

The windows-P bug is tracked by: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539477

For other issues, please open a new bug.

Thanks.