[lm-sensors] Intel Core voltage monitoring

[lm-sensors] Intel Core voltage monitoring

[Peter Ganzhorn]

Hi,

I'm wondering if there is an easy way to monitor the voltage of an Intel 
Core CPU with Linux.
Windows tools like cpu-z report CPU information such as speed and 
multiplicator, but voltage and even temperature as well.
I don't think those Windows tools have a complete set of hardware 
monitoring drivers built-in, and there is already the coretemp driver to 
monitor the temperature of an Intel Core CPU.
Do you know any way to monitor the voltage of my CPU?

BTW: I have a Toshiba Tecra A9 notebook on which lm_sensors can't 
identify the hardware monitoring chips:

Some chips are also accessible through the ISA I/O ports. We have to
write to arbitrary I/O ports to probe them. This is usually safe though.
Yes, you do have ISA I/O ports even if you do not have any ISA slots!
Do you want to scan the ISA I/O ports? (YES/no):
Probing for `National Semiconductor LM78' at 0x290...       No
Probing for `National Semiconductor LM78-J' at 0x290...     No
Probing for `National Semiconductor LM79' at 0x290...       No
Probing for `Winbond W83781D' at 0x290...                   No
Probing for `Winbond W83782D' at 0x290...                   No
Probing for `Silicon Integrated Systems SIS5595'...         No
Probing for `VIA VT82C686 Integrated Sensors'...            No
Probing for `VIA VT8231 Integrated Sensors'...              No
Probing for `IPMI BMC KCS' at 0xca0...                      No
Probing for `IPMI BMC SMIC' at 0xca8...                     No

Some Super I/O chips may also contain sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'...                   No
Trying family `SMSC'...                                     Yes
Found unknown non-standard chip with ID 0x7a
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'...                   No
Trying family `SMSC'...                                     Yes
Found unknown chip with ID 0x0b00

Some CPUs or memory controllers may also contain embedded sensors.
Do you want to scan for them? (YES/no):
AMD K8 thermal sensors...                                   No
Intel Core family thermal sensor...                         Success!
    (driver `coretemp')
Intel AMB FB-DIMM thermal sensor...                         No


coretemp works just fine, but I have no way of monitoring anything else 
which is quite unsatisfying to me...
Maybe you guys can help me monitoring at least vcore!

best regards,
Peter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Intel Core voltage monitoring

[Rudolf Marek]

Hi Peter,

IMHO the CPU-Z reads the VID code from CPU, so the voltage is not the real 
voltage, but the voltage that the CPU wants (not what it is actually getting).

The driver could be extended to show the voltage, but that would not be a real 
voltage, but just voltage it wants... Don't know if it is benefit for user?

What others think?

Rudolf

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Intel Core voltage monitoring

[Jean Delvare]

Hi Rudolf,

On Mon, 10 Dec 2007 14:43:13 +0100, Rudolf Marek wrote:
> Hi Peter,
> 
> IMHO the CPU-Z reads the VID code from CPU, so the voltage is not the real 
> voltage, but the voltage that the CPU wants (not what it is actually getting).
> 
> The driver could be extended to show the voltage, but that would not be a real 
> voltage, but just voltage it wants... Don't know if it is benefit for user?
> 
> What others think?

Well, that's what other hardware monitoring drivers export as cpu0_vid.
If you can read the value from the CPU directly, that would be
interesting, as this means that we can get the value even if the VID
lines aren't (properly) wired to the hardware monitoring chip. So, yes,
I'd say it's worth exporting from the coretemp driver if that can be
done easily and reliably.

Thanks,
-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Intel Core voltage monitoring

[Jean Delvare]

Hi Peter,

On Sun, 09 Dec 2007 13:06:29 +0100, Peter Ganzhorn wrote:
> BTW: I have a Toshiba Tecra A9 notebook on which lm_sensors can't 
> identify the hardware monitoring chips:
> 
> Some chips are also accessible through the ISA I/O ports. We have to
> write to arbitrary I/O ports to probe them. This is usually safe though.
> Yes, you do have ISA I/O ports even if you do not have any ISA slots!
> Do you want to scan the ISA I/O ports? (YES/no):
> Probing for `National Semiconductor LM78' at 0x290...       No
> Probing for `National Semiconductor LM78-J' at 0x290...     No
> Probing for `National Semiconductor LM79' at 0x290...       No
> Probing for `Winbond W83781D' at 0x290...                   No
> Probing for `Winbond W83782D' at 0x290...                   No
> Probing for `Silicon Integrated Systems SIS5595'...         No
> Probing for `VIA VT82C686 Integrated Sensors'...            No
> Probing for `VIA VT8231 Integrated Sensors'...              No
> Probing for `IPMI BMC KCS' at 0xca0...                      No
> Probing for `IPMI BMC SMIC' at 0xca8...                     No
> 
> Some Super I/O chips may also contain sensors. We have to write to
> standard I/O ports to probe them. This is usually safe.
> Do you want to scan for Super I/O sensors? (YES/no):
> Probing for Super-I/O at 0x2e/0x2f
> Trying family `National Semiconductor'...                   No
> Trying family `SMSC'...                                     Yes
> Found unknown non-standard chip with ID 0x7a
> Probing for Super-I/O at 0x4e/0x4f
> Trying family `National Semiconductor'...                   No
> Trying family `SMSC'...                                     Yes
> Found unknown chip with ID 0x0b00
> 
> Some CPUs or memory controllers may also contain embedded sensors.
> Do you want to scan for them? (YES/no):
> AMD K8 thermal sensors...                                   No
> Intel Core family thermal sensor...                         Success!
>     (driver `coretemp')
> Intel AMB FB-DIMM thermal sensor...                         No
> 
> 
> coretemp works just fine, but I have no way of monitoring anything else 
> which is quite unsatisfying to me...
> Maybe you guys can help me monitoring at least vcore!

Your sensors-detect output doesn't include the SMBus scan, I guess that
the SMBus is hidden. I've seen this before on Toshiba laptops, and
after investigation we found that the SMBus was being accessed by SMM
code, so it's not safe to let Linux access it. That's a design decision
by the manufacturer, there's nothing we can do. You might be able to
get the fan reading using the toshiba_acpi driver, but that's about it.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Intel Core voltage monitoring

[Jean Delvare]

On Mon, 10 Dec 2007 15:50:26 +0100, Jean Delvare wrote:
> Your sensors-detect output doesn't include the SMBus scan, I guess that
> the SMBus is hidden. I've seen this before on Toshiba laptops, and
> after investigation we found that the SMBus was being accessed by SMM
> code, so it's not safe to let Linux access it. That's a design decision
> by the manufacturer, there's nothing we can do. You might be able to
> get the fan reading using the toshiba_acpi driver, but that's about it.

Forgot the references if you want to read the technical details:
http://bugzilla.kernel.org/show_bug.cgi?idc15
http://bugzilla.kernel.org/show_bug.cgi?idc95

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Intel Core voltage monitoring

[Peter Ganzhorn]

Thanks for your reply - is it possible that I am missing a driver to 
access my smbus? I enabled the i2C driver for the ICH8 chips 
(CONFIG_I2C_I801) and that's about it.

I investigated the cpu-z output as well and it seems it is using the 
current VID setting to display the voltage - there seem to be no 
fluctuations in voltage which is kinda strange for real hardware...

And BTW, I ommitted some obvious useless output of sensors-detect which 
I consider to be smbus-related; but it looks like smbus is a complete no-go:

# sensors-detect revision 4609 (2007-07-14 09:28:39 -0700)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

We can start with probing for (PCI) I2C or SMBus adapters.
Do you want to probe now? (YES/no):
Probing for PCI bus adapters...
Sorry, no known PCI bus adapters found.

We will now try to load each adapter module in turn.
If you have undetectable or unsupported adapters, you can have them
scanned by manually loading the modules before running this script.

We are now going to do the I2C/SMBus adapter probings. Some chips may
be double detected; we choose the one with the highest confidence
value in that case.
If you found that the adapter hung after probing a certain address,
you can specify that address to remain unprobed.

If you can think of any other way to see what *real* vcore my cpu runs 
with let me know, but I am afraid it won't be possible considering what 
you've told me.
Thanks anyways for the great job you are doing with sensors,

Peter


Jean Delvare wrote:
> Hi Peter,
>
> On Sun, 09 Dec 2007 13:06:29 +0100, Peter Ganzhorn wrote:
>   
>> BTW: I have a Toshiba Tecra A9 notebook on which lm_sensors can't 
>> identify the hardware monitoring chips:
>>
>> Some chips are also accessible through the ISA I/O ports. We have to
>> write to arbitrary I/O ports to probe them. This is usually safe though.
>> Yes, you do have ISA I/O ports even if you do not have any ISA slots!
>> Do you want to scan the ISA I/O ports? (YES/no):
>> Probing for `National Semiconductor LM78' at 0x290...       No
>> Probing for `National Semiconductor LM78-J' at 0x290...     No
>> Probing for `National Semiconductor LM79' at 0x290...       No
>> Probing for `Winbond W83781D' at 0x290...                   No
>> Probing for `Winbond W83782D' at 0x290...                   No
>> Probing for `Silicon Integrated Systems SIS5595'...         No
>> Probing for `VIA VT82C686 Integrated Sensors'...            No
>> Probing for `VIA VT8231 Integrated Sensors'...              No
>> Probing for `IPMI BMC KCS' at 0xca0...                      No
>> Probing for `IPMI BMC SMIC' at 0xca8...                     No
>>
>> Some Super I/O chips may also contain sensors. We have to write to
>> standard I/O ports to probe them. This is usually safe.
>> Do you want to scan for Super I/O sensors? (YES/no):
>> Probing for Super-I/O at 0x2e/0x2f
>> Trying family `National Semiconductor'...                   No
>> Trying family `SMSC'...                                     Yes
>> Found unknown non-standard chip with ID 0x7a
>> Probing for Super-I/O at 0x4e/0x4f
>> Trying family `National Semiconductor'...                   No
>> Trying family `SMSC'...                                     Yes
>> Found unknown chip with ID 0x0b00
>>
>> Some CPUs or memory controllers may also contain embedded sensors.
>> Do you want to scan for them? (YES/no):
>> AMD K8 thermal sensors...                                   No
>> Intel Core family thermal sensor...                         Success!
>>     (driver `coretemp')
>> Intel AMB FB-DIMM thermal sensor...                         No
>>
>>
>> coretemp works just fine, but I have no way of monitoring anything else 
>> which is quite unsatisfying to me...
>> Maybe you guys can help me monitoring at least vcore!
>>     
>
> Your sensors-detect output doesn't include the SMBus scan, I guess that
> the SMBus is hidden. I've seen this before on Toshiba laptops, and
> after investigation we found that the SMBus was being accessed by SMM
> code, so it's not safe to let Linux access it. That's a design decision
> by the manufacturer, there's nothing we can do. You might be able to
> get the fan reading using the toshiba_acpi driver, but that's about it.
>
>   


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Intel Core voltage monitoring

[Jean Delvare]

Hi Peter,

On Mon, 10 Dec 2007 19:12:36 +0100, Peter Ganzhorn wrote:
> Thanks for your reply - is it possible that I am missing a driver to 
> access my smbus? I enabled the i2C driver for the ICH8 chips 
> (CONFIG_I2C_I801) and that's about it.

You're not missing any driver. What you're missing is the SMBus master
device itself, because it was hidden from you by the BIOS, but given
what the BIOS does with it, that's the only safe approach.

> I investigated the cpu-z output as well and it seems it is using the 
> current VID setting to display the voltage - there seem to be no 
> fluctuations in voltage which is kinda strange for real hardware...

OK, this confirms Rudolf's theory then.

> And BTW, I ommitted some obvious useless output of sensors-detect which 
> I consider to be smbus-related; but it looks like smbus is a complete no-go:
> 
> # sensors-detect revision 4609 (2007-07-14 09:28:39 -0700)
> 
> This program will help you determine which kernel modules you need
> to load to use lm_sensors most effectively. It is generally safe
> and recommended to accept the default answers to all questions,
> unless you know what you're doing.
> 
> We can start with probing for (PCI) I2C or SMBus adapters.
> Do you want to probe now? (YES/no):
> Probing for PCI bus adapters...
> Sorry, no known PCI bus adapters found.

This confirms my guess that the SMBus is hidden on your system.

> (...)
> If you can think of any other way to see what *real* vcore my cpu runs 
> with let me know, but I am afraid it won't be possible considering what 
> you've told me.

Indeed I do not think that you'll be able to do that on your laptop.
That's pretty common for laptops, BTW. Laptops where voltages can be
monitored are the exception, not the rule.

> Thanks anyways for the great job you are doing with sensors,

Thanks :)

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Intel Core voltage monitoring

[linux]

> You're not missing any driver. What you're missing is the SMBus master
> device itself, because it was hidden from you by the BIOS, but given
> what the BIOS does with it, that's the only safe approach.

I don't see a Linux driver for it, but there is a spec for SMBus
access via ACPI, which could synchronize with SMM properly.

The spec's at http://www.smbus.org/specs/
specifically
SMBus Control Method Interface Specification, version 1.0
http://www.smbus.org/specs/smbus_cmi10.pdf

Supposedly there should be something like

Device(SMB<id>){
   Name(_HID, "SMBUS01")   // Hardware ID (PnP ID)
   Name(_UID, <uid>)       // Unique Identification
   Method(_SBI, 0) {...}   // SMBus Information
   Method(_SBR, 3) {...}   // SMBus Data Read
   Method(_SBW, 6) {...}   // SMBus Data Write
   Method(_SBT, 6) {...}   // SMBus Data Transfer
   Method(_SBA, 0) {...}   // SMBus Alert Information
}

Does anyone know the right incanation (probably using "acpidump")
to see if this is supported on the problematic machines?  If so,
writing a driver becomes an interesting question.

(This seems rather obvious, so I hope this idea hasn't been
discarded already for some reason I have overlooked.)

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Intel Core voltage monitoring

[Jean Delvare]

On 12 Dec 2007 01:39:30 -0500, linux@horizon.com wrote:
> > You're not missing any driver. What you're missing is the SMBus master
> > device itself, because it was hidden from you by the BIOS, but given
> > what the BIOS does with it, that's the only safe approach.
> 
> I don't see a Linux driver for it, but there is a spec for SMBus
> access via ACPI, which could synchronize with SMM properly.
> 
> The spec's at http://www.smbus.org/specs/
> specifically
> SMBus Control Method Interface Specification, version 1.0
> http://www.smbus.org/specs/smbus_cmi10.pdf
> 
> Supposedly there should be something like
> 
> Device(SMB<id>){
>    Name(_HID, "SMBUS01")   // Hardware ID (PnP ID)
>    Name(_UID, <uid>)       // Unique Identification
>    Method(_SBI, 0) {...}   // SMBus Information
>    Method(_SBR, 3) {...}   // SMBus Data Read
>    Method(_SBW, 6) {...}   // SMBus Data Write
>    Method(_SBT, 6) {...}   // SMBus Data Transfer
>    Method(_SBA, 0) {...}   // SMBus Alert Information
> }

There has been a driver doing that in kernel 2.6.18 to 2.6.22, named
i2c_ec:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/acpi/i2c_ec.c
But then the driver we deleted by Len Brown. As the log message is
empty, I can't tell you why the driver was deleted.

Note that this driver was looking for an ACPI device named "ACPI0001",
not SMB<id> as you described above. So maybe it's something different,
I don't know.

> Does anyone know the right incanation (probably using "acpidump")
> to see if this is supported on the problematic machines?  If so,
> writing a driver becomes an interesting question.

Yes, acpidump should tell you. Or just run "iasl -d" on your DSDT
table, I guess that this is where the device in question would be
declared. But I don't remember ever seeing the above implemented in any
ACPI DSDT I've disassembled.

I'm not sure why this would be more robust to SMM than any other driver
though. How could the ACPI code synchronize with SMM given that you do
not know when an SMI happens?

> (This seems rather obvious, so I hope this idea hasn't been
> discarded already for some reason I have overlooked.)

There clearly is a need for this on some machines, but it remains to be
understood why the Linux ACPI people apparently do not want to expose
this interface.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Intel Core voltage monitoring

[Peter Ganzhorn]

This sounds quite interesting to me - do you think it should be possible 
to find out what's the matter about the removal of the driver and would 
I have been able to access my smbus and the hwmon chip in my laptop with it?
It would be great to have a driver for this stuff, but it should work 
flawlessly of course...and if it was removed I suppose there was a 
problem with it :(

But thanks for the info, please keep me up2date if you're going to 
investigate a bit more!

Peter


Jean Delvare wrote:
> On 12 Dec 2007 01:39:30 -0500, linux@horizon.com wrote:
>   
>>> You're not missing any driver. What you're missing is the SMBus master
>>> device itself, because it was hidden from you by the BIOS, but given
>>> what the BIOS does with it, that's the only safe approach.
>>>       
>> I don't see a Linux driver for it, but there is a spec for SMBus
>> access via ACPI, which could synchronize with SMM properly.
>>
>> The spec's at http://www.smbus.org/specs/
>> specifically
>> SMBus Control Method Interface Specification, version 1.0
>> http://www.smbus.org/specs/smbus_cmi10.pdf
>>
>> Supposedly there should be something like
>>
>> Device(SMB<id>){
>>    Name(_HID, "SMBUS01")   // Hardware ID (PnP ID)
>>    Name(_UID, <uid>)       // Unique Identification
>>    Method(_SBI, 0) {...}   // SMBus Information
>>    Method(_SBR, 3) {...}   // SMBus Data Read
>>    Method(_SBW, 6) {...}   // SMBus Data Write
>>    Method(_SBT, 6) {...}   // SMBus Data Transfer
>>    Method(_SBA, 0) {...}   // SMBus Alert Information
>> }
>>     
>
> There has been a driver doing that in kernel 2.6.18 to 2.6.22, named
> i2c_ec:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/acpi/i2c_ec.c
> But then the driver we deleted by Len Brown. As the log message is
> empty, I can't tell you why the driver was deleted.
>
> Note that this driver was looking for an ACPI device named "ACPI0001",
> not SMB<id> as you described above. So maybe it's something different,
> I don't know.
>
>   
>> Does anyone know the right incanation (probably using "acpidump")
>> to see if this is supported on the problematic machines?  If so,
>> writing a driver becomes an interesting question.
>>     
>
> Yes, acpidump should tell you. Or just run "iasl -d" on your DSDT
> table, I guess that this is where the device in question would be
> declared. But I don't remember ever seeing the above implemented in any
> ACPI DSDT I've disassembled.
>
> I'm not sure why this would be more robust to SMM than any other driver
> though. How could the ACPI code synchronize with SMM given that you do
> not know when an SMI happens?
>
>   
>> (This seems rather obvious, so I hope this idea hasn't been
>> discarded already for some reason I have overlooked.)
>>     
>
> There clearly is a need for this on some machines, but it remains to be
> understood why the Linux ACPI people apparently do not want to expose
> this interface.
>
>   


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Intel Core voltage monitoring

[linux]

> There has been a driver doing that in kernel 2.6.18 to 2.6.22, named
> i2c_ec:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/acpi/i2c_ec.c
> But then the driver we deleted by Len Brown. As the log message is
> empty, I can't tell you why the driver was deleted.
> 
> Note that this driver was looking for an ACPI device named "ACPI0001",
> not SMB<id> as you described above. So maybe it's something different,
> I don't know.

It looks like that was just a helper for a "Smart Battery" driver,
and it was rendered unnecessary.  There are a few clues at
http://marc.info/?t\x117409889900001

> Yes, acpidump should tell you. Or just run "iasl -d" on your DSDT
> table, I guess that this is where the device in question would be
> declared. But I don't remember ever seeing the above implemented in any
> ACPI DSDT I've disassembled.

Unfortunately, my knowledge of ACPI rivals my knowledge of Xhosa, so
acpidump doesn't tell me any more than "xxd /dev/urandom", and "iasl -d"
on my latest machine just produces:

# iasl -d
Intel ACPI Component Architecture
AML Disassembler version 20061109 [May 15 2007]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

Could not obtain DSDT
Could not get ACPI tables, AE_NO_ACPI_TABLES

> I'm not sure why this would be more robust to SMM than any other driver
> though. How could the ACPI code synchronize with SMM given that you do
> not know when an SMI happens?

There are ways to do this, with cooperation from both sides.  The most
obvious to me is a sort of redo log, where the SMM code finishes the
I2C transaction if one is in progress when it needs to use the I2C bus.

Whether BIOS writers can get something that subtle correct is, of course,
always an exciting question.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Intel Core voltage monitoring

[Jean Delvare]

On Wed, 12 Dec 2007 13:05:08 +0100, Peter Ganzhorn wrote:
> This sounds quite interesting to me - do you think it should be possible 
> to find out what's the matter about the removal of the driver and would 
> I have been able to access my smbus and the hwmon chip in my laptop with it?
> It would be great to have a driver for this stuff, but it should work 
> flawlessly of course...and if it was removed I suppose there was a 
> problem with it :(

Please ask Len Brown directly (and let me know his answer, I'm
curious.) I know that the i2c_ec driver was added at the same time as
the sbs driver, and the sbs driver was originally making use of the
i2c_ec driver, but then the sbs driver was rewritten to no longer
depend on i2c_ec. I don't know the details, but maybe this was enough
for Len to decide that the i2c_ec driver was no longer needed at all.
Either way, he should really have put a comment in that removal commit.

Whether or not the driver would have helped you depends on the presence
of the ACPI0001 device in your DSDT. If your DSDT doesn't define this
device than the driver in question wouldn't have worked for you anyway.

> But thanks for the info, please keep me up2date if you're going to 
> investigate a bit more!

Unlikely, I don't really have the time at the moment.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Intel Core voltage monitoring

[Jean Delvare]

On 12 Dec 2007 07:07:40 -0500, linux@horizon.com wrote:
> > There has been a driver doing that in kernel 2.6.18 to 2.6.22, named
> > i2c_ec:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/acpi/i2c_ec.c
> > But then the driver we deleted by Len Brown. As the log message is
> > empty, I can't tell you why the driver was deleted.
> > 
> > Note that this driver was looking for an ACPI device named "ACPI0001",
> > not SMB<id> as you described above. So maybe it's something different,
> > I don't know.
> 
> It looks like that was just a helper for a "Smart Battery" driver,
> and it was rendered unnecessary.  There are a few clues at
> http://marc.info/?t\x117409889900001

This is my guess as well. And I can't really argue against that, as I
never saw any machine implementing this myself, I have no idea whether
there was anything other than the smart battery stuff on the bus.

> > Yes, acpidump should tell you. Or just run "iasl -d" on your DSDT
> > table, I guess that this is where the device in question would be
> > declared. But I don't remember ever seeing the above implemented in any
> > ACPI DSDT I've disassembled.
> 
> Unfortunately, my knowledge of ACPI rivals my knowledge of Xhosa, so
> acpidump doesn't tell me any more than "xxd /dev/urandom", and "iasl -d"
> on my latest machine just produces:
> 
> # iasl -d
> Intel ACPI Component Architecture
> AML Disassembler version 20061109 [May 15 2007]
> Copyright (C) 2000 - 2006 Intel Corporation
> Supports ACPI Specification Revision 3.0a
> 
> Could not obtain DSDT
> Could not get ACPI tables, AE_NO_ACPI_TABLES

You need to pass it your DSDT file as a parameter. It used to be
at /proc/acpi/dsdt but on recent kernels it moved
to /sys/firmware/acpi/tables/DSDT. You might need to copy the file to a
temporary directory before iasl -d will be able to disassemble it. Then
you can grep the disassembled form for "SMB", "ACPI0001" or whatever
you want.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors