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
