[lm-sensors] Kernel fault from ACPI when using W83627EHG on 2.6.15

[lm-sensors] Kernel fault from ACPI when using W83627EHG on 2.6.15

[Roger Lucas]

I have just been setting up a new system using the Abit LG81 motherboard.
This is a fairly recent mobo with the Intel ICH7 chipset and the w83627ehg
sensor chip (...no uGuru, thank goodness...)

I got everything installed OK using a Debian ISO image I downloaded from the
web which is based around what I believe to be the stock 2.6.15 kernel.

The w83627ehf module was not loaded by default, so I modprobe'd the
"w83627ehf" module and it went in without error.  I installed "lm-sensors"
from the Debian packages (v2.9.1). When I ran "sensors", I got back the
correct speeds for the 3 fans fitted and the system temperatures.
Everything matched the BIOS.  

When I ran "sensors -s", however, I immediately got a kernel dump.  I
haven't managed to get a proper capture of this, but the errors at the top
were:
	acpi_ps_parse_aml
	acpi_ps_execute_pass
	acpi_ps_execute_method
	acpi_ps_execute_control_method
	acpi_ps_evaluate_by_handle
	acpi_ps_evaluate_relative
	acpi_evaluate_object
	acpi_evalute_integer
	acpi_thermal_get_temperature 	
	acpi_thermal_check
	acpi_acquire_mutex
	...

When I checked the sensors configuration, I found that the high temperature
thresholds were just below what my board was reading (CPU is at about 50
degrees and the PWM at about 45 degrees - not too high, but above the
original thresholds).  When I changed them to much higher values so that
they wouldn't trigger (high• deg, hyst… deg), the kernel dumps stopped.

I did a bit of a search through the lm-sensors mailing list archives and
found the suggestion to boot with "acpi=off", so I tried it.

Booting with "acpi=off", if I have temperature thresholds that are lower
than the sensors temperatures, and run "sensors -s", I get no kernel faults
but I do get a high-low beeping from the motherboard!  When I change the
sensors.conf file to have higher temperature thresholds so that the alarms
don't trigger, then the beeping from the motherboard stops (and still no
kernel fault).

Although booting with "acpi=off" is a workaround, I would _really_ like to
have ACPI running as it means that the power button on the front of the box
does a controlled shutdown (rather than a hard power-off) if pressed briefly
as well as a few other nice features.

I appreciate that this looks like an ACPI problem, but it seems to be
triggered by the over-temperature from the w83627ehf module, so I thought
that it would be best to check this out first.  Googling for the problem
seems to suggest some kind of device conflict may be occurring, but this was
on a kernel mailing list thread dating back to the 2.6.8.1 kernel in 2004.

Can anyone offer any help on this...
 - Has anyone seen anything similar?
 - Does anyone have a solution that allows me to keep ACPI active?

All help on this is appreciated.

Thanks,

Roger

[lm-sensors] Kernel fault from ACPI when using W83627EHG on

[David Hubbard]

Hi Roger,

I'm new at working on the w83627ehf/s83627ehg chips, but here's by 2c:

On 4/20/06, Roger Lucas <roger at planbit.co.uk> wrote:
> When I ran "sensors -s", however, I immediately got a kernel dump.  I
> haven't managed to get a proper capture of this, but the errors at the top
> were:
>        acpi_ps_parse_aml
>        acpi_ps_execute_pass
>        acpi_ps_execute_method
>        acpi_ps_execute_control_method
>        acpi_ps_evaluate_by_handle
>        acpi_ps_evaluate_relative
>        acpi_evaluate_object
>        acpi_evalute_integer
>        acpi_thermal_get_temperature
>        acpi_thermal_check
>        acpi_acquire_mutex
>        ...
>
> When I checked the sensors configuration, I found that the high temperature
> thresholds were just below what my board was reading (CPU is at about 50
> degrees and the PWM at about 45 degrees - not too high, but above the
> original thresholds).  When I changed them to much higher values so that
> they wouldn't trigger (high• deg, hyst… deg), the kernel dumps stopped.
>
> I did a bit of a search through the lm-sensors mailing list archives and
> found the suggestion to boot with "acpi=off", so I tried it.
>
> Booting with "acpi=off", if I have temperature thresholds that are lower
> than the sensors temperatures, and run "sensors -s", I get no kernel faults
> but I do get a high-low beeping from the motherboard!  When I change the
> sensors.conf file to have higher temperature thresholds so that the alarms
> don't trigger, then the beeping from the motherboard stops (and still no
> kernel fault).
>
> Although booting with "acpi=off" is a workaround, I would _really_ like to
> have ACPI running as it means that the power button on the front of the box
> does a controlled shutdown (rather than a hard power-off) if pressed briefly
> as well as a few other nice features.
>
> I appreciate that this looks like an ACPI problem, but it seems to be
> triggered by the over-temperature from the w83627ehf module, so I thought
> that it would be best to check this out first.  Googling for the problem
> seems to suggest some kind of device conflict may be occurring, but this was
> on a kernel mailing list thread dating back to the 2.6.8.1 kernel in 2004.
>
> Can anyone offer any help on this...
>  - Has anyone seen anything similar?

I have not seen this behavior, even though my motherboard (Asus
A8N-VM/CSM) also has a w83627ehf.

>  - Does anyone have a solution that allows me to keep ACPI active?

I think I understand what is going on. There are several pins
described in the w83627ehf datasheet which could be triggering
something on your motherboard. Pin 5 (OVT# / HM_SMI#) and pin 118
(Beep) can be configured to respond to any of the hardware monitoring
alarms, such as the fan speed and the CPU temperature. The biggest
clue that leads me to think this is "but I do get a high-low beeping
from the motherboard." However, there's also an ACPI interface on the
chip which apparently can power up the system from the power switch,
so the problem could be lurking there.

I propose attempting something like the following:
1. to work around the ACPI behavior, the OVT# Register (0x18) and
Configuration Register (0x40) can be modified to disable OVT# and
HM_SMI# outputs. (Set bit 6 to 1 in register 0x18, set bit 1 to 0 in
register 0x40) If this is what the motherboard is responding to, the
ACPI crash will disappear.

2. since your motherboard responds to the ACPI event generated by a
hardware fault and an over-temperature interrupt (mine does not), this
feature could be included in a future version of the ACPI driver. I
suppose that request needs to go to the ACPI driver mailing list.

David

[lm-sensors] Kernel fault from ACPI when using W83627EHG on

[Roger Lucas]

Hi David,

Thanks for the reply.  I'll modify the w83627ehf driver to change the
register writes and post the results back to the list.

BR,

Roger

> -----Original Message-----
> From: David Hubbard [mailto:david.c.hubbard at gmail.com]
> Sent: 21 April 2006 21:00
> To: Roger Lucas; lm-sensors at lm-sensors.org
> Subject: Re: [lm-sensors] Kernel fault from ACPI when using W83627EHG on
> 2.6.15
> 
> Hi Roger,
> 
> I'm new at working on the w83627ehf/s83627ehg chips, but here's by 2c:
> 
> On 4/20/06, Roger Lucas <roger at planbit.co.uk> wrote:
> > When I ran "sensors -s", however, I immediately got a kernel dump.  I
> > haven't managed to get a proper capture of this, but the errors at the
> top
> > were:
> >        acpi_ps_parse_aml
> >        acpi_ps_execute_pass
> >        acpi_ps_execute_method
> >        acpi_ps_execute_control_method
> >        acpi_ps_evaluate_by_handle
> >        acpi_ps_evaluate_relative
> >        acpi_evaluate_object
> >        acpi_evalute_integer
> >        acpi_thermal_get_temperature
> >        acpi_thermal_check
> >        acpi_acquire_mutex
> >        ...
> >
> > When I checked the sensors configuration, I found that the high
> temperature
> > thresholds were just below what my board was reading (CPU is at about 50
> > degrees and the PWM at about 45 degrees - not too high, but above the
> > original thresholds).  When I changed them to much higher values so that
> > they wouldn't trigger (high• deg, hyst… deg), the kernel dumps
> stopped.
> >
> > I did a bit of a search through the lm-sensors mailing list archives and
> > found the suggestion to boot with "acpi=off", so I tried it.
> >
> > Booting with "acpi=off", if I have temperature thresholds that are lower
> > than the sensors temperatures, and run "sensors -s", I get no kernel
> faults
> > but I do get a high-low beeping from the motherboard!  When I change the
> > sensors.conf file to have higher temperature thresholds so that the
> alarms
> > don't trigger, then the beeping from the motherboard stops (and still no
> > kernel fault).
> >
> > Although booting with "acpi=off" is a workaround, I would _really_ like
> to
> > have ACPI running as it means that the power button on the front of the
> box
> > does a controlled shutdown (rather than a hard power-off) if pressed
> briefly
> > as well as a few other nice features.
> >
> > I appreciate that this looks like an ACPI problem, but it seems to be
> > triggered by the over-temperature from the w83627ehf module, so I
> thought
> > that it would be best to check this out first.  Googling for the problem
> > seems to suggest some kind of device conflict may be occurring, but this
> was
> > on a kernel mailing list thread dating back to the 2.6.8.1 kernel in
> 2004.
> >
> > Can anyone offer any help on this...
> >  - Has anyone seen anything similar?
> 
> I have not seen this behavior, even though my motherboard (Asus
> A8N-VM/CSM) also has a w83627ehf.
> 
> >  - Does anyone have a solution that allows me to keep ACPI active?
> 
> I think I understand what is going on. There are several pins
> described in the w83627ehf datasheet which could be triggering
> something on your motherboard. Pin 5 (OVT# / HM_SMI#) and pin 118
> (Beep) can be configured to respond to any of the hardware monitoring
> alarms, such as the fan speed and the CPU temperature. The biggest
> clue that leads me to think this is "but I do get a high-low beeping
> from the motherboard." However, there's also an ACPI interface on the
> chip which apparently can power up the system from the power switch,
> so the problem could be lurking there.
> 
> I propose attempting something like the following:
> 1. to work around the ACPI behavior, the OVT# Register (0x18) and
> Configuration Register (0x40) can be modified to disable OVT# and
> HM_SMI# outputs. (Set bit 6 to 1 in register 0x18, set bit 1 to 0 in
> register 0x40) If this is what the motherboard is responding to, the
> ACPI crash will disappear.
> 
> 2. since your motherboard responds to the ACPI event generated by a
> hardware fault and an over-temperature interrupt (mine does not), this
> feature could be included in a future version of the ACPI driver. I
> suppose that request needs to go to the ACPI driver mailing list.
> 
> David

[lm-sensors] Kernel fault from ACPI when using W83627EHG

[Roger Lucas]

Well, I think I made the correct changes.  

	CONFIG (addr 0x40) = 0x01
	OVT (addr 0x18) = 0x43

... but it doesn't change the behaviour.

I've posted a similar message to the ACPI mailing list to see if they can
shed any light on it...

Thanks anyhow, it was definitely worth trying.

- Roger

> -----Original Message-----
> From: lm-sensors-bounces at lm-sensors.org [mailto:lm-sensors-bounces at lm-
> sensors.org] On Behalf Of Roger Lucas
> Sent: 21 April 2006 22:52
> To: 'David Hubbard'
> Cc: lm-sensors at lm-sensors.org
> Subject: Re: [lm-sensors] Kernel fault from ACPI when using W83627EHG
> on2.6.15
> 
> Hi David,
> 
> Thanks for the reply.  I'll modify the w83627ehf driver to change the
> register writes and post the results back to the list.
> 
> BR,
> 
> Roger
> 
> > -----Original Message-----
> > From: David Hubbard [mailto:david.c.hubbard at gmail.com]
> > Sent: 21 April 2006 21:00
> > To: Roger Lucas; lm-sensors at lm-sensors.org
> > Subject: Re: [lm-sensors] Kernel fault from ACPI when using W83627EHG on
> > 2.6.15
> >
> > Hi Roger,
> >
> > I'm new at working on the w83627ehf/s83627ehg chips, but here's by 2c:
> >
> > On 4/20/06, Roger Lucas <roger at planbit.co.uk> wrote:
> > > When I ran "sensors -s", however, I immediately got a kernel dump.  I
> > > haven't managed to get a proper capture of this, but the errors at the
> > top
> > > were:
> > >        acpi_ps_parse_aml
> > >        acpi_ps_execute_pass
> > >        acpi_ps_execute_method
> > >        acpi_ps_execute_control_method
> > >        acpi_ps_evaluate_by_handle
> > >        acpi_ps_evaluate_relative
> > >        acpi_evaluate_object
> > >        acpi_evalute_integer
> > >        acpi_thermal_get_temperature
> > >        acpi_thermal_check
> > >        acpi_acquire_mutex
> > >        ...
> > >
> > > When I checked the sensors configuration, I found that the high
> > temperature
> > > thresholds were just below what my board was reading (CPU is at about
> 50
> > > degrees and the PWM at about 45 degrees - not too high, but above the
> > > original thresholds).  When I changed them to much higher values so
> that
> > > they wouldn't trigger (high• deg, hyst… deg), the kernel dumps
> > stopped.
> > >
> > > I did a bit of a search through the lm-sensors mailing list archives
> and
> > > found the suggestion to boot with "acpi=off", so I tried it.
> > >
> > > Booting with "acpi=off", if I have temperature thresholds that are
> lower
> > > than the sensors temperatures, and run "sensors -s", I get no kernel
> > faults
> > > but I do get a high-low beeping from the motherboard!  When I change
> the
> > > sensors.conf file to have higher temperature thresholds so that the
> > alarms
> > > don't trigger, then the beeping from the motherboard stops (and still
> no
> > > kernel fault).
> > >
> > > Although booting with "acpi=off" is a workaround, I would _really_
> like
> > to
> > > have ACPI running as it means that the power button on the front of
> the
> > box
> > > does a controlled shutdown (rather than a hard power-off) if pressed
> > briefly
> > > as well as a few other nice features.
> > >
> > > I appreciate that this looks like an ACPI problem, but it seems to be
> > > triggered by the over-temperature from the w83627ehf module, so I
> > thought
> > > that it would be best to check this out first.  Googling for the
> problem
> > > seems to suggest some kind of device conflict may be occurring, but
> this
> > was
> > > on a kernel mailing list thread dating back to the 2.6.8.1 kernel in
> > 2004.
> > >
> > > Can anyone offer any help on this...
> > >  - Has anyone seen anything similar?
> >
> > I have not seen this behavior, even though my motherboard (Asus
> > A8N-VM/CSM) also has a w83627ehf.
> >
> > >  - Does anyone have a solution that allows me to keep ACPI active?
> >
> > I think I understand what is going on. There are several pins
> > described in the w83627ehf datasheet which could be triggering
> > something on your motherboard. Pin 5 (OVT# / HM_SMI#) and pin 118
> > (Beep) can be configured to respond to any of the hardware monitoring
> > alarms, such as the fan speed and the CPU temperature. The biggest
> > clue that leads me to think this is "but I do get a high-low beeping
> > from the motherboard." However, there's also an ACPI interface on the
> > chip which apparently can power up the system from the power switch,
> > so the problem could be lurking there.
> >
> > I propose attempting something like the following:
> > 1. to work around the ACPI behavior, the OVT# Register (0x18) and
> > Configuration Register (0x40) can be modified to disable OVT# and
> > HM_SMI# outputs. (Set bit 6 to 1 in register 0x18, set bit 1 to 0 in
> > register 0x40) If this is what the motherboard is responding to, the
> > ACPI crash will disappear.
> >
> > 2. since your motherboard responds to the ACPI event generated by a
> > hardware fault and an over-temperature interrupt (mine does not), this
> > feature could be included in a future version of the ACPI driver. I
> > suppose that request needs to go to the ACPI driver mailing list.
> >
> > David
> 
> 
> _______________________________________________
> lm-sensors mailing list
> lm-sensors at lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[lm-sensors] Kernel fault from ACPI when using W83627EHG

[David Hubbard]

Hi Roger,

I take that back. You've got the registers set right. Well, there are
other places where the bits can be disabled, but I wonder if the DSDT
of your ACPI polls the alarms on the w83627ehf to monitor it. It
wouldn't surprise me.

David

On 4/23/06, David Hubbard <david.c.hubbard at gmail.com> wrote:
> Hi Roger,
>
> On 4/23/06, Roger Lucas <roger at planbit.co.uk> wrote:
> > Well, I think I made the correct changes.
> >
> >         CONFIG (addr 0x40) = 0x01
> >         OVT (addr 0x18) = 0x43
>
> I think you need to set CONFIG to 0x00.
>
> >
> > ... but it doesn't change the behaviour.
> >
> > I've posted a similar message to the ACPI mailing list to see if they can
> > shed any light on it...
> >
> > Thanks anyhow, it was definitely worth trying.
> >
> > - Roger
>
> There are other bits worth trying too, but maybe you just want to grab
> the datasheet and look around?
>
> Anyway, good luck!
> David
>

[lm-sensors] Kernel fault from ACPI when using W83627EHG on

[Jean Delvare]

Hi Roger,

When starting a new thread, please do NOT use the "reply" function of
your e-mail client on a random post. This confuses users of threading
e-mail clients a lot.

> Although booting with "acpi=off" is a workaround, I would _really_ like to
> have ACPI running as it means that the power button on the front of the box
> does a controlled shutdown (rather than a hard power-off) if pressed briefly
> as well as a few other nice features.

The various ACPI features can be built modular. You could try this, and
only load the parts you need (e.g. ac, button) and not the ones which
are probably responsible for the crash (e.g. thermal). This might help
you survive for now, and isolate the problem within acpi.

And this definitely needs to be reported to the acpi people (bugzilla?)

-- 
Jean Delvare

[lm-sensors] Kernel fault from ACPI when using W83627EHG on

[Roger Lucas]

Hi Jean,

> -----Original Message-----
> From: Jean Delvare [mailto:khali at linux-fr.org]
> Sent: 23 April 2006 19:40
> To: Roger Lucas
> Cc: LM Sensors
> Subject: Re: [lm-sensors] Kernel fault from ACPI when using W83627EHG on
> 2.6.15
> 
> Hi Roger,
> 
> When starting a new thread, please do NOT use the "reply" function of
> your e-mail client on a random post. This confuses users of threading
> e-mail clients a lot.

I thought that I had started the thread with a new subject line.  Is there
something else that I am missing that happens behind-the-scenes?

> 
> > Although booting with "acpi=off" is a workaround, I would _really_ like
> to
> > have ACPI running as it means that the power button on the front of the
> box
> > does a controlled shutdown (rather than a hard power-off) if pressed
> briefly
> > as well as a few other nice features.
> 
> The various ACPI features can be built modular. You could try this, and
> only load the parts you need (e.g. ac, button) and not the ones which
> are probably responsible for the crash (e.g. thermal). This might help
> you survive for now, and isolate the problem within acpi.
> 
> And this definitely needs to be reported to the acpi people (bugzilla?)

I've raised the problem on the mailing list: 
http://permalink.gmane.org/gmane.linux.acpi.devel/17523

I still want to know what is really going on though.  This ACPI area is not
one I am familiar with, and although I have tried reading the documentation,
much of it is old and much more seems to indicate that a lot is
manufacturer-specific.

I have a few work-arounds for this problem, but I'm not comfortable using
them until I know what is actually going on.  Disabling ACPI completely
resolves the problem (but I lose ACPI).  Removing the "thermal" module in
ACPI stops the kernel dump, but the machine still runs very slowly until the
over-temperature situation clears.  This may be correct behaviour (e.g. the
processor is run at a much lower clock speed to help cool it down) but I
don't know for sure.   If I just set a very high cpu temperature limit (e.g.
95C) then this also "fixes" the problem, but it is really just a hack rather
than a real solution.

Hopefully, the guys on the ACPI mailing list can help.  This doesn't seem to
be a problem with lm-sensors (as far as I can see).

> 
> --
> Jean Delvare

[lm-sensors] Kernel fault from ACPI when using W83627EHG on

[Jean Delvare]

Hi Roger,

> > When starting a new thread, please do NOT use the "reply" function of
> > your e-mail client on a random post. This confuses users of threading
> > e-mail clients a lot.
> 
> I thought that I had started the thread with a new subject line.  Is there
> something else that I am missing that happens behind-the-scenes?

No, changing the subject line doesn't make a new discussion thread. As
long as you use "reply", your post will include an "In-Reply-To:"
header with a reference to the post you are supposedly replying to, and
most "threading" clients will rely on this information rather than the
subject line. You really need to use "new" or "compose" to start a new
thread.

> I've raised the problem on the mailing list: 
> http://permalink.gmane.org/gmane.linux.acpi.devel/17523
> 
> I still want to know what is really going on though.  This ACPI area is not
> one I am familiar with, and although I have tried reading the documentation,
> much of it is old and much more seems to indicate that a lot is
> manufacturer-specific.
> 
> I have a few work-arounds for this problem, but I'm not comfortable using
> them until I know what is actually going on.  Disabling ACPI completely
> resolves the problem (but I lose ACPI).  Removing the "thermal" module in
> ACPI stops the kernel dump, but the machine still runs very slowly until the
> over-temperature situation clears.  This may be correct behaviour (e.g. the
> processor is run at a much lower clock speed to help cool it down) but I
> don't know for sure.   If I just set a very high cpu temperature limit (e.g.
> 95C) then this also "fixes" the problem, but it is really just a hack rather
> than a real solution.
> 
> Hopefully, the guys on the ACPI mailing list can help.  This doesn't seem to
> be a problem with lm-sensors (as far as I can see).

Yup, I agree with all you said above.

-- 
Jean Delvare

[lm-sensors] Kernel fault from ACPI when using W83627EHG on

[Roger Lucas]

Resolved.

It appears to be a BIOS bug.  The mobo had BIOS version 1.0 installed, and I
updated it to v1.4.  I cannot now repeat the problem, and all runs smoothly.

Should have checked that first really, I guess...

> -----Original Message-----
> From: Jean Delvare [mailto:khali at linux-fr.org]
> Sent: 24 April 2006 07:35
> To: Roger Lucas
> Cc: LM Sensors
> Subject: Re: [lm-sensors] Kernel fault from ACPI when using W83627EHG on
> 2.6.15
> 
> Hi Roger,
> 
> > > When starting a new thread, please do NOT use the "reply" function of
> > > your e-mail client on a random post. This confuses users of threading
> > > e-mail clients a lot.
> >
> > I thought that I had started the thread with a new subject line.  Is
> there
> > something else that I am missing that happens behind-the-scenes?
> 
> No, changing the subject line doesn't make a new discussion thread. As
> long as you use "reply", your post will include an "In-Reply-To:"
> header with a reference to the post you are supposedly replying to, and
> most "threading" clients will rely on this information rather than the
> subject line. You really need to use "new" or "compose" to start a new
> thread.
> 
> > I've raised the problem on the mailing list:
> > http://permalink.gmane.org/gmane.linux.acpi.devel/17523
> >
> > I still want to know what is really going on though.  This ACPI area is
> not
> > one I am familiar with, and although I have tried reading the
> documentation,
> > much of it is old and much more seems to indicate that a lot is
> > manufacturer-specific.
> >
> > I have a few work-arounds for this problem, but I'm not comfortable
> using
> > them until I know what is actually going on.  Disabling ACPI completely
> > resolves the problem (but I lose ACPI).  Removing the "thermal" module
> in
> > ACPI stops the kernel dump, but the machine still runs very slowly until
> the
> > over-temperature situation clears.  This may be correct behaviour (e.g.
> the
> > processor is run at a much lower clock speed to help cool it down) but I
> > don't know for sure.   If I just set a very high cpu temperature limit
> (e.g.
> > 95C) then this also "fixes" the problem, but it is really just a hack
> rather
> > than a real solution.
> >
> > Hopefully, the guys on the ACPI mailing list can help.  This doesn't
> seem to
> > be a problem with lm-sensors (as far as I can see).
> 
> Yup, I agree with all you said above.
> 
> --
> Jean Delvare