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: 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=95 deg, hyst=85 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