From: "Pali Rohár" <pali.rohar@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Arnd Bergmann <arnd@arndb.de>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
Steven Honeyman <stevenhoneyman@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i8k: Add support for temperature sensor labels
Date: Sun, 30 Nov 2014 11:11:35 +0100 [thread overview]
Message-ID: <201411301111.35988@pali> (raw)
In-Reply-To: <547A71F5.4030306@roeck-us.net>
[-- Attachment #1: Type: Text/Plain, Size: 2685 bytes --]
On Sunday 30 November 2014 02:25:09 Guenter Roeck wrote:
> On 11/29/2014 11:07 AM, Pali Rohár wrote:
> [ ... ]
>
> > Original Dell DOS executable ignores all temperature sensors
> > if type SMM function fails (if I decoded and understand
> > that DOS assembler code correctly). So maybe we should do
> > same...
>
> Pali,
>
> Makes me wonder - does the assembler code tell you what to do
> if the reported temperature is invalid, and does it
> distinguish between error codes ?
I do not see anything like that. But there are lot of indirect
calls (offset to pointer to function is stored in some global at
init zero data), so it is hard to understand what that DOS binary
is doing. I'm happy that I decoded loop which trying to call that
type function and if it does not fail then it call read
temperature function. And in that section I do not see any error
handling of invalid values (but it could be somewhere else).
Anyway DOS binary is quite old (7 years maybe?). It is not even
available for my last E6440 model. Now all new Dell laptops have
EFI system and ePSA application (new version of diagnostic tool
which reports info about fan, temperature, ...). That tool looks
like is burned directly into machine (I can start it with empty
HDD from Setup screen) or into BIOS image.
And what is interesting about this ePSA:
* it show more temperature sensors (battery temperature)
* it show correct RPM of fan and *can* control fan speed
I think that DOS binary has no idea about Optimus or PowerExpress
cards so for that error handling we need to understand what is
doing new EFI ePSA application...
And because function for turning card on/off is controlled via
ACPI I bet that DOS or EFI application does not touch it, so
assume that card is always on and does not need any error
handling.
Another info about DOS binary: After SMM code for reading fan RPM
is finished, then function divide returned RPM value by some
number stored in local data. So now I think that magic fan
multiplier is not constant, but runtime value. I will try to look
at it, if we can fix this problem in linux i8k.c.
> So far we have
> 0x99 - presumably a spurious error
> 0xc1 - GPU temperature sensor, GPU turned off
>
> It would be nice if we could find a better solution for error
> handling.
>
Yes, but now we can only guess... My idea is that Dell SMM
handler does not check GPU presence at runtime and just try to
read info from PCI bus. And because turned off card is not there
just random (or non random) garbage is returned...
> Thanks,
> Guenter
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2014-11-30 10:11 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-29 16:04 [PATCH] i8k: Add support for temperature sensor labels Pali Rohár
2014-11-29 16:09 ` Pali Rohár
2014-11-29 16:24 ` Guenter Roeck
2014-11-29 16:32 ` Pali Rohár
2014-11-29 16:37 ` Steven Honeyman
2014-11-29 17:07 ` Gabriele Mazzotta
2014-11-29 17:18 ` Pali Rohár
2014-11-29 18:27 ` Gabriele Mazzotta
2014-11-29 18:58 ` Guenter Roeck
2014-11-29 19:07 ` Pali Rohár
2014-11-29 21:34 ` Guenter Roeck
2014-11-30 0:07 ` Guenter Roeck
2014-11-30 9:53 ` Pali Rohár
2014-11-30 16:00 ` Guenter Roeck
2014-11-30 17:44 ` Pali Rohár
2014-11-30 17:54 ` Guenter Roeck
2014-11-30 18:00 ` Pali Rohár
2014-11-30 18:22 ` Guenter Roeck
2014-11-30 1:25 ` Guenter Roeck
2014-11-30 10:11 ` Pali Rohár [this message]
2014-11-30 16:04 ` Guenter Roeck
2014-11-29 16:24 ` Guenter Roeck
2014-11-29 16:30 ` Pali Rohár
2014-11-29 18:15 ` Guenter Roeck
2014-11-29 17:43 ` Greg Kroah-Hartman
2014-11-29 17:49 ` Pali Rohár
2014-11-29 17:51 ` Greg Kroah-Hartman
2014-11-29 18:04 ` Pali Rohár
2014-12-02 13:23 ` Jean Delvare
2014-12-02 14:26 ` Guenter Roeck
2014-12-03 9:09 ` Jean Delvare
2014-12-03 9:25 ` Pali Rohár
2014-12-03 10:11 ` Jean Delvare
2014-12-03 19:14 ` Guenter Roeck
2014-12-04 10:16 ` Jean Delvare
2014-11-29 18:05 ` Guenter Roeck
2014-11-29 18:00 ` 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=201411301111.35988@pali \
--to=pali.rohar@gmail.com \
--cc=arnd@arndb.de \
--cc=gabriele.mzt@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=stevenhoneyman@gmail.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