Hi all...
I have a couple boxes where the thermal acpi driver gives this:
bran:~> sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +26.8°C (crit = +100.0°C)
bran:~> acpi -t
No support for device type: battery
Thermal 1: ok, 27.0 degrees C
It stays _always_ the same, there is no difference if I run some number
crunchin, or even if one of them is overclocked from 2.8 to 3.0 GHz.
They are 1U supermicro boxes, ventilation is good, but I don't trust this
measures...
It looks like the system is using some kind of 'generic' acpi TZ driver,
but as I'm used to good-ol' sensors modules, I don't know where to look.
Previously I used the w83627hf module from sensors.
This is the system info:
bran:~# x86info
x86info v1.23. Dave Jones 2001-2008
Feedback to <[email protected]>.
Found 2 CPUs
--------------------------------------------------------------------------
CPU #1
EFamily: 0 EModel: 0 Family: 15 Model: 2 Stepping: 9
CPU Model: Pentium 4 (Northwood) [D1]
Processor name string: Intel(R) Pentium(R) 4 CPU 2.80GHz
Type: 0 (Original OEM) Brand: 9 (Intel® Pentium® 4 processor)
Number of cores per physical package=1
Number of logical processors per socket=2
Number of logical processors per core=2
APIC ID: 0x0 Package: 0 Core: 0 SMT ID 0
--------------------------------------------------------------------------
CPU #2
EFamily: 0 EModel: 0 Family: 15 Model: 2 Stepping: 9
CPU Model: Pentium 4 (Northwood) [D1]
Processor name string: Intel(R) Pentium(R) 4 CPU 2.80GHz
Type: 0 (Original OEM) Brand: 9 (Intel® Pentium® 4 processor)
Number of cores per physical package=1
Number of logical processors per socket=2
Number of logical processors per core=2
APIC ID: 0x1 Package: 0 Core: 0 SMT ID 1
--------------------------------------------------------------------------
bran:~# lspci
00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP Controller (rev 02)
00:06.0 System peripheral: Intel Corporation 82875P/E7210 Processor to I/O Memory Interface (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02)
02:03.0 Ethernet controller: Intel Corporation 82543GC Gigabit Ethernet Controller (Copper) (rev 02)
02:09.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
02:0a.0 Ethernet controller: Intel Corporation 82541EI Gigabit Ethernet Controller
02:0b.0 Ethernet controller: Intel Corporation 82541EI Gigabit Ethernet Controller
dmidecode for mobo:
System Information
Manufacturer: Supermicro
Product Name: P4SCE
Version: 1234567890
Serial Number: 1234567890
UUID: Not Present
Wake-up Type: Power Switch
Is there any acpi driver for this kind of box ?
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2010.0 (Cooker) for x86_64
Linux 2.6.29.3-desktop-1mnb (gcc 4.3.2 (GCC) #1 Wed May
On 12/09/2009 04:26 PM, J.A. Magallón wrote:
> Hi all...
>
> I have a couple boxes where the thermal acpi driver gives this:
>
> bran:~> sensors
> acpitz-virtual-0
> Adapter: Virtual device
> temp1: +26.8°C (crit = +100.0°C)
>
> bran:~> acpi -t
> No support for device type: battery
> Thermal 1: ok, 27.0 degrees C
>
> It stays _always_ the same, there is no difference if I run some number
> crunchin, or even if one of them is overclocked from 2.8 to 3.0 GHz.
There are systems where an ACPI thermal zone exists but isn't really
hooked up to anything and just reports some dummy temperature value. My
old system reported 40 degrees C no matter what. (I think it's something
like the thermal zone support is part of the standard ACPI DSDT template
the mobo maker got from the BIOS developer and they effectively disabled
it by putting in the dummy temperature.)
> They are 1U supermicro boxes, ventilation is good, but I don't trust this
> measures...
> It looks like the system is using some kind of 'generic' acpi TZ driver,
> but as I'm used to good-ol' sensors modules, I don't know where to look.
>
> Previously I used the w83627hf module from sensors.
I'm assuming the kernel is preventing that module from loading since the
ACPI DSDT has operation regions that refer to the device registers.
There's no guarantee that this means the BIOS actually accesses the
device, or if it does, that there's a way to get it to report what it
sees other than to itself. If the BIOS doesn't actually access the
device then you can use the acpi_enforce_resources=lax to allow it. The
problem is this might be totally unsafe and the kernel has no way to
tell if it is or isn't.
On Wed, 9 Dec 2009, Robert Hancock wrote:
> On 12/09/2009 04:26 PM, J.A. Magallón wrote:
> > Hi all...
> >
> > I have a couple boxes where the thermal acpi driver gives this:
> >
> > bran:~> sensors
> > acpitz-virtual-0
> > Adapter: Virtual device
> > temp1: +26.8°C (crit = +100.0°C)
> >
> > bran:~> acpi -t
> > No support for device type: battery
> > Thermal 1: ok, 27.0 degrees C
> >
> > It stays _always_ the same, there is no difference if I run some number
> > crunchin, or even if one of them is overclocked from 2.8 to 3.0 GHz.
>
> There are systems where an ACPI thermal zone exists but isn't really hooked up
> to anything and just reports some dummy temperature value. My old system
> reported 40 degrees C no matter what. (I think it's something like the thermal
> zone support is part of the standard ACPI DSDT template the mobo maker got
> from the BIOS developer and they effectively disabled it by putting in the
> dummy temperature.)
send the output from acpidump, and a quick look will tell us
if your ACPI suport is dummy, or accesses real registers.
Also, show the output from
grep . /proc/acpi/thermal_zone/*/*
cheers,
-Len Brown, Intel Open Source Technology Center
> > They are 1U supermicro boxes, ventilation is good, but I don't trust this
> > measures...
> > It looks like the system is using some kind of 'generic' acpi TZ driver,
> > but as I'm used to good-ol' sensors modules, I don't know where to look.
> >
> > Previously I used the w83627hf module from sensors.
>
> I'm assuming the kernel is preventing that module from loading since the ACPI
> DSDT has operation regions that refer to the device registers. There's no
> guarantee that this means the BIOS actually accesses the device, or if it
> does, that there's a way to get it to report what it sees other than to
> itself. If the BIOS doesn't actually access the device then you can use the
> acpi_enforce_resources=lax to allow it. The problem is this might be totally
> unsafe and the kernel has no way to tell if it is or isn't.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Fri, 11 Dec 2009 01:25:49 -0500 (EST), Len Brown <[email protected]> wrote:
> On Wed, 9 Dec 2009, Robert Hancock wrote:
>
> > On 12/09/2009 04:26 PM, J.A. Magallón wrote:
> > > Hi all...
> > >
> > > I have a couple boxes where the thermal acpi driver gives this:
> > >
> > > bran:~> sensors
> > > acpitz-virtual-0
> > > Adapter: Virtual device
> > > temp1: +26.8°C (crit = +100.0°C)
> > >
> > > bran:~> acpi -t
> > > No support for device type: battery
> > > Thermal 1: ok, 27.0 degrees C
> > >
> > > It stays _always_ the same, there is no difference if I run some number
> > > crunchin, or even if one of them is overclocked from 2.8 to 3.0 GHz.
> >
> > There are systems where an ACPI thermal zone exists but isn't really hooked up
> > to anything and just reports some dummy temperature value. My old system
> > reported 40 degrees C no matter what. (I think it's something like the thermal
> > zone support is part of the standard ACPI DSDT template the mobo maker got
> > from the BIOS developer and they effectively disabled it by putting in the
> > dummy temperature.)
>
> send the output from acpidump, and a quick look will tell us
> if your ACPI suport is dummy, or accesses real registers.
>
> Also, show the output from
>
> grep . /proc/acpi/thermal_zone/*/*
>
Here they go:
bran:~# grep . /proc/acpi/thermal_zone/*/*
/proc/acpi/thermal_zone/THRM/cooling_mode:0 - Active; 1 - Passive
/proc/acpi/thermal_zone/THRM/polling_frequency:<polling disabled>
/proc/acpi/thermal_zone/THRM/state:state: ok
/proc/acpi/thermal_zone/THRM/temperature:temperature: 27 C
/proc/acpi/thermal_zone/THRM/trip_points:critical (S5): 100 C
/proc/acpi/thermal_zone/THRM/trip_points:passive: 75 C: tc1=4 tc2=3 tsp=60 devices=CPU0
/proc/acpi/thermal_zone/THRM/trip_points:active[0]: 75 C: devices= FAN
Result from acpidump is attached.
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2010.0 (Cooker) for x86_64
Linux 2.6.29.3-desktop-1mnb (gcc 4.3.2 (GCC) #1 Wed May
this DSDT returns a constant temperature, always:
Method (_TMP, 0, NotSerialized)
{
Return (0x0BB8)
}
so in this case, Linux is just reporting the (lack of) news:-)
cheers,
Len Brown, Intel Open Source Technology Center
On Mon, 14 Dec 2009 22:00:25 -0500 (EST), Len Brown <[email protected]> wrote:
> this DSDT returns a constant temperature, always:
>
> Method (_TMP, 0, NotSerialized)
> {
> Return (0x0BB8)
> }
>
>
> so in this case, Linux is just reporting the (lack of) news:-)
>
So, lets see...:
- Someone decided ACPI is the only-real-good-way
- Only a few devices are ported to ACPI
- The old way is unusable
- We can not return to the old way
So, any solution ? Thermal ACPI info in this boards (and I suspect in many
others) is useless. We can not disable that part of ACPI, we can not enable
sensors. So no thermal monitoring.
Nice.
Ayways, as in this case the ACPI part does not any real work, is still
present the problem of two drivers poking the same hardware or could I use
that 'lax' trick ?
And second, can the traditional sensor drivers be ported to offer an ACPI
device replacing the default one, or is that a stupid question ?
TIA
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2010.0 (Cooker) for x86_64
Linux 2.6.29.3-desktop-1mnb (gcc 4.3.2 (GCC) #1 Wed May
On Tue, 15 Dec 2009, J.A. Magall?n wrote:
> On Mon, 14 Dec 2009 22:00:25 -0500 (EST), Len Brown <[email protected]> wrote:
>
> > this DSDT returns a constant temperature, always:
> >
> > Method (_TMP, 0, NotSerialized)
> > {
> > Return (0x0BB8)
> > }
> >
> >
> > so in this case, Linux is just reporting the (lack of) news:-)
> >
>
> So, lets see...:
>
> - Someone decided ACPI is the only-real-good-way
> - Only a few devices are ported to ACPI
> - The old way is unusable
> - We can not return to the old way
>
> So, any solution ? Thermal ACPI info in this boards (and I suspect in many
> others) is useless. We can not disable that part of ACPI, we can not enable
> sensors. So no thermal monitoring.
> Nice.
>
> Ayways, as in this case the ACPI part does not any real work, is still
> present the problem of two drivers poking the same hardware or could I use
> that 'lax' trick ?
>
> And second, can the traditional sensor drivers be ported to offer an ACPI
> device replacing the default one, or is that a stupid question ?
>
Check, for an updated BIOS from the vendor.
If there is none, then express your displeasure to the vendor
and consider a different one for your next purchase.
For the box you have, try "acpi_enforce_resources=lax"
and load your native sensor driver.
Likely you'll be happy with that -- I just can't guarantee it.
cheers,
-Len Brown, Intel Open Source Technology Center
On 12/15/2009 04:46 PM, J.A. Magall?n wrote:
> On Mon, 14 Dec 2009 22:00:25 -0500 (EST), Len Brown<[email protected]> wrote:
>
>> this DSDT returns a constant temperature, always:
>>
>> Method (_TMP, 0, NotSerialized)
>> {
>> Return (0x0BB8)
>> }
>>
>>
>> so in this case, Linux is just reporting the (lack of) news:-)
>>
>
> So, lets see...:
>
> - Someone decided ACPI is the only-real-good-way
> - Only a few devices are ported to ACPI
> - The old way is unusable
> - We can not return to the old way
You can return to the "old way", that's what acpi_enforce_resources=lax
is for. It won't be any more dangerous than it was before. The problem
is that there's no way (at least, no simple one, it seems) to know if
the BIOS is really going to access those registers it indicates it
might. There are systems where it indeed does access them and this
breaks things badly (causing problems like spurious thermal shutdowns).
What is the error that prevents w83627hf from loading? It might be
useful to find what reference in the AML causes the detection that it
may access the device registers.
>
> So, any solution ? Thermal ACPI info in this boards (and I suspect in many
> others) is useless. We can not disable that part of ACPI, we can not enable
> sensors. So no thermal monitoring.
> Nice.
>
> Ayways, as in this case the ACPI part does not any real work, is still
> present the problem of two drivers poking the same hardware or could I use
> that 'lax' trick ?
>
> And second, can the traditional sensor drivers be ported to offer an ACPI
> device replacing the default one, or is that a stupid question ?
It wouldn't make any sense. An ACPI driver would have to access some
interface that the BIOS ACPI AML code provides to access the sensor
data. Presumably this BIOS doesn't provide such an interface. (The only
such interface other than the standard ACPI thermal zone interface that
I'm aware of is the ATK0110 interface used on a lot of Asus motherboards.)