FC5 Upgrade: CPU Temperature/Thermal Lockup

Greg Kilfoyle greg at kilfoyle.com
Mon Apr 3 15:04:54 UTC 2006


I'm still fighting with this. I spent many hours building a new kernel
from the source RPM with CONFIG_ACPI_THERMAL disabled. This kernel still
locks up in the same way.

Does anyone know if I need to de-configure CONFIG_X86_MCE_P4THERMAL too?

You're probably wondering why I don't just get the motherboard replaced
again. Because they won't perform any warranty work unless it is a
Windows issue (because that's what the laptop came installed with).

I guess I'll kick off another 6 hours of kernel building with
CONFIG_X86_MCE_P4THERMAL disabled, but it would help if someone had some
insight for me, rather than just taking stabs in the dark.

Cheers, Greg.


On Sun, 2006-04-02 at 12:37 -0700, Greg Kilfoyle wrote:
> So I made two changes and only accounted for one of them. My laptop had 
> a new motherboard and as soon as I got it back I upgraded from FC4 to 
> FC5. I think what has happened is that the sensors are reporting the 
> wrong temperatures on the new motherboard. I found a windows program 
> which also reported the CPU temperature to be very high.
> 
> Now I'm trying to build a kernel RPM which has ACPI thermal disabled. I 
> have to do this under VMware on Windows, because building a kernel makes 
> the system lockup almost immediately :(
> 
> Does anyone know if there is a way to disable thermal checking from the 
> kernel boot line?
> 
> Cheers, Greg.
> 
> 
> Greg Kilfoyle wrote:
> > Hi,
> >
> > I have a Fujitsu Lifebook N5010 laptop that has been running FC4 for a
> > long time now. I've just upgraded it to FC5 and it locks up after a
> > while.
> >
> > Just before locking up, there is generally some extra CPU activity (over
> > and above just moving between email, web and text editing) and then a
> > couple of messages are sent to all terminal sessions:
> >
> >   sandy kernel: CPU0: Temperature above threshold
> >   sandy kernel: CPU0: Running in modulated clock mode
> >
> > As best I can tell, the fan is automatically controlled by the hardware,
> > without software intervention. Under Windows XP the system behaves fine,
> > with the fan adjusting automatically to heavy load.
> >
> > Under Linux the lockup is generally proceeded by the fan increasing
> > speed but not to its maximum. Running "rpm --rebuilddb" will cause the
> > messages and lockup. To reset the system I have to remove the power card
> > and battery - it does not respond to the power button.
> >
> > I checked some acpi information under /proc/acpi. Just before the last
> > lockup, a cat of /proc/acpi/thermal_zone/THRC/temperature showed 74C. A
> > cat of /proc/acpi/thermal_zone/THRC/trip_points shows 98C.
> >
> > Some other things I've tried, all to no avail:
> >
> >   o add noacpi and nolacpi to the kernel boot line
> >   o turn off HT (hyper-threading) in the BIOS
> >   o stop acpid
> >
> > In case it helps, here the output from lspci:
> >
> > 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 645xx (rev 51)
> > 00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS AGP Port
> > (virtual PCI-to-PCI bridge)
> > 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL
> > Media IO] (rev 25)
> > 00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus
> > Controller
> > 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
> > 00:02.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller
> > (rev a0)
> > 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS]
> > Sound Controller (rev a0)
> > 00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0
> > Controller (rev 0f)
> > 00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0
> > Controller (rev 0f)
> > 00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 2.0
> > Controller
> > 00:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> > RTL-8139/8139C/8139C+ (rev 10)
> > 00:09.0 CardBus bridge: Texas Instruments PCI7420 CardBus Controller
> > 00:09.1 CardBus bridge: Texas Instruments PCI7420 CardBus Controller
> > 00:09.2 FireWire (IEEE 1394): Texas Instruments PCI7x20 1394a-2000 OHCI
> > Two-Port PHY/Link-Layer Controller
> > 00:09.3 Mass storage controller: <pci_lookup_name: buffer too small>
> > 00:0a.0 Ethernet controller: Atheros Communications, Inc. AR5212
> > 802.11abg NIC (rev 01)
> > 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility
> > Radeon 9600 M10]
> >
> > I'm running the latest 2080 non-smp kernel.
> >
> > Cheers, Greg.
> >   
> 
-- 
Greg Kilfoyle <greg at kilfoyle.com>




More information about the users mailing list