Laptop is too hot to touch for very long on bottom, yet as you can see in acpi -V output it reports less than 30 C.

Created attachment 24581 [details]
acpi -V

Created attachment 24582 [details]
dmesg

Created attachment 24583 [details]
dmidecode

Created attachment 24584 [details]
DSDT

Created attachment 24585 [details]
interrupts

Created attachment 24586 [details]
lspci -vvvn

Laptop has latest bios available from HP, F.34 from 9/2008

> TRM:          0     745594   Thermal event interrupts

This is not normal.
It means that the laptop is running so hot
that the hardware is throttling -- and informing the OS
that it is doing so.

please supply the output from...

grep . /proc/acpi/thermal_zone/*/*

please attach the complete output from acpidump

Isn't the acpidump I posted complete already?

/proc/acpi/thermal_zone/TZ01/cooling_mode:<setting not supported>
/proc/acpi/thermal_zone/TZ01/polling_frequency:<polling disabled>
/proc/acpi/thermal_zone/TZ01/state:state:                   ok
/proc/acpi/thermal_zone/TZ01/temperature:temperature:             27 C
/proc/acpi/thermal_zone/TZ01/trip_points:critical (S5):           100 C

Also, given the situation of overheat and EC throttling, doesn't it seem strange there are no MCE logged?  By comparison, my HP laptop almost always generates a MCE when it has to throttle.

There is 1 thermal zone in the DSDT
and it is returning a constant
0xBB8 = 3000 dK = 300.0 K = 26.85 C:

            Method (_TMP, 0, Serialized)
            {
                If (ECON) {...Return(...)}

                Return (0x0BB8)
            }

There are no active trip points in the TZ,
and thus even if the TZ were functioning,
ACPI would not control the fans.

"ECON" is referenced in many places in the supplied DSDT,
and lots of functions are gutted when it is not set.
I don't know what is supposed to set ECON -- maybe the
rest of the acpidump will tell us; or maybe there is 
some sort of BIOS SETUP option...

We could scribble on it if we want to find out, it lives here:

OperationRegion (NVST, SystemMemory, 0xBF6BCE95, 0x0000003A)
    Field (NVST, AnyAcc, Lock, Preserve)
    {
        SMIF,   8,
        PRM0,   8,
        PRM1,   8,
        BRTL,   8,
        IGDS,   8,
        TLST,   8,
        CADL,   8,
        PADL,   8,
        CSTE,   16,
        NSTE,   16,
        SSTE,   16,
        LCDA,   16,
        LIDS,   8,
        PWRS,   8,
        BVAL,   32,
        CMPF,   8,
        CSTF,   8,
        GTF0,   56,
        GTF2,   56,
        IDEM,   8,
        DTS1,   8,
        DTS2,   8,
        DTSF,   8,
        PPMF,   32,
        ECON,   8,

oh sorry, i saw the dsdt.dsl and didn't notice the acpidump

If you tell me where to set ECON (maybe in that stupid _TMP function) then I can build and load a new DSDT.  (Assuming that's still possible to do via initrd, I heard that was being removed a while back.)

SSDT.dsl does not give any clues into ECON in DSDT.dsl;
but appears to contain just the standard C-state and P-state stuff.

But just for completeness, please attach the dynamic tables
that are loaded by the SSDT:

# acpidump -a 0xBF67CC10 -l 0x0000026E -o cpu0ist
# acpidump -a 0xBF67CF10 -l 0x000000C4 -o cpu1ist

# acpidump -a 0xBF67B610 -l 0x000005D7 -o cpuocst
# acpidump -a 0xBF67ED10 -l 0x00000083 -o cpu1cst

Created attachment 24587 [details]
cpu0cst

Created attachment 24588 [details]
cpu0ist

Created attachment 24589 [details]
cpu1cst

Created attachment 24590 [details]
cpu1ist

DSDT override via initrd has never shipped in a kernel.org release,
just in distro releases.

DSDT override via re-compile has been in Linux source for years:
http://lesswatts.org/projects/acpi/overridingDSDT.php

However, there is is an easier way to override a method in
2.6.33-rc as in Documentation/acpi/method-customizing.txt
if you are running that and want to have some fun.

I recommend building the kernel with CONFIG_ACPI_DEBUG=y
and enabling moved to the AML Debug object to print
to the console.

Per Documentation/kernel-parameters.txt:
Enable AML "Debug" output, i.e., stores to the Debug
                        object while interpreting AML:
acpi.debug_layer=0xffffffff acpi.debug_level=0x2

thanks for providing the dynamic SSDTs.
As expected, they supply _CST and _PPC for the processors
for C-states and P-states, and do not touch ECON
or the issue at hand.

Which brings us to....
Name (_HID, "pnp0c14")

This system implements WMI, which is a Windows platform-specific
extension built on top of ACPI.  I expect that the difficulties
you are having with Linux result from the lack of a WMI platform
specific driver for Linux like Compaq presumably supplies for Windows.

Are there any other systems that use WMI for basic thermal management?

Matthew pointed out that I overlooked a place in the DSDT
where ECON is set -- the EC _REG method.  So perhaps the
EC initialization on this system is malfunctioning - Alexey?

               Device (EC0)
                {
                    Name (_HID, EisaId ("PNP0C09"))
...
                    Method (_REG, 2, NotSerialized)
                    {
                        If (LAnd (LEqual (Arg0, 0x03), LEqual (Arg1, One)))
                        {
                            Store (One, ECON)
                            Store (One, ELID)
                            If (LNotEqual (ELID, ^^^OVGA.CLID))
                            {
                                If (LNot (^^^OVGA.GLID (ELID)))
                                {
                                    Store (ELID, LIDS)
                                    Notify (LID0, 0x80)
                                }
                            }
                        }
                    }

I can build with EC debug enabled and post a log if that helps.

Also, this kernel is bitten with this DMI bug:
ACPI: EC: Enabling special treatment for EC from MSI.

I think it only adds extra time for EC replies, but maybe I should try a newer kernel for that reason too.

I had to take the laptop apart to repair a broken audio jack and noticed that the motherboard is a Compal (not Compaq) LA-4031P.  Could fixing this laptop have anything to do with the existing Compal WMI driver?

does the problem still exist in the latest upstream kernel, say 2.6.35 or 2.6.36-rc?

Tried 2.6.36.  So far so good.  After a hibernate/resume thermal interrupts are only around 300 and not increasing.

please re-open it if the bug still exists.