From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Michael Zintakis <michael.zintakis@googlemail.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
lm-sensors@lm-sensors.org, Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org
Subject: Re: [lm-sensors] Fintek f71882fg ACPI conflict
Date: Thu, 28 Jun 2012 02:45:49 +0100 [thread overview]
Message-ID: <20120628014548.GA15994@srcf.ucam.org> (raw)
In-Reply-To: <4FEB90A8.8050901@googlemail.com>
On Thu, Jun 28, 2012 at 12:00:56AM +0100, Michael Zintakis wrote:
> This is precisely what I stumbled upon when reading the
> documentation about the kernel acpi parameters today and tried it
> straight away (though, in all honesty, I didn't have a clue that it
> is actually a bad idea until I read the article above - thanks for
> posting!). Could any of the more knowledgeable on here explain why
> is it such a bad idea please?
Because there's no handshaking between the firmware and the OS driver,
and accesses to hardware sensors are often indexed. Imagine this
scenario:
ACPI lmsensors
---- ---------
select temperature register
select fan speed register
read value
read value
ACPi will read the fan speed register instead of the temperature
register, and the value may be far too high and cause a critical
shutdown of the system.
That's the *good* outcome. The bad outcome involves these register
accesses racing in a way that disables fan control or thermal trip
points and risks causing hardware damage. It's not safe for two
different codepaths to access the same hardware without having any kind
of locking, so if your system firmware declares that ACPI is using the
temperature device the hardware sensors framework will refuse to.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2012-06-28 1:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4FEA4C10.2060904@googlemail.com>
2012-06-27 17:15 ` Fintek f71882fg ACPI conflict Guenter Roeck
2012-06-27 23:00 ` [lm-sensors] " Michael Zintakis
2012-06-28 1:45 ` Matthew Garrett [this message]
2012-06-28 11:15 ` Michael Zintakis
2012-06-28 12:40 ` Jean Delvare
2012-06-28 12:53 ` Michael Zintakis
2012-06-28 13:27 ` Jean Delvare
2012-06-29 5:35 ` Robert Hancock
2012-06-29 12:11 ` Michael Zintakis
2012-06-29 16:34 ` Guenter Roeck
2012-06-28 5:20 ` Guenter Roeck
2012-06-28 11:31 ` Michael Zintakis
2012-06-28 17:12 ` Guenter Roeck
2012-06-28 17:39 ` Michael Zintakis
2012-06-28 18:57 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120628014548.GA15994@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lm-sensors@lm-sensors.org \
--cc=michael.zintakis@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).