Could the k8temp driver be interfering with ACPI?

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:

quoted

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 [off-list ref] 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 [off-list ref] writes:

quoted

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

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

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.

quoted

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:

quoted

Chuck Ebbert wrote:

quoted

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 | mjg59@srcf.ucam.org

On 2/20/07, Matthew Garrett [off-list ref] wrote:

On Sun, Feb 18, 2007 at 06:38:05PM +0100, Jean Delvare wrote:

quoted

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:

quoted

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:

quoted

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:

quoted

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.

quoted

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



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

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!

quoted

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

Hi Pavel,

On Wed, 28 Feb 2007 21:38:04 +0000, Pavel Machek wrote:

quoted

quoted

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.

I never suggested otherwise. But the Linux 2.6 device driver model is
based, in part, on the fact that each driver must request the
resources it needs before actually using them. The acpi subsystem fails
to do that, so it is, in that sense, misbehaving. The is the root cause
of the problems people are reporting these days.

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.

It really doesn't have anything to do with bit-banged I2C. It's about
SMBus master chips (most often embedded in south bridges), hardware
monitoring chips (be them SMBus-based or not), or basically any driver
which uses a resource ACPI is using as well (virtually any driver
accessing a Super-IO/LPC device is affected, for example.)

Secondly, your logic is somewhat broken. Just because one specification
doesn't explicitely allow me to do something, I must stop doing it?
There must be two dozen different specifications modern PC hardware
supposedly conforms to. If we stop doing everything which isn't
explicitely allowed by all of them, I fear there won't be much left ;)
A better question would be IMHO: Does the ACPI specification
explicitely _prohibits_ accessing directly to some categories of
hardware?

Lastly, I wholeheartedly agree that the core problem appears to be in
the ACPI design rather than in the Linux implementation. As a matter of
fact, other operating systems are facing the same problem [1]. The
problem isn't less real, though.

Now, you may try to change specs to be hwmon-friendly... good luck.

I would like them to be driver-model-friendly, that's even a broader
challenge ;)

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

I would love things to be that easy, but unfortunately they are not.

Firstly, the first records of hidden SMBus, in September 2000, predate
ACPI. All the early boards where the SMBus was hidden did not have ACPI
code poking at it at all, so this is definitely not the reason why it
was removed. The Asus P4 series is a good example of that. Unhiding the
SMBus on these boards actually let the user take benefit of the
hardware they had paid for.

Secondly, only a few south bridges are capable of hiding the SMBus. And
an even smaller number of systems have their SMBus actually hidden by
the BIOS. A much large number of systems, especially recent ones, have
ACPI poking at the hardware monitoring chip (again, SMBus-based or
not.) So there is no correlation between hidden SMBus and ACPI poking
at the hardware monitoring chip. So, even though we are very careful
these days when adding a quirk to unhide the SMBus on a new system (we
make sure that ACPI isn't accessing it), this is not going to solve the
general problem.

I would be happy to prevent SMBus and/or hardware monitoring drivers
from being loaded on ACPI-based system if we had a way to know which
systems do have ACPI code accessing these chips and which do not, and if
ACPI was offering a level of functionality comparable to what
individual hardware monitoring drivers offer. Unfortunately:

1* As far as I know, we currently have no way to know if the ACPI code
plans to ever access the hardware monitoring chip. If the acpi
subsystem could export this information somehow, it would help a lot.
But I'm not familiar with ACPI, so I don't know if this is feasable or
not. We just can't prevent the SMBus and hardware monitoring drivers
drivers from being loaded as soon as ACPI is enabled. This would
prevent a majority of users from using them, while they work fine for
most of them.

2* The hardware monitoring features offered by ACPI today are one level
of magnitude weaker than what lm_sensors was already offering back in
1999. The monitoring chips can do much but unfortunately ACPI only
exposes a very small subset of the chip features. ACPI doesn't handle
voltage monitoring at all. It usually reports no more than one fan, and
in my experience, more often than not, the speed is reported as a
boolean (spinning or not), when lm_sensors gives you the exact speed of
all your fans. ACPI thermal zones are not so bad, but the interface to
control them is ugly, and lm_sensors usually gives more details. And
more importantly, on almost all desktop and server motherboards, ACPI
does _not_ provide any hardware monitoring feature. So we really can't
go tell our users: give up the individual hardware monitoring drivers
and lm_sensors on all ACPI-enabled systems and use whatever ACPI offers
instead. This would be a major functionality loss for a vast majority
of users.

What do you propose?

[1] http://www.microsoft.com/whdc/system/pnppwr/powermgmt/BIOSAML.mspx

-- 
Jean Delvare

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

On Thu, Mar 01, 2007 at 03:26:55PM +0100, Jean Delvare wrote:

 > Firstly, the first records of hidden SMBus, in September 2000, predate
 > ACPI.

The earliest ACPI spec I have handy is 1.0b, which came out in Feb 2 1999
so this isn't true. The all knowing (and always accurate :) wikipedia
claims it was first released in 1996, though I believe that all the pre 1.0b
machines were using acpi implementations before the standard was finalised.

I certainly remember seeing ACPI capable machines circa 1997/1998.

		Dave

-- 
http://www.codemonkey.org.uk

On Thu, 1 Mar 2007 12:48:06 -0500, Dave Jones wrote:

On Thu, Mar 01, 2007 at 03:26:55PM +0100, Jean Delvare wrote:

 > Firstly, the first records of hidden SMBus, in September 2000, predate
 > ACPI.

The earliest ACPI spec I have handy is 1.0b, which came out in Feb 2 1999
so this isn't true. The all knowing (and always accurate :) wikipedia
claims it was first released in 1996, though I believe that all the pre 1.0b
machines were using acpi implementations before the standard was finalised.

I certainly remember seeing ACPI capable machines circa 1997/1998.

Yeah, and these early ACPI implementations were so good that we have an
option to blacklist them.
arch/i386/defconfig:CONFIG_ACPI_BLACKLIST_YEAR=2001

My point (which you didn't quote) was that there is no correlation
between the SMBus being hidden and ACPI accessing the hardware
monitoring chip, contrary to what Pavel was suggesting.

-- 
Jean Delvare

Hi!

quoted

 > Firstly, the first records of hidden SMBus, in September 2000, predate
 > ACPI.

The earliest ACPI spec I have handy is 1.0b, which came out in Feb 2 1999
so this isn't true. The all knowing (and always accurate :) wikipedia
claims it was first released in 1996, though I believe that all the pre 1.0b
machines were using acpi implementations before the standard was finalised.

I certainly remember seeing ACPI capable machines circa 1997/1998.

Yeah, and these early ACPI implementations were so good that we have an
option to blacklist them.
arch/i386/defconfig:CONFIG_ACPI_BLACKLIST_YEAR=2001

My point (which you didn't quote) was that there is no correlation
between the SMBus being hidden and ACPI accessing the hardware
monitoring chip, contrary to what Pavel was suggesting.

It may not be correlated with ACPI, but BIOS authors clearly want to
keep you away from their SMBus controllers....
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi!

quoted

quoted

quoted

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.

I never suggested otherwise. But the Linux 2.6 device driver model is
based, in part, on the fact that each driver must request the
resources it needs before actually using them. The acpi subsystem fails
to do that, so it is, in that sense, misbehaving. The is the root cause
of the problems people are reporting these days.

Ok. You are right that ACPI is an ugly piece of mess. But I'm pretty
sure that 90%+ of ACPI notebook implementations *will* want to talk to
their monitoring chips... for temperature readings.

So even if we fixed ACPI to reserve the ports, you'd be still unhappy;
lm-sensors would break at least on all the notebooks.

quoted

Now, you may try to change specs to be hwmon-friendly... good luck.

I would like them to be driver-model-friendly, that's even a broader
challenge ;)

:-).

quoted

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

I would love things to be that easy, but unfortunately they are not.

Firstly, the first records of hidden SMBus, in September 2000, predate
ACPI. All the early boards where the SMBus was hidden did not have ACPI
code poking at it at all, so this is definitely not the reason why it
was removed. The Asus P4 series is a good example of that. Unhiding the
SMBus on these boards actually let the user take benefit of the
hardware they had paid for.

...against wishes of the manufacturers. Which sometimes know what they
are doing. (Sometimes not :-).

I would be happy to prevent SMBus and/or hardware monitoring drivers
from being loaded on ACPI-based system if we had a way to know which
systems do have ACPI code accessing these chips and which do not, and if
ACPI was offering a level of functionality comparable to what
individual hardware monitoring drivers offer. Unfortunately:

Well, I'm afraid you should assume all recent notebooks touch sensors
from ACPI.

1* As far as I know, we currently have no way to know if the ACPI code
plans to ever access the hardware monitoring chip. If the acpi
subsystem could export this information somehow, it would help a lot.
But I'm not familiar with ACPI, so I don't know if this is feasable or
not. We just can't prevent the SMBus and hardware monitoring drivers
drivers from being loaded as soon as ACPI is enabled. This would
prevent a majority of users from using them, while they work fine for
most of them.

What about whitelist? DMI-based? That's only way to do it, I'm afraid.

2* The hardware monitoring features offered by ACPI today are one level
of magnitude weaker than what lm_sensors was already offering back in
1999. The monitoring chips can do much but unfortunately ACPI only
exposes a very small subset of the chip features. ACPI doesn't
handle

Yes, I know ACPI sucks at hardware monitoring. Unfortunately, we can't
go without ACPI.

voltage monitoring at all. It usually reports no more than one fan, and
in my experience, more often than not, the speed is reported as a
boolean (spinning or not), when lm_sensors gives you the exact speed of
all your fans. ACPI thermal zones are not so bad, but the interface to
control them is ugly, and lm_sensors usually gives more details. And

Fix the interface? ;-). Actually that move may be underway as we are
moving out of /proc.

What do you propose?

Whitelist seems like a way to go :(.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Fri, Mar 02, 2007 at 12:40:23PM +0100, Pavel Machek wrote:

Whitelist seems like a way to go :(.

The DSDT code clearly can't touch the hardware itself - hardware access 
is carried out by the kernel. If we can identify cases where ACPI reads 
and writes would touch resources claimed by other drivers, that would be 
a good starting point for working out what's going on.

Of course, this ignores the case where the DSDT just traps into SMM 
code. That one is clearly unsolvable.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

On Fri, 2 Mar 2007 12:31:58 +0100, Pavel Machek wrote:

quoted

My point (which you didn't quote) was that there is no correlation
between the SMBus being hidden and ACPI accessing the hardware
monitoring chip, contrary to what Pavel was suggesting.

It may not be correlated with ACPI, but BIOS authors clearly want to
keep you away from their SMBus controllers....

drivers/pci/quirks.c is full of things we do against the BIOS authors
intent. You don't plan to remove them all, do you?

(And as a side note, this is really the board's owner SMBus controller.
The hardware doesn't belong to the BIOS author.)

-- 
Jean Delvare

On Fri, 02 Mar 2007, Jean Delvare wrote:

(And as a side note, this is really the board's owner SMBus controller.
The hardware doesn't belong to the BIOS author.)

Especially when they won't do their job right, and won't fix it later
either...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

On Fri 2007-03-02 14:37:20, Jean Delvare wrote:

On Fri, 2 Mar 2007 12:31:58 +0100, Pavel Machek wrote:

quoted

quoted

My point (which you didn't quote) was that there is no correlation
between the SMBus being hidden and ACPI accessing the hardware
monitoring chip, contrary to what Pavel was suggesting.

It may not be correlated with ACPI, but BIOS authors clearly want to
keep you away from their SMBus controllers....

drivers/pci/quirks.c is full of things we do against the BIOS authors
intent. You don't plan to remove them all, do you?

Notice how quirks.c is careful to name machines where given quirk is
used.

If you do whitelist "it is okay to do sensors accesses on this board",
that is okay with me. But having quirk "on all future Intel chipsets,
do foo" would be stupid. Enabling sensors blindly is pretty similar.

(And as a side note, this is really the board's owner SMBus controller.
The hardware doesn't belong to the BIOS author.)

True.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Fri 2007-03-02 11:47:47, Matthew Garrett wrote:

On Fri, Mar 02, 2007 at 12:40:23PM +0100, Pavel Machek wrote:

quoted

Whitelist seems like a way to go :(.

The DSDT code clearly can't touch the hardware itself - hardware access 
is carried out by the kernel. If we can identify cases where ACPI reads 
and writes would touch resources claimed by other drivers, that would be 
a good starting point for working out what's going on.

Of course, this ignores the case where the DSDT just traps into SMM 
code. That one is clearly unsolvable.

We can't solve SMM stuff. (Whitelist needed :-).

Actually for the acpi stuff... we might wrap ACPI interpretter with a
semaphore that needs to be taken before starting any AML code. Then
just make sure sensors take same semaphore?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi Pavel,

On Fri, 2 Mar 2007 12:40:23 +0100, Pavel Machek wrote:

Ok. You are right that ACPI is an ugly piece of mess. But I'm pretty
sure that 90%+ of ACPI notebook implementations *will* want to talk to
their monitoring chips... for temperature readings.

So even if we fixed ACPI to reserve the ports, you'd be still unhappy;
lm-sensors would break at least on all the notebooks.

That's a secondary problem. The primary issue is the concurrent access
to resources, which cause lots of trouble which are hard to investigate.
If ACPI reserves the ports, then the SMBus or hardware monitoring
drivers (or any other conflicting driver) will cleanly fail to load,
which would be a move in the right direction. Ideally we would be able
to synchronize the accesses between ACPI and the other drivers, but if
we can't, I'd already be _very happy_ to just prevent conflicting
drivers from being loaded at the same time.

So, can ACPI actually reserve the ports it accesses?

quoted

I would be happy to prevent SMBus and/or hardware monitoring drivers
from being loaded on ACPI-based system if we had a way to know which
systems do have ACPI code accessing these chips and which do not, and if
ACPI was offering a level of functionality comparable to what
individual hardware monitoring drivers offer. Unfortunately:

Well, I'm afraid you should assume all recent notebooks touch sensors
from ACPI.

Correct, and on most notebooks, traditional hardware monitoring
drivers do not work anyway. Or I should say, used to not work. The
recent CPUs have embedded sensors which can be read using Rudolf
Marek's k8temp and coretemp drivers, this works on laptops as well.
Chances are good that future laptops will not include a separate
temperature sensor but will read the temperature from the CPU directly,
which will cause conflicts with our drivers.

Now the problem is that we can't blacklist SMBus and hardware
monitoring drivers on all laptops by default. There may be other
devices on the SMBus which the user can legitimately want to access,
such as EEPROMs or RTCs.

quoted

1* As far as I know, we currently have no way to know if the ACPI code
plans to ever access the hardware monitoring chip. If the acpi
subsystem could export this information somehow, it would help a lot.
But I'm not familiar with ACPI, so I don't know if this is feasable or
not. We just can't prevent the SMBus and hardware monitoring drivers
drivers from being loaded as soon as ACPI is enabled. This would
prevent a majority of users from using them, while they work fine for
most of them.

What about whitelist? DMI-based? That's only way to do it, I'm afraid.

What kind of whitelist do you have in mind? We can't realistically
maintain an ever-growing whitelist of hundreds of entries in the
kernel. We could block all laptops by default and maintain a white list
only for them, and a black list for other systems, the would probably
limit the maintenance work, maybe not to an acceptable level though.

Anyway I would definitely prefer the resource conflicts approach, as it
wouldn't need maintenance at all.

quoted

2* The hardware monitoring features offered by ACPI today are one level
of magnitude weaker than what lm_sensors was already offering back in
1999. The monitoring chips can do much but unfortunately ACPI only
exposes a very small subset of the chip features. ACPI doesn't
handle

Yes, I know ACPI sucks at hardware monitoring. Unfortunately, we can't
go without ACPI.

Agreed.

quoted

voltage monitoring at all. It usually reports no more than one fan, and
in my experience, more often than not, the speed is reported as a
boolean (spinning or not), when lm_sensors gives you the exact speed of
all your fans. ACPI thermal zones are not so bad, but the interface to
control them is ugly, and lm_sensors usually gives more details. And

Fix the interface? ;-). Actually that move may be underway as we are
moving out of /proc.

Great, looking forward.

-- 
Jean Delvare

Hi Matthew,

On Fri, 2 Mar 2007 11:47:47 +0000, Matthew Garrett wrote:

The DSDT code clearly can't touch the hardware itself - hardware access 
is carried out by the kernel. If we can identify cases where ACPI reads 
and writes would touch resources claimed by other drivers, that would be 
a good starting point for working out what's going on.

I'm not familiar with APCI at all so I didn't know, but what you write
here brings some hope. Would it be possible to parse all the DSDT code
at boot time and deduce all the ports which ACPI would need to request
to be safe? Or do we have to wait for the accesses to actually happen?

Of course, this ignores the case where the DSDT just traps into SMM 
code. That one is clearly unsolvable.

Yeah, SMM is an even more complex problem :(

Do we know in advance when we are going to SMM mode and back? If we do,
I'd be happy with a mutex every interested driver could use to protect
relevant parts of its code. SMBus master drivers for example could
request that mutex during SMBus transactions. Of course we don't know
if SMM will actually touch the SMBus, but better safe than sorry I
guess. And SMM calls aren't happening so frequently, are they?

Thanks,
-- 
Jean Delvare

On Fri, Mar 02, 2007 at 03:10:55PM +0100, Jean Delvare wrote:

I'm not familiar with APCI at all so I didn't know, but what you write
here brings some hope. Would it be possible to parse all the DSDT code
at boot time and deduce all the ports which ACPI would need to request
to be safe? Or do we have to wait for the accesses to actually happen?

In theory I /think/ so, but it would probably end up being an 
overestimate of the coverage actually needed. Trapping at runtime is 
arguably more elegant?

Do we know in advance when we are going to SMM mode and back? If we do,
I'd be happy with a mutex every interested driver could use to protect
relevant parts of its code. SMBus master drivers for example could
request that mutex during SMBus transactions. Of course we don't know
if SMM will actually touch the SMBus, but better safe than sorry I
guess. And SMM calls aren't happening so frequently, are they?

My understanding is that pretty much arbitrary hardware access can cause 
SMM transitions without OS notification, though this is getting outside 
the areas I know about.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Hi!

quoted

The DSDT code clearly can't touch the hardware itself - hardware access 
is carried out by the kernel. If we can identify cases where ACPI reads 
and writes would touch resources claimed by other drivers, that would be 
a good starting point for working out what's going on.

I'm not familiar with APCI at all so I didn't know, but what you write
here brings some hope. Would it be possible to parse all the DSDT code
at boot time and deduce all the ports which ACPI would need to request
to be safe?

I'm afraid it is about as hard as disassembling SMM BIOS to figure out
what it accesses.

quoted

Of course, this ignores the case where the DSDT just traps into SMM 
code. That one is clearly unsolvable.

Yeah, SMM is an even more complex problem :(

Do we know in advance when we are going to SMM mode and back? If we

SMM is often invoked by timer, AC unplug, etc.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi!

quoted

Ok. You are right that ACPI is an ugly piece of mess. But I'm pretty
sure that 90%+ of ACPI notebook implementations *will* want to talk to
their monitoring chips... for temperature readings.

So even if we fixed ACPI to reserve the ports, you'd be still unhappy;
lm-sensors would break at least on all the notebooks.

That's a secondary problem. The primary issue is the concurrent access
to resources, which cause lots of trouble which are hard to investigate.
If ACPI reserves the ports, then the SMBus or hardware monitoring
drivers (or any other conflicting driver) will cleanly fail to load,
which would be a move in the right direction. Ideally we would be able
to synchronize the accesses between ACPI and the other drivers, but if
we can't, I'd already be _very happy_ to just prevent conflicting
drivers from being loaded at the same time.

So, can ACPI actually reserve the ports it accesses?

No idea, talk to Len Brown (or start reading the code) :-(. I don't
think it will be easy.

quoted

quoted

1* As far as I know, we currently have no way to know if the ACPI code
plans to ever access the hardware monitoring chip. If the acpi
subsystem could export this information somehow, it would help a lot.
But I'm not familiar with ACPI, so I don't know if this is feasable or
not. We just can't prevent the SMBus and hardware monitoring drivers
drivers from being loaded as soon as ACPI is enabled. This would
prevent a majority of users from using them, while they work fine for
most of them.

What about whitelist? DMI-based? That's only way to do it, I'm afraid.

What kind of whitelist do you have in mind? We can't realistically
maintain an ever-growing whitelist of hundreds of entries in the
kernel. We could block all laptops by default and maintain a white list
only for them, and a black list for other systems, the would probably
limit the maintenance work, maybe not to an acceptable level though.

I'm afraid something like that is way to go.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

How about this? It's informational only, but ought to result in 
complaints whenever ACPI tries to touch something that other hardware 
has reserved. We can't fail these accesses, but in theory we could 
consider some sort of locking layer that made it possible to interact 
anyway. I haven't even checked if this builds, but I think the concept 
is reasonable.

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index d870fb2..088abd1 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c

@@ -35,6 +35,7 @@
 #include <linux/kmod.h>
 #include <linux/delay.h>
 #include <linux/workqueue.h>
+#include <linux/ioport.h>
 #include <linux/nmi.h>
 #include <acpi/acpi.h>
 #include <asm/io.h>

@@ -338,6 +339,10 @@ acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width)
 {
 	u32 dummy;
 
+	if (__check_region(&ioport_resource, port, width/8))
+		printk (KERN_INFO "ACPI read from allocated ioport %lx\n", 
+			port);
+
 	if (!value)
 		value = &dummy;
 

@@ -362,6 +367,10 @@ EXPORT_SYMBOL(acpi_os_read_port);
 
 acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width)
 {
+	if (__check_region(&ioport_resource, port, width/8))
+		printk (KERN_INFO "ACPI write to allocated ioport %lx\n", 
+			port);
+
 	switch (width) {
 	case 8:
 		outb(value, port);

@@ -387,6 +396,10 @@ acpi_os_read_memory(acpi_physical_address phys_addr, u32 * value, u32 width)
 	u32 dummy;
 	void __iomem *virt_addr;
 
+	if (__check_region(&iomem_resource, phys_addr, width/8))
+		printk (KERN_INFO "ACPI read from allocated iomem %lx\n", 
+			phys_addr);
+
 	virt_addr = ioremap(phys_addr, width);
 	if (!value)
 		value = &dummy;

@@ -415,6 +428,10 @@ acpi_os_write_memory(acpi_physical_address phys_addr, u32 value, u32 width)
 {
 	void __iomem *virt_addr;
 
+	if (__check_region(&iomem_resource, phys_addr, width/8))
+		printk (KERN_INFO "ACPI write to allocated iomem %lx\n", 
+			phys_addr);
+
 	virt_addr = ioremap(phys_addr, width);
 
 	switch (width) {

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Hi Pavel,

On Fri, 2 Mar 2007 14:58:10 +0100, Pavel Machek wrote:

Actually for the acpi stuff... we might wrap ACPI interpretter with a
semaphore that needs to be taken before starting any AML code. Then
just make sure sensors take same semaphore?

I like the idea, it should work as long as we are guaranteed that all
the hwmon device accesses happen in the AML code? I'm not familiar with
ACPI, so you tell me.

In practice it's rather the SMBus drivers which will need to take the
lock, as this is what the AML code will access (for SMBus-based
hardware monitoring drivers.) For non-SMBus based hardware monitoring
drivers, indeed the driver itself should take it. We will have to pay
attention to deadlocks on systems with multiple hardware monitoring
chips and/or SMBus channels.

Can you please provide a patch implementing your proposal in acpi? Then
I could implement the i2c/hwmon part on some selected drivers and start
testing real world scenarii.

Thanks,
-- 
Jean Delvare

On Fri, 2 Mar 2007 14:18:40 +0000, Matthew Garrett wrote:

On Fri, Mar 02, 2007 at 03:10:55PM +0100, Jean Delvare wrote:

quoted

I'm not familiar with APCI at all so I didn't know, but what you write
here brings some hope. Would it be possible to parse all the DSDT code
at boot time and deduce all the ports which ACPI would need to request
to be safe? Or do we have to wait for the accesses to actually happen?

In theory I /think/ so, but it would probably end up being an 
overestimate of the coverage actually needed. Trapping at runtime is 
arguably more elegant?

It might be more elegant but it won't work. We don't want to prevent
ACPI from accessing these I/O ports. If we need to choose only one
"driver" accessing the I/O port, it must be acpi, at leat for now,
despite the fact that acpi provides very weak hardware monitoring
capabilities compared to the specific drivers.

Why would we end up with an overestimation if we check the I/O ports at
boot time? Do you have concrete cases in mind?

Thanks,
-- 
Jean Delvare

On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote:

On Fri, 2 Mar 2007 14:18:40 +0000, Matthew Garrett wrote:

quoted

In theory I /think/ so, but it would probably end up being an 
overestimate of the coverage actually needed. Trapping at runtime is 
arguably more elegant?

It might be more elegant but it won't work. We don't want to prevent
ACPI from accessing these I/O ports. If we need to choose only one
"driver" accessing the I/O port, it must be acpi, at leat for now,
despite the fact that acpi provides very weak hardware monitoring
capabilities compared to the specific drivers.

Assuming arbitration of access, what's the problem with having two 
drivers accessing the same hardware? Do these chips generally have any 
significant internal state other than trip points and the like?

Why would we end up with an overestimation if we check the I/O ports at
boot time? Do you have concrete cases in mind?

ACPI will often describe large operation regions, but won't necessarily 
touch all of them. Effectively, every codepath would have to be walked 
through at boot time and checked for io access.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

On Fri, 02 Mar 2007, Jean Delvare wrote:

I like the idea, it should work as long as we are guaranteed that all
the hwmon device accesses happen in the AML code? I'm not familiar with
ACPI, so you tell me.

Some fubar machines do it in SMM mode, and the AML code just reads memory
regions that were updated by the SMBIOS.  Or, if one is lucky, the AML
triggers the SMI (ThinkPads do this, for example -- but I am not sure that's
the only way a ThinkPad will cause a SMI), so it could be made to run
protected by the lock.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Hi Matthew,

On Fri, 2 Mar 2007 14:57:09 +0000, Matthew Garrett wrote:

How about this? It's informational only, but ought to result in 
complaints whenever ACPI tries to touch something that other hardware 
has reserved. We can't fail these accesses, but in theory we could 
consider some sort of locking layer that made it possible to interact 
anyway. I haven't even checked if this builds, but I think the concept 
is reasonable.

I like the patch, after adding some casts to the printf args it
compiles fine. However you print warnings each time a resource has been
reserved... without checking if it hasn't been reserved by ACPI itself!
My machine looks like this:

1000-107f : 0000:00:1f.0
  1000-1003 : ACPI PM1a_EVT_BLK
  1004-1005 : ACPI PM1a_CNT_BLK
  1008-100b : ACPI PM_TMR
  1010-1015 : ACPI CPU throttle
  1020-1020 : ACPI PM2_CNT_BLK
  1028-102b : ACPI GPE0_BLK
  102c-102f : ACPI GPE1_BLK

Given that these ports were reserved by ACPI it is perfectly legitimate
that ACPI accesses it, so we must not print a warning in this case. We
need to exclude from the test the regions those "name" starts with
"ACPI", but I'm not sure how we can do that.

Thanks,
-- 
Jean Delvare

On Fri, Mar 02, 2007 at 10:41:55PM +0100, Jean Delvare wrote:

I like the patch, after adding some casts to the printf args it
compiles fine. However you print warnings each time a resource has been
reserved... without checking if it hasn't been reserved by ACPI itself!
My machine looks like this:

Oops! I'll look into fixing that. Thanks, that's an excellent point...

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.

-----Original Message-----
From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
owner@vger.kernel.org] On Behalf Of Jean Delvare
Sent: Friday, March 02, 2007 1:05 PM
To: Matthew Garrett
Cc: Pavel Machek; Chuck Ebbert; Rudolf Marek;

linux-acpi@vger.kernel.org;

linux-kernel; lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] Could the k8temp driver be interfering with
ACPI?

On Fri, 2 Mar 2007 14:18:40 +0000, Matthew Garrett wrote:

quoted

On Fri, Mar 02, 2007 at 03:10:55PM +0100, Jean Delvare wrote:

quoted

I'm not familiar with APCI at all so I didn't know, but what you

write

quoted

quoted

here brings some hope. Would it be possible to parse all the DSDT

code

quoted

quoted

at boot time and deduce all the ports which ACPI would need to

request

quoted

quoted

to be safe? Or do we have to wait for the accesses to actually

happen?

quoted

In theory I /think/ so, but it would probably end up being an
overestimate of the coverage actually needed. Trapping at runtime is
arguably more elegant?

It might be more elegant but it won't work. We don't want to prevent
ACPI from accessing these I/O ports. If we need to choose only one
"driver" accessing the I/O port, it must be acpi, at leat for now,
despite the fact that acpi provides very weak hardware monitoring
capabilities compared to the specific drivers.

Why would we end up with an overestimation if we check the I/O ports

at

boot time? Do you have concrete cases in mind?

Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi"

in

the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, 2 Mar 2007 14:57:06 +0100, Pavel Machek wrote:

On Fri 2007-03-02 14:37:20, Jean Delvare wrote:

quoted

drivers/pci/quirks.c is full of things we do against the BIOS authors
intent. You don't plan to remove them all, do you?

Notice how quirks.c is careful to name machines where given quirk is
used.

Notice how we unhide the SMBus only on a few named machines as well.

If you do whitelist "it is okay to do sensors accesses on this board",
that is okay with me. But having quirk "on all future Intel chipsets,
do foo" would be stupid.

We don't do that, never did, and never planed to do.

                   (...) Enabling sensors blindly is pretty similar.

This is the view of someone obviously not interested in sensors. Go
tell that to all the lm-sensors users and they'll reply: "Disabling
sensors blindly would be stupid." Please realize that we're not writing
hardware monitoring drivers just for the fun of conflicting with ACPI
on some machines. We're writing them because users are asking for these
features.

-- 
Jean Delvare

Hi Matthew,

On Fri, 2 Mar 2007 21:12:51 +0000, Matthew Garrett wrote:

On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote:

quoted

It might be more elegant but it won't work. We don't want to prevent
ACPI from accessing these I/O ports. If we need to choose only one
"driver" accessing the I/O port, it must be acpi, at leat for now,
despite the fact that acpi provides very weak hardware monitoring
capabilities compared to the specific drivers.

Assuming arbitration of access, what's the problem with having two 
drivers accessing the same hardware? Do these chips generally have any 
significant internal state other than trip points and the like?

The "assuming arbitration of access" is the key part of your
sentence ;) The problem is that currently no arbitration is done. If it
was done, then state would probably not be a problem. Most hardware
monitoring drivers don't assume any state is preserved between
accesses, and those which do can easily be changed not to. The ACPI
side is another story though, I guess we can't assume anything about
the AML code's assumption on states, as it differs from one machine to
the next. But we can try to be cooperative and restore the sensible
registers (e.g. bank selector) in the same state we found them.

Anyway, just because we can't get things right on 100% of the machines
is no reason not to try anything at all. The current situation is bad,
any improvement would be welcome.

quoted

Why would we end up with an overestimation if we check the I/O ports at
boot time? Do you have concrete cases in mind?

ACPI will often describe large operation regions, but won't necessarily 
touch all of them. Effectively, every codepath would have to be walked 
through at boot time and checked for io access.

Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?

If we can't do that, the overestimation approach might still work. I
wonder if it would cause problems in practice. If it does, we're back
to Pavel's AML lock.

-- 
Jean Delvare

Hi Jean,

Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?

Here's a random idea -- what do you think of it?

ACPI already allocates some I/O ranges, which was a surprise to me:

My machine looks like this:

1000-107f : 0000:00:1f.0
 1000-1003 : ACPI PM1a_EVT_BLK
 1004-1005 : ACPI PM1a_CNT_BLK
 1008-100b : ACPI PM_TMR
 1010-1015 : ACPI CPU throttle
 1020-1020 : ACPI PM2_CNT_BLK
 1028-102b : ACPI GPE0_BLK
 102c-102f : ACPI GPE1_BLK

For I/O and memory that ACPI accesses and has not reserved, the AML
interpreter could allocate at run-time.

I'm not sure how to implement exactly. For example, it would be bad to
have a /proc/ioports that had a lot of single ports allocated, for
example:
1000-107f : 0000:00:1f.0
1000-1000 : ACPI PM1a_EVT_BLK
1001-1001 : ACPI PM1a_EVT_BLK
1002-1002 : ACPI PM1a_EVT_BLK
1003-1003 : ACPI PM1a_EVT_BLK

Thus the AML interpreter would need to have some reasonable
intelligence when allocating regions. Conflict resolution would also
be more difficult, e.g. if a hwmon driver was loaded first and then
acpi as a module, ACPI could not allocate the region. Maybe run-time
allocating won't work.

And then, how would ACPI release a region after it has used it? The
easiest method would be to never release anything used even once.

Thoughts?

David

On Sat, Mar 03, 2007 at 08:47:21AM -0700, David Hubbard wrote:

For I/O and memory that ACPI accesses and has not reserved, the AML
interpreter could allocate at run-time.

Not ideal. ACPI's already fiddling with ranges that have been reserved 
by other drivers.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Hello all,

I was already thinking about some very general port forwarder,
(http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018788.html)

But I'm not able to find out how to do that painlessly. Even don't know if to
use the classes or even some new "bus" in driver model :/ some suggestions on
this would be very welcome.

Let start with some very naive 1:1 solution which would try out if we can handle
"transactions" (typically write to one port read from other operation)
and preserve the "banks". As was already written some virtualization in driver
would be required, but it may be done because we know how the hardware is
supposed to work.

It seems that most simple solution to try out would be to add a possible
callback structure into a IORESOURCE structure. Please don't blame me for this,
it is just for testing purpose, we must think of better place, but as I said I
dont know where or how :/

Here is some concept:

When the request_region fails, ACPI could call request_region_acpi
which will return a pointer to some structure with defined callbacks
like do->outb do->inb. ACPI will first chekc if the pointer is not NULL ;)

This callback would end up in let say other linux driver.

For the typical hwmon chip things works similar way as CMOS access. Port is
written 0x295 with register address and port 0x296 is read or written.

Therefore:
void outb(port, val) {

if (port == 0x295) {
	reg_pointer=val;
} else if (port == 0x296) {
	// ACPI wants to write to the chip
	if (reg_pointer == BANKREG)
		reg_bank=val;
	}
	do_chip_write(reg_pointer, reg_bank_val);
}
}

void inb(port, val) {

if (port == 0x296) {
	

	return do_read_chip(reg_pointer, reg_bank);
}

}

The code above shows how the IO access could be synchronized with the ACPI, to
make everyone happy again. The driver could snoop what ACPI tries to change, so
it for example force reloading the cached values...

The second device which might be a challange is the SMBus controller. The
virtualization could be done same/similar way.

For PCI memory regions, the situation is same as for IO, however for the
pci_config space I cannot see any straight solution.


Regards
Rudolf

Hi David,

On Sat, 3 Mar 2007 08:47:21 -0700, David Hubbard wrote:

quoted

Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?

Here's a random idea -- what do you think of it?

ACPI already allocates some I/O ranges, which was a surprise to me:

quoted

My machine looks like this:

1000-107f : 0000:00:1f.0
 1000-1003 : ACPI PM1a_EVT_BLK
 1004-1005 : ACPI PM1a_CNT_BLK
 1008-100b : ACPI PM_TMR
 1010-1015 : ACPI CPU throttle
 1020-1020 : ACPI PM2_CNT_BLK
 1028-102b : ACPI GPE0_BLK
 102c-102f : ACPI GPE1_BLK

For I/O and memory that ACPI accesses and has not reserved, the AML
interpreter could allocate at run-time.

I'm not sure how to implement exactly. For example, it would be bad to
have a /proc/ioports that had a lot of single ports allocated, for
example:
1000-107f : 0000:00:1f.0
 1000-1000 : ACPI PM1a_EVT_BLK
 1001-1001 : ACPI PM1a_EVT_BLK
 1002-1002 : ACPI PM1a_EVT_BLK
 1003-1003 : ACPI PM1a_EVT_BLK

Thus the AML interpreter would need to have some reasonable
intelligence when allocating regions. Conflict resolution would also
be more difficult, e.g. if a hwmon driver was loaded first and then
acpi as a module, ACPI could not allocate the region. Maybe run-time
allocating won't work.

And then, how would ACPI release a region after it has used it? The
easiest method would be to never release anything used even once.

I've been thinking about it too, but I could convince myself quickly
that it would never work, so I didn't bother posting about it ;)

As you found out yourself, it isn't trivial to allocate the ports
dynamically. Either you'll end up with lots of 1-address ranges, or
you'll allocate more than is actually needed, or you'll need a
buddy-allocator like mechanism to merge contiguous ranges. This sounds
quite complex to get right. And very costly, too. I don't know the
exact algorithm to find out whether an I/O range is already allocated
or not, and by who, but having to do it for each port access from AML,
forever, sounds like a huge overhead.

On top of that, there is a risk that another driver already requested
the I/O range. And we do not want to prevent ACPI from accessing it!
OK, it would be cleaner that the current situation in a way, but it
could also have bad consequences as was underlined elsewhere in this
thread.

What we want is to grant access to the resources to at least ACPI (and
ACPI only if we can't do better), or if possible to both ACPI and
individual drivers but with some mechanism avoiding concurrent access
(be it a mutex or a port forwarder.)

-- 
Jean Delvare

Hello again,

I produced some code which I proposed in mail above. The patch is not for review
it is just a PoC to better show what I'm trying to do. It is a test case for my
motherboard which has W83627EHF chip and ACPI thermal method and w83627ehf
compete the device.

When no driver is loaded, acpi is doing its own raw access to device. However
when the w83627ehf driver is loaded, the ACPI access to ports (0x295/0x296) is
forwarded to the w83627ehf driver.

How it works? I added one pointer to the struct resource which will contain a
pointer to the structure with callback functions. I know this is not an ideal
solution, but for a test it works fine. Everytime ACPI wants do IO it will ask
via ____request_resource(conflict, &res) if some driver claimed the resource,
if so, it iterates the resource structure to the last entry, if the callback
structure exists it is called (and device driver context is passed too), if not,
raw hw access is performed.

The routines in EHF driver partly emulates the chip, the address of which next
acpi access will want to read or write is saved in the data->reg_pointer.

The actual access to the chip is done only when the data port of the chip is
accessed, and driver generic io function is called. Bank register writes are
faked to the data->reg_bank. All access to the chip which is done in these
routines respects the "virtual" bank register which was previously set by ACPI.
(current emulation is not 100% perfect, but this could be easily fixed)
If something was written to the chip, driver's register cache is invalidated.

This approach does not need any external locking because the actual device
access is done by one function of driver (which already locks).

As from ACPI point of view the device behaves same way as real HW, the big plus
is that the driver actually KNOWs what is ACPI trying to do to the chip. Of
course if the HW access is done in SMM some other countermeasures must be
invented like GBL lock or the "take ownership" stuff.

Maybe this forwarder may be used by other drivers, which may want to know what
is ACPI doing to hardware during suspend/resume methods...

As I wrote earlier the SMBus access could be also virtualized same way, there
will be only more virtual registers, real transaction will start when the ACPI
sets the "begin transaction" bits ;).

Maybe the pointer to driver context could be removed, and container_of could be
used instead to reach it. I will need some advise how to implement this
randevouz between ACPI and one Linux driver... Exploiting the resource structure
  is nice but pehaps not acceptable??? Some class maybe? We have only 1:1
relation...

Thanks,
Rudolf

Hi Rudolf,

On Sun, 04 Mar 2007 18:29:12 +0100, Rudolf Marek wrote:

I produced some code which I proposed in mail above. The patch is not for review
it is just a PoC to better show what I'm trying to do. It is a test case for my
motherboard which has W83627EHF chip and ACPI thermal method and w83627ehf
compete the device.

When no driver is loaded, acpi is doing its own raw access to device. However
when the w83627ehf driver is loaded, the ACPI access to ports (0x295/0x296) is
forwarded to the w83627ehf driver.

How it works? I added one pointer to the struct resource which will contain a
pointer to the structure with callback functions. I know this is not an ideal
solution, but for a test it works fine. Everytime ACPI wants do IO it will ask
via ____request_resource(conflict, &res) if some driver claimed the resource,
if so, it iterates the resource structure to the last entry, if the callback
structure exists it is called (and device driver context is passed too), if not,
raw hw access is performed.

The routines in EHF driver partly emulates the chip, the address of which next
acpi access will want to read or write is saved in the data->reg_pointer.

The actual access to the chip is done only when the data port of the chip is
accessed, and driver generic io function is called. Bank register writes are
faked to the data->reg_bank. All access to the chip which is done in these
routines respects the "virtual" bank register which was previously set by ACPI.
(current emulation is not 100% perfect, but this could be easily fixed)
If something was written to the chip, driver's register cache is invalidated.

This approach does not need any external locking because the actual device
access is done by one function of driver (which already locks).

As from ACPI point of view the device behaves same way as real HW, the big plus
is that the driver actually KNOWs what is ACPI trying to do to the chip. Of
course if the HW access is done in SMM some other countermeasures must be
invented like GBL lock or the "take ownership" stuff.

Maybe this forwarder may be used by other drivers, which may want to know what
is ACPI doing to hardware during suspend/resume methods...

As I wrote earlier the SMBus access could be also virtualized same way, there
will be only more virtual registers, real transaction will start when the ACPI
sets the "begin transaction" bits ;).

Maybe the pointer to driver context could be removed, and container_of could be
used instead to reach it. I will need some advise how to implement this
randevouz between ACPI and one Linux driver... Exploiting the resource structure
  is nice but pehaps not acceptable??? Some class maybe? We have only 1:1
relation...

I like your implementation, it's nice. Thanks for coming up with this
idea. The only change I would propose is to make the last parameter of
the read_io and write_io callback functions a device * instead of a
void *. This would let the compiler check the types and avoid improper
casts.

One bug in your code:

You want to check that conflict->res_ops->read_io exists, not write_io.

This port forwarding approach is interesting, maybe even beyond the
ACPI case we are trying to solve here. However, it has some drawbacks:

1* It requires that we modify each driver individually. It's quite a
shame that we have to update drivers all around the kernel tree with
specific code to workaround a problem which is originally located in a
single place (the ACPI subsystem.) That being said this isn't a blocker
point, if this is the only way, we'll do it. But that's a rather great
amount of work.

2* It seems to incur a signficant performance penalty.
____request_resource isn't cheap as far as I know. And in the
absence of conflict, you are even allocating and releasing the resource
on _each_ I/O operation, which certainly isn't cheap either. Again, it
is not a blocker point, after all this is a workaround for an improper
behavior of the acpi subsystem, this performance penalty is the price to
pay. But there is also a performance penalty for legitimate I/O access,
which worries me more.

3* What about concurrent accesses from ACPI itself? Unless we have a
guarantee that only one kernel thread can run AML code at a given
moment, I can imagine a conflict happening, as your code protects us
well against ACPI and driver concurrent accesses, but not against two
concurrent ACPI accesses. But I'm not familiar with ACPI - maybe we do
have this guarantee? OTOH, if this ever happens, well, it would happen
even without your code.

So for now I tend to think that the idea of a global AML lock proposed
by Pavel Machek and Bodo Eggert would be more efficient. And it
wouldn't need any driver-specific code, so it would be much more simple
to implement. The drawback being that we serialize more than we really
need to (e.g. the hardware monitoring driver will not be allowed to
access the chip when _any_ AML code is running, not just when the AML
code accesses the hardware monitoring chip, and if two drivers want to
check the AML lock, they'll exclude each other as well.) But I wonder
if this is a problem in practice. Maybe we'll have to make some
profiling on both solutions and compare.

Thanks,
-- 
Jean Delvare

Hi Jean, Rudolf,

1* It requires that we modify each driver individually. It's quite a
shame that we have to update drivers all around the kernel tree with
specific code to workaround a problem which is originally located in a
single place (the ACPI subsystem.) That being said this isn't a blocker
point, if this is the only way, we'll do it. But that's a rather great
amount of work.

These additions to drivers might help with the kernel virtualization.

2* It seems to incur a signficant performance penalty.
____request_resource isn't cheap as far as I know. And in the
absence of conflict, you are even allocating and releasing the resource
on _each_ I/O operation, which certainly isn't cheap either. Again, it
is not a blocker point, after all this is a workaround for an improper
behavior of the acpi subsystem, this performance penalty is the price to
pay. But there is also a performance penalty for legitimate I/O access,
which worries me more.

I thought Rudolf's patch allocated the resource in the driver
(w83627ehf) and ACPI contacted the driver when it could not allocate
the resource. Since ACPI never *really* wants to allocate the
resource, is there a fast-path check it could do? This would help
performance.

3* What about concurrent accesses from ACPI itself? Unless we have a
guarantee that only one kernel thread can run AML code at a given
moment, I can imagine a conflict happening, as your code protects us
well against ACPI and driver concurrent accesses, but not against two
concurrent ACPI accesses. But I'm not familiar with ACPI - maybe we do
have this guarantee? OTOH, if this ever happens, well, it would happen
even without your code.

All of ACPI uses the same "virtualized" access mechanism, so even if
two threads are poking at the bank select register in a race condition
(that would be awful code, I think) they would see the same virtual
behavior.

So for now I tend to think that the idea of a global AML lock proposed
by Pavel Machek and Bodo Eggert would be more efficient. And it
wouldn't need any driver-specific code, so it would be much more simple
to implement. The drawback being that we serialize more than we really
need to (e.g. the hardware monitoring driver will not be allowed to
access the chip when _any_ AML code is running, not just when the AML
code accesses the hardware monitoring chip, and if two drivers want to
check the AML lock, they'll exclude each other as well.) But I wonder
if this is a problem in practice. Maybe we'll have to make some
profiling on both solutions and compare.

I like the virtualized driver method (if it wasn't obvious!) but the
global AML lock works also. It will be interesting to see profiling of
both solutions.

David

Hi!

quoted

quoted

Why would we end up with an overestimation if we check the I/O ports at
boot time? Do you have concrete cases in mind?

ACPI will often describe large operation regions, but won't necessarily 
touch all of them. Effectively, every codepath would have to be walked 
through at boot time and checked for io access.

Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?

ACPI AML is probably turing-complete: I'm afraid you are trying to
solve the halting problem (-> impossible).
						Pavel

If we can't do that, the overestimation approach might still work. I
wonder if it would cause problems in practice. If it does, we're back
to Pavel's AML lock.

-- 
Jean Delvare

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

quoted

quoted

quoted

quoted

"PM" == Pavel Machek [off-list ref] writes:

PM> ACPI AML is probably turing-complete: I'm afraid you are trying to
PM> solve the halting problem (-> impossible).

If you can restrict the virtual machine which AML runs in to a limited
amount of memory/storage, you can solve halting for it in exponential
time.

Unfortunately the problem here is even harder than halting. With the
halting problem you get all inputs beforehand. For AML, the locations
it accesses could be dependent on what it reads off of the hardware.


/Benny

Hi David,

On Mon, 5 Mar 2007 13:35:20 -0800, David Hubbard wrote:

quoted

2* It seems to incur a signficant performance penalty.
____request_resource isn't cheap as far as I know. And in the
absence of conflict, you are even allocating and releasing the resource
on _each_ I/O operation, which certainly isn't cheap either. Again, it
is not a blocker point, after all this is a workaround for an improper
behavior of the acpi subsystem, this performance penalty is the price to
pay. But there is also a performance penalty for legitimate I/O access,
which worries me more.

I thought Rudolf's patch allocated the resource in the driver
(w83627ehf) and ACPI contacted the driver when it could not allocate
the resource. Since ACPI never *really* wants to allocate the
resource, is there a fast-path check it could do? This would help
performance.

Alas, I don't think it can work safely. If ACPI doesn't actually
allocate the resource, there is a risk that another driver does so
between the conflict check and the I/O access. I believe this is the
reason why Rudolf used ____request_resource and not __check_region.

I like the virtualized driver method (if it wasn't obvious!) but the
global AML lock works also. It will be interesting to see profiling of
both solutions.

In fact Rudolf's solution is nice for LPC chips, however I don't think
it can work with SMBus chips. It might intercept the accesses to the
SMBus master and be able to emulate it, even though this will be more
complex that the W83627EHF case, and I'm not sure about the PCI config
space. But ultimately we need to emulate all the chips behind the
SMBus, too. The drivers for these chips won't know if they are accessed
for real of through the emulation layer, so there is no way they'll
remember states, while they might have to (e.g. the W83781D has a bank
register too.)

The AML lock approach, OTOH, should work fine in all cases as long as
the context doesn't need to be remembered across AML "sections".

-- 
Jean Delvare

Hi Pavel,

On Mon, 5 Mar 2007 22:25:48 +0000, Pavel Machek wrote:

quoted

Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?

ACPI AML is probably turing-complete: I'm afraid you are trying to
solve the halting problem (-> impossible).

Can you please translate this into something mere humans like myself
have a chance to understand?

Thanks,
-- 
Jean Delvare

quoted

quoted

Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?

ACPI AML is probably turing-complete: I'm afraid you are trying to
solve the halting problem (-> impossible).

Can you please translate this into something mere humans like myself
have a chance to understand?

Try wikipedia "Halting problem".


        Stefan

Hi!

quoted

quoted

Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?

ACPI AML is probably turing-complete: I'm afraid you are trying to
solve the halting problem (-> impossible).

Can you please translate this into something mere humans like myself
have a chance to understand?

ACPI AML is turing-complete -- that means it is as powerful any
programming language. It can do arbitrary computation. That means it
is theoretically impossible to analyze its accesses using any program.

Now... may be possible to introduce _some_ ACPI BIOSes, but doing it
would certainly be very complex -- we are talking "put gcc into
kernel" here.

So no, it is not possible to preallocate the ranges.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

In other words, as per my earlier message:

Port addresses can be dynamically generated by the AML code and thus,
there is no way that the ACPI subsystem can statically predict any
addresses that will be accessed by the AML.

Bob

-----Original Message-----
From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
owner@vger.kernel.org] On Behalf Of Pavel Machek
Sent: Tuesday, March 06, 2007 1:21 PM
To: Jean Delvare
Cc: Matthew Garrett; Chuck Ebbert; Rudolf Marek; linux-
acpi@vger.kernel.org; linux-kernel; lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] Could the k8temp driver be interfering with
ACPI?

Hi!

quoted

quoted

quoted

Is there anything preventing us from doing such a walk and pre-

allocate

quoted

quoted

quoted

all the I/O ranges? I am not familiar with the ACPI code at all,

would

quoted

quoted

quoted

you possibly propose a patch doing that?

ACPI AML is probably turing-complete: I'm afraid you are trying to
solve the halting problem (-> impossible).

Can you please translate this into something mere humans like myself
have a chance to understand?

ACPI AML is turing-complete -- that means it is as powerful any
programming language. It can do arbitrary computation. That means it
is theoretically impossible to analyze its accesses using any program.

Now... may be possible to introduce _some_ ACPI BIOSes, but doing it
would certainly be very complex -- we are talking "put gcc into
kernel" here.

So no, it is not possible to preallocate the ranges.
								Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi"

in

the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Matthew,

On Fri, 2 Mar 2007 21:46:43 +0000, Matthew Garrett wrote:

On Fri, Mar 02, 2007 at 10:41:55PM +0100, Jean Delvare wrote:

quoted

I like the patch, after adding some casts to the printf args it
compiles fine. However you print warnings each time a resource has been
reserved... without checking if it hasn't been reserved by ACPI itself!
My machine looks like this:

Oops! I'll look into fixing that. Thanks, that's an excellent point...

Here is what I have come up with, by mixing your patch with Rudolf
Marek's one. Again this is only a reporting patch, but now it only
reports real unreserved accesses. I plan to use it for debugging
purposes.

Signed-off-by: Jean Delvare <redacted>
---
 drivers/acpi/osl.c |   72 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

--- linux-2.6.21-rc2.orig/drivers/acpi/osl.c	2007-03-06 20:59:00.000000000 +0100
+++ linux-2.6.21-rc2/drivers/acpi/osl.c	2007-03-06 21:33:13.000000000 +0100

@@ -35,6 +35,7 @@
 #include <linux/kmod.h>
 #include <linux/delay.h>
 #include <linux/workqueue.h>
+#include <linux/ioport.h>
 #include <linux/nmi.h>
 #include <linux/acpi.h>
 #include <acpi/acpi.h>

@@ -370,6 +371,7 @@ u64 acpi_os_get_timer(void)
 acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width)
 {
 	u32 dummy;
+	struct resource *conflict, res;
 
 	if (!value)
 		value = &dummy;

@@ -388,6 +390,23 @@ acpi_status acpi_os_read_port(acpi_io_ad
 		BUG();
 	}
 
+	res.flags = IORESOURCE_IO;
+	res.name = "_ACPI Access";
+	res.start = port;
+	res.end = port + width/8 - 1;
+
+	conflict = ____request_resource(&ioport_resource, &res);
+	while (conflict && conflict->child)
+		conflict = ____request_resource(conflict, &res);
+
+	if (conflict && strncmp(conflict->name, "ACPI ", 5)) {
+		printk (KERN_INFO "ACPI read from allocated ioport %lx, value %lx, width %d\n",
+			(unsigned long)port, (unsigned long)(*value), (int)width);
+	}
+
+	if (conflict == NULL)
+		release_resource(&res);
+
 	return AE_OK;
 }
 

@@ -395,6 +414,25 @@ EXPORT_SYMBOL(acpi_os_read_port);
 
 acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width)
 {
+	struct resource *conflict, res;
+
+	res.flags = IORESOURCE_IO;
+	res.name = "_ACPI Access";
+	res.start = port;
+	res.end = port + width/8 - 1;
+
+	conflict = ____request_resource(&ioport_resource, &res);
+	while (conflict && conflict->child)
+		conflict = ____request_resource(conflict, &res);
+
+	if (conflict && strncmp(conflict->name, "ACPI ", 5)) {
+		printk (KERN_INFO "ACPI write to allocated ioport %lx, value %lx, width %d\n",
+			(unsigned long)port, (unsigned long)(value), (int)width);
+	}
+
+	if (conflict == NULL)
+		release_resource(&res);
+
 	switch (width) {
 	case 8:
 		outb(value, port);

@@ -419,6 +457,7 @@ acpi_os_read_memory(acpi_physical_addres
 {
 	u32 dummy;
 	void __iomem *virt_addr;
+	struct resource *conflict, res;
 
 	virt_addr = ioremap(phys_addr, width);
 	if (!value)

@@ -440,6 +479,22 @@ acpi_os_read_memory(acpi_physical_addres
 
 	iounmap(virt_addr);
 
+	res.flags = IORESOURCE_MEM;
+	res.name = "_ACPI Access";
+	res.start = phys_addr;
+	res.end = phys_addr + width/8 - 1;
+
+	conflict = ____request_resource(&iomem_resource, &res);
+	while (conflict && conflict->child)
+		conflict = ____request_resource(conflict, &res);
+
+	if (conflict && strncmp(conflict->name, "ACPI ", 5))
+		pr_info("ACPI read from allocated iomem %lx, value %lx, width %d\n",
+			(unsigned long)phys_addr, (unsigned long)(*value), (int)width);
+
+	if (conflict == NULL)
+		release_resource(&res);
+
 	return AE_OK;
 }
 

@@ -447,6 +502,23 @@ acpi_status
 acpi_os_write_memory(acpi_physical_address phys_addr, u32 value, u32 width)
 {
 	void __iomem *virt_addr;
+	struct resource *conflict, res;
+
+	res.flags = IORESOURCE_MEM;
+	res.name = "_ACPI Access";
+	res.start = phys_addr;
+	res.end = phys_addr + width/8 - 1;
+
+	conflict = ____request_resource(&iomem_resource, &res);
+	while (conflict && conflict->child)
+		conflict = ____request_resource(conflict, &res);
+
+	if (conflict && strncmp(conflict->name, "ACPI ", 5))
+		pr_info("ACPI write to allocated iomem %lx, value %lx, width %d\n",
+			(unsigned long)phys_addr, (unsigned long)value, (int)width);
+
+	if (conflict == NULL)
+		release_resource(&res);
 
 	virt_addr = ioremap(phys_addr, width);
 

-- 
Jean Delvare

Hi!

Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.

Can you take this as a wishlist item?

It would be nice if next version of acpi specs supported table

'AML / SMM BIOS will access these ports'

...so we can get it correct with acpi4 or something..?

							Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Fri, 9 Mar 2007 07:18:56 +0000, Pavel Machek wrote:

quoted

Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.

Can you take this as a wishlist item?

It would be nice if next version of acpi specs supported table

'AML / SMM BIOS will access these ports'

...so we can get it correct with acpi4 or something..?

I can only second Pavel's wish here. This would be highly convenient
for OS developers to at least know which resources are accessed by AML
and SMM. Without this information, we can never be sure that OS-level
code won't conflict with ACPI or SMM.

-- 
Jean Delvare

Jean Delvare wrote:

On Fri, 9 Mar 2007 07:18:56 +0000, Pavel Machek wrote:
  

quoted

quoted

Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.
      

Can you take this as a wishlist item?

It would be nice if next version of acpi specs supported table

'AML / SMM BIOS will access these ports'

...so we can get it correct with acpi4 or something..?
    

I can only second Pavel's wish here. This would be highly convenient
for OS developers to at least know which resources are accessed by AML
and SMM. Without this information, we can never be sure that OS-level
code won't conflict with ACPI or SMM.

  

BIOS vendors are not required to support latest and greatest ACPI spec. So even if some future spec version
will include this ports description, we will still have majority of hardware not exporting it...

Regards,
   Alex.

Hi!

quoted

quoted

Can you take this as a wishlist item?

It would be nice if next version of acpi specs supported table

'AML / SMM BIOS will access these ports'

...so we can get it correct with acpi4 or something..?
   

I can only second Pavel's wish here. This would be highly convenient
for OS developers to at least know which resources are accessed by AML
and SMM. Without this information, we can never be sure that OS-level
code won't conflict with ACPI or SMM.

 

BIOS vendors are not required to support latest and greatest ACPI spec. 
So even if some future spec version
will include this ports description, we will still have majority of 
hardware not exporting it...

That's okay... vendors are not required to support _ACPI_, but they
mostly do. Can we get the "ports used by BIOS" table to the spec?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi Alexey,

On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote:

Jean Delvare wrote:

quoted

I can only second Pavel's wish here. This would be highly convenient
for OS developers to at least know which resources are accessed by AML
and SMM. Without this information, we can never be sure that OS-level
code won't conflict with ACPI or SMM.

BIOS vendors are not required to support latest and greatest ACPI spec. 
So even if some future spec version
will include this ports description, we will still have majority of 
hardware not exporting it...

Your reasoning is amazing. So we should refrain from proposing any
improvement which we aren't certain 100% of the systems will support
tomorrow? Then let's all stay away from our keyboards forever, as the
evolution of computer technology is based on exactly that -
improvements which not all systems implement.

It's friday evening, let's have some more for fun. With a similar
logic, ten years ago we'd have come up with the following conclusions:

The majority of computers have a single CPU, there is no point in
adding SMP support to Linux.

Let's not add a new instruction set in our next CPU family. The
majority of systems will not implement it so it will be useless anyway.

There's no point in supporting PnP in Linux, there are a majority of
legacy ISA cards out there which do not support it anyway!

See my point? Just because not every hardware out there supports a
given standard doesn't make that standard necessarily useless.

Just make the next version of ACPI better than the previous one (not
necessarily a challenge) and everyone will embrace it.

-- 
Jean Delvare

Jean Delvare wrote:

Hi Alexey,

On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote:
  

quoted

Jean Delvare wrote:
    

quoted

I can only second Pavel's wish here. This would be highly convenient
for OS developers to at least know which resources are accessed by AML
and SMM. Without this information, we can never be sure that OS-level
code won't conflict with ACPI or SMM.
      

BIOS vendors are not required to support latest and greatest ACPI spec. So even if some future spec version
will include this ports description, we will still have majority of hardware not exporting it...
    

Your reasoning is amazing. So we should refrain from proposing any
improvement which we aren't certain 100% of the systems will support
tomorrow? Then let's all stay away from our keyboards forever, as the
evolution of computer technology is based on exactly that -
improvements which not all systems implement.

It's friday evening, let's have some more for fun. With a similar
logic, ten years ago we'd have come up with the following conclusions:

The majority of computers have a single CPU, there is no point in
adding SMP support to Linux.

Let's not add a new instruction set in our next CPU family. The
majority of systems will not implement it so it will be useless anyway.

There's no point in supporting PnP in Linux, there are a majority of
legacy ISA cards out there which do not support it anyway!

See my point? Just because not every hardware out there supports a
given standard doesn't make that standard necessarily useless.

Just make the next version of ACPI better than the previous one (not
necessarily a challenge) and everyone will embrace it.

  

You get me wrong, I'm not against the proposal, so keep your breath.
I'm just saying that you get old waiting for BIOS vendors to export this info, even if it's in spec.

Regards,
Alex.

Included the Intel ACPI spec representative.

I have heard that Windows is somehow restricting the ports and memory
locations that are accessible via AML; I don't know any of the details.
Also, there are fears of an "AML virus" attacking the machine.

Bob

-----Original Message-----
From: Pavel Machek [mailto:pavel@ucw.cz]
Sent: Thursday, March 08, 2007 11:19 PM
To: Moore, Robert
Cc: Jean Delvare; Matthew Garrett; Chuck Ebbert; Rudolf Marek; linux-
acpi@vger.kernel.org; linux-kernel; lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] Could the k8temp driver be interfering with
ACPI?

Hi!

quoted

Port (and memory) addresses can be dynamically generated by the AML

code

quoted

and thus, there is no way that the ACPI subsystem can statically

predict

quoted

any addresses that will be accessed by the AML.

Can you take this as a wishlist item?

It would be nice if next version of acpi specs supported table

'AML / SMM BIOS will access these ports'

...so we can get it correct with acpi4 or something..?

							Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

No ACPI discussion can be complete without mentioning Microsoft and
Microsoft compatibility -- Windows does not fully support ACPI 2.0 to
this day, even though it was released in the year 2000, and ACPI 3.0 has
been out since 2004.

-----Original Message-----
From: Alexey Starikovskiy

[mailto:alexey.y.starikovskiy@linux.intel.com]

Sent: Friday, March 09, 2007 9:35 AM
To: Jean Delvare
Cc: Pavel Machek; Moore, Robert; Matthew Garrett; Chuck Ebbert; Rudolf
Marek; linux-acpi@vger.kernel.org; linux-kernel;

lm-sensors@lm-sensors.org

Subject: Re: [lm-sensors] Could the k8temp driver be interfering with
ACPI?

Jean Delvare wrote:

quoted

Hi Alexey,

On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote:

quoted

Jean Delvare wrote:

quoted

I can only second Pavel's wish here. This would be highly

convenient

quoted

quoted

quoted

for OS developers to at least know which resources are accessed by

AML

quoted

quoted

quoted

and SMM. Without this information, we can never be sure that

OS-level

quoted

quoted

quoted

code won't conflict with ACPI or SMM.

BIOS vendors are not required to support latest and greatest ACPI

spec.

quoted

quoted

So even if some future spec version
will include this ports description, we will still have majority of
hardware not exporting it...

Your reasoning is amazing. So we should refrain from proposing any
improvement which we aren't certain 100% of the systems will support
tomorrow? Then let's all stay away from our keyboards forever, as

the

quoted

evolution of computer technology is based on exactly that -
improvements which not all systems implement.

It's friday evening, let's have some more for fun. With a similar
logic, ten years ago we'd have come up with the following

conclusions:

quoted

The majority of computers have a single CPU, there is no point in
adding SMP support to Linux.

Let's not add a new instruction set in our next CPU family. The
majority of systems will not implement it so it will be useless

anyway.

quoted

There's no point in supporting PnP in Linux, there are a majority of
legacy ISA cards out there which do not support it anyway!

See my point? Just because not every hardware out there supports a
given standard doesn't make that standard necessarily useless.

Just make the next version of ACPI better than the previous one (not
necessarily a challenge) and everyone will embrace it.

You get me wrong, I'm not against the proposal, so keep your breath.
I'm just saying that you get old waiting for BIOS vendors to export

this

info, even if it's in spec.

Regards,
Alex.