* Could the k8temp driver be interfering with ACPI? @ 2007-02-16 17:31 ` Chuck Ebbert 0 siblings, 0 replies; 207+ messages in thread From: Chuck Ebbert @ 2007-02-16 17:31 UTC (permalink / raw) To: linux-kernel; +Cc: linux-acpi, lm-sensors 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? ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-16 17:31 ` Chuck Ebbert 0 siblings, 0 replies; 207+ messages in thread From: Chuck Ebbert @ 2007-02-16 17:31 UTC (permalink / raw) To: linux-kernel; +Cc: linux-acpi, lm-sensors 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? ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: Could the k8temp driver be interfering with ACPI? 2007-02-16 17:31 ` [lm-sensors] " Chuck Ebbert @ 2007-02-16 17:57 ` Len Brown -1 siblings, 0 replies; 207+ messages in thread From: Len Brown @ 2007-02-16 17:57 UTC (permalink / raw) To: Chuck Ebbert; +Cc: linux-kernel, linux-acpi, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-16 17:57 ` Len Brown 0 siblings, 0 replies; 207+ messages in thread From: Len Brown @ 2007-02-16 17:57 UTC (permalink / raw) To: Chuck Ebbert; +Cc: linux-kernel, linux-acpi, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: Could the k8temp driver be interfering with ACPI? 2007-02-16 17:57 ` [lm-sensors] " Len Brown @ 2007-02-16 18:14 ` Chuck Ebbert -1 siblings, 0 replies; 207+ messages in thread From: Chuck Ebbert @ 2007-02-16 18:14 UTC (permalink / raw) To: Len Brown; +Cc: linux-kernel, linux-acpi, lm-sensors Len Brown wrote: >> So, could ACPI and the k8temp driver be at odds? > > > Yes. Hmm, now it's showing 130 degrees once every five seconds and 54 degrees for the other four. And while I was typing this on another machine I heard a click from the notebook -- it shut down again. ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-16 18:14 ` Chuck Ebbert 0 siblings, 0 replies; 207+ messages in thread From: Chuck Ebbert @ 2007-02-16 18:14 UTC (permalink / raw) To: Len Brown; +Cc: linux-kernel, linux-acpi, lm-sensors Len Brown wrote: >> So, could ACPI and the k8temp driver be at odds? > > > Yes. Hmm, now it's showing 130 degrees once every five seconds and 54 degrees for the other four. And while I was typing this on another machine I heard a click from the notebook -- it shut down again. ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: Could the k8temp driver be interfering with ACPI? 2007-02-16 17:31 ` [lm-sensors] " Chuck Ebbert @ 2007-02-16 19:59 ` Andi Kleen -1 siblings, 0 replies; 207+ messages in thread From: Andi Kleen @ 2007-02-16 19:59 UTC (permalink / raw) To: Chuck Ebbert; +Cc: linux-kernel, linux-acpi, lm-sensors Chuck Ebbert <cebbert@redhat.com> 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-16 19:59 ` Andi Kleen 0 siblings, 0 replies; 207+ messages in thread From: Andi Kleen @ 2007-02-16 19:59 UTC (permalink / raw) To: Chuck Ebbert; +Cc: linux-kernel, linux-acpi, lm-sensors Chuck Ebbert <cebbert at redhat.com> 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: Could the k8temp driver be interfering with ACPI? 2007-02-16 19:59 ` [lm-sensors] " Andi Kleen @ 2007-02-16 19:31 ` Chuck Ebbert -1 siblings, 0 replies; 207+ messages in thread From: Chuck Ebbert @ 2007-02-16 19:31 UTC (permalink / raw) To: Andi Kleen; +Cc: linux-kernel, linux-acpi, lm-sensors Andi Kleen wrote: > Chuck Ebbert <cebbert@redhat.com> writes: >> So, could ACPI and the k8temp driver be at odds? > > Yes, there is no locking between ACPI and Linux drivers for register access. > e.g. if there is a indexed register both try to access (and temperature > sensors tend to use these things) they can race and get corrupted data. I blacklisted the k8temp driver and everything looks OK now. ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-16 19:31 ` Chuck Ebbert 0 siblings, 0 replies; 207+ messages in thread From: Chuck Ebbert @ 2007-02-16 19:31 UTC (permalink / raw) To: Andi Kleen; +Cc: linux-kernel, linux-acpi, lm-sensors Andi Kleen wrote: > Chuck Ebbert <cebbert at redhat.com> writes: >> So, could ACPI and the k8temp driver be at odds? > > Yes, there is no locking between ACPI and Linux drivers for register access. > e.g. if there is a indexed register both try to access (and temperature > sensors tend to use these things) they can race and get corrupted data. I blacklisted the k8temp driver and everything looks OK now. ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-16 19:31 ` [lm-sensors] " Chuck Ebbert @ 2007-02-18 17:32 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-18 17:32 UTC (permalink / raw) To: Chuck Ebbert; +Cc: Andi Kleen, linux-acpi, linux-kernel, lm-sensors Hi Chuck, On Fri, 16 Feb 2007 14:31:44 -0500, Chuck Ebbert wrote: > Andi Kleen wrote: > > Chuck Ebbert wrote: > > > So, could ACPI and the k8temp driver be at odds? > > > > Yes, there is no locking between ACPI and Linux drivers for register access. > > e.g. if there is a indexed register both try to access (and temperature > > sensors tend to use these things) they can race and get corrupted data. > > I blacklisted the k8temp driver and everything looks OK now. You could blacklist the ACPI "thermal" module instead. If you're interested in monitoring your CPU temperature, k8temp is IMHO more convenient to use than ACPI, as it interfaces properly with libsensors and all hardware monitoring user interfaces. -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-18 17:32 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-18 17:32 UTC (permalink / raw) To: Chuck Ebbert; +Cc: Andi Kleen, linux-acpi, linux-kernel, lm-sensors Hi Chuck, On Fri, 16 Feb 2007 14:31:44 -0500, Chuck Ebbert wrote: > Andi Kleen wrote: > > Chuck Ebbert wrote: > > > So, could ACPI and the k8temp driver be at odds? > > > > Yes, there is no locking between ACPI and Linux drivers for register access. > > e.g. if there is a indexed register both try to access (and temperature > > sensors tend to use these things) they can race and get corrupted data. > > I blacklisted the k8temp driver and everything looks OK now. You could blacklist the ACPI "thermal" module instead. If you're interested in monitoring your CPU temperature, k8temp is IMHO more convenient to use than ACPI, as it interfaces properly with libsensors and all hardware monitoring user interfaces. -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-18 17:32 ` Jean Delvare @ 2007-02-18 23:22 ` Andi Kleen -1 siblings, 0 replies; 207+ messages in thread From: Andi Kleen @ 2007-02-18 23:22 UTC (permalink / raw) To: Jean Delvare Cc: Chuck Ebbert, Andi Kleen, linux-acpi, linux-kernel, lm-sensors > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-18 23:22 ` Andi Kleen 0 siblings, 0 replies; 207+ messages in thread From: Andi Kleen @ 2007-02-18 23:22 UTC (permalink / raw) To: Jean Delvare Cc: Chuck Ebbert, Andi Kleen, linux-acpi, linux-kernel, lm-sensors > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: Could the k8temp driver be interfering with ACPI? 2007-02-16 17:31 ` [lm-sensors] " Chuck Ebbert (?) @ 2007-02-17 10:49 ` Rudolf Marek -1 siblings, 0 replies; 207+ messages in thread From: Rudolf Marek @ 2007-02-17 10:49 UTC (permalink / raw) To: Chuck Ebbert; +Cc: linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-17 10:49 ` Rudolf Marek 0 siblings, 0 replies; 207+ messages in thread From: Rudolf Marek @ 2007-02-17 10:49 UTC (permalink / raw) To: Chuck Ebbert; +Cc: linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-17 10:49 ` Rudolf Marek 0 siblings, 0 replies; 207+ messages in thread From: Rudolf Marek @ 2007-02-17 10:49 UTC (permalink / raw) To: Chuck Ebbert; +Cc: linux-kernel, linux-acpi, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-17 10:49 ` Rudolf Marek @ 2007-02-17 18:14 ` Chuck Ebbert -1 siblings, 0 replies; 207+ messages in thread From: Chuck Ebbert @ 2007-02-17 18:14 UTC (permalink / raw) To: Rudolf Marek; +Cc: linux-kernel, linux-acpi, 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. >> 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. ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-17 18:14 ` Chuck Ebbert 0 siblings, 0 replies; 207+ messages in thread From: Chuck Ebbert @ 2007-02-17 18:14 UTC (permalink / raw) To: Rudolf Marek; +Cc: linux-kernel, linux-acpi, 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. >> 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. ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-17 18:14 ` Chuck Ebbert @ 2007-02-18 17:38 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-18 17:38 UTC (permalink / raw) To: Chuck Ebbert; +Cc: Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-18 17:38 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-18 17:38 UTC (permalink / raw) To: Chuck Ebbert; +Cc: Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-18 17:38 ` Jean Delvare @ 2007-02-20 15:18 ` Matthew Garrett -1 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-02-20 15:18 UTC (permalink / raw) To: Jean Delvare Cc: Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-20 15:18 ` Matthew Garrett 0 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-02-20 15:18 UTC (permalink / raw) To: Jean Delvare Cc: Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 at srcf.ucam.org ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-20 15:18 ` Matthew Garrett @ 2007-02-20 15:33 ` Luca Tettamanti -1 siblings, 0 replies; 207+ messages in thread From: Luca Tettamanti @ 2007-02-20 15:33 UTC (permalink / raw) To: Matthew Garrett Cc: Jean Delvare, linux-acpi, linux-kernel, Chuck Ebbert, lm-sensors On 2/20/07, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Sun, Feb 18, 2007 at 06:38:05PM +0100, Jean Delvare wrote: > > > ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI > > doesn't conflict with only k8temp, but with virtually all hardware > > monitoring drivers, all I2C/SMBus drivers, and probably other types of > > drivers too. We just can't restrict or blacklist all these drivers > > because ACPI misbehaves. > > No, the simple fact of the matter is that if you're running on an ACPI > platform you need to change some of your assumptions. ACPI owns the > hardware. The OS doesn't. To an extent this has always been true on > laptops and servers /anyway/ - the BIOS is free to have a wide variety > of SMM insanity that invalidates basic assumptions like "If I hold this > lock, nothing can interrupt me between this write and this read". That's > simply not true. > > So this isn't about fixing ACPI. It's about trying to find a mechanism > that allows ACPI and raw hardware drivers to coexist, which is made > somewhat harder by it not being a situation that the platform designers > have considered in the slightest. Motherboard vendors usually provide tools for $(TheOtherOS) that can read from all thermal / fan / voltage / whatever sensors, so I guess it's possible to make the ACPI driver and the "raw" one play nice with each other[1]. Luca [1] Unless their solution is "poke at the hardware and hope that ACPI doesn't blow up", that is. ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-20 15:33 ` Luca Tettamanti 0 siblings, 0 replies; 207+ messages in thread From: Luca Tettamanti @ 2007-02-20 15:33 UTC (permalink / raw) To: Matthew Garrett Cc: Jean Delvare, linux-acpi, linux-kernel, Chuck Ebbert, lm-sensors On 2/20/07, Matthew Garrett <mjg59 at srcf.ucam.org> wrote: > On Sun, Feb 18, 2007 at 06:38:05PM +0100, Jean Delvare wrote: > > > ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI > > doesn't conflict with only k8temp, but with virtually all hardware > > monitoring drivers, all I2C/SMBus drivers, and probably other types of > > drivers too. We just can't restrict or blacklist all these drivers > > because ACPI misbehaves. > > No, the simple fact of the matter is that if you're running on an ACPI > platform you need to change some of your assumptions. ACPI owns the > hardware. The OS doesn't. To an extent this has always been true on > laptops and servers /anyway/ - the BIOS is free to have a wide variety > of SMM insanity that invalidates basic assumptions like "If I hold this > lock, nothing can interrupt me between this write and this read". That's > simply not true. > > So this isn't about fixing ACPI. It's about trying to find a mechanism > that allows ACPI and raw hardware drivers to coexist, which is made > somewhat harder by it not being a situation that the platform designers > have considered in the slightest. Motherboard vendors usually provide tools for $(TheOtherOS) that can read from all thermal / fan / voltage / whatever sensors, so I guess it's possible to make the ACPI driver and the "raw" one play nice with each other[1]. Luca [1] Unless their solution is "poke at the hardware and hope that ACPI doesn't blow up", that is. ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-20 15:33 ` Luca Tettamanti @ 2007-02-21 14:59 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-21 14:59 UTC (permalink / raw) To: Luca Tettamanti Cc: Matthew Garrett, linux-acpi, linux-kernel, Chuck Ebbert, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-21 14:59 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-21 14:59 UTC (permalink / raw) To: Luca Tettamanti Cc: Matthew Garrett, linux-acpi, linux-kernel, Chuck Ebbert, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-20 15:18 ` Matthew Garrett @ 2007-02-21 15:07 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-21 15:07 UTC (permalink / raw) To: Matthew Garrett Cc: Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Matthew, On Tue, 20 Feb 2007 15:18:13 +0000, Matthew Garrett wrote: > On Sun, Feb 18, 2007 at 06:38:05PM +0100, Jean Delvare wrote: > > > ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI > > doesn't conflict with only k8temp, but with virtually all hardware > > monitoring drivers, all I2C/SMBus drivers, and probably other types of > > drivers too. We just can't restrict or blacklist all these drivers > > because ACPI misbehaves. > > No, the simple fact of the matter is that if you're running on an ACPI > platform you need to change some of your assumptions. ACPI owns the > hardware. The OS doesn't. To an extent this has always been true on The Linux device driver model assumes that it owns the hardware. If this is not true, then should we prevent any non-ACPI driver from loading as soon as ACPI is enabled? > laptops and servers /anyway/ - the BIOS is free to have a wide variety > of SMM insanity that invalidates basic assumptions like "If I hold this > lock, nothing can interrupt me between this write and this read". That's > simply not true. Yeah, this is correct, and just as unfortunate. It's amazingly sad that hardware vendors as a whole are still repeating the same design mistakes over and over again :( > So this isn't about fixing ACPI. It's about trying to find a mechanism > that allows ACPI and raw hardware drivers to coexist, which is made Exactly what I said, you're only rewording it to make it sound nicer ;) > somewhat harder by it not being a situation that the platform designers > have considered in the slightest. The suggested low-level driver for > io-port arbitration would certainly be a step forward in making this > work better. I sure hope we can find a solution, by as your said yourself, nothing is going to prevent SMM and similar oddities from messing up the drivers assumptions. -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-21 15:07 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-21 15:07 UTC (permalink / raw) To: Matthew Garrett Cc: Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Matthew, On Tue, 20 Feb 2007 15:18:13 +0000, Matthew Garrett wrote: > On Sun, Feb 18, 2007 at 06:38:05PM +0100, Jean Delvare wrote: > > > ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI > > doesn't conflict with only k8temp, but with virtually all hardware > > monitoring drivers, all I2C/SMBus drivers, and probably other types of > > drivers too. We just can't restrict or blacklist all these drivers > > because ACPI misbehaves. > > No, the simple fact of the matter is that if you're running on an ACPI > platform you need to change some of your assumptions. ACPI owns the > hardware. The OS doesn't. To an extent this has always been true on The Linux device driver model assumes that it owns the hardware. If this is not true, then should we prevent any non-ACPI driver from loading as soon as ACPI is enabled? > laptops and servers /anyway/ - the BIOS is free to have a wide variety > of SMM insanity that invalidates basic assumptions like "If I hold this > lock, nothing can interrupt me between this write and this read". That's > simply not true. Yeah, this is correct, and just as unfortunate. It's amazingly sad that hardware vendors as a whole are still repeating the same design mistakes over and over again :( > So this isn't about fixing ACPI. It's about trying to find a mechanism > that allows ACPI and raw hardware drivers to coexist, which is made Exactly what I said, you're only rewording it to make it sound nicer ;) > somewhat harder by it not being a situation that the platform designers > have considered in the slightest. The suggested low-level driver for > io-port arbitration would certainly be a step forward in making this > work better. I sure hope we can find a solution, by as your said yourself, nothing is going to prevent SMM and similar oddities from messing up the drivers assumptions. -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-18 17:38 ` Jean Delvare @ 2007-02-28 21:38 ` Pavel Machek -1 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-02-28 21:38 UTC (permalink / raw) To: Jean Delvare Cc: Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > Well I had an idea after looking at k8temp -- why not make it default to > > doing only reads from the sensor? You'd only get information from whatever > > core/sensor combination that ACPI had last used, but it would be safe. > > ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI > doesn't conflict with only k8temp, but with virtually all hardware > monitoring drivers, all I2C/SMBus drivers, and probably other types of > drivers too. We just can't restrict or blacklist all these drivers > because ACPI misbehaves. Oops, sorry about that but no, that will not work. There's piece of paper, called ACPI specification, and we are following it. Bug is not in our implementation. Bug is in the ACPI specs... it does not explicitely allow you to go out and bitbang i2c, and you do it, and you get problems. Now, you may try to change specs to be hwmon-friendly... good luck. But currently hw manufacturers follow ACPI specs, so we have to follow it, too; bad luck for hwmon. BIOS hiding smbus from you is good hint you are doing something wrong...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-28 21:38 ` Pavel Machek 0 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-02-28 21:38 UTC (permalink / raw) To: Jean Delvare Cc: Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > Well I had an idea after looking at k8temp -- why not make it default to > > doing only reads from the sensor? You'd only get information from whatever > > core/sensor combination that ACPI had last used, but it would be safe. > > ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI > doesn't conflict with only k8temp, but with virtually all hardware > monitoring drivers, all I2C/SMBus drivers, and probably other types of > drivers too. We just can't restrict or blacklist all these drivers > because ACPI misbehaves. Oops, sorry about that but no, that will not work. There's piece of paper, called ACPI specification, and we are following it. Bug is not in our implementation. Bug is in the ACPI specs... it does not explicitely allow you to go out and bitbang i2c, and you do it, and you get problems. Now, you may try to change specs to be hwmon-friendly... good luck. But currently hw manufacturers follow ACPI specs, so we have to follow it, too; bad luck for hwmon. BIOS hiding smbus from you is good hint you are doing something wrong...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: Could the k8temp driver be interfering with ACPI? 2007-02-28 21:38 ` Pavel Machek (?) @ 2007-03-01 14:26 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-01 14:26 UTC (permalink / raw) To: Pavel Machek; +Cc: linux-acpi, linux-kernel, Chuck Ebbert, lm-sensors Hi Pavel, On Wed, 28 Feb 2007 21:38:04 +0000, Pavel Machek 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. > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-01 14:26 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-01 14:26 UTC (permalink / raw) To: Pavel Machek; +Cc: linux-acpi, linux-kernel, Chuck Ebbert, lm-sensors Hi Pavel, On Wed, 28 Feb 2007 21:38:04 +0000, Pavel Machek 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. > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-01 14:26 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-01 14:26 UTC (permalink / raw) To: Pavel Machek Cc: Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Pavel, On Wed, 28 Feb 2007 21:38:04 +0000, Pavel Machek 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. > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-01 14:26 ` Jean Delvare @ 2007-03-01 17:48 ` Dave Jones -1 siblings, 0 replies; 207+ messages in thread From: Dave Jones @ 2007-03-01 17:48 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-01 17:48 ` Dave Jones 0 siblings, 0 replies; 207+ messages in thread From: Dave Jones @ 2007-03-01 17:48 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-01 17:48 ` Dave Jones @ 2007-03-02 11:27 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 11:27 UTC (permalink / raw) To: Dave Jones Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 11:27 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 11:27 UTC (permalink / raw) To: Dave Jones Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 01 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 11:27 ` Jean Delvare @ 2007-03-02 11:31 ` Pavel Machek -1 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-02 11:31 UTC (permalink / raw) To: Jean Delvare Cc: Dave Jones, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 11:31 ` Pavel Machek 0 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-02 11:31 UTC (permalink / raw) To: Jean Delvare Cc: Dave Jones, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > > 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 01 > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 11:31 ` Pavel Machek @ 2007-03-02 13:37 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 13:37 UTC (permalink / raw) To: Pavel Machek Cc: Dave Jones, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Fri, 2 Mar 2007 12:31:58 +0100, Pavel Machek wrote: > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 13:37 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 13:37 UTC (permalink / raw) To: Pavel Machek Cc: Dave Jones, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Fri, 2 Mar 2007 12:31:58 +0100, Pavel Machek wrote: > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 13:37 ` Jean Delvare @ 2007-03-02 13:47 ` Henrique de Moraes Holschuh -1 siblings, 0 replies; 207+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-02 13:47 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert, Dave Jones, Rudolf 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 13:47 ` Henrique de Moraes Holschuh 0 siblings, 0 replies; 207+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-02 13:47 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert, Dave Jones, Rudolf 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 13:37 ` Jean Delvare @ 2007-03-02 13:57 ` Pavel Machek -1 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-02 13:57 UTC (permalink / raw) To: Jean Delvare Cc: Dave Jones, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Fri 2007-03-02 14:37:20, Jean Delvare wrote: > On Fri, 2 Mar 2007 12:31:58 +0100, Pavel Machek wrote: > > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 13:57 ` Pavel Machek 0 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-02 13:57 UTC (permalink / raw) To: Jean Delvare Cc: Dave Jones, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Fri 2007-03-02 14:37:20, Jean Delvare wrote: > On Fri, 2 Mar 2007 12:31:58 +0100, Pavel Machek wrote: > > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 13:57 ` Pavel Machek @ 2007-03-03 6:44 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-03 6:44 UTC (permalink / raw) To: Pavel Machek Cc: Dave Jones, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Fri, 2 Mar 2007 14:57:06 +0100, Pavel Machek wrote: > On Fri 2007-03-02 14:37:20, Jean Delvare wrote: > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-03 6:44 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-03 6:44 UTC (permalink / raw) To: Pavel Machek Cc: Dave Jones, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Fri, 2 Mar 2007 14:57:06 +0100, Pavel Machek wrote: > On Fri 2007-03-02 14:37:20, Jean Delvare wrote: > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-01 14:26 ` Jean Delvare @ 2007-03-02 11:40 ` Pavel Machek -1 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-02 11:40 UTC (permalink / raw) To: Jean Delvare Cc: Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > > > Well I had an idea after looking at k8temp -- why not make it default to > > > > doing only reads from the sensor? You'd only get information from whatever > > > > core/sensor combination that ACPI had last used, but it would be safe. > > > > > > ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI > > > doesn't conflict with only k8temp, but with virtually all hardware > > > monitoring drivers, all I2C/SMBus drivers, and probably other types of > > > drivers too. We just can't restrict or blacklist all these drivers > > > because ACPI misbehaves. > > > > Oops, sorry about that but no, that will not work. > > > > There's piece of paper, called ACPI specification, and we are > > following it. > > 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. > > 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. ...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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 11:40 ` Pavel Machek 0 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-02 11:40 UTC (permalink / raw) To: Jean Delvare Cc: Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > > > Well I had an idea after looking at k8temp -- why not make it default to > > > > doing only reads from the sensor? You'd only get information from whatever > > > > core/sensor combination that ACPI had last used, but it would be safe. > > > > > > ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI > > > doesn't conflict with only k8temp, but with virtually all hardware > > > monitoring drivers, all I2C/SMBus drivers, and probably other types of > > > drivers too. We just can't restrict or blacklist all these drivers > > > because ACPI misbehaves. > > > > Oops, sorry about that but no, that will not work. > > > > There's piece of paper, called ACPI specification, and we are > > following it. > > 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. > > 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. ...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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 11:40 ` Pavel Machek @ 2007-03-02 11:47 ` Matthew Garrett -1 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-03-02 11:47 UTC (permalink / raw) To: Pavel Machek Cc: Jean Delvare, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 11:47 ` Matthew Garrett 0 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-03-02 11:47 UTC (permalink / raw) To: Pavel Machek Cc: Jean Delvare, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 at srcf.ucam.org ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 11:47 ` Matthew Garrett @ 2007-03-02 13:58 ` Pavel Machek -1 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-02 13:58 UTC (permalink / raw) To: Matthew Garrett Cc: Jean Delvare, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Fri 2007-03-02 11:47:47, Matthew Garrett wrote: > 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. 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 13:58 ` Pavel Machek 0 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-02 13:58 UTC (permalink / raw) To: Matthew Garrett Cc: Jean Delvare, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Fri 2007-03-02 11:47:47, Matthew Garrett wrote: > 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. 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 13:58 ` Pavel Machek @ 2007-03-02 21:00 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 21:00 UTC (permalink / raw) To: Pavel Machek Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 21:00 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 21:00 UTC (permalink / raw) To: Pavel Machek Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 21:00 ` Jean Delvare @ 2007-03-02 21:22 ` Henrique de Moraes Holschuh -1 siblings, 0 replies; 207+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-02 21:22 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 21:22 ` Henrique de Moraes Holschuh 0 siblings, 0 replies; 207+ messages in thread From: Henrique de Moraes Holschuh @ 2007-03-02 21:22 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 21:00 ` Jean Delvare @ 2007-04-01 15:39 ` Pavel Machek -1 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-04-01 15:39 UTC (permalink / raw) To: Jean Delvare Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > 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. I'm sorry, but I do not have time for a patch.... and I'm not really acpi expert, anyway. Ask Len? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-01 15:39 ` Pavel Machek 0 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-04-01 15:39 UTC (permalink / raw) To: Jean Delvare Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > 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. I'm sorry, but I do not have time for a patch.... and I'm not really acpi expert, anyway. Ask Len? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: Could the k8temp driver be interfering with ACPI? 2007-04-01 15:39 ` Pavel Machek @ 2007-04-02 15:48 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-04-02 15:48 UTC (permalink / raw) To: Pavel Machek, Len Brown Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Pavel, Len, On Sun, 1 Apr 2007 15:39:52 +0000, 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. > > I'm sorry, but I do not have time for a patch.... and I'm not really > acpi expert, anyway. Ask Len? Meanwhile Alexey Starikovskiy pointed me to the acpi_ex_enter/exit_interpreter functions, which take an ACPI mutex (ACPI_MTX_INTERPRETER). As the mutex already exists, it sounds more efficient to just reuse it rather than introducing a new one. I made an experiment with the f71805f driver on a machine where ACPI is accessing the F71805F chip, and it appears to work fine; patch at the end of this post is someone wants to take a look and/or comment. Looking at the comment before acpi_ex_exit_interpreter raises two questions though: > * Cases where the interpreter is unlocked: > * 1) Completion of the execution of a control method > * 2) Method blocked on a Sleep() AML opcode > * 3) Method blocked on an Acquire() AML opcode > * 4) Method blocked on a Wait() AML opcode > * 5) Method blocked to acquire the global lock > * 6) Method blocked to execute a serialized control method that is > * already executing > * 7) About to invoke a user-installed opregion handler 1* This suggests that the mutex could be released by the AML interpreter in the middle of an SMBus transaction. If so, and if it happens in practice, this means that we unfortunately cannot use this mutex to reliably protect the SMBus drivers from concurrent accesses. This even suggests that it's simply not possible to have a mutex we take at the beginning when entering the AML interpreter and we release when leaving the AML interpreter, as it looks like ACPI itself allows interlaced execution of AML functions. Len, is this true? What is the purpose of the ACPI_MTX_INTERPRETER mutex in the first place, given that it seems it will be released on numerous occasions? Is it to prevent concurrent AML execution while still allowing interlaced execution? 2* What are "user-installed opregion handlers"? Are they something that could help solve the ACPI vs. other drivers problem? Thanks. --- drivers/acpi/utilities/utmutex.c | 2 ++ drivers/hwmon/f71805f.c | 32 +++++++++++++++++++++++++++++++- 2 files changed, 33 insertions(+), 1 deletion(-) --- linux-2.6.21-rc5.orig/drivers/acpi/utilities/utmutex.c 2007-02-21 08:34:20.000000000 +0100 +++ linux-2.6.21-rc5/drivers/acpi/utilities/utmutex.c 2007-04-02 15:48:41.000000000 +0200 @@ -265,6 +265,7 @@ acpi_status acpi_ut_acquire_mutex(acpi_m return (status); } +EXPORT_SYMBOL_GPL(acpi_ut_acquire_mutex); /******************************************************************************* * @@ -339,3 +340,4 @@ acpi_status acpi_ut_release_mutex(acpi_m acpi_os_release_mutex(acpi_gbl_mutex_info[mutex_id].mutex); return (AE_OK); } +EXPORT_SYMBOL_GPL(acpi_ut_release_mutex); --- linux-2.6.21-rc5.orig/drivers/hwmon/f71805f.c 2007-04-02 15:20:46.000000000 +0200 +++ linux-2.6.21-rc5/drivers/hwmon/f71805f.c 2007-04-02 17:15:46.000000000 +0200 @@ -37,6 +37,10 @@ #include <linux/sysfs.h> #include <asm/io.h> +#ifdef CONFIG_ACPI +#include <acpi/acpi.h> +#endif + static struct platform_device *pdev; #define DRVNAME "f71805f" @@ -273,15 +277,29 @@ static inline u8 temp_to_reg(long val) /* Must be called with data->update_lock held, except during initialization */ static u8 f71805f_read8(struct f71805f_data *data, u8 reg) { + u8 val; +#ifdef CONFIG_ACPI + acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER); +#endif outb(reg, data->addr + ADDR_REG_OFFSET); - return inb(data->addr + DATA_REG_OFFSET); + val = inb(data->addr + DATA_REG_OFFSET); +#ifdef CONFIG_ACPI + acpi_ut_release_mutex(ACPI_MTX_INTERPRETER); +#endif + return val; } /* Must be called with data->update_lock held, except during initialization */ static void f71805f_write8(struct f71805f_data *data, u8 reg, u8 val) { +#ifdef CONFIG_ACPI + acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER); +#endif outb(reg, data->addr + ADDR_REG_OFFSET); outb(val, data->addr + DATA_REG_OFFSET); +#ifdef CONFIG_ACPI + acpi_ut_release_mutex(ACPI_MTX_INTERPRETER); +#endif } /* It is important to read the MSB first, because doing so latches the @@ -291,10 +309,16 @@ static u16 f71805f_read16(struct f71805f { u16 val; +#ifdef CONFIG_ACPI + acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER); +#endif outb(reg, data->addr + ADDR_REG_OFFSET); val = inb(data->addr + DATA_REG_OFFSET) << 8; outb(++reg, data->addr + ADDR_REG_OFFSET); val |= inb(data->addr + DATA_REG_OFFSET); +#ifdef CONFIG_ACPI + acpi_ut_release_mutex(ACPI_MTX_INTERPRETER); +#endif return val; } @@ -302,10 +326,16 @@ static u16 f71805f_read16(struct f71805f /* Must be called with data->update_lock held, except during initialization */ static void f71805f_write16(struct f71805f_data *data, u8 reg, u16 val) { +#ifdef CONFIG_ACPI + acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER); +#endif outb(reg, data->addr + ADDR_REG_OFFSET); outb(val >> 8, data->addr + DATA_REG_OFFSET); outb(++reg, data->addr + ADDR_REG_OFFSET); outb(val & 0xff, data->addr + DATA_REG_OFFSET); +#ifdef CONFIG_ACPI + acpi_ut_release_mutex(ACPI_MTX_INTERPRETER); +#endif } static struct f71805f_data *f71805f_update_device(struct device *dev) -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-02 15:48 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-04-02 15:48 UTC (permalink / raw) To: Pavel Machek, Len Brown Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Pavel, Len, On Sun, 1 Apr 2007 15:39:52 +0000, 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. > > I'm sorry, but I do not have time for a patch.... and I'm not really > acpi expert, anyway. Ask Len? Meanwhile Alexey Starikovskiy pointed me to the acpi_ex_enter/exit_interpreter functions, which take an ACPI mutex (ACPI_MTX_INTERPRETER). As the mutex already exists, it sounds more efficient to just reuse it rather than introducing a new one. I made an experiment with the f71805f driver on a machine where ACPI is accessing the F71805F chip, and it appears to work fine; patch at the end of this post is someone wants to take a look and/or comment. Looking at the comment before acpi_ex_exit_interpreter raises two questions though: > * Cases where the interpreter is unlocked: > * 1) Completion of the execution of a control method > * 2) Method blocked on a Sleep() AML opcode > * 3) Method blocked on an Acquire() AML opcode > * 4) Method blocked on a Wait() AML opcode > * 5) Method blocked to acquire the global lock > * 6) Method blocked to execute a serialized control method that is > * already executing > * 7) About to invoke a user-installed opregion handler 1* This suggests that the mutex could be released by the AML interpreter in the middle of an SMBus transaction. If so, and if it happens in practice, this means that we unfortunately cannot use this mutex to reliably protect the SMBus drivers from concurrent accesses. This even suggests that it's simply not possible to have a mutex we take at the beginning when entering the AML interpreter and we release when leaving the AML interpreter, as it looks like ACPI itself allows interlaced execution of AML functions. Len, is this true? What is the purpose of the ACPI_MTX_INTERPRETER mutex in the first place, given that it seems it will be released on numerous occasions? Is it to prevent concurrent AML execution while still allowing interlaced execution? 2* What are "user-installed opregion handlers"? Are they something that could help solve the ACPI vs. other drivers problem? Thanks. --- drivers/acpi/utilities/utmutex.c | 2 ++ drivers/hwmon/f71805f.c | 32 +++++++++++++++++++++++++++++++- 2 files changed, 33 insertions(+), 1 deletion(-) --- linux-2.6.21-rc5.orig/drivers/acpi/utilities/utmutex.c 2007-02-21 08:34:20.000000000 +0100 +++ linux-2.6.21-rc5/drivers/acpi/utilities/utmutex.c 2007-04-02 15:48:41.000000000 +0200 @@ -265,6 +265,7 @@ acpi_status acpi_ut_acquire_mutex(acpi_m return (status); } +EXPORT_SYMBOL_GPL(acpi_ut_acquire_mutex); /******************************************************************************* * @@ -339,3 +340,4 @@ acpi_status acpi_ut_release_mutex(acpi_m acpi_os_release_mutex(acpi_gbl_mutex_info[mutex_id].mutex); return (AE_OK); } +EXPORT_SYMBOL_GPL(acpi_ut_release_mutex); --- linux-2.6.21-rc5.orig/drivers/hwmon/f71805f.c 2007-04-02 15:20:46.000000000 +0200 +++ linux-2.6.21-rc5/drivers/hwmon/f71805f.c 2007-04-02 17:15:46.000000000 +0200 @@ -37,6 +37,10 @@ #include <linux/sysfs.h> #include <asm/io.h> +#ifdef CONFIG_ACPI +#include <acpi/acpi.h> +#endif + static struct platform_device *pdev; #define DRVNAME "f71805f" @@ -273,15 +277,29 @@ static inline u8 temp_to_reg(long val) /* Must be called with data->update_lock held, except during initialization */ static u8 f71805f_read8(struct f71805f_data *data, u8 reg) { + u8 val; +#ifdef CONFIG_ACPI + acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER); +#endif outb(reg, data->addr + ADDR_REG_OFFSET); - return inb(data->addr + DATA_REG_OFFSET); + val = inb(data->addr + DATA_REG_OFFSET); +#ifdef CONFIG_ACPI + acpi_ut_release_mutex(ACPI_MTX_INTERPRETER); +#endif + return val; } /* Must be called with data->update_lock held, except during initialization */ static void f71805f_write8(struct f71805f_data *data, u8 reg, u8 val) { +#ifdef CONFIG_ACPI + acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER); +#endif outb(reg, data->addr + ADDR_REG_OFFSET); outb(val, data->addr + DATA_REG_OFFSET); +#ifdef CONFIG_ACPI + acpi_ut_release_mutex(ACPI_MTX_INTERPRETER); +#endif } /* It is important to read the MSB first, because doing so latches the @@ -291,10 +309,16 @@ static u16 f71805f_read16(struct f71805f { u16 val; +#ifdef CONFIG_ACPI + acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER); +#endif outb(reg, data->addr + ADDR_REG_OFFSET); val = inb(data->addr + DATA_REG_OFFSET) << 8; outb(++reg, data->addr + ADDR_REG_OFFSET); val |= inb(data->addr + DATA_REG_OFFSET); +#ifdef CONFIG_ACPI + acpi_ut_release_mutex(ACPI_MTX_INTERPRETER); +#endif return val; } @@ -302,10 +326,16 @@ static u16 f71805f_read16(struct f71805f /* Must be called with data->update_lock held, except during initialization */ static void f71805f_write16(struct f71805f_data *data, u8 reg, u16 val) { +#ifdef CONFIG_ACPI + acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER); +#endif outb(reg, data->addr + ADDR_REG_OFFSET); outb(val >> 8, data->addr + DATA_REG_OFFSET); outb(++reg, data->addr + ADDR_REG_OFFSET); outb(val & 0xff, data->addr + DATA_REG_OFFSET); +#ifdef CONFIG_ACPI + acpi_ut_release_mutex(ACPI_MTX_INTERPRETER); +#endif } static struct f71805f_data *f71805f_update_device(struct device *dev) -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: Could the k8temp driver be interfering with ACPI? 2007-04-02 15:48 ` [lm-sensors] " Jean Delvare @ 2007-04-02 19:22 ` Dave Jones -1 siblings, 0 replies; 207+ messages in thread From: Dave Jones @ 2007-04-02 19:22 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Len Brown, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Mon, Apr 02, 2007 at 05:48:59PM +0200, Jean Delvare wrote: > + u8 val; > +#ifdef CONFIG_ACPI > + acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER); > +#endif > outb(reg, data->addr + ADDR_REG_OFFSET); > - return inb(data->addr + DATA_REG_OFFSET); > + val = inb(data->addr + DATA_REG_OFFSET); > +#ifdef CONFIG_ACPI > + acpi_ut_release_mutex(ACPI_MTX_INTERPRETER); > +#endif > + return val; > ... deletia, more of the same. it'd probably end up a lot cleaner to #define them to empty macros in the !ACPI case in acpi/acpi.h and just #include it unconditionally. Dave -- http://www.codemonkey.org.uk ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-02 19:22 ` Dave Jones 0 siblings, 0 replies; 207+ messages in thread From: Dave Jones @ 2007-04-02 19:22 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Len Brown, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Mon, Apr 02, 2007 at 05:48:59PM +0200, Jean Delvare wrote: > + u8 val; > +#ifdef CONFIG_ACPI > + acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER); > +#endif > outb(reg, data->addr + ADDR_REG_OFFSET); > - return inb(data->addr + DATA_REG_OFFSET); > + val = inb(data->addr + DATA_REG_OFFSET); > +#ifdef CONFIG_ACPI > + acpi_ut_release_mutex(ACPI_MTX_INTERPRETER); > +#endif > + return val; > ... deletia, more of the same. it'd probably end up a lot cleaner to #define them to empty macros in the !ACPI case in acpi/acpi.h and just #include it unconditionally. Dave -- http://www.codemonkey.org.uk _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: Could the k8temp driver be interfering with ACPI? 2007-04-02 19:22 ` [lm-sensors] " Dave Jones @ 2007-04-03 5:49 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-04-03 5:49 UTC (permalink / raw) To: Dave Jones Cc: Pavel Machek, Len Brown, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Dave, On Mon, 2 Apr 2007 15:22:09 -0400, Dave Jones wrote: > On Mon, Apr 02, 2007 at 05:48:59PM +0200, Jean Delvare wrote: > > + u8 val; > > +#ifdef CONFIG_ACPI > > + acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER); > > +#endif > > outb(reg, data->addr + ADDR_REG_OFFSET); > > - return inb(data->addr + DATA_REG_OFFSET); > > + val = inb(data->addr + DATA_REG_OFFSET); > > +#ifdef CONFIG_ACPI > > + acpi_ut_release_mutex(ACPI_MTX_INTERPRETER); > > +#endif > > + return val; > > ... deletia, more of the same. > > it'd probably end up a lot cleaner to #define them to empty macros > in the !ACPI case in acpi/acpi.h and just #include it unconditionally. Sure, the implementation details can be refined later. I'm only trying to see what can be done for now. -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-03 5:49 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-04-03 5:49 UTC (permalink / raw) To: Dave Jones Cc: Pavel Machek, Len Brown, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Dave, On Mon, 2 Apr 2007 15:22:09 -0400, Dave Jones wrote: > On Mon, Apr 02, 2007 at 05:48:59PM +0200, Jean Delvare wrote: > > + u8 val; > > +#ifdef CONFIG_ACPI > > + acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER); > > +#endif > > outb(reg, data->addr + ADDR_REG_OFFSET); > > - return inb(data->addr + DATA_REG_OFFSET); > > + val = inb(data->addr + DATA_REG_OFFSET); > > +#ifdef CONFIG_ACPI > > + acpi_ut_release_mutex(ACPI_MTX_INTERPRETER); > > +#endif > > + return val; > > ... deletia, more of the same. > > it'd probably end up a lot cleaner to #define them to empty macros > in the !ACPI case in acpi/acpi.h and just #include it unconditionally. Sure, the implementation details can be refined later. I'm only trying to see what can be done for now. -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* RE: Could the k8temp driver be interfering with ACPI? 2007-04-02 15:48 ` [lm-sensors] " Jean Delvare (?) @ 2007-04-02 20:55 ` Moore, Robert -1 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-04-02 20:55 UTC (permalink / raw) To: Jean Delvare, Pavel Machek, Brown, Len Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors The ACPI specification allows concurrent execution of control methods although methods cannot be preempted. The ACPICA interpreter mutex is used to implement this model. >From section 5.5.2, "Control Method Execution": Interpretation of a Control Method is not preemptive, but it can block. When a control method does block, the operating software can initiate or continue the execution of a different control method. A control method can only assume that access to global objects is exclusive for any period the control method does not block. Therefore, the interpreter lock is acquired and a control method is allowed to execute to completion unless it blocks on one of the events described below. If the method blocks, the interpreter is unlocked and other control methods may execute. I'm not sure what you mean by "in the middle of an SMBus transaction", I don't know how long such a transaction is valid. I might guess that a single transaction can only span a single operation region access, but I'm not sure of this. A user-installed operation region handler is an operation region handler that is installed by a device driver. This feature would probably only be used for custom (OEM-defined) operation region address spaces. (I have not seen one yet.) For the standard address spaces (memory, I/O, etc.), usually only the default handlers are used. Bob > -----Original Message----- > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi- > owner@vger.kernel.org] On Behalf Of Jean Delvare > Sent: Monday, April 02, 2007 8:49 AM > To: Pavel Machek; Brown, Len > Cc: Matthew Garrett; Chuck Ebbert; Rudolf Marek; linux- > acpi@vger.kernel.org; linux-kernel; lm-sensors@lm-sensors.org > Subject: Re: Could the k8temp driver be interfering with ACPI? > > Looking at the comment before acpi_ex_exit_interpreter raises two > questions though: > > > * Cases where the interpreter is unlocked: > > * 1) Completion of the execution of a control method > > * 2) Method blocked on a Sleep() AML opcode > > * 3) Method blocked on an Acquire() AML opcode > > * 4) Method blocked on a Wait() AML opcode > > * 5) Method blocked to acquire the global lock > > * 6) Method blocked to execute a serialized control method that is > > * already executing > > * 7) About to invoke a user-installed opregion handler > > 1* This suggests that the mutex could be released by the AML > interpreter in the middle of an SMBus transaction. If so, and if it > happens in practice, this means that we unfortunately cannot use this > mutex to reliably protect the SMBus drivers from concurrent accesses. > This even suggests that it's simply not possible to have a mutex we > take at the beginning when entering the AML interpreter and we release > when leaving the AML interpreter, as it looks like ACPI itself allows > interlaced execution of AML functions. Len, is this true? > > What is the purpose of the ACPI_MTX_INTERPRETER mutex in the first > place, given that it seems it will be released on numerous occasions? > Is it to prevent concurrent AML execution while still allowing > interlaced execution? > > 2* What are "user-installed opregion handlers"? Are they something that > could help solve the ACPI vs. other drivers problem? > > Thanks. ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-02 20:55 ` Moore, Robert 0 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-04-02 20:55 UTC (permalink / raw) To: Jean Delvare, Pavel Machek, Brown, Len Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors The ACPI specification allows concurrent execution of control methods although methods cannot be preempted. The ACPICA interpreter mutex is used to implement this model. From section 5.5.2, "Control Method Execution": Interpretation of a Control Method is not preemptive, but it can block. When a control method does block, the operating software can initiate or continue the execution of a different control method. A control method can only assume that access to global objects is exclusive for any period the control method does not block. Therefore, the interpreter lock is acquired and a control method is allowed to execute to completion unless it blocks on one of the events described below. If the method blocks, the interpreter is unlocked and other control methods may execute. I'm not sure what you mean by "in the middle of an SMBus transaction", I don't know how long such a transaction is valid. I might guess that a single transaction can only span a single operation region access, but I'm not sure of this. A user-installed operation region handler is an operation region handler that is installed by a device driver. This feature would probably only be used for custom (OEM-defined) operation region address spaces. (I have not seen one yet.) For the standard address spaces (memory, I/O, etc.), usually only the default handlers are used. Bob > -----Original Message----- > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi- > owner@vger.kernel.org] On Behalf Of Jean Delvare > Sent: Monday, April 02, 2007 8:49 AM > To: Pavel Machek; Brown, Len > Cc: Matthew Garrett; Chuck Ebbert; Rudolf Marek; linux- > acpi@vger.kernel.org; linux-kernel; lm-sensors@lm-sensors.org > Subject: Re: Could the k8temp driver be interfering with ACPI? > > Looking at the comment before acpi_ex_exit_interpreter raises two > questions though: > > > * Cases where the interpreter is unlocked: > > * 1) Completion of the execution of a control method > > * 2) Method blocked on a Sleep() AML opcode > > * 3) Method blocked on an Acquire() AML opcode > > * 4) Method blocked on a Wait() AML opcode > > * 5) Method blocked to acquire the global lock > > * 6) Method blocked to execute a serialized control method that is > > * already executing > > * 7) About to invoke a user-installed opregion handler > > 1* This suggests that the mutex could be released by the AML > interpreter in the middle of an SMBus transaction. If so, and if it > happens in practice, this means that we unfortunately cannot use this > mutex to reliably protect the SMBus drivers from concurrent accesses. > This even suggests that it's simply not possible to have a mutex we > take at the beginning when entering the AML interpreter and we release > when leaving the AML interpreter, as it looks like ACPI itself allows > interlaced execution of AML functions. Len, is this true? > > What is the purpose of the ACPI_MTX_INTERPRETER mutex in the first > place, given that it seems it will be released on numerous occasions? > Is it to prevent concurrent AML execution while still allowing > interlaced execution? > > 2* What are "user-installed opregion handlers"? Are they something that > could help solve the ACPI vs. other drivers problem? > > Thanks. _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* RE: Could the k8temp driver be interfering with ACPI? @ 2007-04-02 20:55 ` Moore, Robert 0 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-04-02 20:55 UTC (permalink / raw) To: Jean Delvare, Pavel Machek, Brown, Len Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors The ACPI specification allows concurrent execution of control methods although methods cannot be preempted. The ACPICA interpreter mutex is used to implement this model. >From section 5.5.2, "Control Method Execution": Interpretation of a Control Method is not preemptive, but it can block. When a control method does block, the operating software can initiate or continue the execution of a different control method. A control method can only assume that access to global objects is exclusive for any period the control method does not block. Therefore, the interpreter lock is acquired and a control method is allowed to execute to completion unless it blocks on one of the events described below. If the method blocks, the interpreter is unlocked and other control methods may execute. I'm not sure what you mean by "in the middle of an SMBus transaction", I don't know how long such a transaction is valid. I might guess that a single transaction can only span a single operation region access, but I'm not sure of this. A user-installed operation region handler is an operation region handler that is installed by a device driver. This feature would probably only be used for custom (OEM-defined) operation region address spaces. (I have not seen one yet.) For the standard address spaces (memory, I/O, etc.), usually only the default handlers are used. Bob > -----Original Message----- > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi- > owner@vger.kernel.org] On Behalf Of Jean Delvare > Sent: Monday, April 02, 2007 8:49 AM > To: Pavel Machek; Brown, Len > Cc: Matthew Garrett; Chuck Ebbert; Rudolf Marek; linux- > acpi@vger.kernel.org; linux-kernel; lm-sensors@lm-sensors.org > Subject: Re: Could the k8temp driver be interfering with ACPI? > > Looking at the comment before acpi_ex_exit_interpreter raises two > questions though: > > > * Cases where the interpreter is unlocked: > > * 1) Completion of the execution of a control method > > * 2) Method blocked on a Sleep() AML opcode > > * 3) Method blocked on an Acquire() AML opcode > > * 4) Method blocked on a Wait() AML opcode > > * 5) Method blocked to acquire the global lock > > * 6) Method blocked to execute a serialized control method that is > > * already executing > > * 7) About to invoke a user-installed opregion handler > > 1* This suggests that the mutex could be released by the AML > interpreter in the middle of an SMBus transaction. If so, and if it > happens in practice, this means that we unfortunately cannot use this > mutex to reliably protect the SMBus drivers from concurrent accesses. > This even suggests that it's simply not possible to have a mutex we > take at the beginning when entering the AML interpreter and we release > when leaving the AML interpreter, as it looks like ACPI itself allows > interlaced execution of AML functions. Len, is this true? > > What is the purpose of the ACPI_MTX_INTERPRETER mutex in the first > place, given that it seems it will be released on numerous occasions? > Is it to prevent concurrent AML execution while still allowing > interlaced execution? > > 2* What are "user-installed opregion handlers"? Are they something that > could help solve the ACPI vs. other drivers problem? > > Thanks. ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: Could the k8temp driver be interfering with ACPI? 2007-04-02 20:55 ` Moore, Robert (?) @ 2007-04-03 7:21 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-04-03 7:21 UTC (permalink / raw) To: Moore, Robert Cc: Pavel Machek, Brown, Len, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Bob, On Mon, 2 Apr 2007 13:55:49 -0700, Moore, Robert wrote: > The ACPI specification allows concurrent execution of control methods > although methods cannot be preempted. The ACPICA interpreter mutex is > used to implement this model. > > From section 5.5.2, "Control Method Execution": Interpretation of a > Control Method is not preemptive, but it can block. When a control > method does block, the operating software can initiate or continue the > execution of a different control method. A control method can only > assume that access to global objects is exclusive for any period the > control method does not block. Do I/O regions count as "global objects"? > Therefore, the interpreter lock is acquired and a control method is > allowed to execute to completion unless it blocks on one of the events > described below. If the method blocks, the interpreter is unlocked and > other control methods may execute. > > I'm not sure what you mean by "in the middle of an SMBus transaction", I > don't know how long such a transaction is valid. I might guess that a > single transaction can only span a single operation region access, but > I'm not sure of this. Basically an SMBus transaction looks like this: 1* Prepare the transaction. 2* Start the transaction. 3* Wait for the transaction to complete, typically a few ms. 4* Read the result of the transaction. Steps 1 and 2 require writing to the SMBus I/O region. Step 4 requires reading from it, and so does step 3 if the wait loop is poll-based. The transaction is only safe if we have an exclusive access to the I/O region during all the 4 steps. My fear is that step 3 could be implemented by ACPI using either a Sleep() or Acquire() or Wait() opcode. If it is, we're doomed. OTOH, if it does, it is probably not even safe for itself, unless there's an additional, implementation-specific mutex to protect SMBus transactions. I yet have to get my hands on the DSDT of ACPI implementations which actually access the SMBus to see exactly how they do it. > A user-installed operation region handler is an operation region handler > that is installed by a device driver. This feature would probably only > be used for custom (OEM-defined) operation region address spaces. (I > have not seen one yet.) For the standard address spaces (memory, I/O, > etc.), usually only the default handlers are used. Could regular Linux device drivers install such handlers for a specific I/O region? I'm asking because Rudolf Marek's proposal [1] to solve the concurrent access problem involved extending struct resource with callbacks to driver-specific routines to handle external access to an I/O region. This sounds somewhat similar to these "user-installed operation region handler" defined by ACPI, doesn't it? If ACPI already has an infrastructure to handle this problem, we probably want to use it rather than implementing our own. [1] http://marc.info/?l=linux-kernel&m=117302946017204&w=2 -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-03 7:21 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-04-03 7:21 UTC (permalink / raw) To: Moore, Robert Cc: Pavel Machek, Brown, Len, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Bob, On Mon, 2 Apr 2007 13:55:49 -0700, Moore, Robert wrote: > The ACPI specification allows concurrent execution of control methods > although methods cannot be preempted. The ACPICA interpreter mutex is > used to implement this model. > > From section 5.5.2, "Control Method Execution": Interpretation of a > Control Method is not preemptive, but it can block. When a control > method does block, the operating software can initiate or continue the > execution of a different control method. A control method can only > assume that access to global objects is exclusive for any period the > control method does not block. Do I/O regions count as "global objects"? > Therefore, the interpreter lock is acquired and a control method is > allowed to execute to completion unless it blocks on one of the events > described below. If the method blocks, the interpreter is unlocked and > other control methods may execute. > > I'm not sure what you mean by "in the middle of an SMBus transaction", I > don't know how long such a transaction is valid. I might guess that a > single transaction can only span a single operation region access, but > I'm not sure of this. Basically an SMBus transaction looks like this: 1* Prepare the transaction. 2* Start the transaction. 3* Wait for the transaction to complete, typically a few ms. 4* Read the result of the transaction. Steps 1 and 2 require writing to the SMBus I/O region. Step 4 requires reading from it, and so does step 3 if the wait loop is poll-based. The transaction is only safe if we have an exclusive access to the I/O region during all the 4 steps. My fear is that step 3 could be implemented by ACPI using either a Sleep() or Acquire() or Wait() opcode. If it is, we're doomed. OTOH, if it does, it is probably not even safe for itself, unless there's an additional, implementation-specific mutex to protect SMBus transactions. I yet have to get my hands on the DSDT of ACPI implementations which actually access the SMBus to see exactly how they do it. > A user-installed operation region handler is an operation region handler > that is installed by a device driver. This feature would probably only > be used for custom (OEM-defined) operation region address spaces. (I > have not seen one yet.) For the standard address spaces (memory, I/O, > etc.), usually only the default handlers are used. Could regular Linux device drivers install such handlers for a specific I/O region? I'm asking because Rudolf Marek's proposal [1] to solve the concurrent access problem involved extending struct resource with callbacks to driver-specific routines to handle external access to an I/O region. This sounds somewhat similar to these "user-installed operation region handler" defined by ACPI, doesn't it? If ACPI already has an infrastructure to handle this problem, we probably want to use it rather than implementing our own. [1] http://marc.info/?l=linux-kernel&m\x117302946017204&w=2 -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: Could the k8temp driver be interfering with ACPI? @ 2007-04-03 7:21 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-04-03 7:21 UTC (permalink / raw) To: Moore, Robert Cc: Pavel Machek, Brown, Len, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Bob, On Mon, 2 Apr 2007 13:55:49 -0700, Moore, Robert wrote: > The ACPI specification allows concurrent execution of control methods > although methods cannot be preempted. The ACPICA interpreter mutex is > used to implement this model. > > From section 5.5.2, "Control Method Execution": Interpretation of a > Control Method is not preemptive, but it can block. When a control > method does block, the operating software can initiate or continue the > execution of a different control method. A control method can only > assume that access to global objects is exclusive for any period the > control method does not block. Do I/O regions count as "global objects"? > Therefore, the interpreter lock is acquired and a control method is > allowed to execute to completion unless it blocks on one of the events > described below. If the method blocks, the interpreter is unlocked and > other control methods may execute. > > I'm not sure what you mean by "in the middle of an SMBus transaction", I > don't know how long such a transaction is valid. I might guess that a > single transaction can only span a single operation region access, but > I'm not sure of this. Basically an SMBus transaction looks like this: 1* Prepare the transaction. 2* Start the transaction. 3* Wait for the transaction to complete, typically a few ms. 4* Read the result of the transaction. Steps 1 and 2 require writing to the SMBus I/O region. Step 4 requires reading from it, and so does step 3 if the wait loop is poll-based. The transaction is only safe if we have an exclusive access to the I/O region during all the 4 steps. My fear is that step 3 could be implemented by ACPI using either a Sleep() or Acquire() or Wait() opcode. If it is, we're doomed. OTOH, if it does, it is probably not even safe for itself, unless there's an additional, implementation-specific mutex to protect SMBus transactions. I yet have to get my hands on the DSDT of ACPI implementations which actually access the SMBus to see exactly how they do it. > A user-installed operation region handler is an operation region handler > that is installed by a device driver. This feature would probably only > be used for custom (OEM-defined) operation region address spaces. (I > have not seen one yet.) For the standard address spaces (memory, I/O, > etc.), usually only the default handlers are used. Could regular Linux device drivers install such handlers for a specific I/O region? I'm asking because Rudolf Marek's proposal [1] to solve the concurrent access problem involved extending struct resource with callbacks to driver-specific routines to handle external access to an I/O region. This sounds somewhat similar to these "user-installed operation region handler" defined by ACPI, doesn't it? If ACPI already has an infrastructure to handle this problem, we probably want to use it rather than implementing our own. [1] http://marc.info/?l=linux-kernel&m=117302946017204&w=2 -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* RE: Could the k8temp driver be interfering with ACPI? 2007-04-03 7:21 ` Jean Delvare (?) @ 2007-04-04 21:35 ` Moore, Robert -1 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-04-04 21:35 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Brown, Len, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors > Could regular Linux device drivers install such handlers for a specific > I/O region? No. ACPICA only supports operation region handlers on a per-address-space basis, not per-region. > Basically an SMBus transaction looks like this: > 1* Prepare the transaction. > 2* Start the transaction. > 3* Wait for the transaction to complete, typically a few ms. > 4* Read the result of the transaction. As far as the AML interpreter is concerned, access to the SMBus is via an operation region. So, each access to such a region would encompass a single SMBus transaction. Also, the interpreter remains locked during this access (I'm fairly sure) even though the EC driver is involved. > > execution of a different control method. A control method can only > > assume that access to global objects is exclusive for any period the > > control method does not block. > > Do I/O regions count as "global objects"? I think the spec is referring to any global namespace object. This includes operation regions, so the answer is yes, as long as access to the region does not block and cause the interpreter to be released. As far as ACPICA, none of the default handlers for operation regions will block. Bob > -----Original Message----- > From: Jean Delvare [mailto:khali@linux-fr.org] > Sent: Tuesday, April 03, 2007 12:21 AM > To: Moore, Robert > Cc: Pavel Machek; Brown, Len; Matthew Garrett; Chuck Ebbert; Rudolf Marek; > linux-acpi@vger.kernel.org; linux-kernel; lm-sensors@lm-sensors.org > Subject: Re: Could the k8temp driver be interfering with ACPI? > > Hi Bob, > > On Mon, 2 Apr 2007 13:55:49 -0700, Moore, Robert wrote: > > The ACPI specification allows concurrent execution of control methods > > although methods cannot be preempted. The ACPICA interpreter mutex is > > used to implement this model. > > > > From section 5.5.2, "Control Method Execution": Interpretation of a > > Control Method is not preemptive, but it can block. When a control > > method does block, the operating software can initiate or continue the > > execution of a different control method. A control method can only > > assume that access to global objects is exclusive for any period the > > control method does not block. > > Do I/O regions count as "global objects"? > > > Therefore, the interpreter lock is acquired and a control method is > > allowed to execute to completion unless it blocks on one of the events > > described below. If the method blocks, the interpreter is unlocked and > > other control methods may execute. > > > > I'm not sure what you mean by "in the middle of an SMBus transaction", I > > don't know how long such a transaction is valid. I might guess that a > > single transaction can only span a single operation region access, but > > I'm not sure of this. > > Basically an SMBus transaction looks like this: > 1* Prepare the transaction. > 2* Start the transaction. > 3* Wait for the transaction to complete, typically a few ms. > 4* Read the result of the transaction. > > Steps 1 and 2 require writing to the SMBus I/O region. Step 4 requires > reading from it, and so does step 3 if the wait loop is poll-based. The > transaction is only safe if we have an exclusive access to the I/O > region during all the 4 steps. My fear is that step 3 could be > implemented by ACPI using either a Sleep() or Acquire() or Wait() > opcode. If it is, we're doomed. OTOH, if it does, it is probably not > even safe for itself, unless there's an additional, > implementation-specific mutex to protect SMBus transactions. I yet have > to get my hands on the DSDT of ACPI implementations which actually > access the SMBus to see exactly how they do it. > > > A user-installed operation region handler is an operation region handler > > that is installed by a device driver. This feature would probably only > > be used for custom (OEM-defined) operation region address spaces. (I > > have not seen one yet.) For the standard address spaces (memory, I/O, > > etc.), usually only the default handlers are used. > > Could regular Linux device drivers install such handlers for a specific > I/O region? I'm asking because Rudolf Marek's proposal [1] to solve the > concurrent access problem involved extending struct resource with > callbacks to driver-specific routines to handle external access to an > I/O region. This sounds somewhat similar to these "user-installed > operation region handler" defined by ACPI, doesn't it? If ACPI already > has an infrastructure to handle this problem, we probably want to use > it rather than implementing our own. > > [1] http://marc.info/?l=linux-kernel&m=117302946017204&w=2 > > -- > Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-04 21:35 ` Moore, Robert 0 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-04-04 21:35 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Brown, Len, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors > Could regular Linux device drivers install such handlers for a specific > I/O region? No. ACPICA only supports operation region handlers on a per-address-space basis, not per-region. > Basically an SMBus transaction looks like this: > 1* Prepare the transaction. > 2* Start the transaction. > 3* Wait for the transaction to complete, typically a few ms. > 4* Read the result of the transaction. As far as the AML interpreter is concerned, access to the SMBus is via an operation region. So, each access to such a region would encompass a single SMBus transaction. Also, the interpreter remains locked during this access (I'm fairly sure) even though the EC driver is involved. > > execution of a different control method. A control method can only > > assume that access to global objects is exclusive for any period the > > control method does not block. > > Do I/O regions count as "global objects"? I think the spec is referring to any global namespace object. This includes operation regions, so the answer is yes, as long as access to the region does not block and cause the interpreter to be released. As far as ACPICA, none of the default handlers for operation regions will block. Bob > -----Original Message----- > From: Jean Delvare [mailto:khali@linux-fr.org] > Sent: Tuesday, April 03, 2007 12:21 AM > To: Moore, Robert > Cc: Pavel Machek; Brown, Len; Matthew Garrett; Chuck Ebbert; Rudolf Marek; > linux-acpi@vger.kernel.org; linux-kernel; lm-sensors@lm-sensors.org > Subject: Re: Could the k8temp driver be interfering with ACPI? > > Hi Bob, > > On Mon, 2 Apr 2007 13:55:49 -0700, Moore, Robert wrote: > > The ACPI specification allows concurrent execution of control methods > > although methods cannot be preempted. The ACPICA interpreter mutex is > > used to implement this model. > > > > From section 5.5.2, "Control Method Execution": Interpretation of a > > Control Method is not preemptive, but it can block. When a control > > method does block, the operating software can initiate or continue the > > execution of a different control method. A control method can only > > assume that access to global objects is exclusive for any period the > > control method does not block. > > Do I/O regions count as "global objects"? > > > Therefore, the interpreter lock is acquired and a control method is > > allowed to execute to completion unless it blocks on one of the events > > described below. If the method blocks, the interpreter is unlocked and > > other control methods may execute. > > > > I'm not sure what you mean by "in the middle of an SMBus transaction", I > > don't know how long such a transaction is valid. I might guess that a > > single transaction can only span a single operation region access, but > > I'm not sure of this. > > Basically an SMBus transaction looks like this: > 1* Prepare the transaction. > 2* Start the transaction. > 3* Wait for the transaction to complete, typically a few ms. > 4* Read the result of the transaction. > > Steps 1 and 2 require writing to the SMBus I/O region. Step 4 requires > reading from it, and so does step 3 if the wait loop is poll-based. The > transaction is only safe if we have an exclusive access to the I/O > region during all the 4 steps. My fear is that step 3 could be > implemented by ACPI using either a Sleep() or Acquire() or Wait() > opcode. If it is, we're doomed. OTOH, if it does, it is probably not > even safe for itself, unless there's an additional, > implementation-specific mutex to protect SMBus transactions. I yet have > to get my hands on the DSDT of ACPI implementations which actually > access the SMBus to see exactly how they do it. > > > A user-installed operation region handler is an operation region handler > > that is installed by a device driver. This feature would probably only > > be used for custom (OEM-defined) operation region address spaces. (I > > have not seen one yet.) For the standard address spaces (memory, I/O, > > etc.), usually only the default handlers are used. > > Could regular Linux device drivers install such handlers for a specific > I/O region? I'm asking because Rudolf Marek's proposal [1] to solve the > concurrent access problem involved extending struct resource with > callbacks to driver-specific routines to handle external access to an > I/O region. This sounds somewhat similar to these "user-installed > operation region handler" defined by ACPI, doesn't it? If ACPI already > has an infrastructure to handle this problem, we probably want to use > it rather than implementing our own. > > [1] http://marc.info/?l=linux-kernel&m\x117302946017204&w=2 > > -- > Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* RE: Could the k8temp driver be interfering with ACPI? @ 2007-04-04 21:35 ` Moore, Robert 0 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-04-04 21:35 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Brown, Len, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors > Could regular Linux device drivers install such handlers for a specific > I/O region? No. ACPICA only supports operation region handlers on a per-address-space basis, not per-region. > Basically an SMBus transaction looks like this: > 1* Prepare the transaction. > 2* Start the transaction. > 3* Wait for the transaction to complete, typically a few ms. > 4* Read the result of the transaction. As far as the AML interpreter is concerned, access to the SMBus is via an operation region. So, each access to such a region would encompass a single SMBus transaction. Also, the interpreter remains locked during this access (I'm fairly sure) even though the EC driver is involved. > > execution of a different control method. A control method can only > > assume that access to global objects is exclusive for any period the > > control method does not block. > > Do I/O regions count as "global objects"? I think the spec is referring to any global namespace object. This includes operation regions, so the answer is yes, as long as access to the region does not block and cause the interpreter to be released. As far as ACPICA, none of the default handlers for operation regions will block. Bob > -----Original Message----- > From: Jean Delvare [mailto:khali@linux-fr.org] > Sent: Tuesday, April 03, 2007 12:21 AM > To: Moore, Robert > Cc: Pavel Machek; Brown, Len; Matthew Garrett; Chuck Ebbert; Rudolf Marek; > linux-acpi@vger.kernel.org; linux-kernel; lm-sensors@lm-sensors.org > Subject: Re: Could the k8temp driver be interfering with ACPI? > > Hi Bob, > > On Mon, 2 Apr 2007 13:55:49 -0700, Moore, Robert wrote: > > The ACPI specification allows concurrent execution of control methods > > although methods cannot be preempted. The ACPICA interpreter mutex is > > used to implement this model. > > > > From section 5.5.2, "Control Method Execution": Interpretation of a > > Control Method is not preemptive, but it can block. When a control > > method does block, the operating software can initiate or continue the > > execution of a different control method. A control method can only > > assume that access to global objects is exclusive for any period the > > control method does not block. > > Do I/O regions count as "global objects"? > > > Therefore, the interpreter lock is acquired and a control method is > > allowed to execute to completion unless it blocks on one of the events > > described below. If the method blocks, the interpreter is unlocked and > > other control methods may execute. > > > > I'm not sure what you mean by "in the middle of an SMBus transaction", I > > don't know how long such a transaction is valid. I might guess that a > > single transaction can only span a single operation region access, but > > I'm not sure of this. > > Basically an SMBus transaction looks like this: > 1* Prepare the transaction. > 2* Start the transaction. > 3* Wait for the transaction to complete, typically a few ms. > 4* Read the result of the transaction. > > Steps 1 and 2 require writing to the SMBus I/O region. Step 4 requires > reading from it, and so does step 3 if the wait loop is poll-based. The > transaction is only safe if we have an exclusive access to the I/O > region during all the 4 steps. My fear is that step 3 could be > implemented by ACPI using either a Sleep() or Acquire() or Wait() > opcode. If it is, we're doomed. OTOH, if it does, it is probably not > even safe for itself, unless there's an additional, > implementation-specific mutex to protect SMBus transactions. I yet have > to get my hands on the DSDT of ACPI implementations which actually > access the SMBus to see exactly how they do it. > > > A user-installed operation region handler is an operation region handler > > that is installed by a device driver. This feature would probably only > > be used for custom (OEM-defined) operation region address spaces. (I > > have not seen one yet.) For the standard address spaces (memory, I/O, > > etc.), usually only the default handlers are used. > > Could regular Linux device drivers install such handlers for a specific > I/O region? I'm asking because Rudolf Marek's proposal [1] to solve the > concurrent access problem involved extending struct resource with > callbacks to driver-specific routines to handle external access to an > I/O region. This sounds somewhat similar to these "user-installed > operation region handler" defined by ACPI, doesn't it? If ACPI already > has an infrastructure to handle this problem, we probably want to use > it rather than implementing our own. > > [1] http://marc.info/?l=linux-kernel&m=117302946017204&w=2 > > -- > Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 11:47 ` Matthew Garrett @ 2007-03-02 14:10 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 14:10 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 14:10 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 14:10 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 14:10 ` Jean Delvare @ 2007-03-02 14:18 ` Matthew Garrett -1 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-03-02 14:18 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 14:18 ` Matthew Garrett 0 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-03-02 14:18 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 at srcf.ucam.org ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 14:18 ` Matthew Garrett @ 2007-03-02 21:04 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 21:04 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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: > > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 21:04 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 21:04 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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: > > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 21:04 ` Jean Delvare @ 2007-03-02 21:12 ` Matthew Garrett -1 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-03-02 21:12 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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: > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 21:12 ` Matthew Garrett 0 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-03-02 21:12 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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: > > 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 at srcf.ucam.org ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 21:12 ` Matthew Garrett @ 2007-03-03 9:53 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-03 9:53 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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: > > 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. > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-03 9:53 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-03 9:53 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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: > > 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. > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-03 9:53 ` Jean Delvare @ 2007-03-03 15:47 ` David Hubbard -1 siblings, 0 replies; 207+ messages in thread From: David Hubbard @ 2007-03-03 15:47 UTC (permalink / raw) To: Jean Delvare, Matthew Garrett, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert, Rudolf 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-03 15:47 ` David Hubbard 0 siblings, 0 replies; 207+ messages in thread From: David Hubbard @ 2007-03-03 15:47 UTC (permalink / raw) To: Jean Delvare, Matthew Garrett, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert, Rudolf 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-03 15:47 ` David Hubbard @ 2007-03-03 15:50 ` Matthew Garrett -1 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-03-03 15:50 UTC (permalink / raw) To: David Hubbard Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert, Rudolf 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-03 15:50 ` Matthew Garrett 0 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-03-03 15:50 UTC (permalink / raw) To: David Hubbard Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert, Rudolf 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 at srcf.ucam.org ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-03 15:50 ` Matthew Garrett @ 2007-03-03 17:08 ` Rudolf Marek -1 siblings, 0 replies; 207+ messages in thread From: Rudolf Marek @ 2007-03-03 17:08 UTC (permalink / raw) To: Matthew Garrett Cc: David Hubbard, Rudolf, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-03 17:08 ` Rudolf Marek 0 siblings, 0 replies; 207+ messages in thread From: Rudolf Marek @ 2007-03-03 17:08 UTC (permalink / raw) To: Matthew Garrett Cc: David Hubbard, Rudolf, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-03 17:08 ` Rudolf Marek @ 2007-03-04 17:29 ` Rudolf Marek -1 siblings, 0 replies; 207+ messages in thread From: Rudolf Marek @ 2007-03-04 17:29 UTC (permalink / raw) To: Matthew Garrett Cc: Chuck Ebbert, linux-kernel, lm-sensors, linux-acpi, Pavel Machek [-- Attachment #1: Type: text/plain, Size: 2675 bytes --] 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 [-- Attachment #2: acpi-io-sync.patch --] [-- Type: text/x-diff, Size: 7824 bytes --] Index: linux-2.6.20/include/linux/ioport.h =================================================================== --- linux-2.6.20.orig/include/linux/ioport.h 2007-03-04 10:31:03.457166952 +0100 +++ linux-2.6.20/include/linux/ioport.h 2007-03-04 15:55:03.458260761 +0100 @@ -14,10 +14,19 @@ * Resources are tree-like, allowing * nesting etc.. */ + +struct resource_ops { + int (*read_io)(u32 size, u32 port, u32 *where, void *priv); + int (*write_io)(u32 size, u32 port, u32 val, void *priv); + void *priv_data; +}; + struct resource { resource_size_t start; resource_size_t end; const char *name; + //void *resource_data; + struct resource_ops *res_ops; unsigned long flags; struct resource *parent, *sibling, *child; }; Index: linux-2.6.20/drivers/acpi/osl.c =================================================================== --- linux-2.6.20.orig/drivers/acpi/osl.c 2007-03-04 10:31:30.626715256 +0100 +++ linux-2.6.20/drivers/acpi/osl.c 2007-03-04 16:18:29.958412636 +0100 @@ -36,6 +36,7 @@ #include <linux/delay.h> #include <linux/workqueue.h> #include <linux/nmi.h> +#include <linux/ioport.h> #include <acpi/acpi.h> #include <asm/io.h> #include <acpi/acpi_bus.h> @@ -331,13 +332,8 @@ return ++t; } -acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width) +static acpi_status acpi_os_read_port_raw(acpi_io_address port, u32 * value, u32 width) { - u32 dummy; - - if (!value) - value = &dummy; - switch (width) { case 8: *(u8 *) value = inb(port); @@ -355,10 +351,51 @@ return AE_OK; } +acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width) +{ + acpi_status ret = AE_OK; + struct resource *conflict, res; + u32 dummy; + int retval; + + if (!value) + value = &dummy; + + printk("%s: Port %x\n", __FUNCTION__ , (int) port); + res.flags = 0; + 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) && (conflict->res_ops) && (conflict->res_ops->write_io)) { + printk("Redir called\n"); + retval = conflict->res_ops->read_io(width, port, value, conflict->res_ops->priv_data); + + //this needs coding fix + if (retval < 0) { + ret = acpi_os_read_port_raw(port, value, width); + } else { + ret = AE_OK; + } + } else { + printk("Ordinary job\n"); + ret = acpi_os_read_port_raw(port, value, width); + if (conflict == NULL) + release_resource(&res); + } + + return ret; +} + EXPORT_SYMBOL(acpi_os_read_port); -acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width) -{ +static acpi_status acpi_os_write_port_raw(acpi_io_address port, u32 value, u32 width) { + switch (width) { case 8: outb(value, port); @@ -376,6 +413,41 @@ return AE_OK; } +acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width) +{ + struct resource *conflict, res; + acpi_status ret = AE_OK; + int retval; + res.flags = 0; + res.start = port; + res.end = port + width/8 - 1; + res.name = "ACPI Access"; + printk("%s: Port %x\n", __FUNCTION__ , (int) port); + + conflict = ____request_resource(&ioport_resource, &res); + + while ((conflict) && (conflict->child)) + conflict = ____request_resource(conflict, &res); + + if ((conflict) && (conflict->res_ops) && (conflict->res_ops->write_io)) { + printk("Redir called\n"); + retval = conflict->res_ops->write_io(width, port, value, + conflict->res_ops->priv_data); + //this needs coding fix + if (retval < 0) { + ret = acpi_os_write_port_raw(port, value, width); + } else { + ret = AE_OK; + } + } else { + printk("Ordinary job\n"); + ret = acpi_os_write_port_raw(port, value, width); + if (conflict == NULL) + release_resource(&res); + } + return ret; +} + EXPORT_SYMBOL(acpi_os_write_port); acpi_status Index: linux-2.6.20/drivers/hwmon/w83627ehf.c =================================================================== --- linux-2.6.20.orig/drivers/hwmon/w83627ehf.c 2007-03-04 10:31:03.689180173 +0100 +++ linux-2.6.20/drivers/hwmon/w83627ehf.c 2007-03-04 15:51:23.737739602 +0100 @@ -245,6 +245,9 @@ char valid; /* !=0 if following fields are valid */ unsigned long last_updated; /* In jiffies */ + u8 reg_pointer; + u8 reg_bank; + /* Register values */ u8 in[10]; /* Register value */ u8 in_max[10]; /* Register value */ @@ -270,6 +273,7 @@ u8 fan_min_output[4]; /* minimum fan speed */ u8 fan_stop_time[4]; + struct resource_ops res_ops; }; static inline int is_word_sized(u16 reg) @@ -344,6 +348,74 @@ return 0; } + +//we may return error/unsuppored and legacy acpi outb/inb stuff might take a chance + +static int acpi_emul_read(u32 size, u32 port, u32 *where, void *priv_data) { + struct i2c_client *client = (struct i2c_client *) priv_data; + struct w83627ehf_data *data = i2c_get_clientdata(client); + u16 tmp, reg = (data->reg_bank << 8) | data->reg_pointer; + + if (size != 8) { + printk("this io port size is not emulated\n"); + return -EINVAL; + } + + if (port != (client->addr + DATA_REG_OFFSET)) { + printk("this port %x is not emulated\n", port); + return -EINVAL; + } + + printk("%s: client addr %x port: %x \n", __FUNCTION__ , client->addr, port); + printk("Calling read with bank %x reg %x (%x)\n", + data->reg_bank, data->reg_pointer,reg); + + tmp = w83627ehf_read_value(client, reg); + *((u8 *) where) = (is_word_sized(reg)) ? tmp >> 8 : tmp; + return 0; +} + +static int acpi_emul_write(u32 size, u32 port, u32 val, void *priv_data) { + struct i2c_client *client = (struct i2c_client *) priv_data; + struct w83627ehf_data *data = i2c_get_clientdata(client); + u16 reg; + + if (size != 8) { + printk("this io port size is not emulated\n"); + return -EINVAL; + } + + printk("%s client addr %x port %x\n", __FUNCTION__ , client->addr, port); + + if (port == (client->addr + ADDR_REG_OFFSET)) { + data->reg_pointer = val; + } else if (port == (client->addr + DATA_REG_OFFSET)) { + + if (data->reg_pointer == W83627EHF_REG_BANK) { + data->reg_bank = val & 0x3; + printk("REG bank changed %x\n", data->reg_bank); + } else { + reg = (data->reg_bank << 8) | data->reg_pointer; + printk("Calling write with bank %x reg %x value %x\n", + data->reg_bank, data->reg_pointer, val); + + if (is_word_sized(reg)) { + u16 tmp = w83627ehf_read_value(client, reg); + tmp &= 0xff; + w83627ehf_write_value(client, reg, (val << 8) | tmp); + } else { + w83627ehf_write_value(client, reg, val); + } + data->valid = 0; /* invalidate cache */ + } + } else { + printk("this port %x is not emulated\n", port); + return -EINVAL; + } + return 0; +} + + /* This function assumes that the caller holds data->update_lock */ static void w83627ehf_write_fan_div(struct i2c_client *client, int nr) { @@ -1173,11 +1245,12 @@ struct i2c_client *client; struct w83627ehf_data *data; struct device *dev; + struct resource *res; u8 fan4pin, fan5pin; int i, err = 0; - if (!request_region(address + REGION_OFFSET, REGION_LENGTH, - w83627ehf_driver.driver.name)) { + if (!(res = request_region(address + REGION_OFFSET, REGION_LENGTH, + w83627ehf_driver.driver.name))) { err = -EBUSY; goto exit; } @@ -1292,6 +1365,13 @@ goto exit_remove; } + /* there is race condition right now */ + + printk("RES %p res->res_ops %p client %p\n",res, res->res_ops, client); + data->res_ops.write_io = &acpi_emul_write; + data->res_ops.read_io = &acpi_emul_read; + data->res_ops.priv_data = client; + res->res_ops=&data->res_ops; return 0; exit_remove: @@ -1315,6 +1395,7 @@ if ((err = i2c_detach_client(client))) return err; + release_region(client->addr + REGION_OFFSET, REGION_LENGTH); kfree(data); ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-04 17:29 ` Rudolf Marek 0 siblings, 0 replies; 207+ messages in thread From: Rudolf Marek @ 2007-03-04 17:29 UTC (permalink / raw) To: Matthew Garrett Cc: Chuck Ebbert, linux-kernel, lm-sensors, linux-acpi, Pavel Machek 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: acpi-io-sync.patch Type: text/x-diff Size: 7824 bytes Desc: not available Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070304/8d85322d/attachment.bin ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-04 17:29 ` Rudolf Marek @ 2007-03-05 21:16 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-05 21:16 UTC (permalink / raw) To: Rudolf Marek Cc: Matthew Garrett, linux-acpi, Pavel Machek, linux-kernel, Chuck Ebbert, lm-sensors 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: > +acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width) > +{ > + acpi_status ret = AE_OK; > + struct resource *conflict, res; > + u32 dummy; > + int retval; > + > + if (!value) > + value = &dummy; > + > + printk("%s: Port %x\n", __FUNCTION__ , (int) port); > + res.flags = 0; > + 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) && (conflict->res_ops) && (conflict->res_ops->write_io)) { You want to check that conflict->res_ops->read_io exists, not write_io. > + printk("Redir called\n"); > + retval = conflict->res_ops->read_io(width, port, value, conflict->res_ops->priv_data); > + > + //this needs coding fix > + if (retval < 0) { > + ret = acpi_os_read_port_raw(port, value, width); > + } else { > + ret = AE_OK; > + } > + } else { > + printk("Ordinary job\n"); > + ret = acpi_os_read_port_raw(port, value, width); > + if (conflict == NULL) > + release_resource(&res); > + } > + > + return ret; > +} 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-05 21:16 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-05 21:16 UTC (permalink / raw) To: Rudolf Marek Cc: Matthew Garrett, linux-acpi, Pavel Machek, linux-kernel, Chuck Ebbert, lm-sensors 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: > +acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width) > +{ > + acpi_status ret = AE_OK; > + struct resource *conflict, res; > + u32 dummy; > + int retval; > + > + if (!value) > + value = &dummy; > + > + printk("%s: Port %x\n", __FUNCTION__ , (int) port); > + res.flags = 0; > + 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) && (conflict->res_ops) && (conflict->res_ops->write_io)) { You want to check that conflict->res_ops->read_io exists, not write_io. > + printk("Redir called\n"); > + retval = conflict->res_ops->read_io(width, port, value, conflict->res_ops->priv_data); > + > + //this needs coding fix > + if (retval < 0) { > + ret = acpi_os_read_port_raw(port, value, width); > + } else { > + ret = AE_OK; > + } > + } else { > + printk("Ordinary job\n"); > + ret = acpi_os_read_port_raw(port, value, width); > + if (conflict = NULL) > + release_resource(&res); > + } > + > + return ret; > +} 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-05 21:16 ` Jean Delvare @ 2007-03-05 21:35 ` David Hubbard -1 siblings, 0 replies; 207+ messages in thread From: David Hubbard @ 2007-03-05 21:35 UTC (permalink / raw) To: Jean Delvare, Rudolf Marek, Matthew Garrett, Ebbert, Chuck, linux-kernel, linux-acpi, Machek, Pavel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-05 21:35 ` David Hubbard 0 siblings, 0 replies; 207+ messages in thread From: David Hubbard @ 2007-03-05 21:35 UTC (permalink / raw) To: Jean Delvare, Rudolf Marek, Matthew Garrett, Ebbert, Chuck, linux-kernel, linux-acpi, Machek, Pavel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-05 21:35 ` David Hubbard @ 2007-03-06 15:10 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-06 15:10 UTC (permalink / raw) To: David Hubbard Cc: Rudolf Marek, Matthew Garrett, Ebbert, Chuck, linux-kernel, linux-acpi, Machek, Pavel, lm-sensors Hi David, On Mon, 5 Mar 2007 13:35:20 -0800, David Hubbard wrote: > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-06 15:10 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-06 15:10 UTC (permalink / raw) To: David Hubbard Cc: Rudolf Marek, Matthew Garrett, Ebbert, Chuck, linux-kernel, linux-acpi, Machek, Pavel, lm-sensors Hi David, On Mon, 5 Mar 2007 13:35:20 -0800, David Hubbard wrote: > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-03 15:47 ` David Hubbard @ 2007-03-04 10:54 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-04 10:54 UTC (permalink / raw) To: David Hubbard Cc: Matthew Garrett, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert, Rudolf Hi David, On Sat, 3 Mar 2007 08:47:21 -0700, David Hubbard wrote: > > 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. 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-04 10:54 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-04 10:54 UTC (permalink / raw) To: David Hubbard Cc: Matthew Garrett, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert, Rudolf Hi David, On Sat, 3 Mar 2007 08:47:21 -0700, David Hubbard wrote: > > 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. 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-03 9:53 ` Jean Delvare @ 2007-03-05 22:25 ` Pavel Machek -1 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-05 22:25 UTC (permalink / raw) To: Jean Delvare Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-05 22:25 ` Pavel Machek 0 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-05 22:25 UTC (permalink / raw) To: Jean Delvare Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-05 22:25 ` Pavel Machek @ 2007-03-06 7:55 ` Benny Amorsen -1 siblings, 0 replies; 207+ messages in thread From: Benny Amorsen @ 2007-03-06 7:55 UTC (permalink / raw) To: linux-kernel; +Cc: linux-acpi, lm-sensors >>>>> "PM" == Pavel Machek <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-06 7:55 ` Benny Amorsen 0 siblings, 0 replies; 207+ messages in thread From: Benny Amorsen @ 2007-03-06 7:55 UTC (permalink / raw) To: linux-kernel; +Cc: linux-acpi, lm-sensors >>>>> "PM" = Pavel Machek <pavel at ucw.cz> 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-05 22:25 ` Pavel Machek @ 2007-03-06 15:26 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-06 15:26 UTC (permalink / raw) To: Pavel Machek Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Pavel, On Mon, 5 Mar 2007 22:25:48 +0000, Pavel Machek wrote: > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-06 15:26 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-06 15:26 UTC (permalink / raw) To: Pavel Machek Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Pavel, On Mon, 5 Mar 2007 22:25:48 +0000, Pavel Machek wrote: > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-06 15:26 ` Jean Delvare (?) @ 2007-03-06 20:07 ` Stefan Monnier -1 siblings, 0 replies; 207+ messages in thread From: Stefan Monnier @ 2007-03-06 20:07 UTC (permalink / raw) To: linux-acpi; +Cc: linux-kernel, lm-sensors >> > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-06 20:07 ` Stefan Monnier 0 siblings, 0 replies; 207+ messages in thread From: Stefan Monnier @ 2007-03-06 20:07 UTC (permalink / raw) To: linux-acpi; +Cc: linux-kernel, lm-sensors >> > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-06 20:07 ` Stefan Monnier 0 siblings, 0 replies; 207+ messages in thread From: Stefan Monnier @ 2007-03-06 20:07 UTC (permalink / raw) To: linux-kernel; +Cc: linux-acpi, lm-sensors >> > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-06 15:26 ` Jean Delvare @ 2007-03-06 21:20 ` Pavel Machek -1 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-06 21:20 UTC (permalink / raw) To: Jean Delvare Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-06 21:20 ` Pavel Machek 0 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-06 21:20 UTC (permalink / raw) To: Jean Delvare Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* RE: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-06 21:20 ` Pavel Machek (?) @ 2007-03-06 21:25 ` Moore, Robert -1 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-03-06 21:25 UTC (permalink / raw) To: Pavel Machek, Jean Delvare Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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! > > > > > 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 > - > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-06 21:25 ` Moore, Robert 0 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-03-06 21:25 UTC (permalink / raw) To: Pavel Machek, Jean Delvare Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 at vger.kernel.org [mailto:linux-acpi- > owner at 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 at vger.kernel.org; linux-kernel; lm-sensors at lm-sensors.org > Subject: Re: [lm-sensors] Could the k8temp driver be interfering with > ACPI? > > Hi! > > > > > 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 > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 207+ messages in thread
* RE: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-06 21:25 ` Moore, Robert 0 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-03-06 21:25 UTC (permalink / raw) To: Pavel Machek, Jean Delvare Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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! > > > > > 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 > - > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-03 9:53 ` Jean Delvare @ 2007-03-18 19:36 ` richardvoigt at gmail.com -1 siblings, 0 replies; 207+ messages in thread From: richardvoigt @ 2007-03-18 19:36 UTC (permalink / raw) To: Jean Delvare Cc: Matthew Garrett, Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On 3/3/07, Jean Delvare <khali@linux-fr.org> wrote: > 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: > > > 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. I recall that one of the stated drawbacks of a lock was that no ACPI code could execute while the hwmon driver was doing its fairly lengthy conversation with the hardware. It seems that using transactional concepts here would solve that problem. For example, the hwmon driver issues a start transaction request. The first write request to any given location (bank register for example) causes the previous memory value to be saved. Then, instead of locking AML out, AML is allowed to execute, but any access to the memory/port ranges reserved by the driver (when the transaction is set up) cause the hwmon transaction to be rolled back so the AML sees the expected state. Then AML proceeds as usual. When hwmon tries additional operations, they fail with some "transaction interrupted" error message, indicating to the hwmon driver to start over. The only issue with this that I can see, is that if AML isn['t executed atomically wrt hwmon, then knowing when it is safe for hwmon to retry is going to be difficult. This probably requires changes to every hwmon driver, but they can be updated piecemeal, starting with the ones most commonly found in notebooks, where ACPI is most important. ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-18 19:36 ` richardvoigt at gmail.com 0 siblings, 0 replies; 207+ messages in thread From: richardvoigt at gmail.com @ 2007-03-18 19:36 UTC (permalink / raw) To: Jean Delvare Cc: Matthew Garrett, Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On 3/3/07, Jean Delvare <khali at linux-fr.org> wrote: > 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: > > > 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. I recall that one of the stated drawbacks of a lock was that no ACPI code could execute while the hwmon driver was doing its fairly lengthy conversation with the hardware. It seems that using transactional concepts here would solve that problem. For example, the hwmon driver issues a start transaction request. The first write request to any given location (bank register for example) causes the previous memory value to be saved. Then, instead of locking AML out, AML is allowed to execute, but any access to the memory/port ranges reserved by the driver (when the transaction is set up) cause the hwmon transaction to be rolled back so the AML sees the expected state. Then AML proceeds as usual. When hwmon tries additional operations, they fail with some "transaction interrupted" error message, indicating to the hwmon driver to start over. The only issue with this that I can see, is that if AML isn['t executed atomically wrt hwmon, then knowing when it is safe for hwmon to retry is going to be difficult. This probably requires changes to every hwmon driver, but they can be updated piecemeal, starting with the ones most commonly found in notebooks, where ACPI is most important. ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-18 19:36 ` richardvoigt at gmail.com @ 2007-03-19 7:08 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-19 7:08 UTC (permalink / raw) To: Richard Voigt Cc: Matthew Garrett, Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Richard, On Sun, 18 Mar 2007 14:36:08 -0500, Richard Voigt wrote: > On 3/3/07, Jean Delvare wrote: > > On Fri, 2 Mar 2007 21:12:51 +0000, Matthew Garrett wrote: > > > 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. > > I recall that one of the stated drawbacks of a lock was that no ACPI > code could execute while the hwmon driver was doing its fairly lengthy > conversation with the hardware. > > It seems that using transactional concepts here would solve that > problem. For example, the hwmon driver issues a start transaction > request. The first write request to any given location (bank register > for example) causes the previous memory value to be saved. Then, > instead of locking AML out, AML is allowed to execute, but any access > to the memory/port ranges reserved by the driver (when the transaction > is set up) cause the hwmon transaction to be rolled back so the AML > sees the expected state. Then AML proceeds as usual. When hwmon > tries additional operations, they fail with some "transaction > interrupted" error message, indicating to the hwmon driver to start > over. > > The only issue with this that I can see, is that if AML isn't > executed atomically wrt hwmon, then knowing when it is safe for hwmon > to retry is going to be difficult. No. We're not rolling back anything, it's totally unrealistic. These are device drivers we're talking about here, not a database. The I/O accesses done by the hardware monitoring drivers are not that long, so AML gets to wait for them to be finished, and that's it. There is no valid reason to give the priority to AML over regular device drivers. Rudolf Marek's approach sounds much better. > This probably requires changes to every hwmon driver, but they can be > updated piecemeal, starting with the ones most commonly found in > notebooks, where ACPI is most important. Most notebooks don't expose their hardware monitoring chip at all. Those which do use SMBus devices in majority, where I/O forwarding is going to be difficult, as it needs to be done at the SMBus controller level, not the hardware monitoring device level. I want to get my hands on such a laptop first though, as I need to see what exacly ACPI is doing before I can think of a solution. -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-19 7:08 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-19 7:08 UTC (permalink / raw) To: Richard Voigt Cc: Matthew Garrett, Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Richard, On Sun, 18 Mar 2007 14:36:08 -0500, Richard Voigt wrote: > On 3/3/07, Jean Delvare wrote: > > On Fri, 2 Mar 2007 21:12:51 +0000, Matthew Garrett wrote: > > > 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. > > I recall that one of the stated drawbacks of a lock was that no ACPI > code could execute while the hwmon driver was doing its fairly lengthy > conversation with the hardware. > > It seems that using transactional concepts here would solve that > problem. For example, the hwmon driver issues a start transaction > request. The first write request to any given location (bank register > for example) causes the previous memory value to be saved. Then, > instead of locking AML out, AML is allowed to execute, but any access > to the memory/port ranges reserved by the driver (when the transaction > is set up) cause the hwmon transaction to be rolled back so the AML > sees the expected state. Then AML proceeds as usual. When hwmon > tries additional operations, they fail with some "transaction > interrupted" error message, indicating to the hwmon driver to start > over. > > The only issue with this that I can see, is that if AML isn't > executed atomically wrt hwmon, then knowing when it is safe for hwmon > to retry is going to be difficult. No. We're not rolling back anything, it's totally unrealistic. These are device drivers we're talking about here, not a database. The I/O accesses done by the hardware monitoring drivers are not that long, so AML gets to wait for them to be finished, and that's it. There is no valid reason to give the priority to AML over regular device drivers. Rudolf Marek's approach sounds much better. > This probably requires changes to every hwmon driver, but they can be > updated piecemeal, starting with the ones most commonly found in > notebooks, where ACPI is most important. Most notebooks don't expose their hardware monitoring chip at all. Those which do use SMBus devices in majority, where I/O forwarding is going to be difficult, as it needs to be done at the SMBus controller level, not the hardware monitoring device level. I want to get my hands on such a laptop first though, as I need to see what exacly ACPI is doing before I can think of a solution. -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* RE: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 21:04 ` Jean Delvare (?) @ 2007-03-02 22:07 ` Moore, Robert -1 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-03-02 22:07 UTC (permalink / raw) To: Jean Delvare, Matthew Garrett Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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: > > 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? > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 22:07 ` Moore, Robert 0 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-03-02 22:07 UTC (permalink / raw) To: Jean Delvare, Matthew Garrett Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 at vger.kernel.org [mailto:linux-acpi- > owner at 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 at vger.kernel.org; > linux-kernel; lm-sensors at 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: > > 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? > > 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 at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 207+ messages in thread
* RE: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 22:07 ` Moore, Robert 0 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-03-02 22:07 UTC (permalink / raw) To: Jean Delvare, Matthew Garrett Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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: > > 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? > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 22:07 ` Moore, Robert @ 2007-03-09 7:18 ` Pavel Machek -1 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-09 7:18 UTC (permalink / raw) To: Moore, Robert Cc: Jean Delvare, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-09 7:18 ` Pavel Machek 0 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-09 7:18 UTC (permalink / raw) To: Moore, Robert Cc: Jean Delvare, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-09 7:18 ` Pavel Machek @ 2007-03-09 10:24 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-09 10:24 UTC (permalink / raw) To: Pavel Machek, Moore, Robert Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Fri, 9 Mar 2007 07:18:56 +0000, Pavel Machek wrote: > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-09 10:24 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-09 10:24 UTC (permalink / raw) To: Pavel Machek, Moore, Robert Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Fri, 9 Mar 2007 07:18:56 +0000, Pavel Machek wrote: > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-09 10:24 ` Jean Delvare @ 2007-03-09 10:39 ` Alexey Starikovskiy -1 siblings, 0 replies; 207+ messages in thread From: Alexey Starikovskiy @ 2007-03-09 10:39 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Moore, Robert, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Jean Delvare wrote: > On Fri, 9 Mar 2007 07:18:56 +0000, Pavel Machek wrote: > >>> 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. ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-09 10:39 ` Alexey Starikovskiy 0 siblings, 0 replies; 207+ messages in thread From: Alexey Starikovskiy @ 2007-03-09 10:39 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Moore, Robert, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Jean Delvare wrote: > On Fri, 9 Mar 2007 07:18:56 +0000, Pavel Machek wrote: > >>> 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. ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-09 10:39 ` Alexey Starikovskiy @ 2007-03-09 11:21 ` Pavel Machek -1 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-09 11:21 UTC (permalink / raw) To: Alexey Starikovskiy Cc: Jean Delvare, Moore, Robert, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > >>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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-09 11:21 ` Pavel Machek 0 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-09 11:21 UTC (permalink / raw) To: Alexey Starikovskiy Cc: Jean Delvare, Moore, Robert, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > >>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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-09 10:39 ` Alexey Starikovskiy @ 2007-03-09 17:23 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-09 17:23 UTC (permalink / raw) To: Alexey Starikovskiy Cc: Pavel Machek, Moore, Robert, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Alexey, On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote: > Jean Delvare wrote: > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-09 17:23 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-09 17:23 UTC (permalink / raw) To: Alexey Starikovskiy Cc: Pavel Machek, Moore, Robert, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Alexey, On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote: > Jean Delvare wrote: > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-09 17:23 ` Jean Delvare @ 2007-03-09 17:35 ` Alexey Starikovskiy -1 siblings, 0 replies; 207+ messages in thread From: Alexey Starikovskiy @ 2007-03-09 17:35 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Moore, Robert, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Jean Delvare wrote: > Hi Alexey, > > On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote: > >> Jean Delvare wrote: >> >>> 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. ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-09 17:35 ` Alexey Starikovskiy 0 siblings, 0 replies; 207+ messages in thread From: Alexey Starikovskiy @ 2007-03-09 17:35 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Moore, Robert, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Jean Delvare wrote: > Hi Alexey, > > On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote: > >> Jean Delvare wrote: >> >>> 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. ^ permalink raw reply [flat|nested] 207+ messages in thread
* RE: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-09 17:35 ` Alexey Starikovskiy (?) @ 2007-03-09 21:03 ` Moore, Robert -1 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-03-09 21:03 UTC (permalink / raw) To: Alexey Starikovskiy, Jean Delvare Cc: Pavel Machek, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors, Therien, Guy, Walz, Michael 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: > > Hi Alexey, > > > > On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote: > > > >> Jean Delvare wrote: > >> > >>> 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. ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-09 21:03 ` Moore, Robert 0 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-03-09 21:03 UTC (permalink / raw) To: Alexey Starikovskiy, Jean Delvare Cc: Pavel Machek, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors, Therien, Guy, Walz, Michael 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 at 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 at vger.kernel.org; linux-kernel; lm-sensors at lm-sensors.org > Subject: Re: [lm-sensors] Could the k8temp driver be interfering with > ACPI? > > Jean Delvare wrote: > > Hi Alexey, > > > > On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote: > > > >> Jean Delvare wrote: > >> > >>> 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. ^ permalink raw reply [flat|nested] 207+ messages in thread
* RE: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-09 21:03 ` Moore, Robert 0 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-03-09 21:03 UTC (permalink / raw) To: Alexey Starikovskiy, Jean Delvare Cc: Pavel Machek, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors, Therien, Guy, Walz, Michael 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: > > Hi Alexey, > > > > On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote: > > > >> Jean Delvare wrote: > >> > >>> 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. ^ permalink raw reply [flat|nested] 207+ messages in thread
* RE: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-09 7:18 ` Pavel Machek (?) @ 2007-03-09 20:56 ` Moore, Robert -1 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-03-09 20:56 UTC (permalink / raw) To: Pavel Machek Cc: Jean Delvare, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors, Therien, Guy, Walz, Michael 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! > > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-09 20:56 ` Moore, Robert 0 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-03-09 20:56 UTC (permalink / raw) To: Pavel Machek Cc: Jean Delvare, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors, Therien, Guy, Walz, Michael 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 at ucw.cz] > Sent: Thursday, March 08, 2007 11:19 PM > To: Moore, Robert > Cc: Jean Delvare; Matthew Garrett; Chuck Ebbert; Rudolf Marek; linux- > acpi at vger.kernel.org; linux-kernel; lm-sensors at lm-sensors.org > Subject: Re: [lm-sensors] Could the k8temp driver be interfering with > ACPI? > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* RE: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-09 20:56 ` Moore, Robert 0 siblings, 0 replies; 207+ messages in thread From: Moore, Robert @ 2007-03-09 20:56 UTC (permalink / raw) To: Pavel Machek Cc: Jean Delvare, Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors, Therien, Guy, Walz, Michael 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! > > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 14:10 ` Jean Delvare @ 2007-03-02 14:22 ` Pavel Machek -1 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-02 14:22 UTC (permalink / raw) To: Jean Delvare Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > 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. > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 14:22 ` Pavel Machek 0 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-02 14:22 UTC (permalink / raw) To: Jean Delvare Cc: Matthew Garrett, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > 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. > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 11:40 ` Pavel Machek @ 2007-03-02 14:03 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 14:03 UTC (permalink / raw) To: Pavel Machek Cc: Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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? > > 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. > > 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. > > 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. > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 14:03 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 14:03 UTC (permalink / raw) To: Pavel Machek Cc: Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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? > > 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. > > 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. > > 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. > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 14:03 ` Jean Delvare @ 2007-03-02 14:24 ` Pavel Machek -1 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-02 14:24 UTC (permalink / raw) To: Jean Delvare Cc: Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > 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. > > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 14:24 ` Pavel Machek 0 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-03-02 14:24 UTC (permalink / raw) To: Jean Delvare Cc: Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > 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. > > > 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 14:03 ` Jean Delvare @ 2007-03-02 14:57 ` Matthew Garrett -1 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-03-02 14:57 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply related [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 14:57 ` Matthew Garrett 0 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-03-02 14:57 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 at srcf.ucam.org ^ permalink raw reply related [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 14:57 ` Matthew Garrett @ 2007-03-02 21:41 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 21:41 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 21:41 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-02 21:41 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 21:41 ` Jean Delvare @ 2007-03-02 21:46 ` Matthew Garrett -1 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-03-02 21:46 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-02 21:46 ` Matthew Garrett 0 siblings, 0 replies; 207+ messages in thread From: Matthew Garrett @ 2007-03-02 21:46 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 at srcf.ucam.org ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 21:46 ` Matthew Garrett @ 2007-03-06 21:28 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-06 21:28 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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: > > > 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 <khali@linux-fr.org> --- 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-03-06 21:28 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-03-06 21:28 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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: > > > 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 <khali at linux-fr.org> --- 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-03-02 14:03 ` Jean Delvare @ 2007-04-13 18:18 ` Bjorn Helgaas -1 siblings, 0 replies; 207+ messages in thread From: Bjorn Helgaas @ 2007-04-13 18:18 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Friday 02 March 2007 07:03, Jean Delvare wrote: > ... 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. ... > > So, can ACPI actually reserve the ports it accesses? Sorry to join this discussion so late. ACPI tells us the resources used by devices. Today, we don't reserve ACPI resources until a driver claims a device. PCI does some sort of reservation up front, before the driver claims devices. Conceptually, I think ACPI should do the same thing, and I don't think it's that hard to do. But breaking things like lmsensors would make the transition painful. Bjorn ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-13 18:18 ` Bjorn Helgaas 0 siblings, 0 replies; 207+ messages in thread From: Bjorn Helgaas @ 2007-04-13 18:18 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Friday 02 March 2007 07:03, Jean Delvare wrote: > ... 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. ... > > So, can ACPI actually reserve the ports it accesses? Sorry to join this discussion so late. ACPI tells us the resources used by devices. Today, we don't reserve ACPI resources until a driver claims a device. PCI does some sort of reservation up front, before the driver claims devices. Conceptually, I think ACPI should do the same thing, and I don't think it's that hard to do. But breaking things like lmsensors would make the transition painful. Bjorn _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-04-13 18:18 ` Bjorn Helgaas @ 2007-04-13 20:07 ` Pavel Machek -1 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-04-13 20:07 UTC (permalink / raw) To: Bjorn Helgaas Cc: Jean Delvare, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > ... 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. ... > > > > So, can ACPI actually reserve the ports it accesses? > > Sorry to join this discussion so late. > > ACPI tells us the resources used by devices. Today, we don't > reserve Problem seems to be that ACPI does _not_ tell us which ports it accesses from AML code. But we already found a lock we can take; AFAICT we know how to solve this problem. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-13 20:07 ` Pavel Machek 0 siblings, 0 replies; 207+ messages in thread From: Pavel Machek @ 2007-04-13 20:07 UTC (permalink / raw) To: Bjorn Helgaas Cc: Jean Delvare, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi! > > ... 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. ... > > > > So, can ACPI actually reserve the ports it accesses? > > Sorry to join this discussion so late. > > ACPI tells us the resources used by devices. Today, we don't > reserve Problem seems to be that ACPI does _not_ tell us which ports it accesses from AML code. But we already found a lock we can take; AFAICT we know how to solve this problem. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-04-13 20:07 ` Pavel Machek @ 2007-04-13 20:59 ` Bjorn Helgaas -1 siblings, 0 replies; 207+ messages in thread From: Bjorn Helgaas @ 2007-04-13 20:59 UTC (permalink / raw) To: Pavel Machek Cc: Jean Delvare, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Friday 13 April 2007 14:07, Pavel Machek wrote: > > > ... 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. ... > > > > > > So, can ACPI actually reserve the ports it accesses? > > > > Sorry to join this discussion so late. > > > > ACPI tells us the resources used by devices. Today, we don't > > reserve > > Problem seems to be that ACPI does _not_ tell us which ports it > accesses from AML code. I think that would violate at least the spirit of the ACPI spec. The example in section 11.6 of the ACPI 3.0 spec shows a _TMP method that runs an EC method to read the temp, and the EC ioport usage is correctly declared in the EC device's _CRS method. Of course, there are always BIOS defects. But if we could make a case that a BIOS that doesn't declare the resources used by the AML is defective, we could add quirks to reserve the undeclared resources. Chuck's last update (http://lkml.org/lkml/2007/2/20/136) says his problem turned out to be unrelated to k8temp and may have gone away after a BIOS update. > But we already found a lock we can take; AFAICT we know how to solve > this problem. This might solve it, but doesn't seem like a clean way to do it. I don't like the idea of sharing a lock between drivers and ACPI. k8temp happens to be x86-dependent, so we'll always have ACPI, but in principle, we could have the same problem with an arch-independent PCI driver that only has ACPI on x86 and ia64 platforms. (BTW, if Chuck's problem was solved by the BIOS update, I assume there *is* another instance of the problem that we're trying to solve with this lock.) Bjorn ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-13 20:59 ` Bjorn Helgaas 0 siblings, 0 replies; 207+ messages in thread From: Bjorn Helgaas @ 2007-04-13 20:59 UTC (permalink / raw) To: Pavel Machek Cc: Jean Delvare, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Friday 13 April 2007 14:07, Pavel Machek wrote: > > > ... 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. ... > > > > > > So, can ACPI actually reserve the ports it accesses? > > > > Sorry to join this discussion so late. > > > > ACPI tells us the resources used by devices. Today, we don't > > reserve > > Problem seems to be that ACPI does _not_ tell us which ports it > accesses from AML code. I think that would violate at least the spirit of the ACPI spec. The example in section 11.6 of the ACPI 3.0 spec shows a _TMP method that runs an EC method to read the temp, and the EC ioport usage is correctly declared in the EC device's _CRS method. Of course, there are always BIOS defects. But if we could make a case that a BIOS that doesn't declare the resources used by the AML is defective, we could add quirks to reserve the undeclared resources. Chuck's last update (http://lkml.org/lkml/2007/2/20/136) says his problem turned out to be unrelated to k8temp and may have gone away after a BIOS update. > But we already found a lock we can take; AFAICT we know how to solve > this problem. This might solve it, but doesn't seem like a clean way to do it. I don't like the idea of sharing a lock between drivers and ACPI. k8temp happens to be x86-dependent, so we'll always have ACPI, but in principle, we could have the same problem with an arch-independent PCI driver that only has ACPI on x86 and ia64 platforms. (BTW, if Chuck's problem was solved by the BIOS update, I assume there *is* another instance of the problem that we're trying to solve with this lock.) Bjorn _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-04-13 20:59 ` Bjorn Helgaas @ 2007-04-15 9:41 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-04-15 9:41 UTC (permalink / raw) To: Bjorn Helgaas Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Bjorn, On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote: > On Friday 13 April 2007 14:07, Pavel Machek wrote: > > > > ... 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. ... > > > > > > > > So, can ACPI actually reserve the ports it accesses? > > > > > > Sorry to join this discussion so late. > > > > > > ACPI tells us the resources used by devices. Today, we don't > > > reserve > > > > Problem seems to be that ACPI does _not_ tell us which ports it > > accesses from AML code. > > I think that would violate at least the spirit of the ACPI spec. > The example in section 11.6 of the ACPI 3.0 spec shows a _TMP > method that runs an EC method to read the temp, and the EC ioport > usage is correctly declared in the EC device's _CRS method. > > Of course, there are always BIOS defects. But if we could make a > case that a BIOS that doesn't declare the resources used by the AML > is defective, we could add quirks to reserve the undeclared resources. Only realistic if the list of systems needing a quirk is small. Do you think that would be the case? > > But we already found a lock we can take; AFAICT we know how to solve > > this problem. We even have two solutions, but both have drawbacks. The AML lock solution has performance issue. It could be improved with a better semaphore primitive, but that needs to be implemented first. It also requires to modify all drivers ACPI might conflict with, and that's a rather long list. Rudolf Marek's port forwarding idea should perform better, and might also be useful for other problems than ACPI vs. regular drivers, however it makes resources bigger, and requires to modify the same long list of drivers, and with specific code for every driver. I'm not sure that it will be possible for all driver in practice, as this more or less requires to forecast the I/O access pattern of ACPI. > This might solve it, but doesn't seem like a clean way to do it. > I don't like the idea of sharing a lock between drivers and ACPI. > k8temp happens to be x86-dependent, so we'll always have ACPI, but > in principle, we could have the same problem with an arch-independent > PCI driver that only has ACPI on x86 and ia64 platforms. We can protect the additional driver code with #ifdef CONFIG_ACPI, as I did in my proof-of-concept. Not particularly elegant, granted, but it should work. If something cleaner can be done, I'm all for it. Could you please propose an implementation of your idea? It doesn't need to be perfect, but I would like to see what it would look like. > (BTW, if Chuck's problem was solved by the BIOS update, I assume > there *is* another instance of the problem that we're trying to > solve with this lock.) Yes, there are several other systems out there which are known to be affected by the problem. And probably many others where ACPI access I/O ports reserved by regular drivers and we are simply lucky that nothing bad happens. My desktop system has such a motherboard (Jetway K8M8MS). But SMP alternatives are becoming more popular, so we might start seeing more problems in practice in a near future. -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-15 9:41 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-04-15 9:41 UTC (permalink / raw) To: Bjorn Helgaas Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors Hi Bjorn, On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote: > On Friday 13 April 2007 14:07, Pavel Machek wrote: > > > > ... 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. ... > > > > > > > > So, can ACPI actually reserve the ports it accesses? > > > > > > Sorry to join this discussion so late. > > > > > > ACPI tells us the resources used by devices. Today, we don't > > > reserve > > > > Problem seems to be that ACPI does _not_ tell us which ports it > > accesses from AML code. > > I think that would violate at least the spirit of the ACPI spec. > The example in section 11.6 of the ACPI 3.0 spec shows a _TMP > method that runs an EC method to read the temp, and the EC ioport > usage is correctly declared in the EC device's _CRS method. > > Of course, there are always BIOS defects. But if we could make a > case that a BIOS that doesn't declare the resources used by the AML > is defective, we could add quirks to reserve the undeclared resources. Only realistic if the list of systems needing a quirk is small. Do you think that would be the case? > > But we already found a lock we can take; AFAICT we know how to solve > > this problem. We even have two solutions, but both have drawbacks. The AML lock solution has performance issue. It could be improved with a better semaphore primitive, but that needs to be implemented first. It also requires to modify all drivers ACPI might conflict with, and that's a rather long list. Rudolf Marek's port forwarding idea should perform better, and might also be useful for other problems than ACPI vs. regular drivers, however it makes resources bigger, and requires to modify the same long list of drivers, and with specific code for every driver. I'm not sure that it will be possible for all driver in practice, as this more or less requires to forecast the I/O access pattern of ACPI. > This might solve it, but doesn't seem like a clean way to do it. > I don't like the idea of sharing a lock between drivers and ACPI. > k8temp happens to be x86-dependent, so we'll always have ACPI, but > in principle, we could have the same problem with an arch-independent > PCI driver that only has ACPI on x86 and ia64 platforms. We can protect the additional driver code with #ifdef CONFIG_ACPI, as I did in my proof-of-concept. Not particularly elegant, granted, but it should work. If something cleaner can be done, I'm all for it. Could you please propose an implementation of your idea? It doesn't need to be perfect, but I would like to see what it would look like. > (BTW, if Chuck's problem was solved by the BIOS update, I assume > there *is* another instance of the problem that we're trying to > solve with this lock.) Yes, there are several other systems out there which are known to be affected by the problem. And probably many others where ACPI access I/O ports reserved by regular drivers and we are simply lucky that nothing bad happens. My desktop system has such a motherboard (Jetway K8M8MS). But SMP alternatives are becoming more popular, so we might start seeing more problems in practice in a near future. -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-04-15 9:41 ` Jean Delvare @ 2007-04-15 20:31 ` Bjorn Helgaas -1 siblings, 0 replies; 207+ messages in thread From: Bjorn Helgaas @ 2007-04-15 20:31 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Sunday 15 April 2007 03:41, Jean Delvare wrote: > On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote: > > Of course, there are always BIOS defects. But if we could make a > > case that a BIOS that doesn't declare the resources used by the AML > > is defective, we could add quirks to reserve the undeclared resources. > > Only realistic if the list of systems needing a quirk is small. Do you > think that would be the case? I don't know. I confess that I don't clearly understand the problem yet. It sounds like the sensor drivers want to talk to hardware that ACPI methods might also use. But I missed the details, such as the specific devices in question, which ports they use, how they are described in ACPI, which AML methods use those ports, and which non-ACPI drivers also use them. It also sounds like the non-ACPI drivers provide much more functionality than ACPI exposes. I'd like to understand this, too, because an obvious way to solve the problem would be to drop the non-ACPI drivers. Is this extra functionality available on Windows? If so, do we know whether Windows uses non-ACPI drivers or whether they have some smarter way to use ACPI? In the long run, I think the easiest, most reliable route would be to use the system in a similar way. Then we'd be doing things the way the manufacturer intended and we'd take advantage of all the Windows- focused firmware testing. Bjorn ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-15 20:31 ` Bjorn Helgaas 0 siblings, 0 replies; 207+ messages in thread From: Bjorn Helgaas @ 2007-04-15 20:31 UTC (permalink / raw) To: Jean Delvare Cc: Pavel Machek, Chuck Ebbert, Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Sunday 15 April 2007 03:41, Jean Delvare wrote: > On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote: > > Of course, there are always BIOS defects. But if we could make a > > case that a BIOS that doesn't declare the resources used by the AML > > is defective, we could add quirks to reserve the undeclared resources. > > Only realistic if the list of systems needing a quirk is small. Do you > think that would be the case? I don't know. I confess that I don't clearly understand the problem yet. It sounds like the sensor drivers want to talk to hardware that ACPI methods might also use. But I missed the details, such as the specific devices in question, which ports they use, how they are described in ACPI, which AML methods use those ports, and which non-ACPI drivers also use them. It also sounds like the non-ACPI drivers provide much more functionality than ACPI exposes. I'd like to understand this, too, because an obvious way to solve the problem would be to drop the non-ACPI drivers. Is this extra functionality available on Windows? If so, do we know whether Windows uses non-ACPI drivers or whether they have some smarter way to use ACPI? In the long run, I think the easiest, most reliable route would be to use the system in a similar way. Then we'd be doing things the way the manufacturer intended and we'd take advantage of all the Windows- focused firmware testing. Bjorn _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-04-15 20:31 ` Bjorn Helgaas @ 2007-04-15 20:59 ` Luca Tettamanti -1 siblings, 0 replies; 207+ messages in thread From: Luca Tettamanti @ 2007-04-15 20:59 UTC (permalink / raw) To: Bjorn Helgaas Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert On 4/15/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote: > On Sunday 15 April 2007 03:41, Jean Delvare wrote: > > On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote: > > > Of course, there are always BIOS defects. But if we could make a > > > case that a BIOS that doesn't declare the resources used by the AML > > > is defective, we could add quirks to reserve the undeclared resources. > > > > Only realistic if the list of systems needing a quirk is small. Do you > > think that would be the case? > > I don't know. I confess that I don't clearly understand the problem > yet. It sounds like the sensor drivers want to talk to hardware that > ACPI methods might also use. Exactly. > But I missed the details, such as the specific devices in question, > which ports they use, how they are described in ACPI, which AML > methods use those ports, and which non-ACPI drivers also use them. The original report was about the temperature sensors of K8 cpus. It happens that ACPI reads the sensors while the linux driver is using it and gets garbage (and shut down the system). The problem is more generic though, and applies to all hardware monitoring chips for which a driver exists. > It also sounds like the non-ACPI drivers provide much more > functionality than ACPI exposes. I'd like to understand this, > too, because an obvious way to solve the problem would be to > drop the non-ACPI drivers. Problem is that ACPI may access the sensors anyway (e.g. via SMM). > Is this extra functionality available > on Windows? If so, do we know whether Windows uses non-ACPI drivers > or whether they have some smarter way to use ACPI? Usually ACPI exposes 1 or 2 temperature readings (CPU and motherboard), while the hw driver can also provide fans and voltages measurements. Vendors usually provides a monitoring utility for Win that also exposes these information. It's not known whether there's a way to avoid conflicting accesses between ACPI and the raw driver; it's possible that it's vendor-specific and not documented. Luca ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-15 20:59 ` Luca Tettamanti 0 siblings, 0 replies; 207+ messages in thread From: Luca Tettamanti @ 2007-04-15 20:59 UTC (permalink / raw) To: Bjorn Helgaas Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert On 4/15/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote: > On Sunday 15 April 2007 03:41, Jean Delvare wrote: > > On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote: > > > Of course, there are always BIOS defects. But if we could make a > > > case that a BIOS that doesn't declare the resources used by the AML > > > is defective, we could add quirks to reserve the undeclared resources. > > > > Only realistic if the list of systems needing a quirk is small. Do you > > think that would be the case? > > I don't know. I confess that I don't clearly understand the problem > yet. It sounds like the sensor drivers want to talk to hardware that > ACPI methods might also use. Exactly. > But I missed the details, such as the specific devices in question, > which ports they use, how they are described in ACPI, which AML > methods use those ports, and which non-ACPI drivers also use them. The original report was about the temperature sensors of K8 cpus. It happens that ACPI reads the sensors while the linux driver is using it and gets garbage (and shut down the system). The problem is more generic though, and applies to all hardware monitoring chips for which a driver exists. > It also sounds like the non-ACPI drivers provide much more > functionality than ACPI exposes. I'd like to understand this, > too, because an obvious way to solve the problem would be to > drop the non-ACPI drivers. Problem is that ACPI may access the sensors anyway (e.g. via SMM). > Is this extra functionality available > on Windows? If so, do we know whether Windows uses non-ACPI drivers > or whether they have some smarter way to use ACPI? Usually ACPI exposes 1 or 2 temperature readings (CPU and motherboard), while the hw driver can also provide fans and voltages measurements. Vendors usually provides a monitoring utility for Win that also exposes these information. It's not known whether there's a way to avoid conflicting accesses between ACPI and the raw driver; it's possible that it's vendor-specific and not documented. Luca _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-04-15 20:59 ` Luca Tettamanti @ 2007-04-16 0:57 ` Bjorn Helgaas -1 siblings, 0 replies; 207+ messages in thread From: Bjorn Helgaas @ 2007-04-16 0:57 UTC (permalink / raw) To: Luca Tettamanti Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert On Sunday 15 April 2007 14:59, Luca Tettamanti wrote: > On 4/15/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote: > > But I missed the details, such as the specific devices in question, > > which ports they use, how they are described in ACPI, which AML > > methods use those ports, and which non-ACPI drivers also use them. > > The original report was about the temperature sensors of K8 cpus. It > happens that ACPI reads the sensors while the linux driver is using it > and gets garbage (and shut down the system). The problem is more > generic though, and applies to all hardware monitoring chips for which > a driver exists. Yes, I saw that much, but that's not enough detail to craft a good solution. In the case of k8temp, the driver claims PCI devices with a certain vendor and device ID. PCI devices are mostly outside the scope of ACPI. There's a standard enumeration protocol, and a driver should be able to claim any device it recognizes without fear of conflict. I claim that an AML method that accesses a PCI device is defective because the AML can't know whether a native driver has claimed the device. Sometimes the firmware can hide PCI devices so the OS enumeration doesn't find them. In that case, AML might be able to safely use the PCI device, but the native driver wouldn't be able to claim the device, so there would be no conflict. (Linux sometimes uses quirks to "unhide" things like this, which could lead to a conflict of our own making.) I suspect that other sensor drivers may just probe for devices at "known" addresses hard-coded in the driver. This is a problem because the ACPI model is that the OS learns about all built-in devices via the ACPI namespace. If it isn't in the namespace, it shouldn't exist as far as the OS is concerned. So we could easily have the situation where ACPI uses a sensor and does not expose it to the OS in the namespace. In that case, the firmware expectation is that the OS won't touch the device. If the OS pokes around at the magic addresses and happens to trip over the device, we just made ourselves a problem. > > It also sounds like the non-ACPI drivers provide much more > > functionality than ACPI exposes. I'd like to understand this, > > too, because an obvious way to solve the problem would be to > > drop the non-ACPI drivers. > > Problem is that ACPI may access the sensors anyway (e.g. via SMM). If ACPI accesses sensors but there is no native driver, there should be no conflict. > > Is this extra functionality available > > on Windows? If so, do we know whether Windows uses non-ACPI drivers > > or whether they have some smarter way to use ACPI? > > Usually ACPI exposes 1 or 2 temperature readings (CPU and > motherboard), while the hw driver can also provide fans and voltages > measurements. > > Vendors usually provides a monitoring utility for Win that also > exposes these information. It's not known whether there's a way to > avoid conflicting accesses between ACPI and the raw driver; it's > possible that it's vendor-specific and not documented. I'd be surprised if Windows provided interfaces to coordinate between two drivers. My impression is that they really want to have a single owner for a piece of hardware. It would be interesting to figure out how these monitoring utilities work. Maybe the monitor and the AML both go through an embedded controller driver and coordinate that way? Bjorn ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-16 0:57 ` Bjorn Helgaas 0 siblings, 0 replies; 207+ messages in thread From: Bjorn Helgaas @ 2007-04-16 0:57 UTC (permalink / raw) To: Luca Tettamanti Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert On Sunday 15 April 2007 14:59, Luca Tettamanti wrote: > On 4/15/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote: > > But I missed the details, such as the specific devices in question, > > which ports they use, how they are described in ACPI, which AML > > methods use those ports, and which non-ACPI drivers also use them. > > The original report was about the temperature sensors of K8 cpus. It > happens that ACPI reads the sensors while the linux driver is using it > and gets garbage (and shut down the system). The problem is more > generic though, and applies to all hardware monitoring chips for which > a driver exists. Yes, I saw that much, but that's not enough detail to craft a good solution. In the case of k8temp, the driver claims PCI devices with a certain vendor and device ID. PCI devices are mostly outside the scope of ACPI. There's a standard enumeration protocol, and a driver should be able to claim any device it recognizes without fear of conflict. I claim that an AML method that accesses a PCI device is defective because the AML can't know whether a native driver has claimed the device. Sometimes the firmware can hide PCI devices so the OS enumeration doesn't find them. In that case, AML might be able to safely use the PCI device, but the native driver wouldn't be able to claim the device, so there would be no conflict. (Linux sometimes uses quirks to "unhide" things like this, which could lead to a conflict of our own making.) I suspect that other sensor drivers may just probe for devices at "known" addresses hard-coded in the driver. This is a problem because the ACPI model is that the OS learns about all built-in devices via the ACPI namespace. If it isn't in the namespace, it shouldn't exist as far as the OS is concerned. So we could easily have the situation where ACPI uses a sensor and does not expose it to the OS in the namespace. In that case, the firmware expectation is that the OS won't touch the device. If the OS pokes around at the magic addresses and happens to trip over the device, we just made ourselves a problem. > > It also sounds like the non-ACPI drivers provide much more > > functionality than ACPI exposes. I'd like to understand this, > > too, because an obvious way to solve the problem would be to > > drop the non-ACPI drivers. > > Problem is that ACPI may access the sensors anyway (e.g. via SMM). If ACPI accesses sensors but there is no native driver, there should be no conflict. > > Is this extra functionality available > > on Windows? If so, do we know whether Windows uses non-ACPI drivers > > or whether they have some smarter way to use ACPI? > > Usually ACPI exposes 1 or 2 temperature readings (CPU and > motherboard), while the hw driver can also provide fans and voltages > measurements. > > Vendors usually provides a monitoring utility for Win that also > exposes these information. It's not known whether there's a way to > avoid conflicting accesses between ACPI and the raw driver; it's > possible that it's vendor-specific and not documented. I'd be surprised if Windows provided interfaces to coordinate between two drivers. My impression is that they really want to have a single owner for a piece of hardware. It would be interesting to figure out how these monitoring utilities work. Maybe the monitor and the AML both go through an embedded controller driver and coordinate that way? Bjorn _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-04-16 0:57 ` Bjorn Helgaas @ 2007-04-16 21:14 ` Luca Tettamanti -1 siblings, 0 replies; 207+ messages in thread From: Luca Tettamanti @ 2007-04-16 21:14 UTC (permalink / raw) To: Bjorn Helgaas Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert [-- Attachment #1: Type: text/plain, Size: 6102 bytes --] Il Sun, Apr 15, 2007 at 06:57:02PM -0600, Bjorn Helgaas ha scritto: > On Sunday 15 April 2007 14:59, Luca Tettamanti wrote: > > On 4/15/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote: > > > But I missed the details, such as the specific devices in question, > > > which ports they use, how they are described in ACPI, which AML > > > methods use those ports, and which non-ACPI drivers also use them. > > > > The original report was about the temperature sensors of K8 cpus. It > > happens that ACPI reads the sensors while the linux driver is using it > > and gets garbage (and shut down the system). The problem is more > > generic though, and applies to all hardware monitoring chips for which > > a driver exists. > > Yes, I saw that much, but that's not enough detail to craft a good > solution. > > In the case of k8temp, the driver claims PCI devices with a certain > vendor and device ID. PCI devices are mostly outside the scope of > ACPI. There's a standard enumeration protocol, and a driver should > be able to claim any device it recognizes without fear of conflict. > > I claim that an AML method that accesses a PCI device is > defective because the AML can't know whether a native driver > has claimed the device. k8temp seems a special case tough. > Sometimes the firmware can hide PCI devices so the OS > enumeration doesn't find them. In that case, AML might > be able to safely use the PCI device, but the native > driver wouldn't be able to claim the device, so there > would be no conflict. (Linux sometimes uses quirks to > "unhide" things like this, which could lead to a conflict > of our own making.) > > I suspect that other sensor drivers may just probe for devices > at "known" addresses hard-coded in the driver. Usually sensors are attached to SMBUS or available in ISA IO space. AFAIK they're not enumerated anywhere (at least I2C devices are not, you poke at various addresses and see if something responds - not sure about ISA). > This is a > problem because the ACPI model is that the OS learns about > all built-in devices via the ACPI namespace. If it isn't > in the namespace, it shouldn't exist as far as the OS is > concerned. > > So we could easily have the situation where ACPI uses a > sensor and does not expose it to the OS in the namespace. > In that case, the firmware expectation is that the OS > won't touch the device. If the OS pokes around at the > magic addresses and happens to trip over the device, we > just made ourselves a problem. > > > > It also sounds like the non-ACPI drivers provide much more > > > functionality than ACPI exposes. I'd like to understand this, > > > too, because an obvious way to solve the problem would be to > > > drop the non-ACPI drivers. > > > > Problem is that ACPI may access the sensors anyway (e.g. via SMM). > > If ACPI accesses sensors but there is no native driver, there > should be no conflict. Of course. But we do have native drivers ;-) > > > Is this extra functionality available > > > on Windows? If so, do we know whether Windows uses non-ACPI drivers > > > or whether they have some smarter way to use ACPI? > > > > Usually ACPI exposes 1 or 2 temperature readings (CPU and > > motherboard), while the hw driver can also provide fans and voltages > > measurements. > > > > Vendors usually provides a monitoring utility for Win that also > > exposes these information. It's not known whether there's a way to > > avoid conflicting accesses between ACPI and the raw driver; it's > > possible that it's vendor-specific and not documented. > > I'd be surprised if Windows provided interfaces to coordinate > between two drivers. My impression is that they really want > to have a single owner for a piece of hardware. It would be > interesting to figure out how these monitoring utilities work. > Maybe the monitor and the AML both go through an embedded > controller driver and coordinate that way? Hum, the utility I have here (Asus PC Probe) seems to use ACPI: Pro2.dll: [Ordinal/Name Pointer] Table [ 11] OCAPI_ACPI_OC_PresetList [ 12] OCAPI_ACPI_OC__MB_GetBoardName [ 23] OCAPI_CheckAiGear [ 0] OCAPI_CheckIntelPowerSaving [ 6] OCAPI_CheckWorkable [ 2] OCAPI_Close [ 9] OCAPI_EnableQFan [ 16] OCAPI_GENERAL_GetList [ 14] OCAPI_GetCpuVoltRange [ 13] OCAPI_GetCurrentCpuFrequency [ 15] OCAPI_GetFanStartTemp [ 3] OCAPI_GetHealthData [ 4] OCAPI_GetHwSensorData [ 22] OCAPI_GetMBIF [ 8] OCAPI_GetQFanInfo [ 5] OCAPI_HW_EnumerateOption [ 7] OCAPI_HideQFan [ 1] OCAPI_Initialization [ 19] OCAPI_NQFAN_GetData [ 21] OCAPI_NQFAN_GetList [ 20] OCAPI_NQFAN_SetData [ 17] OCAPI_QFAN_GetData [ 18] OCAPI_QFAN_SetData [ 10] OCAPI_SetQFanTarget [ 24] ___CPPdebugHook ASiO.dll: [Ordinal/Name Pointer] Table [ 1] ASIO_Close [ 9] ASIO_GetCpuID [ 3] ASIO_InPortB [ 5] ASIO_InPortD [ 7] ASIO_MapMem [ 0] ASIO_Open [ 4] ASIO_OutPortB [ 6] ASIO_OutPortD [ 10] ASIO_ReadMSR [ 8] ASIO_UnmapMem [ 11] ASIO_WriteMSR [ 2] OC_GetCurrentCpuFrequency It seems that Asus exposes monitorining data using "ATK0110" (enumerated in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D) (they have different methods though). Another motherboard with the same device may actually call it "FOOBAR123" or "WTFISTHIS". Problem is that ACPI methods are not documented at all (how am I supposed to know that "G6T6" is the reading of the 12V rail?) while the datasheet of hw monitoring chips (w83627ehf in my case) are public (more or less). Furthermore, sensor driver exposes all the reading of the chip (e.g. in the DSDT I can't find the VSB or battery voltage). I'm attacching my DSDT, in case you want to have fun ;-) Luca -- Collect some stars to shine for you And start today 'cause there's only a few A sign of times my friend [-- Attachment #2: Asus P5B-E DSDT --] [-- Type: application/octet-stream, Size: 19170 bytes --] ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-16 21:14 ` Luca Tettamanti 0 siblings, 0 replies; 207+ messages in thread From: Luca Tettamanti @ 2007-04-16 21:14 UTC (permalink / raw) To: Bjorn Helgaas Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert [-- Attachment #1: Type: text/plain, Size: 6102 bytes --] Il Sun, Apr 15, 2007 at 06:57:02PM -0600, Bjorn Helgaas ha scritto: > On Sunday 15 April 2007 14:59, Luca Tettamanti wrote: > > On 4/15/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote: > > > But I missed the details, such as the specific devices in question, > > > which ports they use, how they are described in ACPI, which AML > > > methods use those ports, and which non-ACPI drivers also use them. > > > > The original report was about the temperature sensors of K8 cpus. It > > happens that ACPI reads the sensors while the linux driver is using it > > and gets garbage (and shut down the system). The problem is more > > generic though, and applies to all hardware monitoring chips for which > > a driver exists. > > Yes, I saw that much, but that's not enough detail to craft a good > solution. > > In the case of k8temp, the driver claims PCI devices with a certain > vendor and device ID. PCI devices are mostly outside the scope of > ACPI. There's a standard enumeration protocol, and a driver should > be able to claim any device it recognizes without fear of conflict. > > I claim that an AML method that accesses a PCI device is > defective because the AML can't know whether a native driver > has claimed the device. k8temp seems a special case tough. > Sometimes the firmware can hide PCI devices so the OS > enumeration doesn't find them. In that case, AML might > be able to safely use the PCI device, but the native > driver wouldn't be able to claim the device, so there > would be no conflict. (Linux sometimes uses quirks to > "unhide" things like this, which could lead to a conflict > of our own making.) > > I suspect that other sensor drivers may just probe for devices > at "known" addresses hard-coded in the driver. Usually sensors are attached to SMBUS or available in ISA IO space. AFAIK they're not enumerated anywhere (at least I2C devices are not, you poke at various addresses and see if something responds - not sure about ISA). > This is a > problem because the ACPI model is that the OS learns about > all built-in devices via the ACPI namespace. If it isn't > in the namespace, it shouldn't exist as far as the OS is > concerned. > > So we could easily have the situation where ACPI uses a > sensor and does not expose it to the OS in the namespace. > In that case, the firmware expectation is that the OS > won't touch the device. If the OS pokes around at the > magic addresses and happens to trip over the device, we > just made ourselves a problem. > > > > It also sounds like the non-ACPI drivers provide much more > > > functionality than ACPI exposes. I'd like to understand this, > > > too, because an obvious way to solve the problem would be to > > > drop the non-ACPI drivers. > > > > Problem is that ACPI may access the sensors anyway (e.g. via SMM). > > If ACPI accesses sensors but there is no native driver, there > should be no conflict. Of course. But we do have native drivers ;-) > > > Is this extra functionality available > > > on Windows? If so, do we know whether Windows uses non-ACPI drivers > > > or whether they have some smarter way to use ACPI? > > > > Usually ACPI exposes 1 or 2 temperature readings (CPU and > > motherboard), while the hw driver can also provide fans and voltages > > measurements. > > > > Vendors usually provides a monitoring utility for Win that also > > exposes these information. It's not known whether there's a way to > > avoid conflicting accesses between ACPI and the raw driver; it's > > possible that it's vendor-specific and not documented. > > I'd be surprised if Windows provided interfaces to coordinate > between two drivers. My impression is that they really want > to have a single owner for a piece of hardware. It would be > interesting to figure out how these monitoring utilities work. > Maybe the monitor and the AML both go through an embedded > controller driver and coordinate that way? Hum, the utility I have here (Asus PC Probe) seems to use ACPI: Pro2.dll: [Ordinal/Name Pointer] Table [ 11] OCAPI_ACPI_OC_PresetList [ 12] OCAPI_ACPI_OC__MB_GetBoardName [ 23] OCAPI_CheckAiGear [ 0] OCAPI_CheckIntelPowerSaving [ 6] OCAPI_CheckWorkable [ 2] OCAPI_Close [ 9] OCAPI_EnableQFan [ 16] OCAPI_GENERAL_GetList [ 14] OCAPI_GetCpuVoltRange [ 13] OCAPI_GetCurrentCpuFrequency [ 15] OCAPI_GetFanStartTemp [ 3] OCAPI_GetHealthData [ 4] OCAPI_GetHwSensorData [ 22] OCAPI_GetMBIF [ 8] OCAPI_GetQFanInfo [ 5] OCAPI_HW_EnumerateOption [ 7] OCAPI_HideQFan [ 1] OCAPI_Initialization [ 19] OCAPI_NQFAN_GetData [ 21] OCAPI_NQFAN_GetList [ 20] OCAPI_NQFAN_SetData [ 17] OCAPI_QFAN_GetData [ 18] OCAPI_QFAN_SetData [ 10] OCAPI_SetQFanTarget [ 24] ___CPPdebugHook ASiO.dll: [Ordinal/Name Pointer] Table [ 1] ASIO_Close [ 9] ASIO_GetCpuID [ 3] ASIO_InPortB [ 5] ASIO_InPortD [ 7] ASIO_MapMem [ 0] ASIO_Open [ 4] ASIO_OutPortB [ 6] ASIO_OutPortD [ 10] ASIO_ReadMSR [ 8] ASIO_UnmapMem [ 11] ASIO_WriteMSR [ 2] OC_GetCurrentCpuFrequency It seems that Asus exposes monitorining data using "ATK0110" (enumerated in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D) (they have different methods though). Another motherboard with the same device may actually call it "FOOBAR123" or "WTFISTHIS". Problem is that ACPI methods are not documented at all (how am I supposed to know that "G6T6" is the reading of the 12V rail?) while the datasheet of hw monitoring chips (w83627ehf in my case) are public (more or less). Furthermore, sensor driver exposes all the reading of the chip (e.g. in the DSDT I can't find the VSB or battery voltage). I'm attacching my DSDT, in case you want to have fun ;-) Luca -- Collect some stars to shine for you And start today 'cause there's only a few A sign of times my friend [-- Attachment #2: Asus P5B-E DSDT --] [-- Type: application/octet-stream, Size: 19170 bytes --] [-- Attachment #3: Type: text/plain, Size: 153 bytes --] _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-04-16 21:14 ` Luca Tettamanti @ 2007-04-16 22:28 ` Bjorn Helgaas -1 siblings, 0 replies; 207+ messages in thread From: Bjorn Helgaas @ 2007-04-16 22:28 UTC (permalink / raw) To: Luca Tettamanti Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert On Monday 16 April 2007 15:14, Luca Tettamanti wrote: > It seems that Asus exposes monitorining data using "ATK0110" (enumerated > in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D) > (they have different methods though). Another motherboard with the same > device may actually call it "FOOBAR123" or "WTFISTHIS". Yup, we have the same problem with other devices. See the long list of PNP IDs in 8250_pnp.c :-) > Problem is that ACPI methods are not documented at all (how am I > supposed to know that "G6T6" is the reading of the 12V rail?) while the > datasheet of hw monitoring chips (w83627ehf in my case) are public (more > or less). Yes, I see that it's attractive to use a single w83627ehf.c driver. For an ACPI driver, we'd have to build a list of PNP IDs, and possibly information about which methods read which information. That's certainly more work. On the other hand, the ACPI driver would avoid the synchronization issues that started this whole thread. That's a pretty compelling advantage. > Furthermore, sensor driver exposes all the reading of the chip > (e.g. in the DSDT I can't find the VSB or battery voltage). Maybe Asus didn't hook up those readings on the board. I would guess that PC Probe doesn't expose the VSB or battery voltage either. I'm sure you've seen these: http://lists.lm-sensors.org/pipermail/lm-sensors/2005-October/014050.html http://www.lm-sensors.org/wiki/AsusFormulaHacking Looks like nobody took up the challenge, though :-) It looks fun to play with, if only I had the time and hardware. Bjorn ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-16 22:28 ` Bjorn Helgaas 0 siblings, 0 replies; 207+ messages in thread From: Bjorn Helgaas @ 2007-04-16 22:28 UTC (permalink / raw) To: Luca Tettamanti Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert On Monday 16 April 2007 15:14, Luca Tettamanti wrote: > It seems that Asus exposes monitorining data using "ATK0110" (enumerated > in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D) > (they have different methods though). Another motherboard with the same > device may actually call it "FOOBAR123" or "WTFISTHIS". Yup, we have the same problem with other devices. See the long list of PNP IDs in 8250_pnp.c :-) > Problem is that ACPI methods are not documented at all (how am I > supposed to know that "G6T6" is the reading of the 12V rail?) while the > datasheet of hw monitoring chips (w83627ehf in my case) are public (more > or less). Yes, I see that it's attractive to use a single w83627ehf.c driver. For an ACPI driver, we'd have to build a list of PNP IDs, and possibly information about which methods read which information. That's certainly more work. On the other hand, the ACPI driver would avoid the synchronization issues that started this whole thread. That's a pretty compelling advantage. > Furthermore, sensor driver exposes all the reading of the chip > (e.g. in the DSDT I can't find the VSB or battery voltage). Maybe Asus didn't hook up those readings on the board. I would guess that PC Probe doesn't expose the VSB or battery voltage either. I'm sure you've seen these: http://lists.lm-sensors.org/pipermail/lm-sensors/2005-October/014050.html http://www.lm-sensors.org/wiki/AsusFormulaHacking Looks like nobody took up the challenge, though :-) It looks fun to play with, if only I had the time and hardware. Bjorn _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-04-16 22:28 ` Bjorn Helgaas @ 2007-04-17 23:50 ` Luca Tettamanti -1 siblings, 0 replies; 207+ messages in thread From: Luca Tettamanti @ 2007-04-17 23:50 UTC (permalink / raw) To: Bjorn Helgaas Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert On 4/17/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote: > On Monday 16 April 2007 15:14, Luca Tettamanti wrote: > > Problem is that ACPI methods are not documented at all (how am I > > supposed to know that "G6T6" is the reading of the 12V rail?) while the > > datasheet of hw monitoring chips (w83627ehf in my case) are public (more > > or less). > > Yes, I see that it's attractive to use a single w83627ehf.c driver. > For an ACPI driver, we'd have to build a list of PNP IDs, and possibly > information about which methods read which information. That's > certainly more work. > > On the other hand, the ACPI driver would avoid the synchronization > issues that started this whole thread. That's a pretty compelling > advantage. > > > Furthermore, sensor driver exposes all the reading of the chip > > (e.g. in the DSDT I can't find the VSB or battery voltage). > > Maybe Asus didn't hook up those readings on the board. I would > guess that PC Probe doesn't expose the VSB or battery voltage either. PC Probe does not. But the lines are wired and the readings (from Linux) are sensible. > I'm sure you've seen these: > http://lists.lm-sensors.org/pipermail/lm-sensors/2005-October/014050.html > http://www.lm-sensors.org/wiki/AsusFormulaHacking Actually I haven't, I've happily ignored ACPI until now ;-) My DSDT doesn't look too bad, I may give it a try... Luca ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-17 23:50 ` Luca Tettamanti 0 siblings, 0 replies; 207+ messages in thread From: Luca Tettamanti @ 2007-04-17 23:50 UTC (permalink / raw) To: Bjorn Helgaas Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert On 4/17/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote: > On Monday 16 April 2007 15:14, Luca Tettamanti wrote: > > Problem is that ACPI methods are not documented at all (how am I > > supposed to know that "G6T6" is the reading of the 12V rail?) while the > > datasheet of hw monitoring chips (w83627ehf in my case) are public (more > > or less). > > Yes, I see that it's attractive to use a single w83627ehf.c driver. > For an ACPI driver, we'd have to build a list of PNP IDs, and possibly > information about which methods read which information. That's > certainly more work. > > On the other hand, the ACPI driver would avoid the synchronization > issues that started this whole thread. That's a pretty compelling > advantage. > > > Furthermore, sensor driver exposes all the reading of the chip > > (e.g. in the DSDT I can't find the VSB or battery voltage). > > Maybe Asus didn't hook up those readings on the board. I would > guess that PC Probe doesn't expose the VSB or battery voltage either. PC Probe does not. But the lines are wired and the readings (from Linux) are sensible. > I'm sure you've seen these: > http://lists.lm-sensors.org/pipermail/lm-sensors/2005-October/014050.html > http://www.lm-sensors.org/wiki/AsusFormulaHacking Actually I haven't, I've happily ignored ACPI until now ;-) My DSDT doesn't look too bad, I may give it a try... Luca _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-04-17 23:50 ` Luca Tettamanti @ 2007-04-22 16:55 ` Luca Tettamanti -1 siblings, 0 replies; 207+ messages in thread From: Luca Tettamanti @ 2007-04-22 16:55 UTC (permalink / raw) To: Bjorn Helgaas Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert Il Wed, Apr 18, 2007 at 01:50:29AM +0200, Luca Tettamanti ha scritto: > >I'm sure you've seen these: > > http://lists.lm-sensors.org/pipermail/lm-sensors/2005-October/014050.html > > http://www.lm-sensors.org/wiki/AsusFormulaHacking > > Actually I haven't, I've happily ignored ACPI until now ;-) My DSDT > doesn't look too bad, I may give it a try... It wasn't hard :) Temperature reading works fine. AML code is still a bit obscure though: the reading are enumerated in two different sections: * TSIF, FSIF, VSIF: they have read/write methods, easy to understand (I'm using these right now) * SITM/GITM and GGPR for enumeration: more settings are available and in part they overlap the others. The methods are very strange, for e.g. temperature GITM (which calls GIT6) returns a hard-coded magic value; other methods (e.g. CPU frequency, Q-FAN settings) write a random number somewhere in the system memory and return an obscure magic value... very cool :) I'm posting the proof-of-concept driver. A few notes: - only temperature reading is implemented: I just got my MS degree so I've been drun^Wbusy - sysfs files are still RO - coding style: yes, I know... will cleanup - There's a gazillion of debugging printk's :) - I've extended the hwmon sysfs interface, with a new "temp%d_name"; ACPI knows how the sensor is wired - You'll need the following patch (against current Linus' git): diff --git a/drivers/acpi/namespace/nsutils.c b/drivers/acpi/namespace/nsutils.c index 90fd059..97e1139 100644 --- a/drivers/acpi/namespace/nsutils.c +++ b/drivers/acpi/namespace/nsutils.c @@ -700,6 +700,7 @@ struct acpi_namespace_node *acpi_ns_map_handle_to_node(acpi_handle handle) return (ACPI_CAST_PTR(struct acpi_namespace_node, handle)); } +EXPORT_SYMBOL(acpi_ns_map_handle_to_node); /******************************************************************************* * @@ -736,6 +737,7 @@ acpi_handle acpi_ns_convert_entry_to_handle(struct acpi_namespace_node *node) return ((acpi_handle) Node); ------------------------------------------------------*/ } +EXPORT_SYMBOL(acpi_ns_convert_entry_to_handle); /******************************************************************************* * @@ -875,6 +877,7 @@ acpi_ns_get_node(struct acpi_namespace_node *prefix_node, ACPI_FREE(internal_path); return_ACPI_STATUS(status); } +EXPORT_SYMBOL(acpi_ns_get_node); /******************************************************************************* * Now the driver: /* * Copyright (C) 2007 Luca Tettamanti <kronos.it@gmail.com> * Distribute under GPLv2. */ #include <linux/module.h> #include <linux/kernel.h> #include <linux/hwmon.h> #include <acpi/acpi.h> #include <acpi/acnamesp.h> #include <acpi/acpi_drivers.h> #include <acpi/acpi_bus.h> #define ATK_HID "ATK0110" #define ATK_DRV "atk-hwmon" #define ASOC "_SB.PCI0.SBRG.ASOC" struct atk_data { struct class_device *class_dev; acpi_handle atk_handle; struct acpi_device *device; acpi_handle rtmp_handle; } atk_data; typedef ssize_t (*sysfs_show_func)(struct device *dev, struct device_attribute *attr, char *buf); typedef ssize_t (*sysfs_store_func)(struct device *dev, struct device_attribute *attr, const char *buf, size_t count); static void atk_init_attribute(struct device_attribute *attr, char *name, mode_t mode, sysfs_show_func show, sysfs_store_func store) { attr->attr.name = name; attr->attr.mode = mode; attr->show = show; attr->store = store; } #define ATTR_NAME_SIZE 32 struct atk_temp_input { struct device_attribute dev_attr; /* id is used for the ACPI ID of the temp */ int id; char attr_name[ATTR_NAME_SIZE]; }; struct atk_temp_input_list { int count; struct atk_temp_input temp_input[]; }; #define to_atk_temp_input(attr) \ container_of(attr, struct atk_temp_input, dev_attr) static ssize_t atk_temp_input_show(struct device *dev, struct device_attribute *attr, char *buf) { struct atk_temp_input *a = to_atk_temp_input(attr); union acpi_object temp; struct acpi_buffer ret; struct acpi_object_list params; union acpi_object id; acpi_status status; ssize_t count; id.type = ACPI_TYPE_INTEGER; id.integer.value = a->id; params.count = 1; params.pointer = &id; ret.length = sizeof(temp); ret.pointer = &temp; status = acpi_evaluate_object(atk_data.rtmp_handle, NULL, ¶ms, &ret); if (status != AE_OK) { printk("acpi_evaluate_object: %s\n", acpi_format_exception(status)); return -EIO; } if (temp.type != ACPI_TYPE_INTEGER) { printk("not an integer (%d)\n", temp.type); return -EIO; } /* ACPI returns centidegree */ count = sprintf(buf, "%llu\n", temp.integer.value * 10); return count; } struct atk_temp_name { struct device_attribute dev_attr; char attr_name[ATTR_NAME_SIZE]; char const *name; }; struct atk_temp_name_list { int count; struct atk_temp_name temp_name[]; }; #define to_atk_temp_name(attr) \ container_of(attr, struct atk_temp_name, dev_attr) static ssize_t atk_temp_name_show(struct device *dev, struct device_attribute *attr, char *buf) { struct atk_temp_name *a = to_atk_temp_name(attr); return sprintf(buf, "%s\n", a->name); } enum atk_temp_pack_id { ATK_TEMP_PACK_MAX = 2, ATK_TEMP_PACK_CRIT = 3, }; static int atk_temp_pack_read(acpi_handle handle, int pack_id, enum atk_temp_pack_id temp_id, unsigned long long *temp) { struct acpi_buffer ret; struct acpi_object_list params; union acpi_object id; union acpi_object *pack; union acpi_object *obj; acpi_status status; int err = 0; ret.length = ACPI_ALLOCATE_BUFFER; id.type = ACPI_TYPE_INTEGER; id.integer.value = pack_id; params.count = 1; params.pointer = &id; status = acpi_evaluate_object(handle, NULL, ¶ms, &ret); if (status != AE_OK) { printk("atk_temp_pack_read: acpi_evaluate_object: %s\n", acpi_format_exception(status)); return -EIO; } pack = ret.pointer; if (pack->type != ACPI_TYPE_PACKAGE) { printk("atk_temp_pack_read: ret object is not a package: %d\n", pack->type); err = -EIO; goto out; } if (pack->package.count != 5) { printk("atk_temp_pack_read: unexpected package size: %d\n", pack->package.count); err = -EIO; goto out; } obj = &pack->package.elements[temp_id]; if (obj->type != ACPI_TYPE_INTEGER) { printk("atk_temp_pack_read: unexepected type %d\n", obj->type); err = -EIO; goto out; } *temp = obj->integer.value; out: ACPI_FREE(ret.pointer); return err; } struct atk_temp_max { struct device_attribute dev_attr; int id; acpi_handle handle; char attr_name[ATTR_NAME_SIZE]; }; struct atk_temp_max_list { int count; struct atk_temp_max temp_max[]; }; #define to_atk_temp_max(attr) \ container_of(attr, struct atk_temp_max, dev_attr) static ssize_t atk_temp_max_show(struct device *dev, struct device_attribute *attr, char *buf) { struct atk_temp_max *a = to_atk_temp_max(attr); unsigned long long temp; if (atk_temp_pack_read(a->handle, a->id, ATK_TEMP_PACK_MAX, &temp)) return -EIO; return sprintf(buf, "%lld\n", temp * 10); } struct atk_temp_crit { struct device_attribute dev_attr; int id; acpi_handle handle; char attr_name[ATTR_NAME_SIZE]; }; struct atk_temp_crit_list { int count; struct atk_temp_crit temp_crit[]; }; #define to_atk_temp_crit(attr) \ container_of(attr, struct atk_temp_crit, dev_attr) static ssize_t atk_temp_crit_show(struct device *dev, struct device_attribute *attr, char *buf) { struct atk_temp_crit *a = to_atk_temp_crit(attr); unsigned long long temp; if (atk_temp_pack_read(a->handle, a->id, ATK_TEMP_PACK_CRIT, &temp)) return -EIO; return sprintf(buf, "%lld\n", temp * 10); } struct atk_temp_input_list *temp_input_list; struct atk_temp_name_list *temp_name_list; struct atk_temp_max_list *temp_max_list; struct atk_temp_crit_list *temp_crit_list; static int atk_found; static int atk_add(struct acpi_device *device); static int atk_remove(struct acpi_device *device, int type); static struct acpi_driver atk_driver = { .name = ATK_HID, .class = "hwmon", .ids = ATK_HID, .ops = { .add = atk_add, .remove = atk_remove, }, }; static int atk_create_files(struct device *dev) { int i; int ret; /* Temperatures */ for (i = 0; i < temp_input_list->count; i++) { ret = device_create_file(dev, &temp_input_list->temp_input[i].dev_attr); if (ret) return ret; } for (i = 0; i < temp_name_list->count; i++) { ret = device_create_file(dev, &temp_name_list->temp_name[i].dev_attr); if (ret) return ret; } for (i = 0; i < temp_max_list->count; i++) { ret = device_create_file(dev, &temp_max_list->temp_max[i].dev_attr); if (ret) return ret; } for (i = 0; i < temp_crit_list->count; i++) { ret = device_create_file(dev, &temp_crit_list->temp_crit[i].dev_attr); if (ret) return ret; } return 0; } static void atk_remove_files(struct device *dev) { int i; /* Temperatures */ if (temp_input_list) { for (i = 0; i < temp_input_list->count; i++) device_remove_file(dev, &temp_input_list->temp_input[i].dev_attr); } kfree(temp_input_list); if (temp_name_list) { for (i = 0; i < temp_name_list->count; i++) { device_remove_file(dev, &temp_name_list->temp_name[i].dev_attr); kfree(temp_name_list->temp_name[i].name); } } kfree(temp_name_list); if (temp_max_list) { for (i = 0; i < temp_max_list->count; i++) device_remove_file(dev, &temp_max_list->temp_max[i].dev_attr); } kfree(temp_max_list); if (temp_crit_list) { for (i = 0; i < temp_crit_list->count; i++) device_remove_file(dev, &temp_crit_list->temp_crit[i].dev_attr); } kfree(temp_max_list); } static int atk_enumerate_temp(struct acpi_buffer *buf) { union acpi_object *pack; union acpi_object *obj; struct atk_temp_input_list *inputs; struct atk_temp_name_list *names; struct atk_temp_max_list *max; struct atk_temp_crit_list *crit; int i, ret; /* Result must be a package */ pack = buf->pointer; if (pack->type != ACPI_TYPE_PACKAGE) { printk("atk_enumerate_temp: not a package\n"); return -EINVAL; } if (pack->package.count < 1) { printk("atk_enumerate_temp: count < 1\n"); return -EINVAL; } /* First field is the number of available readings */ obj = &pack->package.elements[0]; if (obj->type != ACPI_TYPE_INTEGER) { printk("atk_enumerate_temp: element 0 is not an int (%u)\n", obj->type); return -EINVAL; } /* Sanity check */ if (pack->package.count != obj->integer.value + 1) { printk("atk_enumerate_temp: temperature count (%llu) differs from package count (%u)\n", obj->integer.value, pack->package.count); return -EINVAL; } inputs = kzalloc(sizeof(struct atk_temp_input_list) + sizeof(*inputs->temp_input) * obj->integer.value, GFP_KERNEL); if (!inputs) return -ENOMEM; names = kzalloc(sizeof(struct atk_temp_name_list) + sizeof(*names->temp_name) * obj->integer.value, GFP_KERNEL); if (!names) { ret = -ENOMEM; goto cleanup4; } max = kzalloc(sizeof(*max) + sizeof(*max->temp_max) * obj->integer.value, GFP_KERNEL); if (!max) { ret = -ENOMEM; goto cleanup3; } crit = kzalloc(sizeof(*crit) + sizeof(*crit->temp_crit) * obj->integer.value, GFP_KERNEL); if (!crit) { ret = -ENOMEM; goto cleanup2; } inputs->count = names->count = max->count = crit->count = obj->integer.value; for (i = 0; i < pack->package.count - 1; i++) { struct acpi_buffer buf; union acpi_object *temp_pack; union acpi_object *name; union acpi_object *tmax; union acpi_object *tcrit; acpi_status status; obj = &pack->package.elements[i + 1]; /* obj is a handle to the temperature package */ if (obj->type != ACPI_TYPE_ANY) { printk("atk_enumerate_temp: unexpected type: %d\n", obj->type); ret = -EINVAL; goto cleanup; } buf.length = ACPI_ALLOCATE_BUFFER; status = acpi_evaluate_object(obj->reference.handle, NULL, NULL, &buf); if (status != AE_OK) { printk("ACPI exception on object %u: %s\n", i + 1, acpi_format_exception(status)); ret = -EINVAL; goto cleanup; } /* Temperature package: * byte buffer? * [3]: used by GITM/SITM to locate correct GITx/SITx, * method, same as the other package (GPID) * [2]: same as the other package, seems unused in * GITM/STIM * [1]: type? * 1: cpu freq? * 2: voltage * 3: temperature * 4: fan * 7: Q-FAN (alarm?) * 8: NOS * [0]: used by GITx/SITx for demux; selects the * value stored in ASB1 (PRM0) * description * max * critical * unknown */ temp_pack = buf.pointer; if (temp_pack->type != ACPI_TYPE_PACKAGE) { printk("atk_enumerate_temp: unexpected type for package %u: %d\n", i + 1, temp_pack->type); ret = -EINVAL; goto cleanup; } if (temp_pack->package.count != 5) { printk("Invalid package count: %u\n", temp_pack->package.count); ret = -EINVAL; goto cleanup; } name = &temp_pack->package.elements[1]; tmax = &temp_pack->package.elements[2]; tcrit = &temp_pack->package.elements[3]; if (name->type != ACPI_TYPE_STRING) { printk("atk_enumerate_temp: object %d not a string (%d)\n", i, name->type); ret = -EINVAL; goto cleanup; } if (tmax->type != ACPI_TYPE_INTEGER) { printk("atk_enumerate_temp: object %d int expected (tmax), got: %d\n", i, tmax->type); ret = -EINVAL; goto cleanup; } if (tcrit->type != ACPI_TYPE_INTEGER) { printk("atk_enumerate_temp: object %d int expected (tmax), got: %d\n", i, tcrit->type); ret = -EINVAL; goto cleanup; } inputs->temp_input[i].id = i; snprintf(inputs->temp_input[i].attr_name, ATTR_NAME_SIZE, "temp%d_input", i); atk_init_attribute(&inputs->temp_input[i].dev_attr, inputs->temp_input[i].attr_name, 0444, atk_temp_input_show, NULL); names->temp_name[i].name = kstrdup(name->string.pointer, GFP_KERNEL); snprintf(names->temp_name[i].attr_name, ATTR_NAME_SIZE, "temp%d_name", i); atk_init_attribute(&names->temp_name[i].dev_attr, names->temp_name[i].attr_name, 0444, atk_temp_name_show, NULL); max->temp_max[i].handle = obj->reference.handle; snprintf(max->temp_max[i].attr_name, ATTR_NAME_SIZE, "temp%d_max", i); atk_init_attribute(&max->temp_max[i].dev_attr, max->temp_max[i].attr_name, 0444, atk_temp_max_show, NULL); crit->temp_crit[i].handle = obj->reference.handle; snprintf(crit->temp_crit[i].attr_name, ATTR_NAME_SIZE, "temp%d_crit", i); atk_init_attribute(&crit->temp_crit[i].dev_attr, crit->temp_crit[i].attr_name, 0444, atk_temp_crit_show, NULL); printk("temp %u: %s [%llu-%llu]\n", inputs->temp_input[i].id, names->temp_name[i].name, tmax->integer.value, tcrit->integer.value); ACPI_FREE(buf.pointer); } temp_name_list = names; temp_input_list = inputs; temp_max_list = max; temp_crit_list = crit; return 0; cleanup: kfree(crit); cleanup2: kfree(max); cleanup3: for (i = 0; i < names->count; i++) kfree(names->temp_name[i].name); kfree(names); cleanup4: kfree(inputs); return ret; } static int atk_add(struct acpi_device *device) { acpi_status ret; int err; struct acpi_buffer buf; union acpi_object *obj; struct acpi_namespace_node *search_ns; struct acpi_namespace_node *ns; printk("adding...\n"); atk_data.device = device; atk_data.atk_handle = device->handle; acpi_driver_data(device) = &atk_data; buf.length = ACPI_ALLOCATE_BUFFER; ret = acpi_evaluate_object(atk_data.atk_handle, "MBIF", NULL, &buf); if (ret != AE_OK) return -ENODEV; obj = buf.pointer; if (obj->type == ACPI_TYPE_PACKAGE) { printk("id: %s\n", obj->package.elements[1].string.pointer); } ACPI_FREE(buf.pointer); /* Check for hwmon methods */ search_ns = acpi_ns_map_handle_to_node(device->handle); if (search_ns == NULL) { printk("NULL\n"); return -ENODEV; } /* RTMP: read temperature */ ret = acpi_ns_get_node(search_ns, "RTMP", ACPI_NS_NO_UPSEARCH, &ns); if (ret != AE_OK) { printk(KERN_INFO "atk: RTMP not found\n"); return -ENODEV; } atk_data.rtmp_handle = acpi_ns_convert_entry_to_handle(ns); /* Enumerate temp data - TSIF */ buf.length = ACPI_ALLOCATE_BUFFER; ret = acpi_evaluate_object(atk_data.atk_handle, "TSIF", NULL, &buf); if (ret != AE_OK) { printk("TSIF failed: %s\n", acpi_format_exception(ret)); return -ENODEV; } err = atk_enumerate_temp(&buf); ACPI_FREE(buf.pointer); if (err) return err; atk_found = 1; return 0; } static int atk_remove(struct acpi_device *device, int type) { printk("remove %d\n", type); acpi_driver_data(device) = NULL; return AE_OK; } int atk_init(void) { int ret; ret = acpi_bus_register_driver(&atk_driver); printk("%d\n", ret); if (ret) return ret; if (!atk_data.atk_handle) { ret = -ENODEV; goto bus_unreg; } if (!atk_found) { printk("atk not found\n"); ret = -ENODEV; goto bus_unreg; } atk_data.class_dev = hwmon_device_register(&atk_data.device->dev); if (IS_ERR(atk_data.class_dev)) { ret = PTR_ERR(atk_data.class_dev); goto bus_unreg; } ret = atk_create_files(&atk_data.device->dev); if (ret) goto remove_files; return ret; remove_files: atk_remove_files(&atk_data.device->dev); hwmon_device_unregister(atk_data.class_dev); bus_unreg: acpi_bus_unregister_driver(&atk_driver); return ret; } void atk_exit(void) { hwmon_device_unregister(atk_data.class_dev); atk_remove_files(&atk_data.device->dev); acpi_bus_unregister_driver(&atk_driver); } module_init(atk_init); module_exit(atk_exit); MODULE_LICENSE("GPL"); Luca -- Dicono che il cane sia il miglior amico dell'uomo. Secondo me non e` vero. Quanti dei vostri amici avete fatto castrare, recentemente? ^ permalink raw reply related [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-22 16:55 ` Luca Tettamanti 0 siblings, 0 replies; 207+ messages in thread From: Luca Tettamanti @ 2007-04-22 16:55 UTC (permalink / raw) To: Bjorn Helgaas Cc: Jean Delvare, Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert Il Wed, Apr 18, 2007 at 01:50:29AM +0200, Luca Tettamanti ha scritto: > >I'm sure you've seen these: > > http://lists.lm-sensors.org/pipermail/lm-sensors/2005-October/014050.html > > http://www.lm-sensors.org/wiki/AsusFormulaHacking > > Actually I haven't, I've happily ignored ACPI until now ;-) My DSDT > doesn't look too bad, I may give it a try... It wasn't hard :) Temperature reading works fine. AML code is still a bit obscure though: the reading are enumerated in two different sections: * TSIF, FSIF, VSIF: they have read/write methods, easy to understand (I'm using these right now) * SITM/GITM and GGPR for enumeration: more settings are available and in part they overlap the others. The methods are very strange, for e.g. temperature GITM (which calls GIT6) returns a hard-coded magic value; other methods (e.g. CPU frequency, Q-FAN settings) write a random number somewhere in the system memory and return an obscure magic value... very cool :) I'm posting the proof-of-concept driver. A few notes: - only temperature reading is implemented: I just got my MS degree so I've been drun^Wbusy - sysfs files are still RO - coding style: yes, I know... will cleanup - There's a gazillion of debugging printk's :) - I've extended the hwmon sysfs interface, with a new "temp%d_name"; ACPI knows how the sensor is wired - You'll need the following patch (against current Linus' git): diff --git a/drivers/acpi/namespace/nsutils.c b/drivers/acpi/namespace/nsutils.c index 90fd059..97e1139 100644 --- a/drivers/acpi/namespace/nsutils.c +++ b/drivers/acpi/namespace/nsutils.c @@ -700,6 +700,7 @@ struct acpi_namespace_node *acpi_ns_map_handle_to_node(acpi_handle handle) return (ACPI_CAST_PTR(struct acpi_namespace_node, handle)); } +EXPORT_SYMBOL(acpi_ns_map_handle_to_node); /******************************************************************************* * @@ -736,6 +737,7 @@ acpi_handle acpi_ns_convert_entry_to_handle(struct acpi_namespace_node *node) return ((acpi_handle) Node); ------------------------------------------------------*/ } +EXPORT_SYMBOL(acpi_ns_convert_entry_to_handle); /******************************************************************************* * @@ -875,6 +877,7 @@ acpi_ns_get_node(struct acpi_namespace_node *prefix_node, ACPI_FREE(internal_path); return_ACPI_STATUS(status); } +EXPORT_SYMBOL(acpi_ns_get_node); /******************************************************************************* * Now the driver: /* * Copyright (C) 2007 Luca Tettamanti <kronos.it@gmail.com> * Distribute under GPLv2. */ #include <linux/module.h> #include <linux/kernel.h> #include <linux/hwmon.h> #include <acpi/acpi.h> #include <acpi/acnamesp.h> #include <acpi/acpi_drivers.h> #include <acpi/acpi_bus.h> #define ATK_HID "ATK0110" #define ATK_DRV "atk-hwmon" #define ASOC "_SB.PCI0.SBRG.ASOC" struct atk_data { struct class_device *class_dev; acpi_handle atk_handle; struct acpi_device *device; acpi_handle rtmp_handle; } atk_data; typedef ssize_t (*sysfs_show_func)(struct device *dev, struct device_attribute *attr, char *buf); typedef ssize_t (*sysfs_store_func)(struct device *dev, struct device_attribute *attr, const char *buf, size_t count); static void atk_init_attribute(struct device_attribute *attr, char *name, mode_t mode, sysfs_show_func show, sysfs_store_func store) { attr->attr.name = name; attr->attr.mode = mode; attr->show = show; attr->store = store; } #define ATTR_NAME_SIZE 32 struct atk_temp_input { struct device_attribute dev_attr; /* id is used for the ACPI ID of the temp */ int id; char attr_name[ATTR_NAME_SIZE]; }; struct atk_temp_input_list { int count; struct atk_temp_input temp_input[]; }; #define to_atk_temp_input(attr) \ container_of(attr, struct atk_temp_input, dev_attr) static ssize_t atk_temp_input_show(struct device *dev, struct device_attribute *attr, char *buf) { struct atk_temp_input *a = to_atk_temp_input(attr); union acpi_object temp; struct acpi_buffer ret; struct acpi_object_list params; union acpi_object id; acpi_status status; ssize_t count; id.type = ACPI_TYPE_INTEGER; id.integer.value = a->id; params.count = 1; params.pointer = &id; ret.length = sizeof(temp); ret.pointer = &temp; status = acpi_evaluate_object(atk_data.rtmp_handle, NULL, ¶ms, &ret); if (status != AE_OK) { printk("acpi_evaluate_object: %s\n", acpi_format_exception(status)); return -EIO; } if (temp.type != ACPI_TYPE_INTEGER) { printk("not an integer (%d)\n", temp.type); return -EIO; } /* ACPI returns centidegree */ count = sprintf(buf, "%llu\n", temp.integer.value * 10); return count; } struct atk_temp_name { struct device_attribute dev_attr; char attr_name[ATTR_NAME_SIZE]; char const *name; }; struct atk_temp_name_list { int count; struct atk_temp_name temp_name[]; }; #define to_atk_temp_name(attr) \ container_of(attr, struct atk_temp_name, dev_attr) static ssize_t atk_temp_name_show(struct device *dev, struct device_attribute *attr, char *buf) { struct atk_temp_name *a = to_atk_temp_name(attr); return sprintf(buf, "%s\n", a->name); } enum atk_temp_pack_id { ATK_TEMP_PACK_MAX = 2, ATK_TEMP_PACK_CRIT = 3, }; static int atk_temp_pack_read(acpi_handle handle, int pack_id, enum atk_temp_pack_id temp_id, unsigned long long *temp) { struct acpi_buffer ret; struct acpi_object_list params; union acpi_object id; union acpi_object *pack; union acpi_object *obj; acpi_status status; int err = 0; ret.length = ACPI_ALLOCATE_BUFFER; id.type = ACPI_TYPE_INTEGER; id.integer.value = pack_id; params.count = 1; params.pointer = &id; status = acpi_evaluate_object(handle, NULL, ¶ms, &ret); if (status != AE_OK) { printk("atk_temp_pack_read: acpi_evaluate_object: %s\n", acpi_format_exception(status)); return -EIO; } pack = ret.pointer; if (pack->type != ACPI_TYPE_PACKAGE) { printk("atk_temp_pack_read: ret object is not a package: %d\n", pack->type); err = -EIO; goto out; } if (pack->package.count != 5) { printk("atk_temp_pack_read: unexpected package size: %d\n", pack->package.count); err = -EIO; goto out; } obj = &pack->package.elements[temp_id]; if (obj->type != ACPI_TYPE_INTEGER) { printk("atk_temp_pack_read: unexepected type %d\n", obj->type); err = -EIO; goto out; } *temp = obj->integer.value; out: ACPI_FREE(ret.pointer); return err; } struct atk_temp_max { struct device_attribute dev_attr; int id; acpi_handle handle; char attr_name[ATTR_NAME_SIZE]; }; struct atk_temp_max_list { int count; struct atk_temp_max temp_max[]; }; #define to_atk_temp_max(attr) \ container_of(attr, struct atk_temp_max, dev_attr) static ssize_t atk_temp_max_show(struct device *dev, struct device_attribute *attr, char *buf) { struct atk_temp_max *a = to_atk_temp_max(attr); unsigned long long temp; if (atk_temp_pack_read(a->handle, a->id, ATK_TEMP_PACK_MAX, &temp)) return -EIO; return sprintf(buf, "%lld\n", temp * 10); } struct atk_temp_crit { struct device_attribute dev_attr; int id; acpi_handle handle; char attr_name[ATTR_NAME_SIZE]; }; struct atk_temp_crit_list { int count; struct atk_temp_crit temp_crit[]; }; #define to_atk_temp_crit(attr) \ container_of(attr, struct atk_temp_crit, dev_attr) static ssize_t atk_temp_crit_show(struct device *dev, struct device_attribute *attr, char *buf) { struct atk_temp_crit *a = to_atk_temp_crit(attr); unsigned long long temp; if (atk_temp_pack_read(a->handle, a->id, ATK_TEMP_PACK_CRIT, &temp)) return -EIO; return sprintf(buf, "%lld\n", temp * 10); } struct atk_temp_input_list *temp_input_list; struct atk_temp_name_list *temp_name_list; struct atk_temp_max_list *temp_max_list; struct atk_temp_crit_list *temp_crit_list; static int atk_found; static int atk_add(struct acpi_device *device); static int atk_remove(struct acpi_device *device, int type); static struct acpi_driver atk_driver = { .name = ATK_HID, .class = "hwmon", .ids = ATK_HID, .ops = { .add = atk_add, .remove = atk_remove, }, }; static int atk_create_files(struct device *dev) { int i; int ret; /* Temperatures */ for (i = 0; i < temp_input_list->count; i++) { ret = device_create_file(dev, &temp_input_list->temp_input[i].dev_attr); if (ret) return ret; } for (i = 0; i < temp_name_list->count; i++) { ret = device_create_file(dev, &temp_name_list->temp_name[i].dev_attr); if (ret) return ret; } for (i = 0; i < temp_max_list->count; i++) { ret = device_create_file(dev, &temp_max_list->temp_max[i].dev_attr); if (ret) return ret; } for (i = 0; i < temp_crit_list->count; i++) { ret = device_create_file(dev, &temp_crit_list->temp_crit[i].dev_attr); if (ret) return ret; } return 0; } static void atk_remove_files(struct device *dev) { int i; /* Temperatures */ if (temp_input_list) { for (i = 0; i < temp_input_list->count; i++) device_remove_file(dev, &temp_input_list->temp_input[i].dev_attr); } kfree(temp_input_list); if (temp_name_list) { for (i = 0; i < temp_name_list->count; i++) { device_remove_file(dev, &temp_name_list->temp_name[i].dev_attr); kfree(temp_name_list->temp_name[i].name); } } kfree(temp_name_list); if (temp_max_list) { for (i = 0; i < temp_max_list->count; i++) device_remove_file(dev, &temp_max_list->temp_max[i].dev_attr); } kfree(temp_max_list); if (temp_crit_list) { for (i = 0; i < temp_crit_list->count; i++) device_remove_file(dev, &temp_crit_list->temp_crit[i].dev_attr); } kfree(temp_max_list); } static int atk_enumerate_temp(struct acpi_buffer *buf) { union acpi_object *pack; union acpi_object *obj; struct atk_temp_input_list *inputs; struct atk_temp_name_list *names; struct atk_temp_max_list *max; struct atk_temp_crit_list *crit; int i, ret; /* Result must be a package */ pack = buf->pointer; if (pack->type != ACPI_TYPE_PACKAGE) { printk("atk_enumerate_temp: not a package\n"); return -EINVAL; } if (pack->package.count < 1) { printk("atk_enumerate_temp: count < 1\n"); return -EINVAL; } /* First field is the number of available readings */ obj = &pack->package.elements[0]; if (obj->type != ACPI_TYPE_INTEGER) { printk("atk_enumerate_temp: element 0 is not an int (%u)\n", obj->type); return -EINVAL; } /* Sanity check */ if (pack->package.count != obj->integer.value + 1) { printk("atk_enumerate_temp: temperature count (%llu) differs from package count (%u)\n", obj->integer.value, pack->package.count); return -EINVAL; } inputs = kzalloc(sizeof(struct atk_temp_input_list) + sizeof(*inputs->temp_input) * obj->integer.value, GFP_KERNEL); if (!inputs) return -ENOMEM; names = kzalloc(sizeof(struct atk_temp_name_list) + sizeof(*names->temp_name) * obj->integer.value, GFP_KERNEL); if (!names) { ret = -ENOMEM; goto cleanup4; } max = kzalloc(sizeof(*max) + sizeof(*max->temp_max) * obj->integer.value, GFP_KERNEL); if (!max) { ret = -ENOMEM; goto cleanup3; } crit = kzalloc(sizeof(*crit) + sizeof(*crit->temp_crit) * obj->integer.value, GFP_KERNEL); if (!crit) { ret = -ENOMEM; goto cleanup2; } inputs->count = names->count = max->count = crit->count = obj->integer.value; for (i = 0; i < pack->package.count - 1; i++) { struct acpi_buffer buf; union acpi_object *temp_pack; union acpi_object *name; union acpi_object *tmax; union acpi_object *tcrit; acpi_status status; obj = &pack->package.elements[i + 1]; /* obj is a handle to the temperature package */ if (obj->type != ACPI_TYPE_ANY) { printk("atk_enumerate_temp: unexpected type: %d\n", obj->type); ret = -EINVAL; goto cleanup; } buf.length = ACPI_ALLOCATE_BUFFER; status = acpi_evaluate_object(obj->reference.handle, NULL, NULL, &buf); if (status != AE_OK) { printk("ACPI exception on object %u: %s\n", i + 1, acpi_format_exception(status)); ret = -EINVAL; goto cleanup; } /* Temperature package: * byte buffer? * [3]: used by GITM/SITM to locate correct GITx/SITx, * method, same as the other package (GPID) * [2]: same as the other package, seems unused in * GITM/STIM * [1]: type? * 1: cpu freq? * 2: voltage * 3: temperature * 4: fan * 7: Q-FAN (alarm?) * 8: NOS * [0]: used by GITx/SITx for demux; selects the * value stored in ASB1 (PRM0) * description * max * critical * unknown */ temp_pack = buf.pointer; if (temp_pack->type != ACPI_TYPE_PACKAGE) { printk("atk_enumerate_temp: unexpected type for package %u: %d\n", i + 1, temp_pack->type); ret = -EINVAL; goto cleanup; } if (temp_pack->package.count != 5) { printk("Invalid package count: %u\n", temp_pack->package.count); ret = -EINVAL; goto cleanup; } name = &temp_pack->package.elements[1]; tmax = &temp_pack->package.elements[2]; tcrit = &temp_pack->package.elements[3]; if (name->type != ACPI_TYPE_STRING) { printk("atk_enumerate_temp: object %d not a string (%d)\n", i, name->type); ret = -EINVAL; goto cleanup; } if (tmax->type != ACPI_TYPE_INTEGER) { printk("atk_enumerate_temp: object %d int expected (tmax), got: %d\n", i, tmax->type); ret = -EINVAL; goto cleanup; } if (tcrit->type != ACPI_TYPE_INTEGER) { printk("atk_enumerate_temp: object %d int expected (tmax), got: %d\n", i, tcrit->type); ret = -EINVAL; goto cleanup; } inputs->temp_input[i].id = i; snprintf(inputs->temp_input[i].attr_name, ATTR_NAME_SIZE, "temp%d_input", i); atk_init_attribute(&inputs->temp_input[i].dev_attr, inputs->temp_input[i].attr_name, 0444, atk_temp_input_show, NULL); names->temp_name[i].name = kstrdup(name->string.pointer, GFP_KERNEL); snprintf(names->temp_name[i].attr_name, ATTR_NAME_SIZE, "temp%d_name", i); atk_init_attribute(&names->temp_name[i].dev_attr, names->temp_name[i].attr_name, 0444, atk_temp_name_show, NULL); max->temp_max[i].handle = obj->reference.handle; snprintf(max->temp_max[i].attr_name, ATTR_NAME_SIZE, "temp%d_max", i); atk_init_attribute(&max->temp_max[i].dev_attr, max->temp_max[i].attr_name, 0444, atk_temp_max_show, NULL); crit->temp_crit[i].handle = obj->reference.handle; snprintf(crit->temp_crit[i].attr_name, ATTR_NAME_SIZE, "temp%d_crit", i); atk_init_attribute(&crit->temp_crit[i].dev_attr, crit->temp_crit[i].attr_name, 0444, atk_temp_crit_show, NULL); printk("temp %u: %s [%llu-%llu]\n", inputs->temp_input[i].id, names->temp_name[i].name, tmax->integer.value, tcrit->integer.value); ACPI_FREE(buf.pointer); } temp_name_list = names; temp_input_list = inputs; temp_max_list = max; temp_crit_list = crit; return 0; cleanup: kfree(crit); cleanup2: kfree(max); cleanup3: for (i = 0; i < names->count; i++) kfree(names->temp_name[i].name); kfree(names); cleanup4: kfree(inputs); return ret; } static int atk_add(struct acpi_device *device) { acpi_status ret; int err; struct acpi_buffer buf; union acpi_object *obj; struct acpi_namespace_node *search_ns; struct acpi_namespace_node *ns; printk("adding...\n"); atk_data.device = device; atk_data.atk_handle = device->handle; acpi_driver_data(device) = &atk_data; buf.length = ACPI_ALLOCATE_BUFFER; ret = acpi_evaluate_object(atk_data.atk_handle, "MBIF", NULL, &buf); if (ret != AE_OK) return -ENODEV; obj = buf.pointer; if (obj->type = ACPI_TYPE_PACKAGE) { printk("id: %s\n", obj->package.elements[1].string.pointer); } ACPI_FREE(buf.pointer); /* Check for hwmon methods */ search_ns = acpi_ns_map_handle_to_node(device->handle); if (search_ns = NULL) { printk("NULL\n"); return -ENODEV; } /* RTMP: read temperature */ ret = acpi_ns_get_node(search_ns, "RTMP", ACPI_NS_NO_UPSEARCH, &ns); if (ret != AE_OK) { printk(KERN_INFO "atk: RTMP not found\n"); return -ENODEV; } atk_data.rtmp_handle = acpi_ns_convert_entry_to_handle(ns); /* Enumerate temp data - TSIF */ buf.length = ACPI_ALLOCATE_BUFFER; ret = acpi_evaluate_object(atk_data.atk_handle, "TSIF", NULL, &buf); if (ret != AE_OK) { printk("TSIF failed: %s\n", acpi_format_exception(ret)); return -ENODEV; } err = atk_enumerate_temp(&buf); ACPI_FREE(buf.pointer); if (err) return err; atk_found = 1; return 0; } static int atk_remove(struct acpi_device *device, int type) { printk("remove %d\n", type); acpi_driver_data(device) = NULL; return AE_OK; } int atk_init(void) { int ret; ret = acpi_bus_register_driver(&atk_driver); printk("%d\n", ret); if (ret) return ret; if (!atk_data.atk_handle) { ret = -ENODEV; goto bus_unreg; } if (!atk_found) { printk("atk not found\n"); ret = -ENODEV; goto bus_unreg; } atk_data.class_dev = hwmon_device_register(&atk_data.device->dev); if (IS_ERR(atk_data.class_dev)) { ret = PTR_ERR(atk_data.class_dev); goto bus_unreg; } ret = atk_create_files(&atk_data.device->dev); if (ret) goto remove_files; return ret; remove_files: atk_remove_files(&atk_data.device->dev); hwmon_device_unregister(atk_data.class_dev); bus_unreg: acpi_bus_unregister_driver(&atk_driver); return ret; } void atk_exit(void) { hwmon_device_unregister(atk_data.class_dev); atk_remove_files(&atk_data.device->dev); acpi_bus_unregister_driver(&atk_driver); } module_init(atk_init); module_exit(atk_exit); MODULE_LICENSE("GPL"); Luca -- Dicono che il cane sia il miglior amico dell'uomo. Secondo me non e` vero. Quanti dei vostri amici avete fatto castrare, recentemente? _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply related [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-04-16 21:14 ` Luca Tettamanti @ 2007-04-17 10:03 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-04-17 10:03 UTC (permalink / raw) To: Luca Tettamanti, Bjorn Helgaas Cc: Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert Hi Bjorn, Luca, On Mon, 16 Apr 2007 23:14:11 +0200, Luca Tettamanti wrote: > Il Sun, Apr 15, 2007 at 06:57:02PM -0600, Bjorn Helgaas ha scritto: > > In the case of k8temp, the driver claims PCI devices with a certain > > vendor and device ID. PCI devices are mostly outside the scope of > > ACPI. There's a standard enumeration protocol, and a driver should > > be able to claim any device it recognizes without fear of conflict. > > > > I claim that an AML method that accesses a PCI device is > > defective because the AML can't know whether a native driver > > has claimed the device. > > k8temp seems a special case tough. Yes, it is, and the latest news are that there were no problems with the k8temp driver, it was a false alert. > > Sometimes the firmware can hide PCI devices so the OS > > enumeration doesn't find them. In that case, AML might > > be able to safely use the PCI device, but the native > > driver wouldn't be able to claim the device, so there > > would be no conflict. (Linux sometimes uses quirks to > > "unhide" things like this, which could lead to a conflict > > of our own making.) True, and we are stepping back on this. See: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9208ee8286ea2c0136a4bc58638b0295bad791c8 However, it's not so easy, as I have been explaining to Pavel lately. Some machines have the ACPI vs. lm-sensors conflict while the SMBus wasn't hidden. On others, the SMBus was hidden and there was no conflict. So we are not going to just stop unhiding the SMBus and fix all the problems that way. It's neither necessary, nor sufficient. The decision must be taken independently for every motherboard / laptop. > > I suspect that other sensor drivers may just probe for devices > > at "known" addresses hard-coded in the driver. > > Usually sensors are attached to SMBUS or available in ISA IO space. > AFAIK they're not enumerated anywhere (at least I2C devices are not, you > poke at various addresses and see if something responds - not sure about > ISA). Legacy ISA hardware monitoring chips (W83781D, W83782D, LM78, LM79) were indeed probed at an arbitrary address (0x290). I pretty much doubt that these old chips are found on systems with (working) ACPI though. More recent "ISA" hardware monitoring chips are embedded in Super-I/O chips, they are in fact LPC devices, not ISA. The base I/O address is read from the Super-I/O configuration space, (0x2e/0x2f or 0x4e/0x4f), just like serial ports, parallel ports, floppy disk controllers, IR, etc. So these devices _are_ enumerated. Sometimes they are also listed as PNP devices. As for I2C/SMBus devices, they are indeed not enumerated. But I fail to see why non-enumerated devices would be the sole properly of ACPI. > > This is a > > problem because the ACPI model is that the OS learns about > > all built-in devices via the ACPI namespace. If it isn't > > in the namespace, it shouldn't exist as far as the OS is > > concerned. > > > > So we could easily have the situation where ACPI uses a > > sensor and does not expose it to the OS in the namespace. > > In that case, the firmware expectation is that the OS > > won't touch the device. If the OS pokes around at the > > magic addresses and happens to trip over the device, we > > just made ourselves a problem. Interesting theory, but how does it fly in practice? Not much, I guess. I doubt you could do any useful with an ACPI-enabled system today without any non-ACPI driver. > > > > Is this extra functionality available > > > > on Windows? If so, do we know whether Windows uses non-ACPI drivers > > > > or whether they have some smarter way to use ACPI? > > > > > > Usually ACPI exposes 1 or 2 temperature readings (CPU and > > > motherboard), while the hw driver can also provide fans and voltages > > > measurements. And fan speed control. > > > Vendors usually provides a monitoring utility for Win that also > > > exposes these information. It's not known whether there's a way to > > > avoid conflicting accesses between ACPI and the raw driver; it's > > > possible that it's vendor-specific and not documented. > > > > I'd be surprised if Windows provided interfaces to coordinate > > between two drivers. My impression is that they really want > > to have a single owner for a piece of hardware. It would be > > interesting to figure out how these monitoring utilities work. > > Maybe the monitor and the AML both go through an embedded > > controller driver and coordinate that way? > > Hum, the utility I have here (Asus PC Probe) seems to use ACPI: > > Pro2.dll: > [Ordinal/Name Pointer] Table > [ 11] OCAPI_ACPI_OC_PresetList > [ 12] OCAPI_ACPI_OC__MB_GetBoardName > [ 23] OCAPI_CheckAiGear > [ 0] OCAPI_CheckIntelPowerSaving > [ 6] OCAPI_CheckWorkable > [ 2] OCAPI_Close > [ 9] OCAPI_EnableQFan > [ 16] OCAPI_GENERAL_GetList > [ 14] OCAPI_GetCpuVoltRange > [ 13] OCAPI_GetCurrentCpuFrequency > [ 15] OCAPI_GetFanStartTemp > [ 3] OCAPI_GetHealthData > [ 4] OCAPI_GetHwSensorData > [ 22] OCAPI_GetMBIF > [ 8] OCAPI_GetQFanInfo > [ 5] OCAPI_HW_EnumerateOption > [ 7] OCAPI_HideQFan > [ 1] OCAPI_Initialization > [ 19] OCAPI_NQFAN_GetData > [ 21] OCAPI_NQFAN_GetList > [ 20] OCAPI_NQFAN_SetData > [ 17] OCAPI_QFAN_GetData > [ 18] OCAPI_QFAN_SetData > [ 10] OCAPI_SetQFanTarget > [ 24] ___CPPdebugHook > > ASiO.dll: > [Ordinal/Name Pointer] Table > [ 1] ASIO_Close > [ 9] ASIO_GetCpuID > [ 3] ASIO_InPortB > [ 5] ASIO_InPortD > [ 7] ASIO_MapMem > [ 0] ASIO_Open > [ 4] ASIO_OutPortB > [ 6] ASIO_OutPortD > [ 10] ASIO_ReadMSR > [ 8] ASIO_UnmapMem > [ 11] ASIO_WriteMSR > [ 2] OC_GetCurrentCpuFrequency > > It seems that Asus exposes monitorining data using "ATK0110" (enumerated > in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D) > (they have different methods though). Another motherboard with the same > device may actually call it "FOOBAR123" or "WTFISTHIS". > > Problem is that ACPI methods are not documented at all (how am I > supposed to know that "G6T6" is the reading of the 12V rail?) while the > datasheet of hw monitoring chips (w83627ehf in my case) are public (more > or less). Furthermore, sensor driver exposes all the reading of the chip > (e.g. in the DSDT I can't find the VSB or battery voltage). Asus does things like this, yeah, but I don't remember any other vendor having such ACPI methods. It would make sense to write a driver for this Asus stuff. One of the problem we have in hardware monitoring drivers is that we usually don't know how the chip is wired on a given motherboard. The ACPI data might help. For the other vendors, my assumption is the same as yours: they either ignore the conflict, or have proprietary, undocumented ways to get around it. After all, there must be a reason why there is no native sensors support in Windows and every vendor provides it's own tool. -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-04-17 10:03 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-04-17 10:03 UTC (permalink / raw) To: Luca Tettamanti, Bjorn Helgaas Cc: Pavel Machek, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert Hi Bjorn, Luca, On Mon, 16 Apr 2007 23:14:11 +0200, Luca Tettamanti wrote: > Il Sun, Apr 15, 2007 at 06:57:02PM -0600, Bjorn Helgaas ha scritto: > > In the case of k8temp, the driver claims PCI devices with a certain > > vendor and device ID. PCI devices are mostly outside the scope of > > ACPI. There's a standard enumeration protocol, and a driver should > > be able to claim any device it recognizes without fear of conflict. > > > > I claim that an AML method that accesses a PCI device is > > defective because the AML can't know whether a native driver > > has claimed the device. > > k8temp seems a special case tough. Yes, it is, and the latest news are that there were no problems with the k8temp driver, it was a false alert. > > Sometimes the firmware can hide PCI devices so the OS > > enumeration doesn't find them. In that case, AML might > > be able to safely use the PCI device, but the native > > driver wouldn't be able to claim the device, so there > > would be no conflict. (Linux sometimes uses quirks to > > "unhide" things like this, which could lead to a conflict > > of our own making.) True, and we are stepping back on this. See: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h’08ee8286ea2c0136a4bc58638b0295bad791c8 However, it's not so easy, as I have been explaining to Pavel lately. Some machines have the ACPI vs. lm-sensors conflict while the SMBus wasn't hidden. On others, the SMBus was hidden and there was no conflict. So we are not going to just stop unhiding the SMBus and fix all the problems that way. It's neither necessary, nor sufficient. The decision must be taken independently for every motherboard / laptop. > > I suspect that other sensor drivers may just probe for devices > > at "known" addresses hard-coded in the driver. > > Usually sensors are attached to SMBUS or available in ISA IO space. > AFAIK they're not enumerated anywhere (at least I2C devices are not, you > poke at various addresses and see if something responds - not sure about > ISA). Legacy ISA hardware monitoring chips (W83781D, W83782D, LM78, LM79) were indeed probed at an arbitrary address (0x290). I pretty much doubt that these old chips are found on systems with (working) ACPI though. More recent "ISA" hardware monitoring chips are embedded in Super-I/O chips, they are in fact LPC devices, not ISA. The base I/O address is read from the Super-I/O configuration space, (0x2e/0x2f or 0x4e/0x4f), just like serial ports, parallel ports, floppy disk controllers, IR, etc. So these devices _are_ enumerated. Sometimes they are also listed as PNP devices. As for I2C/SMBus devices, they are indeed not enumerated. But I fail to see why non-enumerated devices would be the sole properly of ACPI. > > This is a > > problem because the ACPI model is that the OS learns about > > all built-in devices via the ACPI namespace. If it isn't > > in the namespace, it shouldn't exist as far as the OS is > > concerned. > > > > So we could easily have the situation where ACPI uses a > > sensor and does not expose it to the OS in the namespace. > > In that case, the firmware expectation is that the OS > > won't touch the device. If the OS pokes around at the > > magic addresses and happens to trip over the device, we > > just made ourselves a problem. Interesting theory, but how does it fly in practice? Not much, I guess. I doubt you could do any useful with an ACPI-enabled system today without any non-ACPI driver. > > > > Is this extra functionality available > > > > on Windows? If so, do we know whether Windows uses non-ACPI drivers > > > > or whether they have some smarter way to use ACPI? > > > > > > Usually ACPI exposes 1 or 2 temperature readings (CPU and > > > motherboard), while the hw driver can also provide fans and voltages > > > measurements. And fan speed control. > > > Vendors usually provides a monitoring utility for Win that also > > > exposes these information. It's not known whether there's a way to > > > avoid conflicting accesses between ACPI and the raw driver; it's > > > possible that it's vendor-specific and not documented. > > > > I'd be surprised if Windows provided interfaces to coordinate > > between two drivers. My impression is that they really want > > to have a single owner for a piece of hardware. It would be > > interesting to figure out how these monitoring utilities work. > > Maybe the monitor and the AML both go through an embedded > > controller driver and coordinate that way? > > Hum, the utility I have here (Asus PC Probe) seems to use ACPI: > > Pro2.dll: > [Ordinal/Name Pointer] Table > [ 11] OCAPI_ACPI_OC_PresetList > [ 12] OCAPI_ACPI_OC__MB_GetBoardName > [ 23] OCAPI_CheckAiGear > [ 0] OCAPI_CheckIntelPowerSaving > [ 6] OCAPI_CheckWorkable > [ 2] OCAPI_Close > [ 9] OCAPI_EnableQFan > [ 16] OCAPI_GENERAL_GetList > [ 14] OCAPI_GetCpuVoltRange > [ 13] OCAPI_GetCurrentCpuFrequency > [ 15] OCAPI_GetFanStartTemp > [ 3] OCAPI_GetHealthData > [ 4] OCAPI_GetHwSensorData > [ 22] OCAPI_GetMBIF > [ 8] OCAPI_GetQFanInfo > [ 5] OCAPI_HW_EnumerateOption > [ 7] OCAPI_HideQFan > [ 1] OCAPI_Initialization > [ 19] OCAPI_NQFAN_GetData > [ 21] OCAPI_NQFAN_GetList > [ 20] OCAPI_NQFAN_SetData > [ 17] OCAPI_QFAN_GetData > [ 18] OCAPI_QFAN_SetData > [ 10] OCAPI_SetQFanTarget > [ 24] ___CPPdebugHook > > ASiO.dll: > [Ordinal/Name Pointer] Table > [ 1] ASIO_Close > [ 9] ASIO_GetCpuID > [ 3] ASIO_InPortB > [ 5] ASIO_InPortD > [ 7] ASIO_MapMem > [ 0] ASIO_Open > [ 4] ASIO_OutPortB > [ 6] ASIO_OutPortD > [ 10] ASIO_ReadMSR > [ 8] ASIO_UnmapMem > [ 11] ASIO_WriteMSR > [ 2] OC_GetCurrentCpuFrequency > > It seems that Asus exposes monitorining data using "ATK0110" (enumerated > in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D) > (they have different methods though). Another motherboard with the same > device may actually call it "FOOBAR123" or "WTFISTHIS". > > Problem is that ACPI methods are not documented at all (how am I > supposed to know that "G6T6" is the reading of the 12V rail?) while the > datasheet of hw monitoring chips (w83627ehf in my case) are public (more > or less). Furthermore, sensor driver exposes all the reading of the chip > (e.g. in the DSDT I can't find the VSB or battery voltage). Asus does things like this, yeah, but I don't remember any other vendor having such ACPI methods. It would make sense to write a driver for this Asus stuff. One of the problem we have in hardware monitoring drivers is that we usually don't know how the chip is wired on a given motherboard. The ACPI data might help. For the other vendors, my assumption is the same as yours: they either ignore the conflict, or have proprietary, undocumented ways to get around it. After all, there must be a reason why there is no native sensors support in Windows and every vendor provides it's own tool. -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-17 18:14 ` Chuck Ebbert @ 2007-02-18 22:43 ` Rudolf Marek -1 siblings, 0 replies; 207+ messages in thread From: Rudolf Marek @ 2007-02-18 22:43 UTC (permalink / raw) To: Chuck Ebbert; +Cc: linux-kernel, linux-acpi, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-18 22:43 ` Rudolf Marek 0 siblings, 0 replies; 207+ messages in thread From: Rudolf Marek @ 2007-02-18 22:43 UTC (permalink / raw) To: Chuck Ebbert; +Cc: linux-kernel, linux-acpi, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-18 22:43 ` Rudolf Marek @ 2007-02-20 15:08 ` Chuck Ebbert -1 siblings, 0 replies; 207+ messages in thread From: Chuck Ebbert @ 2007-02-20 15:08 UTC (permalink / raw) To: Rudolf Marek; +Cc: linux-kernel, linux-acpi, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-20 15:08 ` Chuck Ebbert 0 siblings, 0 replies; 207+ messages in thread From: Chuck Ebbert @ 2007-02-20 15:08 UTC (permalink / raw) To: Rudolf Marek; +Cc: linux-kernel, linux-acpi, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-20 15:08 ` Chuck Ebbert @ 2007-02-20 19:11 ` Dave Jones -1 siblings, 0 replies; 207+ messages in thread From: Dave Jones @ 2007-02-20 19:11 UTC (permalink / raw) To: Chuck Ebbert; +Cc: Rudolf Marek, linux-kernel, linux-acpi, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-20 19:11 ` Dave Jones 0 siblings, 0 replies; 207+ messages in thread From: Dave Jones @ 2007-02-20 19:11 UTC (permalink / raw) To: Chuck Ebbert; +Cc: Rudolf Marek, linux-kernel, linux-acpi, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-20 19:11 ` Dave Jones @ 2007-02-21 16:17 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-21 16:17 UTC (permalink / raw) To: Dave Jones; +Cc: Chuck Ebbert, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-21 16:17 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-21 16:17 UTC (permalink / raw) To: Dave Jones; +Cc: Chuck Ebbert, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-21 16:17 ` Jean Delvare @ 2007-02-21 17:37 ` Dave Jones -1 siblings, 0 replies; 207+ messages in thread From: Dave Jones @ 2007-02-21 17:37 UTC (permalink / raw) To: Jean Delvare; +Cc: Chuck Ebbert, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-21 17:37 ` Dave Jones 0 siblings, 0 replies; 207+ messages in thread From: Dave Jones @ 2007-02-21 17:37 UTC (permalink / raw) To: Jean Delvare; +Cc: Chuck Ebbert, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-21 17:37 ` Dave Jones @ 2007-02-21 20:19 ` Dave Jones -1 siblings, 0 replies; 207+ messages in thread From: Dave Jones @ 2007-02-21 20:19 UTC (permalink / raw) To: Jean Delvare, Chuck Ebbert, linux-acpi, linux-kernel, lm-sensors, notting 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-21 20:19 ` Dave Jones 0 siblings, 0 replies; 207+ messages in thread From: Dave Jones @ 2007-02-21 20:19 UTC (permalink / raw) To: Jean Delvare, Chuck Ebbert, linux-acpi, linux-kernel, lm-sensors, notting 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-21 20:19 ` Dave Jones @ 2007-02-22 16:37 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-22 16:37 UTC (permalink / raw) To: Dave Jones; +Cc: Chuck Ebbert, linux-acpi, linux-kernel, lm-sensors, notting 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-22 16:37 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-22 16:37 UTC (permalink / raw) To: Dave Jones; +Cc: Chuck Ebbert, linux-acpi, linux-kernel, lm-sensors, notting 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: Could the k8temp driver be interfering with ACPI? 2007-02-22 16:37 ` Jean Delvare (?) @ 2007-02-23 7:13 ` Hans de Goede -1 siblings, 0 replies; 207+ messages in thread From: Hans de Goede @ 2007-02-23 7:13 UTC (permalink / raw) To: Jean Delvare Cc: notting, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert, Dave Jones Jean Delvare wrote: > On Wed, 21 Feb 2007 15:19:44 -0500, Dave Jones wrote: >> Ah, Fedora has this horror in its initscripts (which explains why I missed >> it in my grep).. >> >> # Initialize ACPI bits >> if [ -d /proc/acpi ]; then >> for module in /lib/modules/$unamer/kernel/drivers/acpi/* ; do >> module=${module##*/} >> module=${module%.ko} >> modprobe $module >/dev/null 2>&1 >> done >> fi > > Ah, this also explains why the i2c_ec and sbs drivers were loaded on > Chuck's system, although they were not needed. > >> This is there because there's no clean way for userspace to know whether >> to load the system specific stuff right now. Bill Nottingham pointed >> out that we could add a /sys/class/dmi/modalias and appropriate MODULE_DMI >> tags to the various modules like asus_acpi to make udev autoload them. > > Something similiar should be doable for i2c_ec, as it's only useful if a > given ACPI object is present. sbs, in turn, is only useful if i2c_ec is > loaded. > I'm thinking that it might be an idea to also use this idea of udev autoloading through DMI info for the abituguru and abituguru3 driver (review please). The both only support about 12 motherboards. For the abituguru driver, dmi info could also be used to automatically set the module options needed on the 2 oldest uguru featuring abit motherboards. What do you think about this? Regards, Hans _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-23 7:13 ` Hans de Goede 0 siblings, 0 replies; 207+ messages in thread From: Hans de Goede @ 2007-02-23 7:13 UTC (permalink / raw) To: Jean Delvare Cc: notting, linux-kernel, lm-sensors, linux-acpi, Chuck Ebbert, Dave Jones Jean Delvare wrote: > On Wed, 21 Feb 2007 15:19:44 -0500, Dave Jones wrote: >> Ah, Fedora has this horror in its initscripts (which explains why I missed >> it in my grep).. >> >> # Initialize ACPI bits >> if [ -d /proc/acpi ]; then >> for module in /lib/modules/$unamer/kernel/drivers/acpi/* ; do >> module=${module##*/} >> module=${module%.ko} >> modprobe $module >/dev/null 2>&1 >> done >> fi > > Ah, this also explains why the i2c_ec and sbs drivers were loaded on > Chuck's system, although they were not needed. > >> This is there because there's no clean way for userspace to know whether >> to load the system specific stuff right now. Bill Nottingham pointed >> out that we could add a /sys/class/dmi/modalias and appropriate MODULE_DMI >> tags to the various modules like asus_acpi to make udev autoload them. > > Something similiar should be doable for i2c_ec, as it's only useful if a > given ACPI object is present. sbs, in turn, is only useful if i2c_ec is > loaded. > I'm thinking that it might be an idea to also use this idea of udev autoloading through DMI info for the abituguru and abituguru3 driver (review please). The both only support about 12 motherboards. For the abituguru driver, dmi info could also be used to automatically set the module options needed on the 2 oldest uguru featuring abit motherboards. What do you think about this? Regards, Hans ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-23 7:13 ` Hans de Goede 0 siblings, 0 replies; 207+ messages in thread From: Hans de Goede @ 2007-02-23 7:13 UTC (permalink / raw) To: Jean Delvare Cc: Dave Jones, linux-acpi, notting, linux-kernel, Chuck Ebbert, lm-sensors Jean Delvare wrote: > On Wed, 21 Feb 2007 15:19:44 -0500, Dave Jones wrote: >> Ah, Fedora has this horror in its initscripts (which explains why I missed >> it in my grep).. >> >> # Initialize ACPI bits >> if [ -d /proc/acpi ]; then >> for module in /lib/modules/$unamer/kernel/drivers/acpi/* ; do >> module=${module##*/} >> module=${module%.ko} >> modprobe $module >/dev/null 2>&1 >> done >> fi > > Ah, this also explains why the i2c_ec and sbs drivers were loaded on > Chuck's system, although they were not needed. > >> This is there because there's no clean way for userspace to know whether >> to load the system specific stuff right now. Bill Nottingham pointed >> out that we could add a /sys/class/dmi/modalias and appropriate MODULE_DMI >> tags to the various modules like asus_acpi to make udev autoload them. > > Something similiar should be doable for i2c_ec, as it's only useful if a > given ACPI object is present. sbs, in turn, is only useful if i2c_ec is > loaded. > I'm thinking that it might be an idea to also use this idea of udev autoloading through DMI info for the abituguru and abituguru3 driver (review please). The both only support about 12 motherboards. For the abituguru driver, dmi info could also be used to automatically set the module options needed on the 2 oldest uguru featuring abit motherboards. What do you think about this? Regards, Hans ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-23 7:13 ` Hans de Goede @ 2007-02-23 7:47 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-23 7:47 UTC (permalink / raw) To: Hans de Goede Cc: Dave Jones, linux-acpi, notting, linux-kernel, Chuck Ebbert, 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-23 7:47 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-23 7:47 UTC (permalink / raw) To: Hans de Goede Cc: Dave Jones, linux-acpi, notting, linux-kernel, Chuck Ebbert, 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-20 15:08 ` Chuck Ebbert @ 2007-02-21 14:54 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-21 14:54 UTC (permalink / raw) To: Chuck Ebbert; +Cc: Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-21 14:54 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-21 14:54 UTC (permalink / raw) To: Chuck Ebbert; +Cc: Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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\x117160531631100&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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-21 14:54 ` Jean Delvare @ 2007-02-21 16:03 ` Chuck Ebbert -1 siblings, 0 replies; 207+ messages in thread From: Chuck Ebbert @ 2007-02-21 16:03 UTC (permalink / raw) To: Jean Delvare; +Cc: Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-21 16:03 ` Chuck Ebbert 0 siblings, 0 replies; 207+ messages in thread From: Chuck Ebbert @ 2007-02-21 16:03 UTC (permalink / raw) To: Jean Delvare; +Cc: Rudolf Marek, linux-acpi, linux-kernel, lm-sensors 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 ^ permalink raw reply [flat|nested] 207+ messages in thread
* Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-21 16:03 ` Chuck Ebbert @ 2007-02-21 16:22 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-21 16:22 UTC (permalink / raw) To: Chuck Ebbert; +Cc: Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Wed, 21 Feb 2007 11:03:07 -0500, Chuck Ebbert wrote: > Jean Delvare wrote: > > Can you try to load the i2c-dev driver, then run the following commands > > and report the results: > > $ i2cdetect -l > > For each bus listed: > > $ i2cdetect N > > FWIW it's really an ATIIXP chipset, but supposedly PIIX4 compatible: > > # i2cdetect -l > i2c-0 smbus SMBus PIIX4 adapter at 8400 Non-I2C SMBus adapter No i2c_ec. Maybe your distribution is loading it by default for everyone then. Either way, it means you can forget right away about sbs, if i2c_ec didn't register a device, sbs cannot be used. > # i2cdetect 0 > WARNING! This program can confuse your I2C bus, cause data loss and worse! > I will probe file /dev/i2c-0. > I will probe address range 0x03-0x77. > Continue? [Y/n] y > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: XX XX XX XX XX XX XX XX XX XX XX XX XX > 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > 50: 50 51 XX XX XX XX XX XX XX XX XX XX XX XX XX XX > 60: XX XX XX XX XX XX XX XX XX 69 XX XX XX XX XX XX > 70: XX XX XX XX XX XX XX XX Only a couple EEPROMs and a clock chip on your SMBus, it's very unlikely that ACPI accesses this at all. So I'd be surprised that i2c-piix4 is causing any trouble. This leaves asus_acpi as the only candidate? Better unload _all_ the drivers you consider as suspects, and see if it changes anything. I guess not. -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? @ 2007-02-21 16:22 ` Jean Delvare 0 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-21 16:22 UTC (permalink / raw) To: Chuck Ebbert; +Cc: Rudolf Marek, linux-acpi, linux-kernel, lm-sensors On Wed, 21 Feb 2007 11:03:07 -0500, Chuck Ebbert wrote: > Jean Delvare wrote: > > Can you try to load the i2c-dev driver, then run the following commands > > and report the results: > > $ i2cdetect -l > > For each bus listed: > > $ i2cdetect N > > FWIW it's really an ATIIXP chipset, but supposedly PIIX4 compatible: > > # i2cdetect -l > i2c-0 smbus SMBus PIIX4 adapter at 8400 Non-I2C SMBus adapter No i2c_ec. Maybe your distribution is loading it by default for everyone then. Either way, it means you can forget right away about sbs, if i2c_ec didn't register a device, sbs cannot be used. > # i2cdetect 0 > WARNING! This program can confuse your I2C bus, cause data loss and worse! > I will probe file /dev/i2c-0. > I will probe address range 0x03-0x77. > Continue? [Y/n] y > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: XX XX XX XX XX XX XX XX XX XX XX XX XX > 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > 50: 50 51 XX XX XX XX XX XX XX XX XX XX XX XX XX XX > 60: XX XX XX XX XX XX XX XX XX 69 XX XX XX XX XX XX > 70: XX XX XX XX XX XX XX XX Only a couple EEPROMs and a clock chip on your SMBus, it's very unlikely that ACPI accesses this at all. So I'd be surprised that i2c-piix4 is causing any trouble. This leaves asus_acpi as the only candidate? Better unload _all_ the drivers you consider as suspects, and see if it changes anything. I guess not. -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-16 17:31 ` [lm-sensors] " Chuck Ebbert ` (3 preceding siblings ...) (?) @ 2007-02-23 8:08 ` Hans de Goede -1 siblings, 0 replies; 207+ messages in thread From: Hans de Goede @ 2007-02-23 8:08 UTC (permalink / raw) To: lm-sensors Jean Delvare wrote: > 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. > <snipping CC-list down a bit> I'm glad you like it, but how does this relate to using dmi info in sensors-detect, if we add that capability to sensors-detect and add a database with known motherboards and there configs, then that would be a doublure with having the info in the drivers, this is the main reason why I hesitate. Regards, Hans ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-16 17:31 ` [lm-sensors] " Chuck Ebbert ` (4 preceding siblings ...) (?) @ 2007-02-26 17:24 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-26 17:24 UTC (permalink / raw) To: lm-sensors Hi Hans, On Fri, 23 Feb 2007 09:08:30 +0100, Hans de Goede wrote: > I'm glad you like it, but how does this relate to using dmi info in > sensors-detect, if we add that capability to sensors-detect and add a database > with known motherboards and there configs, then that would be a doublure with > having the info in the drivers, this is the main reason why I hesitate. Very good point. I believe that the abituguru case is a bit special. The DMI data is not only useful to find out which boards need the driver. It is also useful to prevent the driver from being loaded on random hardware. Given that the chip is impossible to detect, it would sound sensible to at least prevent the abituguru driver from being loaded on non-Abit systems. If the list of supported boards is short and well known, including it too can't hurt. But we can't do that for the rest of the hwmon drivers. The list of supported boards for each driver is too long and growing too fast to live in the kernel. For other drivers my plan is to just detect them and trigger the module load. For Super-I/O chips, they have ID registers, we can read them and have a table that match IDs to drivers. For SMBus chip, once we have David Brownell's new i2c-core infrastructure, we should be able to write a hwmon-smbus-probe drivers which would probe the SMBus for chips and trigger the right module loading. But it might take a long time before we manage to implement all this. In the meantime we have to let user-space deal with it, which is the case at the moment, and it doesn't work so bad if you ask me. As for sensors-detect itself, there's much more to do with the DMI data than just finding which drivers need to be loaded. I don't think we would bother adding DMI support to sensors-detect just for that, except for the few boards with undetectable chips (uGuru) or which are otherwise known to cause trouble when probed. The true value of using DMI data in sensors-detect is to have a repository of configuration files identified by DMI data, so that sensors-detect can fetch and install a custom configuration file for your system. Being able to find out the right drivers without probing is more or less a side effect. -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-16 17:31 ` [lm-sensors] " Chuck Ebbert ` (5 preceding siblings ...) (?) @ 2007-02-26 19:03 ` Hans de Goede -1 siblings, 0 replies; 207+ messages in thread From: Hans de Goede @ 2007-02-26 19:03 UTC (permalink / raw) To: lm-sensors Jean Delvare wrote: > Hi Hans, > > On Fri, 23 Feb 2007 09:08:30 +0100, Hans de Goede wrote: >> I'm glad you like it, but how does this relate to using dmi info in >> sensors-detect, if we add that capability to sensors-detect and add a database >> with known motherboards and there configs, then that would be a doublure with >> having the info in the drivers, this is the main reason why I hesitate. > > Very good point. > > I believe that the abituguru case is a bit special. The DMI data is not > only useful to find out which boards need the driver. It is also useful > to prevent the driver from being loaded on random hardware. Given that > the chip is impossible to detect, it would sound sensible to at least > prevent the abituguru driver from being loaded on non-Abit systems. If > the list of supported boards is short and well known, including it too > can't hurt. > Ok, notice though that although the detection of the abituguru is indeed very weak, it will probably cause tons of false positives, that the driver will not actually load as the driver probe function will do a full test-read, which will fail on anything but an uguru (1 in a million chance this doesn't happen). The problems here are: 1) the read cycle does isa outb's which could upset non uguru hardware 2) at this point in the mod-loading stage, the insmod has succeeded confusing users, as the see the module but get no sysfs hwmon entries (the driver didn't load but the platform device was created) Now 2 can be fixed by doing the test-read before creating the platform device, but I don't know if thats worth it. > As for sensors-detect itself, there's much more to do with the DMI data > than just finding which drivers need to be loaded. I don't think we > would bother adding DMI support to sensors-detect just for that, except > for the few boards with undetectable chips (uGuru) or which are > otherwise known to cause trouble when probed. The true value of using > DMI data in sensors-detect is to have a repository of configuration > files identified by DMI data, so that sensors-detect can fetch and > install a custom configuration file for your system. Being able to find > out the right drivers without probing is more or less a side effect. > Agreed 100% this is _exactly_ the asignment I have given my students, I've even told them to create a web interface to allow people to upload correct sensors.conf settings for a certain motherboatd together with the DMI data. Please read the document they have posted, it is in English and it should contain a product description exactly matching what you describe / want. If you want to fix the requirements I laid down for this now would be THE time. Regards, Hans ^ permalink raw reply [flat|nested] 207+ messages in thread
* [lm-sensors] Could the k8temp driver be interfering with ACPI? 2007-02-16 17:31 ` [lm-sensors] " Chuck Ebbert ` (6 preceding siblings ...) (?) @ 2007-02-27 8:45 ` Jean Delvare -1 siblings, 0 replies; 207+ messages in thread From: Jean Delvare @ 2007-02-27 8:45 UTC (permalink / raw) To: lm-sensors On Mon, 26 Feb 2007 20:03:59 +0100, Hans de Goede wrote: > Ok, notice though that although the detection of the abituguru is indeed > very weak, it will probably cause tons of false positives, that the > driver will not actually load as the driver probe function will do a > full test-read, which will fail on anything but an uguru (1 in a million > chance this doesn't happen). The problems here are: > 1) the read cycle does isa outb's which could upset non uguru hardware outb is, by definition, a write, which is why we should prevent it from happening on systems without the relevant hardware. > 2) at this point in the mod-loading stage, the insmod has succeeded > confusing users, as the see the module but get no sysfs hwmon entries > (the driver didn't load but the platform device was created) > > Now 2 can be fixed by doing the test-read before creating the platform > device, but I don't know if thats worth it. Well there are two approaches: 1* Keep the platform driver approach, and have the platform device created outside the abituguru driver. In this case it is OK to let the abituguru driver load when no device is found, same as PCI drivers do. * Think of the uGuru as a legacy ISA device. In that case the driver should fail if the uGuru isn't found. Maybe you can look into the new isa driver type (drivers/base/isa.c). I must look into it myself, it might be the right solution to move the lm78 and w83781d drivers out of using i2c-isa. > Agreed 100% this is _exactly_ the asignment I have given my students, > I've even told them to create a web interface to allow people to upload > correct sensors.conf settings for a certain motherboatd together with > the DMI data. Please read the document they have posted, it is in > English and it should contain a product description exactly matching > what you describe / want. If you want to fix the requirements I laid > down for this now would be THE time. I've read the "Background Information" and "Objectives" parts, overall it looks good, except that a proofread of the document would be very welcome. I'll comment in the adequate thread. -- Jean Delvare ^ permalink raw reply [flat|nested] 207+ messages in thread
end of thread, other threads:[~2007-04-22 16:55 UTC | newest] Thread overview: 207+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-02-16 17:31 Could the k8temp driver be interfering with ACPI? Chuck Ebbert 2007-02-16 17:31 ` [lm-sensors] " Chuck Ebbert 2007-02-16 17:57 ` Len Brown 2007-02-16 17:57 ` [lm-sensors] " Len Brown 2007-02-16 18:14 ` Chuck Ebbert 2007-02-16 18:14 ` [lm-sensors] " Chuck Ebbert 2007-02-16 19:59 ` Andi Kleen 2007-02-16 19:59 ` [lm-sensors] " Andi Kleen 2007-02-16 19:31 ` Chuck Ebbert 2007-02-16 19:31 ` [lm-sensors] " Chuck Ebbert 2007-02-18 17:32 ` Jean Delvare 2007-02-18 17:32 ` Jean Delvare 2007-02-18 23:22 ` Andi Kleen 2007-02-18 23:22 ` Andi Kleen 2007-02-17 10:49 ` Rudolf Marek 2007-02-17 10:49 ` [lm-sensors] " Rudolf Marek 2007-02-17 10:49 ` Rudolf Marek 2007-02-17 18:14 ` Chuck Ebbert 2007-02-17 18:14 ` Chuck Ebbert 2007-02-18 17:38 ` Jean Delvare 2007-02-18 17:38 ` Jean Delvare 2007-02-20 15:18 ` Matthew Garrett 2007-02-20 15:18 ` Matthew Garrett 2007-02-20 15:33 ` Luca Tettamanti 2007-02-20 15:33 ` Luca Tettamanti 2007-02-21 14:59 ` Jean Delvare 2007-02-21 14:59 ` Jean Delvare 2007-02-21 15:07 ` Jean Delvare 2007-02-21 15:07 ` Jean Delvare 2007-02-28 21:38 ` Pavel Machek 2007-02-28 21:38 ` Pavel Machek 2007-03-01 14:26 ` Jean Delvare 2007-03-01 14:26 ` [lm-sensors] " Jean Delvare 2007-03-01 14:26 ` Jean Delvare 2007-03-01 17:48 ` Dave Jones 2007-03-01 17:48 ` Dave Jones 2007-03-02 11:27 ` Jean Delvare 2007-03-02 11:27 ` Jean Delvare 2007-03-02 11:31 ` Pavel Machek 2007-03-02 11:31 ` Pavel Machek 2007-03-02 13:37 ` Jean Delvare 2007-03-02 13:37 ` Jean Delvare 2007-03-02 13:47 ` Henrique de Moraes Holschuh 2007-03-02 13:47 ` Henrique de Moraes Holschuh 2007-03-02 13:57 ` Pavel Machek 2007-03-02 13:57 ` Pavel Machek 2007-03-03 6:44 ` Jean Delvare 2007-03-03 6:44 ` Jean Delvare 2007-03-02 11:40 ` Pavel Machek 2007-03-02 11:40 ` Pavel Machek 2007-03-02 11:47 ` Matthew Garrett 2007-03-02 11:47 ` Matthew Garrett 2007-03-02 13:58 ` Pavel Machek 2007-03-02 13:58 ` Pavel Machek 2007-03-02 21:00 ` Jean Delvare 2007-03-02 21:00 ` Jean Delvare 2007-03-02 21:22 ` Henrique de Moraes Holschuh 2007-03-02 21:22 ` Henrique de Moraes Holschuh 2007-04-01 15:39 ` Pavel Machek 2007-04-01 15:39 ` Pavel Machek 2007-04-02 15:48 ` Jean Delvare 2007-04-02 15:48 ` [lm-sensors] " Jean Delvare 2007-04-02 19:22 ` Dave Jones 2007-04-02 19:22 ` [lm-sensors] " Dave Jones 2007-04-03 5:49 ` Jean Delvare 2007-04-03 5:49 ` [lm-sensors] " Jean Delvare 2007-04-02 20:55 ` Moore, Robert 2007-04-02 20:55 ` [lm-sensors] " Moore, Robert 2007-04-02 20:55 ` Moore, Robert 2007-04-03 7:21 ` Jean Delvare 2007-04-03 7:21 ` [lm-sensors] " Jean Delvare 2007-04-03 7:21 ` Jean Delvare 2007-04-04 21:35 ` Moore, Robert 2007-04-04 21:35 ` [lm-sensors] " Moore, Robert 2007-04-04 21:35 ` Moore, Robert 2007-03-02 14:10 ` [lm-sensors] " Jean Delvare 2007-03-02 14:10 ` Jean Delvare 2007-03-02 14:18 ` Matthew Garrett 2007-03-02 14:18 ` Matthew Garrett 2007-03-02 21:04 ` Jean Delvare 2007-03-02 21:04 ` Jean Delvare 2007-03-02 21:12 ` Matthew Garrett 2007-03-02 21:12 ` Matthew Garrett 2007-03-03 9:53 ` Jean Delvare 2007-03-03 9:53 ` Jean Delvare 2007-03-03 15:47 ` David Hubbard 2007-03-03 15:47 ` David Hubbard 2007-03-03 15:50 ` Matthew Garrett 2007-03-03 15:50 ` Matthew Garrett 2007-03-03 17:08 ` Rudolf Marek 2007-03-03 17:08 ` Rudolf Marek 2007-03-04 17:29 ` Rudolf Marek 2007-03-04 17:29 ` Rudolf Marek 2007-03-05 21:16 ` Jean Delvare 2007-03-05 21:16 ` Jean Delvare 2007-03-05 21:35 ` David Hubbard 2007-03-05 21:35 ` David Hubbard 2007-03-06 15:10 ` Jean Delvare 2007-03-06 15:10 ` Jean Delvare 2007-03-04 10:54 ` Jean Delvare 2007-03-04 10:54 ` Jean Delvare 2007-03-05 22:25 ` Pavel Machek 2007-03-05 22:25 ` Pavel Machek 2007-03-06 7:55 ` Benny Amorsen 2007-03-06 7:55 ` Benny Amorsen 2007-03-06 15:26 ` Jean Delvare 2007-03-06 15:26 ` Jean Delvare 2007-03-06 20:07 ` Stefan Monnier 2007-03-06 20:07 ` Stefan Monnier 2007-03-06 20:07 ` Stefan Monnier 2007-03-06 21:20 ` Pavel Machek 2007-03-06 21:20 ` Pavel Machek 2007-03-06 21:25 ` Moore, Robert 2007-03-06 21:25 ` Moore, Robert 2007-03-06 21:25 ` Moore, Robert 2007-03-18 19:36 ` richardvoigt 2007-03-18 19:36 ` richardvoigt at gmail.com 2007-03-19 7:08 ` Jean Delvare 2007-03-19 7:08 ` Jean Delvare 2007-03-02 22:07 ` Moore, Robert 2007-03-02 22:07 ` Moore, Robert 2007-03-02 22:07 ` Moore, Robert 2007-03-09 7:18 ` Pavel Machek 2007-03-09 7:18 ` Pavel Machek 2007-03-09 10:24 ` Jean Delvare 2007-03-09 10:24 ` Jean Delvare 2007-03-09 10:39 ` Alexey Starikovskiy 2007-03-09 10:39 ` Alexey Starikovskiy 2007-03-09 11:21 ` Pavel Machek 2007-03-09 11:21 ` Pavel Machek 2007-03-09 17:23 ` Jean Delvare 2007-03-09 17:23 ` Jean Delvare 2007-03-09 17:35 ` Alexey Starikovskiy 2007-03-09 17:35 ` Alexey Starikovskiy 2007-03-09 21:03 ` Moore, Robert 2007-03-09 21:03 ` Moore, Robert 2007-03-09 21:03 ` Moore, Robert 2007-03-09 20:56 ` Moore, Robert 2007-03-09 20:56 ` Moore, Robert 2007-03-09 20:56 ` Moore, Robert 2007-03-02 14:22 ` Pavel Machek 2007-03-02 14:22 ` Pavel Machek 2007-03-02 14:03 ` Jean Delvare 2007-03-02 14:03 ` Jean Delvare 2007-03-02 14:24 ` Pavel Machek 2007-03-02 14:24 ` Pavel Machek 2007-03-02 14:57 ` Matthew Garrett 2007-03-02 14:57 ` Matthew Garrett 2007-03-02 21:41 ` Jean Delvare 2007-03-02 21:41 ` Jean Delvare 2007-03-02 21:46 ` Matthew Garrett 2007-03-02 21:46 ` Matthew Garrett 2007-03-06 21:28 ` Jean Delvare 2007-03-06 21:28 ` Jean Delvare 2007-04-13 18:18 ` Bjorn Helgaas 2007-04-13 18:18 ` Bjorn Helgaas 2007-04-13 20:07 ` Pavel Machek 2007-04-13 20:07 ` Pavel Machek 2007-04-13 20:59 ` Bjorn Helgaas 2007-04-13 20:59 ` Bjorn Helgaas 2007-04-15 9:41 ` Jean Delvare 2007-04-15 9:41 ` Jean Delvare 2007-04-15 20:31 ` Bjorn Helgaas 2007-04-15 20:31 ` Bjorn Helgaas 2007-04-15 20:59 ` Luca Tettamanti 2007-04-15 20:59 ` Luca Tettamanti 2007-04-16 0:57 ` Bjorn Helgaas 2007-04-16 0:57 ` Bjorn Helgaas 2007-04-16 21:14 ` Luca Tettamanti 2007-04-16 21:14 ` Luca Tettamanti 2007-04-16 22:28 ` Bjorn Helgaas 2007-04-16 22:28 ` Bjorn Helgaas 2007-04-17 23:50 ` Luca Tettamanti 2007-04-17 23:50 ` Luca Tettamanti 2007-04-22 16:55 ` Luca Tettamanti 2007-04-22 16:55 ` Luca Tettamanti 2007-04-17 10:03 ` Jean Delvare 2007-04-17 10:03 ` Jean Delvare 2007-02-18 22:43 ` Rudolf Marek 2007-02-18 22:43 ` Rudolf Marek 2007-02-20 15:08 ` Chuck Ebbert 2007-02-20 15:08 ` Chuck Ebbert 2007-02-20 19:11 ` Dave Jones 2007-02-20 19:11 ` Dave Jones 2007-02-21 16:17 ` Jean Delvare 2007-02-21 16:17 ` Jean Delvare 2007-02-21 17:37 ` Dave Jones 2007-02-21 17:37 ` Dave Jones 2007-02-21 20:19 ` Dave Jones 2007-02-21 20:19 ` Dave Jones 2007-02-22 16:37 ` Jean Delvare 2007-02-22 16:37 ` Jean Delvare 2007-02-23 7:13 ` Hans de Goede 2007-02-23 7:13 ` [lm-sensors] " Hans de Goede 2007-02-23 7:13 ` Hans de Goede 2007-02-23 7:47 ` Jean Delvare 2007-02-23 7:47 ` Jean Delvare 2007-02-21 14:54 ` Jean Delvare 2007-02-21 14:54 ` Jean Delvare 2007-02-21 16:03 ` Chuck Ebbert 2007-02-21 16:03 ` Chuck Ebbert 2007-02-21 16:22 ` Jean Delvare 2007-02-21 16:22 ` Jean Delvare 2007-02-23 8:08 ` Hans de Goede 2007-02-26 17:24 ` Jean Delvare 2007-02-26 19:03 ` Hans de Goede 2007-02-27 8:45 ` Jean Delvare
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.