kernel-source-2.6.7: Modular fan support could result in hardware damage

Automatically imported from Debian bug report #262383 http://bugs.debian.org/262383

Message-Id: <email address hidden>
Date: Fri, 30 Jul 2004 21:39:08 +0100
From: Matthew Garrett <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: kernel-source-2.6.7: Modular fan support could result in hardware damage

Package: kernel-source-2.6.7
Severity: critical
Justification: breaks the whole system

If the kernel notifies the hardware that it is acpi-aware, then the
hardware may hand over control of cooling to the OS. However, if the
fan module (and possibly thermal.ko) is not loaded, the OS is unable to
do so. This will probably lead to the hardware overheating, resulting in
either instability (the hardware will shut itself off) or damage (if the
thermal cutoff threshold is set too high). hotplug and discover are
unable to automatically load acpi modules at present.

The acpid package will load acpi modules automatically. However, it's
not clear whether it can be installed early enough in a d-i run to be
helpful (if the d-i kernel is acpi, then there could be some time before
a sensible number of modules have been loaded - a laptop being floppy
booted for a network install, for instance).

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i586)
Kernel: Linux 2.6.7
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8

This bug seems rather silly...I don't think that "hand over control of cooling
to the OS" involves shutting the CPU fan off or anything dangerous like that.

Comments?

Message-ID: <email address hidden>
Date: Sat, 31 Jul 2004 09:19:36 +0200
From: "Francesco P. Lovergine" <email address hidden>
To: Matthew Garrett <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#262383: kernel-source-2.6.7: Modular fan support could result in hardware damage

severity 262383 important
severity 259481 important
merge 262383 259481
tags 262383 upstream
thanks

Sorry for cross-posting guys, please reply where appropriate only.

Ratio for changing severity: A bug which has a major effect on the usability of a package, without rendering
it completely unusable to everyone. ACPI issues are not of general interest. It depends on processor,
kind of system (laptop or desktop). Moreover the issue can be approached by loading fan and thermal module
in initrd, that is almost at startup.

Debian kernel team:
Please, consider to set CONFIG_ACPI_BOOT=n
by default in 2.6. I see no reason to have it OFF in 2.4 and ON in 2.6. What's the ratio (if any)?

Acpi-devel list:
is this a bug in current implementation? Should not the fan stay ON after initialization
up to fan/thermal loading? Or (as I think) it that a damn DSDT bug of some vendors?
Some references for you:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=259481&msg=20
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=262383

On Fri, Jul 30, 2004 at 09:39:08PM +0100, Matthew Garrett wrote:
> Package: kernel-source-2.6.7
> Severity: critical
> Justification: breaks the whole system
>
> If the kernel notifies the hardware that it is acpi-aware, then the
> hardware may hand over control of cooling to the OS. However, if the
> fan module (and possibly thermal.ko) is not loaded, the OS is unable to
> do so. This will probably lead to the hardware overheating, resulting in
> either instability (the hardware will shut itself off) or damage (if the
> thermal cutoff threshold is set too high). hotplug and discover are
> unable to automatically load acpi modules at present.
>
> The acpid package will load acpi modules automatically. However, it's
> not clear whether it can be installed early enough in a d-i run to be
> helpful (if the d-i kernel is acpi, then there could be some time before
> a sensible number of modules have been loaded - a laptop being floppy
> booted for a network install, for instance).
>
> -- System Information:
> Debian Release: testing/unstable
> APT prefers unstable
> APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: i386 (i586)
> Kernel: Linux 2.6.7
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
>
>
> --
> To UNSUBSCRIBE, email to <email address hidden>
> with a subject of "unsubscribe". Trouble? Contact <email address hidden>

--
Francesco P. Lovergine

Message-ID: <email address hidden>
Date: Sat, 31 Jul 2004 09:40:40 +0200
From: "Francesco P. Lovergine" <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: Re: Processed: Re: Bug#262383: kernel-source-2.6.7: Modular fan support could result in
 hardware damage

reassign 262383 kernel-image-2.6.7-1-686
merge 262383 259481
thanks

On Sat, Jul 31, 2004 at 12:33:04AM -0700, Debian Bug Tracking System wrote:
> Processing commands for <email address hidden>:
>
> > severity 262383 important
> Bug#262383: kernel-source-2.6.7: Modular fan support could result in hardware damage
> Severity set to `important'.
>
> > severity 259481 important
> Bug#259481: ACPI Turns Off Fan, Allowing Overheating
> Severity set to `important'.
>
> > merge 262383 259481
> Bug#259481: ACPI Turns Off Fan, Allowing Overheating
> Bug#262383: kernel-source-2.6.7: Modular fan support could result in hardware damage
> Mismatch - only Bugs in same state can be merged:
> Values for `package' don't match:
> #259481 has `kernel-image-2.6.7-1-686';
> #262383 has `kernel-source-2.6.7'
>
> > tags 262383 upstream
> Bug#262383: kernel-source-2.6.7: Modular fan support could result in hardware damage
> There were no tags set.
> Tags added: upstream
>
> > thanks
> Stopping processing here.
>
> Please contact me if you need assistance.
>
> Debian bug tracking system administrator
> (administrator, Debian Bugs database)
>
>
> --
> To UNSUBSCRIBE, email to <email address hidden>
> with a subject of "unsubscribe". Trouble? Contact <email address hidden>

--
Francesco P. Lovergine

I have emailed Herbert and asked his opinion of this bug

My question and Herbert's response:

> What is your opinion of this bug? Is it legitimate to build ACPI in module
> form, or should it be compiled in? If there is a genuine issue here, we
> should resolve it for the new kernel package.

Well building it into the kernel doesn't help without running acpid as
well. So whether it's a module or not is irrelevant.

Disabling ACPI is not an option either since some machines require ACPI
tables to boot.

So the only option left if such broken machines exist is to make sure
that the module is loaded ASAP and that acpid is running ASAP.

However, I personally doubt the existence of such machines. The reason
is that if hardware can become damaged in such a state that what if the
OS crashes in an infinite loop? That surely must not be fatal to the system.

Last time this issue came up on LKML it was declared that all Intel CPUs
have built-in protection as they'll shut themselves down. I'd imagine that
AMD CPUs would have something similar.

Thom and I discussed this and decided to start acpid earlier to alleviate this
issue, though I still consider it a hardware bug

Message-ID: <email address hidden>
Date: Thu, 19 Aug 2004 07:54:27 -0700
From: Matt Zimmerman <email address hidden>
To: <email address hidden>
Subject: Options

Is it possible to have ACPI disabled in the kernel until acpid starts, and
enable it then? Or must this decision be made very early in the boot
process?

--
 - mdz

Message-ID: <email address hidden>
Date: Thu, 19 Aug 2004 17:19:07 +0200
From: Christoph Hellwig <email address hidden>
To: Matt Zimmerman <email address hidden>, <email address hidden>
Subject: Re: Bug#262383: Options

On Thu, Aug 19, 2004 at 07:54:27AM -0700, Matt Zimmerman wrote:
> Is it possible to have ACPI disabled in the kernel until acpid starts, and
> enable it then? Or must this decision be made very early in the boot
> process?

Back at Caldera we hacked acpi to be a loadable module. These days it's
not feasible anymore because many modern systems requite ACPI for early
boot actions like irq routing and SMP support.

What's the status of this bug? I think we decided that we should try to load
the acpi modules from the initrd

(In reply to comment #10)
> What's the status of this bug? I think we decided that we should try to load
> the acpi modules from the initrd

Yup, planning to finish and test this tomorrow.

new acpid (1.0.3-19ubuntu6) and initrd-tools (0.1.70ubuntu4) should fix this in
concert.

rootskel 0.84ubuntu5 now does this in the installer as well.

rootskel (0.84ubuntu5) warty; urgency=low

  * Merge from Debian (rootskel 0.91):
    - Add S05acpi-i386 to load fan and thermal modules if available as early
      as practical in boot to avoid machine meltdown.
  * Do this on amd64 too.

 -- Colin Watson <email address hidden> Wed, 8 Sep 2004 18:49:04 +0100

Message-ID: <email address hidden>
Date: Fri, 10 Sep 2004 09:20:45 +0200
From: maks attems <email address hidden>
To: <email address hidden>
Subject: reassign hole bunch of 2.6.7 bugs, get them on the radar

reassign #263420 kernel
reassign #265039 kernel
reassign #263753 kernel
reassign #258282 kernel
reassign #259481 kernel
reassign #262383 kernel
reassign #262657 kernel
reassign #264197 kernel
reassign #267014 kernel
reassign #270194 kernel
reassign #270198 kernel
reassign #257526 kernel
reassign #257629 kernel
reassign #257691 kernel
reassign #257996 kernel
reassign #259042 kernel
reassign #259185 kernel
reassign #259381 kernel
reassign #259886 kernel
reassign #259893 kernel
reassign #259910 kernel
reassign #260755 kernel
reassign #260917 kernel
reassign #261348 kernel
reassign #261734 kernel
reassign #263316 kernel
reassign #264528 kernel
reassign #264633 kernel
reassign #265536 kernel
reassign #267006 kernel
reassign #267077 kernel
reassign #267079 kernel
reassign #267553 kernel
reassign #267628 kernel
reassign #268583 kernel
reassign #268964 kernel
reassign #269451 kernel
reassign #269579 kernel
reassign #260694 kernel
reassign #260695 kernel
reassign #262628 kernel
reassign #259698 kernel
reassign #267466 kernel
thanks