Re: [lm-sensors] #2361: i2c and lm_sensors do not work on Slackware 12.1 with kernel 2.6.27.6

Re: [lm-sensors] #2361: i2c and lm_sensors do not work on Slackware 12.1 with kernel 2.6.27.6

[Robert Delahunt]

How is it fixed?  ACPI and sensors should be able to live together.  If I 
can't have one without the other, in my opinion, this is a blind spot for 
both projects.  Has anyone brought this up to the kernel ACPI developers to 
see if they can "unhide" or "expose" the hardware monitoring?

As for this laptop, thermal regulating is actually controlled in the hardware: 
neither ACPI nor sensors/i2c is needed to regulate temperature in the OS 
level.  I just find it odd that i2c/lm_sensors claims to support this chipset 
yet the answer I get is that the kernel ACPI "hides" them.

I'll bring this up to the kernel ACPI developers, but I would like to see this 
issue resolved.  Again, I am willing to test out whatever code necessary to 
help this process.

On Tuesday 18 November 2008 06:20:48 pm lm-sensors wrote:
> #2361: i2c and lm_sensors do not work on Slackware 12.1 with kernel
> 2.6.27.6
> ----------------------+----------------------------------------------------
>- Reporter:  ticket   |       Owner:  somebody
>       Type:  defect   |      Status:  closed
>   Priority:  major    |   Milestone:
>  Component:  sensors  |     Version:  3.0.3
> Resolution:  fixed    |    Keywords:
> ----------------------+----------------------------------------------------
>- Changes (by khali):
>
>  * cc: twinreverb@puresimplicity.net. (added)
>   * status:  new => closed
>   * resolution:  => fixed
>   * milestone:  3.0.4 =>
>
> Comment:
>
>  I don't see anything wrong here. Most laptops do not have (exposed)
>  hardware monitoring chips. Thermal regulation is handled by ACPI.



-- 
Very respectfully,
Robert Delahunt
-------------------------------------------------------------------
Ezekiel 11:19 New King James Version
Then I will give them one heart, and I will put a new spirit within
them, and take the stony heart out of their flesh, and give them a
heart of flesh....

Re: [lm-sensors] #2361: i2c and lm_sensors do not work on Slackware 12.1 with kernel 2.6.27.6

[Matthew Garrett]

On Tue, Nov 18, 2008 at 08:17:42PM +0900, Robert Delahunt wrote:
> How is it fixed?  ACPI and sensors should be able to live together.  If I 
> can't have one without the other, in my opinion, this is a blind spot for 
> both projects.  Has anyone brought this up to the kernel ACPI developers to 
> see if they can "unhide" or "expose" the hardware monitoring?

Hitting thermal regulation hardware directly can cause problems if 
you're also using ACPI, since there's no way of implementing locking 
between the firmware and the operating system in this case. Since most 
thermal monitoring hardware is accessed using indexed registers, having 
two pieces of code trying to access the hardware simultaneously will 
give bogus values and potentially result in hardware damage. Many 
laptops therefore hide the smbus from the operating system. While it's 
possible to unhide them, it's not a good idea.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

Re: #2361: i2c and lm_sensors do not work on Slackware 12.1 with kernel 2.6.27.6

[Jean Delvare]

Hi Robert,

On Tue, 18 Nov 2008 20:17:42 +0900, Robert Delahunt wrote:
> How is it fixed?  ACPI and sensors should be able to live together.

Playing the devil's advocate for a minute: why? ACPI and lm-sensors are
ways to achieve something, and at some level they are different ways to
achieve the same thing. Having both working together is not a goal per
se. The two real goals are: 1* let the user obtain information about
his/her hardware (temperature in particular) and 2* make sure we do not
crash the system. The former may be obtained without getting ACPI and
lm-sensors to work at the same time, and for the latter, ACPI and
lm-sensors generally must NOT be used at the same time.

Now, in practice ACPI is often getting way less out of the hardware than
lm-sensors would do and I definitely agree that this is frustrating.
But as responsible developers we have to first guarantee that the
user's system is safe, before looking at how to expose more features.

> (...) If I 
> can't have one without the other, in my opinion, this is a blind spot for 
> both projects.  Has anyone brought this up to the kernel ACPI developers to 
> see if they can "unhide" or "expose" the hardware monitoring?
> 
> As for this laptop, thermal regulating is actually controlled in the hardware: 
> neither ACPI nor sensors/i2c is needed to regulate temperature in the OS 
> level.  I just find it odd that i2c/lm_sensors claims to support this chipset 
> yet the answer I get is that the kernel ACPI "hides" them.

I'm not sure which chipset exactly you refer to? The Intel 82801DB is a
south bridge that doesn't include sensors. It includes an SMBus
controller, behind which hardware monitoring chips can live, but it is
disabled on your system. In most cases, this is an indication that ACPI
wants the SMBus for itself so we better don't access it. We would need
to look at the acpidump of this system to make sure.

Anyway, even if your laptop had a hardware monitoring chips which is
listed as supported by lm-sensors, but ACPI is using it, then you
shouldn't be using the "native" driver for it. Just because we claim to
support some device doesn't mean that loading the driver is the right
thing to do on all systems (I really would like it to be the case, it
would be much easier for everyone, but in the real world it isn't.)

> I'll bring this up to the kernel ACPI developers, but I would like to see this 
> issue resolved.  Again, I am willing to test out whatever code necessary to 
> help this process.

Wait for APCI v4 maybe? Fundamentally this is a design flaw of ACPI to
grab resources which the OS would also need without providing a way to
synchronize access.

-- 
Jean Delvare

Re: #2361: i2c and lm_sensors do not work on Slackware 12.1 with kernel 2.6.27.6

[Jean Delvare]

Robert,

Please, pretty please, keep the lists Cc'd.

On Wed, 19 Nov 2008 04:43:39 +0900, Robert Delahunt wrote:
> Sir,
> 
> 	ACPI and lm_sensors are not the same concept or system.  ACPI is meant to 
> control power consumption.

Not really. ACPI is meant for so many things that it is difficult to
give a complete list. That's probably a key problem of ACPI: trying to
do too many things, it fails to do most things properly (or, in some
cases, BIOS authors fail to implement things properly.)

> lm_sensors is meant to simply show information.

Who decided this? The lm-sensors project goes well beyond just showing
information.

> These seem to get blurred in concept, however, at the Linux kernel.  If 
> anything, ACPI and lm_sensors should be working together (which they are).

No, they are (unfortunately) not. If they were, you wouldn't have
reported a bug, would you?

> However, their goals are not the same.  ACPI shouldn't be telling me 
> temperatures: that's the job of lm_sensors.  However, lm_sensors shouldn't be 
> setting fans and such: that's ACPI's job.

That's your (totally incorrect IMHO) view of the situation. The ACPI
people's view is that ACPI should be taking care of everything where
available and lm-sensors shouldn't be used. My own view is that ACPI
should either not touch hardware monitoring chips at all, or it should
drive them completely in a standard way. The current approach (each
BIOS author implements things his/her own often broken way and the OS
and user don't have their say) sucks.

So as you can see there are many ways to look at the problem. On top of
that, one technical issue is that "showing temperatures" and
"controlling fans" are in practice done by the same piece of hardware,
so claiming that lm-sensors should do one and ACPI the other is highly
impractical: if both access the hardware at the same time, havoc ensues.

> 	Much less on this chipset combination (see my lspci.txt) the system hardware 
> automatically schedules fans and such.

How do you know for sure? If I had to place a bet, I'd say that this is
in fact handled by your BIOS using SMM code. If I am right, then this
is one more reason to keep lm-sensors away from your hardware
monitoring chip.

>  You'd think that this means I don't 
> need ACPI, but instead lm_sensors.  However, to boot with acpi=off on this 
> machine results in your CD drive not being registered at all, regardless of 
> what the user does to try and manually tell the kernel that it exists.

See my rant above: the problem is that ACPI is doing way too many
unrelated things. This makes the acpi=off option pretty much useless.
You'd need an acpi=notherm option or some such, which unfortunately
doesn't exist. (Note that this wouldn't be enough if my assumption
about SMM is correct anyway.)

> 	I already spoke with khali and he and an ACPI developer on the linux kernel 
> team are working this issue.  I don't blame you guys: I blame ACPI.  However, 
> for now, we're stuck with it.  So at this point it becomes more of an 
> attitude check.  Do the developers try to fix something that they maintain, 
> or do they blame ACPI and move on?

Me, I blame ACPI (and SMM even more, and BIOS designers even more) and
move on. There's almost nothing that can be done, easy as that. The
best we can do is prevent lm-sensors from being used on systems where
it would break, and that's something we are (slowly) working on. Trying
to get lm-sensors and ACPI to cooperate beyond that has so little
chance of success that my time is much better spent on other tasks.

-- 
Jean Delvare

Re: [lm-sensors] #2361: i2c and lm_sensors do not work on Slackware

[Jean Delvare]

Robert,

Please, pretty please, keep the lists Cc'd.

On Wed, 19 Nov 2008 04:43:39 +0900, Robert Delahunt wrote:
> Sir,
> 
> 	ACPI and lm_sensors are not the same concept or system.  ACPI is meant to 
> control power consumption.

Not really. ACPI is meant for so many things that it is difficult to
give a complete list. That's probably a key problem of ACPI: trying to
do too many things, it fails to do most things properly (or, in some
cases, BIOS authors fail to implement things properly.)

> lm_sensors is meant to simply show information.

Who decided this? The lm-sensors project goes well beyond just showing
information.

> These seem to get blurred in concept, however, at the Linux kernel.  If 
> anything, ACPI and lm_sensors should be working together (which they are).

No, they are (unfortunately) not. If they were, you wouldn't have
reported a bug, would you?

> However, their goals are not the same.  ACPI shouldn't be telling me 
> temperatures: that's the job of lm_sensors.  However, lm_sensors shouldn't be 
> setting fans and such: that's ACPI's job.

That's your (totally incorrect IMHO) view of the situation. The ACPI
people's view is that ACPI should be taking care of everything where
available and lm-sensors shouldn't be used. My own view is that ACPI
should either not touch hardware monitoring chips at all, or it should
drive them completely in a standard way. The current approach (each
BIOS author implements things his/her own often broken way and the OS
and user don't have their say) sucks.

So as you can see there are many ways to look at the problem. On top of
that, one technical issue is that "showing temperatures" and
"controlling fans" are in practice done by the same piece of hardware,
so claiming that lm-sensors should do one and ACPI the other is highly
impractical: if both access the hardware at the same time, havoc ensues.

> 	Much less on this chipset combination (see my lspci.txt) the system hardware 
> automatically schedules fans and such.

How do you know for sure? If I had to place a bet, I'd say that this is
in fact handled by your BIOS using SMM code. If I am right, then this
is one more reason to keep lm-sensors away from your hardware
monitoring chip.

>  You'd think that this means I don't 
> need ACPI, but instead lm_sensors.  However, to boot with acpi=off on this 
> machine results in your CD drive not being registered at all, regardless of 
> what the user does to try and manually tell the kernel that it exists.

See my rant above: the problem is that ACPI is doing way too many
unrelated things. This makes the acpi=off option pretty much useless.
You'd need an acpi=notherm option or some such, which unfortunately
doesn't exist. (Note that this wouldn't be enough if my assumption
about SMM is correct anyway.)

> 	I already spoke with khali and he and an ACPI developer on the linux kernel 
> team are working this issue.  I don't blame you guys: I blame ACPI.  However, 
> for now, we're stuck with it.  So at this point it becomes more of an 
> attitude check.  Do the developers try to fix something that they maintain, 
> or do they blame ACPI and move on?

Me, I blame ACPI (and SMM even more, and BIOS designers even more) and
move on. There's almost nothing that can be done, easy as that. The
best we can do is prevent lm-sensors from being used on systems where
it would break, and that's something we are (slowly) working on. Trying
to get lm-sensors and ACPI to cooperate beyond that has so little
chance of success that my time is much better spent on other tasks.

-- 
Jean Delvare

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