Recently my notebook has started shutting down with
these messages in the logs:
ACPI: Critical trip point
Critical temperature reached (128 C), shutting down.
But it didn't seem hot at all to me, so I wrote a script to
cat /proc/acpi/thermal_zone/THRM/temperature once a second
and eventually caught this (but no shutdown):
temperature: 47 C
temperature: 47 C
temperature: 128 C
temperature: 48 C
temperature: 47 C
Google found several people reporting problems like mine
after installing lm-sensors, and when I looked at the list
of loaded modules I found k8temp and hwmon there. Then I
realized my problems had started after installing a 2.6.19
kernel that had the new k8temp driver.
So, could ACPI and the k8temp driver be at odds?
On Friday 16 February 2007 12:31, Chuck Ebbert wrote:
> Recently my notebook has started shutting down with
> these messages in the logs:
>
> ACPI: Critical trip point
> Critical temperature reached (128 C), shutting down.
>
> But it didn't seem hot at all to me, so I wrote a script to
> cat /proc/acpi/thermal_zone/THRM/temperature once a second
> and eventually caught this (but no shutdown):
>
> temperature: 47 C
> temperature: 47 C
> temperature: 128 C
> temperature: 48 C
> temperature: 47 C
>
> Google found several people reporting problems like mine
> after installing lm-sensors, and when I looked at the list
> of loaded modules I found k8temp and hwmon there. Then I
> realized my problems had started after installing a 2.6.19
> kernel that had the new k8temp driver.
>
> So, could ACPI and the k8temp driver be at odds?
Yes.
-Len
Len Brown wrote:
>> So, could ACPI and the k8temp driver be at odds?
>
>
> Yes.
Hmm, now it's showing 130 degrees once every five seconds
and 54 degrees for the other four.
And while I was typing this on another machine I heard a
click from the notebook -- it shut down again.
Chuck Ebbert <[email protected]> writes:
>
> So, could ACPI and the k8temp driver be at odds?
Yes, there is no locking between ACPI and Linux drivers for register access.
e.g. if there is a indexed register both try to access (and temperature
sensors tend to use these things) they can race and get corrupted data.
-Andi
Andi Kleen wrote:
> Chuck Ebbert <[email protected]> writes:
>> So, could ACPI and the k8temp driver be at odds?
>
> Yes, there is no locking between ACPI and Linux drivers for register access.
> e.g. if there is a indexed register both try to access (and temperature
> sensors tend to use these things) they can race and get corrupted data.
I blacklisted the k8temp driver and everything looks OK now.
Hello Chuck,
I'm the author of K8temp. Please can you share with us your DSDT table?
(cat /proc/acpi/dsdt > /tmp/dsdt.bin)
> So, could ACPI and the k8temp driver be at odds?
Yes because ACPI AML code has no synchronization with Linux drivers. Second
reason is that ACPI AML code assign resource regions to itself but with cleared
busy flag - so other drivers could bind and might possibly interfere with ACPI.
This is very long term problem, I already proposed some possible solutions to
this problem
(http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018788.html)
There are some ideas, but none is implemented yet. As you already wrote, best
solution is to stop using k8temp driver.
I will check the DSDT table to confirm this fact.
Thanks,
Rudolf
Rudolf Marek wrote:
> Hello Chuck,
>
> I'm the author of K8temp. Please can you share with us your DSDT table?
> (cat /proc/acpi/dsdt > /tmp/dsdt.bin)
>
The system is Compaq Presario V2300 series notebook. I won't be able
to get the DSDT until tomorrow or Monday.
>> So, could ACPI and the k8temp driver be at odds?
>
> Yes because ACPI AML code has no synchronization with Linux drivers. Second
> reason is that ACPI AML code assign resource regions to itself but with cleared
> busy flag - so other drivers could bind and might possibly interfere with ACPI.
Well I had an idea after looking at k8temp -- why not make it default to
doing only reads from the sensor? You'd only get information from whatever
core/sensor combination that ACPI had last used, but it would be safe.
Hi Chuck,
On Fri, 16 Feb 2007 14:31:44 -0500, Chuck Ebbert wrote:
> Andi Kleen wrote:
> > Chuck Ebbert wrote:
> > > So, could ACPI and the k8temp driver be at odds?
> >
> > Yes, there is no locking between ACPI and Linux drivers for register access.
> > e.g. if there is a indexed register both try to access (and temperature
> > sensors tend to use these things) they can race and get corrupted data.
>
> I blacklisted the k8temp driver and everything looks OK now.
You could blacklist the ACPI "thermal" module instead. If you're
interested in monitoring your CPU temperature, k8temp is IMHO more
convenient to use than ACPI, as it interfaces properly with libsensors
and all hardware monitoring user interfaces.
--
Jean Delvare
On Sat, 17 Feb 2007 13:14:50 -0500, Chuck Ebbert wrote:
> Well I had an idea after looking at k8temp -- why not make it default to
> doing only reads from the sensor? You'd only get information from whatever
> core/sensor combination that ACPI had last used, but it would be safe.
ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI
doesn't conflict with only k8temp, but with virtually all hardware
monitoring drivers, all I2C/SMBus drivers, and probably other types of
drivers too. We just can't restrict or blacklist all these drivers
because ACPI misbehaves.
--
Jean Delvare
Hello all,
I got the DSDT from chuck and it seems there is nothing interesting - no
declaration of PCI_config for the registers. If someone wants to check it I can
send him the DSDT.
_TMP looks like this:
Store (\_SB.PCI0.LPC0.EC0.RTMP, Local0)
Store ("Current temp is: ", Debug)
Store (Local0, Debug)
Store (Local0, \_SB.CM25)
Return (Add (0x0AAC, Multiply (Local0, 0x0A)))
This looks quite OK LPC0.EC0 is embedded controller IO RAM at 0x62. Nothing
special. I guess some SMM interrupt is reading the the PCI regs and sends it to EC.
Chuck, please can you try to use your script which reads the temps from acpi
once a second and in other console run following command: (as root)
watch -d -n 1 lspci -xxx -s 18.3
This will list the pci registers every second and marks the diff. You should see
changes at 0xe6 which is your temperature. However if you see 0xe4 changing and
the k8temp driver is NOT loaded - it means something else is doing that.
If you spot the 0xe4 changes, please stop your script and check if it is still
changing.
Maybe you will not be able to see any changes at all - then the SMM is doing
reads only. Also you did not say how many cores, or places temps you see using
the k8temp driver. You have dual core with two possible places?
Thanks
Rudolf
> You could blacklist the ACPI "thermal" module instead. If you're
> interested in monitoring your CPU temperature, k8temp is IMHO more
> convenient to use than ACPI, as it interfaces properly with libsensors
> and all hardware monitoring user interfaces.
That would be somewhat dangerous because ACPI thermal does more than
just displaying the temperature. Especially laptops often need it.
-Andi
Rudolf Marek wrote:
> Hello all,
>
> I got the DSDT from chuck and it seems there is nothing interesting - no
> declaration of PCI_config for the registers. If someone wants to check it I can
> send him the DSDT.
>
> _TMP looks like this:
>
> Store (\_SB.PCI0.LPC0.EC0.RTMP, Local0)
> Store ("Current temp is: ", Debug)
>
> Store (Local0, Debug)
>
> Store (Local0, \_SB.CM25)
>
> Return (Add (0x0AAC, Multiply (Local0, 0x0A)))
>
> This looks quite OK LPC0.EC0 is embedded controller IO RAM at 0x62. Nothing
> special. I guess some SMM interrupt is reading the the PCI regs and sends it to EC.
I blacklisted the k8temp driver (and the out-of-tree k8_edac driver
in Fedora) and the temps were still volatile, so that's not causing
it. Since then I've upgraded the system BIOS from F.06 to F.27 and
the problems _may_ have gone away. My own custom 2.6.19 kernel has
never been a problem, so I'm thinking it's one of these drivers
loaded by Fedora that I never even compile:
i2c_core
i2c_ec
i2c_piix4
asus_acpi (on a Compaq???)
sbs
On Sun, Feb 18, 2007 at 06:38:05PM +0100, Jean Delvare wrote:
> ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI
> doesn't conflict with only k8temp, but with virtually all hardware
> monitoring drivers, all I2C/SMBus drivers, and probably other types of
> drivers too. We just can't restrict or blacklist all these drivers
> because ACPI misbehaves.
No, the simple fact of the matter is that if you're running on an ACPI
platform you need to change some of your assumptions. ACPI owns the
hardware. The OS doesn't. To an extent this has always been true on
laptops and servers /anyway/ - the BIOS is free to have a wide variety
of SMM insanity that invalidates basic assumptions like "If I hold this
lock, nothing can interrupt me between this write and this read". That's
simply not true.
So this isn't about fixing ACPI. It's about trying to find a mechanism
that allows ACPI and raw hardware drivers to coexist, which is made
somewhat harder by it not being a situation that the platform designers
have considered in the slightest. The suggested low-level driver for
io-port arbitration would certainly be a step forward in making this
work better.
--
Matthew Garrett | [email protected]
On 2/20/07, Matthew Garrett <[email protected]> wrote:
> On Sun, Feb 18, 2007 at 06:38:05PM +0100, Jean Delvare wrote:
>
> > ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI
> > doesn't conflict with only k8temp, but with virtually all hardware
> > monitoring drivers, all I2C/SMBus drivers, and probably other types of
> > drivers too. We just can't restrict or blacklist all these drivers
> > because ACPI misbehaves.
>
> No, the simple fact of the matter is that if you're running on an ACPI
> platform you need to change some of your assumptions. ACPI owns the
> hardware. The OS doesn't. To an extent this has always been true on
> laptops and servers /anyway/ - the BIOS is free to have a wide variety
> of SMM insanity that invalidates basic assumptions like "If I hold this
> lock, nothing can interrupt me between this write and this read". That's
> simply not true.
>
> So this isn't about fixing ACPI. It's about trying to find a mechanism
> that allows ACPI and raw hardware drivers to coexist, which is made
> somewhat harder by it not being a situation that the platform designers
> have considered in the slightest.
Motherboard vendors usually provide tools for $(TheOtherOS) that can
read from all thermal / fan / voltage / whatever sensors, so I guess
it's possible to make the ACPI driver and the "raw" one play nice with
each other[1].
Luca
[1] Unless their solution is "poke at the hardware and hope that ACPI
doesn't blow up", that is.
On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
> i2c_core
> i2c_ec
> i2c_piix4
> asus_acpi (on a Compaq???)
> sbs
Something is pulling in asus_acpi as a dependancy. I've never
figured out what the cause is. For a long time I was thinking
that we had an explicit modprobe for it in an initscript, but
grepping for it in /etc turns up zip.
Dave
--
http://www.codemonkey.org.uk
Hi Chuck,
On Tue, 20 Feb 2007 10:08:26 -0500, Chuck Ebbert wrote:
> I blacklisted the k8temp driver (and the out-of-tree k8_edac driver
> in Fedora) and the temps were still volatile, so that's not causing
> it. Since then I've upgraded the system BIOS from F.06 to F.27 and
> the problems _may_ have gone away. My own custom 2.6.19 kernel has
> never been a problem, so I'm thinking it's one of these drivers
> loaded by Fedora that I never even compile:
>
> i2c_core
i2c-core doesn't touch the hardware by itself.
> i2c_ec
Presumably autoloaded by the ACPI subsystem, I guess your ACPI
implementation includes an SMBus 2.0 controller.
> i2c_piix4
i2c-piix4 will autoload if a supported PCI device is found on your
system. Assuming this is the same physical bus as i2c_ec is exposing,
it's no good to load both i2c-piix4 and i2c_ec at the same time.
Unfortunately i2c_ec doesn't request the I/O resources it uses so this
kind of conflict cannot be avoided currently.
Can you try to load the i2c-dev driver, then run the following commands
and report the results:
$ i2cdetect -l
For each bus listed:
$ i2cdetect N
(where N is the i2c bus number)
> asus_acpi (on a Compaq???)
> sbs
This is a new battery driver used in conjunction with i2c_ec. I guess
you have a smart battery in your laptop which is accessed through
the SMBus. I found that this driver bypasses the i2c-core locking,
which is really bad. I reported it one week ago:
http://marc.theaimsgroup.com/?l=linux-acpi&m=117160531631100&w=2
(for some reason my original post wasn't archived)
My patch wasn't applied, but the problems you describe could well be
caused by this locking issue. So I suggest that you unload the sbs
driver and see if things get better. If they do, you could try to apply
my patch and load sbs again, and see if it fixes it.
--
Jean Delvare
Hi Luca,
On Tue, 20 Feb 2007 16:33:56 +0100, Luca Tettamanti wrote:
> Motherboard vendors usually provide tools for $(TheOtherOS) that can
> read from all thermal / fan / voltage / whatever sensors, so I guess
> it's possible to make the ACPI driver and the "raw" one play nice with
> each other[1].
>
> Luca
> [1] Unless their solution is "poke at the hardware and hope that ACPI
> doesn't blow up", that is.
Without the sources it's hard to tell. And all these applications are
vendor-specific, so if they indeed have ways to avoid conflicting
accesses between ACPI and the rest of the system, these ways are likely
to be vendor-specific as well, and not documented.
Either way, this means we need the support from hardware vendors to
solve this concurrent access problem, and unfortunately I doubt this
happens anytime soon :(
--
Jean Delvare
Hi Matthew,
On Tue, 20 Feb 2007 15:18:13 +0000, Matthew Garrett wrote:
> On Sun, Feb 18, 2007 at 06:38:05PM +0100, Jean Delvare wrote:
>
> > ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI
> > doesn't conflict with only k8temp, but with virtually all hardware
> > monitoring drivers, all I2C/SMBus drivers, and probably other types of
> > drivers too. We just can't restrict or blacklist all these drivers
> > because ACPI misbehaves.
>
> No, the simple fact of the matter is that if you're running on an ACPI
> platform you need to change some of your assumptions. ACPI owns the
> hardware. The OS doesn't. To an extent this has always been true on
The Linux device driver model assumes that it owns the hardware. If
this is not true, then should we prevent any non-ACPI driver from
loading as soon as ACPI is enabled?
> laptops and servers /anyway/ - the BIOS is free to have a wide variety
> of SMM insanity that invalidates basic assumptions like "If I hold this
> lock, nothing can interrupt me between this write and this read". That's
> simply not true.
Yeah, this is correct, and just as unfortunate. It's amazingly sad that
hardware vendors as a whole are still repeating the same design
mistakes over and over again :(
> So this isn't about fixing ACPI. It's about trying to find a mechanism
> that allows ACPI and raw hardware drivers to coexist, which is made
Exactly what I said, you're only rewording it to make it sound nicer ;)
> somewhat harder by it not being a situation that the platform designers
> have considered in the slightest. The suggested low-level driver for
> io-port arbitration would certainly be a step forward in making this
> work better.
I sure hope we can find a solution, by as your said yourself, nothing
is going to prevent SMM and similar oddities from messing up the drivers
assumptions.
--
Jean Delvare
Jean Delvare wrote:
> Can you try to load the i2c-dev driver, then run the following commands
> and report the results:
> $ i2cdetect -l
> For each bus listed:
> $ i2cdetect N
FWIW it's really an ATIIXP chipset, but supposedly PIIX4 compatible:
# i2cdetect -l
i2c-0 smbus SMBus PIIX4 adapter at 8400 Non-I2C SMBus adapter
# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: XX XX XX XX XX XX XX XX XX XX XX XX XX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
50: 50 51 XX XX XX XX XX XX XX XX XX XX XX XX XX XX
60: XX XX XX XX XX XX XX XX XX 69 XX XX XX XX XX XX
70: XX XX XX XX XX XX XX XX
On Tue, 20 Feb 2007 14:11:42 -0500, Dave Jones wrote:
> On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
>
> > i2c_core
> > i2c_ec
> > i2c_piix4
> > asus_acpi (on a Compaq???)
> > sbs
>
> Something is pulling in asus_acpi as a dependancy. I've never
> figured out what the cause is. For a long time I was thinking
> that we had an explicit modprobe for it in an initscript, but
> grepping for it in /etc turns up zip.
How could it be, given that asus_acpi doesn't export any symbol?
--
Jean Delvare
On Wed, 21 Feb 2007 11:03:07 -0500, Chuck Ebbert wrote:
> Jean Delvare wrote:
> > Can you try to load the i2c-dev driver, then run the following commands
> > and report the results:
> > $ i2cdetect -l
> > For each bus listed:
> > $ i2cdetect N
>
> FWIW it's really an ATIIXP chipset, but supposedly PIIX4 compatible:
>
> # i2cdetect -l
> i2c-0 smbus SMBus PIIX4 adapter at 8400 Non-I2C SMBus adapter
No i2c_ec. Maybe your distribution is loading it by default for
everyone then.
Either way, it means you can forget right away about sbs, if i2c_ec
didn't register a device, sbs cannot be used.
> # i2cdetect 0
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-0.
> I will probe address range 0x03-0x77.
> Continue? [Y/n] y
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: XX XX XX XX XX XX XX XX XX XX XX XX XX
> 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 50: 50 51 XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 60: XX XX XX XX XX XX XX XX XX 69 XX XX XX XX XX XX
> 70: XX XX XX XX XX XX XX XX
Only a couple EEPROMs and a clock chip on your SMBus, it's very
unlikely that ACPI accesses this at all. So I'd be surprised that
i2c-piix4 is causing any trouble.
This leaves asus_acpi as the only candidate? Better unload _all_ the
drivers you consider as suspects, and see if it changes anything. I
guess not.
--
Jean Delvare
On Wed, Feb 21, 2007 at 05:17:37PM +0100, Jean Delvare wrote:
> On Tue, 20 Feb 2007 14:11:42 -0500, Dave Jones wrote:
> > On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
> >
> > > i2c_core
> > > i2c_ec
> > > i2c_piix4
> > > asus_acpi (on a Compaq???)
> > > sbs
> >
> > Something is pulling in asus_acpi as a dependancy. I've never
> > figured out what the cause is. For a long time I was thinking
> > that we had an explicit modprobe for it in an initscript, but
> > grepping for it in /etc turns up zip.
>
> How could it be, given that asus_acpi doesn't export any symbol?
If I knew I'd have fixed it by now.
Dave
--
http://www.codemonkey.org.uk
On Wed, Feb 21, 2007 at 12:37:40PM -0500, Dave Jones wrote:
> On Wed, Feb 21, 2007 at 05:17:37PM +0100, Jean Delvare wrote:
> > On Tue, 20 Feb 2007 14:11:42 -0500, Dave Jones wrote:
> > > On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
> > >
> > > > i2c_core
> > > > i2c_ec
> > > > i2c_piix4
> > > > asus_acpi (on a Compaq???)
> > > > sbs
> > >
> > > Something is pulling in asus_acpi as a dependancy. I've never
> > > figured out what the cause is. For a long time I was thinking
> > > that we had an explicit modprobe for it in an initscript, but
> > > grepping for it in /etc turns up zip.
> >
> > How could it be, given that asus_acpi doesn't export any symbol?
>
> If I knew I'd have fixed it by now.
Ah, Fedora has this horror in its initscripts (which explains why I missed
it in my grep)..
# Initialize ACPI bits
if [ -d /proc/acpi ]; then
for module in /lib/modules/$unamer/kernel/drivers/acpi/* ; do
module=${module##*/}
module=${module%.ko}
modprobe $module >/dev/null 2>&1
done
fi
This is there because there's no clean way for userspace to know whether
to load the system specific stuff right now. Bill Nottingham pointed
out that we could add a /sys/class/dmi/modalias and appropriate MODULE_DMI
tags to the various modules like asus_acpi to make udev autoload them.
Dave
--
http://www.codemonkey.org.uk
On Wed, 21 Feb 2007 15:19:44 -0500, Dave Jones wrote:
> Ah, Fedora has this horror in its initscripts (which explains why I missed
> it in my grep)..
>
> # Initialize ACPI bits
> if [ -d /proc/acpi ]; then
> for module in /lib/modules/$unamer/kernel/drivers/acpi/* ; do
> module=${module##*/}
> module=${module%.ko}
> modprobe $module >/dev/null 2>&1
> done
> fi
Ah, this also explains why the i2c_ec and sbs drivers were loaded on
Chuck's system, although they were not needed.
> This is there because there's no clean way for userspace to know whether
> to load the system specific stuff right now. Bill Nottingham pointed
> out that we could add a /sys/class/dmi/modalias and appropriate MODULE_DMI
> tags to the various modules like asus_acpi to make udev autoload them.
Something similiar should be doable for i2c_ec, as it's only useful if a
given ACPI object is present. sbs, in turn, is only useful if i2c_ec is
loaded.
--
Jean Delvare
Jean Delvare wrote:
> On Wed, 21 Feb 2007 15:19:44 -0500, Dave Jones wrote:
>> Ah, Fedora has this horror in its initscripts (which explains why I missed
>> it in my grep)..
>>
>> # Initialize ACPI bits
>> if [ -d /proc/acpi ]; then
>> for module in /lib/modules/$unamer/kernel/drivers/acpi/* ; do
>> module=${module##*/}
>> module=${module%.ko}
>> modprobe $module >/dev/null 2>&1
>> done
>> fi
>
> Ah, this also explains why the i2c_ec and sbs drivers were loaded on
> Chuck's system, although they were not needed.
>
>> This is there because there's no clean way for userspace to know whether
>> to load the system specific stuff right now. Bill Nottingham pointed
>> out that we could add a /sys/class/dmi/modalias and appropriate MODULE_DMI
>> tags to the various modules like asus_acpi to make udev autoload them.
>
> Something similiar should be doable for i2c_ec, as it's only useful if a
> given ACPI object is present. sbs, in turn, is only useful if i2c_ec is
> loaded.
>
I'm thinking that it might be an idea to also use this idea of udev autoloading
through DMI info for the abituguru and abituguru3 driver (review please). The
both only support about 12 motherboards. For the abituguru driver, dmi info
could also be used to automatically set the module options needed on the 2
oldest uguru featuring abit motherboards. What do you think about this?
Regards,
Hans
On Fri, 23 Feb 2007 08:13:30 +0100, Hans de Goede wrote:
> I'm thinking that it might be an idea to also use this idea of udev autoloading
> through DMI info for the abituguru and abituguru3 driver (review please). The
> both only support about 12 motherboards. For the abituguru driver, dmi info
> could also be used to automatically set the module options needed on the 2
> oldest uguru featuring abit motherboards. What do you think about this?
Given that the uguru chips are hard (impossible) to detect and only a
small number of boards need it, yes, I think it's a good idea.
--
Jean Delvare
Hi!
> > Well I had an idea after looking at k8temp -- why not make it default to
> > doing only reads from the sensor? You'd only get information from whatever
> > core/sensor combination that ACPI had last used, but it would be safe.
>
> ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI
> doesn't conflict with only k8temp, but with virtually all hardware
> monitoring drivers, all I2C/SMBus drivers, and probably other types of
> drivers too. We just can't restrict or blacklist all these drivers
> because ACPI misbehaves.
Oops, sorry about that but no, that will not work.
There's piece of paper, called ACPI specification, and we are
following it.
Bug is not in our implementation.
Bug is in the ACPI specs... it does not explicitely allow you to go
out and bitbang i2c, and you do it, and you get problems.
Now, you may try to change specs to be hwmon-friendly... good luck.
But currently hw manufacturers follow ACPI specs, so we have to follow
it, too; bad luck for hwmon. BIOS hiding smbus from you is good hint
you are doing something wrong...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html