hi,
On Mon, Mar 9, 2009 at 4:18 AM, Zhang Rui <rui.zhang@xxxxxxxxx> wrote:
>
> > The fan also didn't seem to react to the processor temperature, suddenly
> > springing to full-power when it reached the 80C trip point (which wasn't
> > even reported in trip_points) and never switching off again.
> >
> > These problems manifested with 2.6.2{6,8,9-rc7}.
> so the problem exists in all the kernels you have tried, right?
Yes, exactly, but I have only tried the described "solution" with
2.6.29-rc{5,6,7}.
> > My questions are:
> > - am I right in assuming the EC could be playing behind ACPI's back and
> > controlling the fan speed by itself, only depending on ACPI to react
> > when issued the _Q11 event?
> I think so, EC needs a notification (ACPI interrupt) to change the fan
> speed when temperature changes.
Pardon my ignorance, but what's actually generating these interrupts?
If ACPI's not even aware of the right trip points, I'd assume it's
something not directly connected to it asking the ACPI code to fiddle
with bits in the EC, but then why doesn't the BIOS implement it
completely out of sight? And more importantly, without depending on
the OS implementation for it.
Is there a point I'm not seeing in this, or are the BIOS-maker's
decisions also unclear to you?
> > - should this problem be understood as a failure in the DSDT for not
> > explicitly initializing something; a failure in ACPI for not implicitly
> > initializing something or a failure in the hardware/BIOS for depending
> > on partially non-ACPI behavior to control fan speed?
> Not sure it's a hardware/software problem.
> I don't know what difference "Store(\_SB.PCI0.LPC.EC0.FNST, Debug)"
> brings us.
> Alexey, can you have a look at this problem please?
Thanks for the help!
Cheers
--
Leo Antunes
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
