Kernel fault from ACPI when using W83627EHG on 2.6.15

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux