Date:	Mon, 16 Apr 2007 23:14:11 +0200
From:	Luca Tettamanti <kronos.it@...il.com>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Jean Delvare <khali@...ux-fr.org>, Pavel Machek <pavel@....cz>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	lm-sensors@...sensors.org, linux-acpi@...r.kernel.org,
	Chuck Ebbert <cebbert@...hat.com>
Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

Il Sun, Apr 15, 2007 at 06:57:02PM -0600, Bjorn Helgaas ha scritto: 
> On Sunday 15 April 2007 14:59, Luca Tettamanti wrote:
> > On 4/15/07, Bjorn Helgaas <bjorn.helgaas@...com> wrote:
> > > But I missed the details, such as the specific devices in question,
> > > which ports they use, how they are described in ACPI, which AML
> > > methods use those ports, and which non-ACPI drivers also use them.
> > 
> > The original report was about the temperature sensors of K8 cpus. It
> > happens that ACPI reads the sensors while the linux driver is using it
> > and gets garbage (and shut down the system). The problem is more
> > generic though, and applies to all hardware monitoring chips for which
> > a driver exists.
> 
> Yes, I saw that much, but that's not enough detail to craft a good
> solution.
> 
> In the case of k8temp, the driver claims PCI devices with a certain
> vendor and device ID.  PCI devices are mostly outside the scope of
> ACPI.  There's a standard enumeration protocol, and a driver should
> be able to claim any device it recognizes without fear of conflict.
>
> I claim that an AML method that accesses a PCI device is
> defective because the AML can't know whether a native driver
> has claimed the device.

k8temp seems a special case tough.

> Sometimes the firmware can hide PCI devices so the OS
> enumeration doesn't find them.  In that case, AML might
> be able to safely use the PCI device, but the native
> driver wouldn't be able to claim the device, so there
> would be no conflict.  (Linux sometimes uses quirks to
> "unhide" things like this, which could lead to a conflict
> of our own making.)
> 
> I suspect that other sensor drivers may just probe for devices
> at "known" addresses hard-coded in the driver.

Usually sensors are attached to SMBUS or available in ISA IO space.
AFAIK they're not enumerated anywhere (at least I2C devices are not, you
poke at various addresses and see if something responds - not sure about
ISA).

> This is a
> problem because the ACPI model is that the OS learns about
> all built-in devices via the ACPI namespace.  If it isn't
> in the namespace, it shouldn't exist as far as the OS is
> concerned.
> 
> So we could easily have the situation where ACPI uses a
> sensor and does not expose it to the OS in the namespace.
> In that case, the firmware expectation is that the OS
> won't touch the device.  If the OS pokes around at the
> magic addresses and happens to trip over the device, we
> just made ourselves a problem.
> 
> > > It also sounds like the non-ACPI drivers provide much more
> > > functionality than ACPI exposes.  I'd like to understand this,
> > > too, because an  obvious way to solve the problem would be to
> > > drop the non-ACPI drivers.
> > 
> > Problem is that ACPI may access the sensors anyway (e.g. via SMM).
> 
> If ACPI accesses sensors but there is no native driver, there
> should be no conflict.

Of course. But we do have native drivers ;-)

> > > Is this extra functionality available
> > > on Windows?  If so, do we know whether Windows uses non-ACPI drivers
> > > or whether they have some smarter way to use ACPI?
> > 
> > Usually ACPI exposes 1 or 2 temperature readings (CPU and
> > motherboard), while the hw driver can also provide fans and voltages
> > measurements.
> > 
> > Vendors usually provides a monitoring utility for Win that also
> > exposes these information. It's not known whether there's a way to
> > avoid conflicting accesses between ACPI and the raw driver; it's
> > possible that it's vendor-specific and not documented.
> 
> I'd be surprised if Windows provided interfaces to coordinate
> between two drivers.  My impression is that they really want
> to have a single owner for a piece of hardware.  It would be
> interesting to figure out how these monitoring utilities work.
> Maybe the monitor and the AML both go through an embedded
> controller driver and coordinate that way?

Hum, the utility I have here (Asus PC Probe) seems to use ACPI:

Pro2.dll:
[Ordinal/Name Pointer] Table
        [  11] OCAPI_ACPI_OC_PresetList
        [  12] OCAPI_ACPI_OC__MB_GetBoardName
        [  23] OCAPI_CheckAiGear
        [   0] OCAPI_CheckIntelPowerSaving
        [   6] OCAPI_CheckWorkable
        [   2] OCAPI_Close
        [   9] OCAPI_EnableQFan
        [  16] OCAPI_GENERAL_GetList
        [  14] OCAPI_GetCpuVoltRange
        [  13] OCAPI_GetCurrentCpuFrequency
        [  15] OCAPI_GetFanStartTemp
        [   3] OCAPI_GetHealthData
        [   4] OCAPI_GetHwSensorData
        [  22] OCAPI_GetMBIF
        [   8] OCAPI_GetQFanInfo
        [   5] OCAPI_HW_EnumerateOption
        [   7] OCAPI_HideQFan
        [   1] OCAPI_Initialization
        [  19] OCAPI_NQFAN_GetData
        [  21] OCAPI_NQFAN_GetList
        [  20] OCAPI_NQFAN_SetData
        [  17] OCAPI_QFAN_GetData
        [  18] OCAPI_QFAN_SetData
        [  10] OCAPI_SetQFanTarget
        [  24] ___CPPdebugHook

ASiO.dll:
[Ordinal/Name Pointer] Table
        [   1] ASIO_Close
        [   9] ASIO_GetCpuID
        [   3] ASIO_InPortB
        [   5] ASIO_InPortD
        [   7] ASIO_MapMem
        [   0] ASIO_Open
        [   4] ASIO_OutPortB
        [   6] ASIO_OutPortD
        [  10] ASIO_ReadMSR
        [   8] ASIO_UnmapMem
        [  11] ASIO_WriteMSR
        [   2] OC_GetCurrentCpuFrequency

It seems that Asus exposes monitorining data using "ATK0110" (enumerated
in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D)
(they have different methods though). Another motherboard with the same
device may actually call it "FOOBAR123" or "WTFISTHIS".

Problem is that ACPI methods are not documented at all (how am I
supposed to know that "G6T6" is the reading of the 12V rail?) while the
datasheet of hw monitoring chips (w83627ehf in my case) are public (more
or less). Furthermore, sensor driver exposes all the reading of the chip
(e.g. in the DSDT I can't find the VSB or battery voltage).

I'm attacching my DSDT, in case you want to have fun ;-)

Luca
-- 
Collect some stars to shine for you
And start today 'cause there's only a few
A sign of times my friend

Download attachment "dsdt.dsl.bz2" of type "application/octet-stream" (19170 bytes)

Powered by blists - more mailing lists