Comment 155 for bug 370173

Revision history for this message
Andreas Kostyrka (andreas-kostyrka) wrote : Re: [Bug 370173] Re: Ubuntu 9.04 laptop overheat and shutdown

For me, the 2.6.28 kernel does trigger it. Running 2.6.27-14 works fine.

(Actually, subjectivly 2.6.27-14 is not perfect either, but I haven't
managed yet to kill it via burnK7, while 2.6.28 takes less than 60s of
2xburnK7 (dualcore) to shutdown)

To summarize:

Hardy/Intrepid ran perfect on the hardware (temperature-wise)

2.6.27-14 feels slightly to loud on fan noise, but that's strictly
subjective. The scripts that I wrote to burn and log have been not able
to force a thermal shutdown for over 15 minutes.

2.6.28 can be easily crashed by
So it's really only the kernel, or something in userland that depends
upon the currently running kernel. Demonstrated via logs/scripts that I
posted to my bug report. Thermal shutdown happens after less than 60
seconds.

So just booting a different kernel makes my laptop go into thermal
shutdown, so it is a kernel or kernel-specific userland problem.

Andreas

Am Donnerstag, den 25.06.2009, 08:31 +0000 schrieb Andy Whitcroft:
> @Michal Pěnka -- yes you can just download the appropriate kernel for
> you i386/amd64 and just install those with dpkg. They should install in
> parallel and you can simply select them in the main grub menu.
>
> @all -- the key desire here is to isolate exactly when this issue
> appeared. There seems to be enough people indicating they have an issue
> to make it likely that later kernels are triggering this behaviour. As
> generally the kernel does not get involved in fan control directly it
> must be something else triggering the change. As there are some 20k
> changes in every mainline release and normally at least 2 mainline
> releases in every Ubuntu release, there is a huge amount of change in
> each kernel. This huge change makes it hard to pinpoint such a
> behaviour. The normal way to do this is to identify kernel versions
> which exhibit the behaviour and those which do not and bisect the gap to
> narrow down the the exact mainline release produced the change, and then
> within that release. This is the source of my requests for testing of
> specific kernel versions.
>