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

Bodo Eggert 7eggert at gmx.de
Wed Mar 7 18:09:09 CET 2007

On Wed, 7 Mar 2007, Jean Delvare wrote:
> On Tue, 6 Mar 2007 21:40:19 +0100 (CET), Bodo Eggert wrote:

> > 1) I asume port allocations or ACPI foreign port acces to be rare, so
> >    there would be little impact on (un)registering hardware. Off cause
> >    there are some long ACPI calls (like reading the battery?), in these
> >    cases it might be beneficial to release the global allocation lock
> >    after gaining exclusive access to the driver's port range. (This can
> >    only be done if the device driver is loaded.)
> The problem is that the rarity of ACPI foreign port access doesn't
> matter much, as you have to do all the tests first to find out that it
> was a foreign port, and I suspect that these tests will cost more than
> taking the lock itself.

Testing for the internal ranges can be done by searching a list of about
five ranges, that should be not much slower than taking an uncontended
lock, and very much faster than waiting for smbus to finish it's current
task in case the lock is contended. I'm more concerned about driver
(un)loading being slowed down by ACPI.

> We may be able to workaround the inter-driver exclusion though, if we
> use a semaphore initialized to N, have ACPI take N, but other drivers
> take just one. This would let ACPI be exclusive with all the other
> drivers, but drivers themselves could otherwise run concurrently. That
> being said, we do not appear to have the required primitives to take
> more than 1 semaphore resource at once at the moment, so we'd need to
> do that first.

worst case I can imagine: IDE/graphic stalles while ACPI takes a second to
read the battery state.

Top 100 things you don't want the sysadmin to say:
82. Where's the DIR command?

More information about the lm-sensors mailing list