http://bugzilla.kernel.org/show_bug.cgi?id=8842


[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acpi-
                   |                            |[EMAIL PROTECTED]
                   |                            |et
         AssignedTo|[EMAIL PROTECTED]  |[EMAIL PROTECTED]
                   |bugs.osdl.org               |
             Status|NEW                         |ASSIGNED
            Summary|performance regression,     |thermal throttling at 50C
                   |cause: trip_points file is  |impacts performance - AOpen
                   |read only since 2.6.22      |i915GMm-hfs, Pentium-M 750




------- Comment #6 from [EMAIL PROTECTED]  2007-08-06 20:22 -------
> ACPI: Unable to turn cooling device [c18dc9dc] 'on'
> bus-0201 [-411] bus_set_power: Device `[PNP0C0B:00]' is not power manageable

Knut,
Are you running with (latest) BIOS SETUP options all in default settings?
Are there any fan-related options such as quiet vs performance settings?

Please attach the complete output from dmesg -s64000
including the cooling device message above.
(the bus_set_power message is unrelated)

What do you see in /proc/acpi/fan/*/state before and after the
temperature crosses the 50C threshold -- is that when
the message above comes out, or does that occur upon boot?
Does the fan actually come on automatically when you reach 50,
or at another temperature?
If you echo 0 and 3 into the the fan state files(s) are you able
to have any effect on the fan state?

Curiously, the DSDT has an SFAN method with FON/FOFF
which are likely for controlling the fan, but these
methods are not referenced.

Looking over the DSDT, it does appear that this system intends
to support passive and active cooling modes.   However, both
the trip_points file and the dd above agree that the BIOS
is for some reason initializing both the active and passive
high-trip points to 50C.  Curiously, the DSDT records low
trip points that dd shows are 46C, but it doesn't seem to
implement hysteresis -- at least not in AML.
It would be interesting to observe at what temperature the
fan turns off at when the system cools.
It would be interesting if any system events at all had
any effect on the output of the dd above.

Please echo 1 and 0 into /proc/acpi/thermal_zone/*/cooling_mode
While the AML will not change the trip-points, it is possible
that something needs to trigger an SMI that would change
them and then updated trip-points would be picked up by AML
from the region you describe above. (and thus they'd be
visible in the trip_points file)

BTW. there is no danger of harming the flash soldered onto the board
by using dd to over-write the underlying trip-points above.
If that region is mapped to FLASH, then dd would simply fail.
If it works, then you'd be updating writable memory
(and the effect would go away after reboot/reset)
However, you'd have to notify AML of the update, such
as by executing an _SCP by writing to the cooling_mode file
as above.  Further, it is possible that SMM may overwrite
the value that you write...

The other question is where and what thermal events this
machine actually produces and what controls them.
Please kill acpid and cat /proc/acpi/event and see
what thermal events you get as the temperature changes.
(you can press the power button to make sure this scheme
 is working -- /proc/interrupts should show the acpi line
 increment for each press, and you should get a text line
 out of /proc/acpi/event)

When you boot with "acpi=off", does the system boot properly,
run full load at full speed, and enable the fan as needed?
Can you detect from the sound if the fan speed in this mode
is the about same as the fan speed in ACPI mode, or can
you perceive a speed difference?

Finally, please confirm that your kernel has CONFIG_HWMON=n

Andrey,
your issue (fan always on) is different (and less severe) than Knut's.
Please open a new bug report, please attach the output from acpidump.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla

Reply via email to