lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201411292007.36975@pali>
Date:	Sat, 29 Nov 2014 20:07:36 +0100
From:	Pali Rohár <pali.rohar@...il.com>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Gabriele Mazzotta <gabriele.mzt@...il.com>,
	Arnd Bergmann <arnd@...db.de>,
	"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
	Steven Honeyman <stevenhoneyman@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i8k: Add support for temperature sensor labels

On Saturday 29 November 2014 19:58:28 Guenter Roeck wrote:
> On 11/29/2014 10:27 AM, Gabriele Mazzotta wrote:
> > On Saturday 29 November 2014 18:18:18 Pali Rohár wrote:
> >> On Saturday 29 November 2014 18:07:19 Gabriele Mazzotta 
wrote:
> >>> On Saturday 29 November 2014 17:09:35 Pali Rohár wrote:
> >>>> On Saturday 29 November 2014 17:04:07 Pali Rohár wrote:
> >>>>> This patch adds labels for temperature sensors if SMM
> >>>>> function with EAX register 0x11a3 reports it. These
> >>>>> informations was taken from DOS binary NBSVC.MDM.
> >>>>> 
> >>>>> Signed-off-by: Pali Rohár <pali.rohar@...il.com>
> >>>>> ---
> >>>>> 
> >>>>>   drivers/char/i8k.c |  110
> >>>>> 
> >>>>> +++++++++++++++++++++++++++++++++++++++++----------- 1
> >>>>> file changed, 88 insertions(+), 22 deletions(-)
> >>>> 
> >>>> I tested patch on Latitude E6440 and i8k CPU & GPU temps
> >>>> match intel coretemp & amd radeion temps.
> >>>> 
> >>>> But I would like if somebody with other Dell laptop can
> >>>> test if temperature labels are correct...
> >>> 
> >>> I tested it on my XPS13 9333, here what sensors outputs:
> >>> 
> >>> acpitz-virtual-0
> >>> Adapter: Virtual device
> >>> temp1:        +27.8°C  (crit = +105.0°C)
> >>> temp2:        +29.8°C  (crit = +105.0°C)
> >>> 
> >>> coretemp-isa-0000
> >>> Adapter: ISA adapter
> >>> Physical id 0:  +62.0°C  (high = +100.0°C, crit =
> >>> +100.0°C) Core 0:         +62.0°C  (high = +100.0°C, crit
> >>> = +100.0°C) Core 1:         +61.0°C  (high = +100.0°C,
> >>> crit = +100.0°C)
> >>> 
> >>> i8k-virtual-0
> >>> Adapter: Virtual device
> >>> fan2:           0 RPM
> >>> CPU:          +62.0°C
> >>> Ambient:      +49.0°C
> >>> SODIMM:       +46.0°C
> >>> temp4:            N/A
> >>> 
> >>> CPU seems to be correct, but I can't say anything on
> >>> Ambient and SODIMM. temp4 is constantly equal to SODIMM
> >>> without this patch, so I'd say N/A is correct.
> >>> 
> >>> 
> >>> Gabriele
> >> 
> >> It is unknown for me how to directly read Ambient and
> >> SODIMM temperatures (without Dell SMM functions). So we
> >> can only trust Dell SMM that it reporting correct values
> >> and type is really Ambient and SODIMM.
> >> 
> >> And about temp4:
> >> 
> >> Label is not set when SMM function fails. Original DOS
> >> NBSVC.MDM just ignore all sensors for which SMM type
> >> function fails.
> >> 
> >> This patch should not disable any sensor, so if you
> >> previously had some value (<= 128°C) and now not, then
> >> there is some bug.
> >> 
> >> Can you test this patch?
> >> https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-mi
> >> sc.git/comm
> >> it/?h=char-misc-testing&id=723493ca59c8d81fed3e7f261165fee
> >> 493a29ffa
> >> 
> >> It is possible that same value is caused by incorrect use
> >> of prev[] array which should be fixed by above patch.
> >> 
> >> Can you test i8k with and without above patch?
> > 
> > I did some more tests. What I think is happening is that
> > temp4_label returns -22, so I sensors prints N/A without
> > actually reading temp4_input.
> > 
> > I'm doing some tests to understand what's going on with
> > temp4_input. It reports the value of the last temp*_input I
> > read. If I read it right after I loaded i8k, I get an error
> > (-22).
> > 
> > The same doesn't happen for temp3_label, which constantly
> > returns -22.
> > 
> > I already had
> > https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-mi
> > sc.git/commit/?h=char-misc-testing&id=723493ca59c8d81fed3e7f
> > 261165fee493a29ffa applied. Without it, things seem not to
> > change much. I either get an error (-22) or some incorrect
> > values (for now always 1000) when I read temp4_input right
> > after i8k was loaded. Once I read some other temp*_input, I
> > always get the last value read.
> 
> I am seeing exactly the same behavior on an XPS13.
> 
> Guenter

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...

But because our i8k.c code ignores sensor only if it returns 
invalid temperature, there could be possible regression that on 
same machines type SMM function is not implemented or not 
working...

What do you think?

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ