All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Lindroth <thomas.lindroth@gmail.com>
To: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org
Subject: Re: Problem: ACPI related soft lockup on Fujitsu-Siemens AMILO Si 2636
Date: Thu, 09 Oct 2008 09:46:40 +0200	[thread overview]
Message-ID: <48EDB6E0.8000609@gmail.com> (raw)
In-Reply-To: <alpine.LFD.1.10.0810082144370.3041@localhost.localdomain>

Len Brown wrote:
> 
> On Wed, 8 Oct 2008, Thomas Lindroth wrote:
> 
>> I've done some debugging of this problem myself and reached some conclusions.
>>
>> I tried activating the ACPI_LV_INFO ACPI debug mode and observed what happens
>> when the system is under load. I saved one trace and put it in the file
>> acpi_debug_log at http://www.cyd.liu.se/~tholi945/acpi-bug-2008-10-06/
>>
>> When the temp goes over the ACPI passive trip point the processor gets
>> throttled. It usually never goes over T4 before the temp falls below the
>> passive temp but sometimes it reaches the highest T7. If it reach T7 the
>> next call to _TMP or _L18 never returns. I've confirmed this by running
>> echo T7 > /proc/acpi/processor/CPU*/throttling and then tried to read
>> from /proc/acpi/thermal_zone/TZ00/temperature and it fails in the same way.
>>
>> I've tried activating the ACPI_LV_PARSE ACPI debug mode, enter T7 and read
>> from temp. I put the result of that in the trace_debug file at the same adress.
>>
>> The AML call chain looks like this _TMP -> PMRD -> RCMD -> WIBF
>> WIBF always returns 1 causing the interpreter to get stuck in the while
>> loop in PMRD.
>>
>> While (RCMD (0x80, Local0))
>> {
>>     Noop
>>     Noop
>>     Store (PMUC, Local5)
>>     If (And (Local5, One, Local2))
>>     {
>>         Store (PMUD, Local5)
>>     }
>> }
>>
>> I don't really understand how AML code works so I can't get much further than
>> this.
>>
>> I did not experience complete lockups in Windows but I did notice some minor
>> stalls. Maybe the Windows AML parser can break infinite loops or maybe the
>> stalls is a normal part of the Windows experience. I tried to boot with the
>> acpi_osi=Linux option active but it didn't make any difference.
> 
> please send the output from
> 
> grep . /proc/acpi/thermal_zone/*/*

/proc/acpi/thermal_zone/TZ00/cooling_mode:<setting not supported>
/proc/acpi/thermal_zone/TZ00/polling_frequency:<polling disabled>
/proc/acpi/thermal_zone/TZ00/state:state:                   ok
/proc/acpi/thermal_zone/TZ00/temperature:temperature:             53 C
/proc/acpi/thermal_zone/TZ00/trip_points:critical (S5):           94 C
/proc/acpi/thermal_zone/TZ00/trip_points:passive:                 86 C: tc1=0 tc2=10 tsp=50 devices=CPU0 CPU1
/proc/acpi/thermal_zone/TZ01/cooling_mode:0 - Active; 1 - Passive
/proc/acpi/thermal_zone/TZ01/polling_frequency:<polling disabled>
/proc/acpi/thermal_zone/TZ01/state:state:                   ok
/proc/acpi/thermal_zone/TZ01/temperature:temperature:             27 C
/proc/acpi/thermal_zone/TZ01/trip_points:critical (S5):           94 C
/proc/acpi/thermal_zone/TZ01/trip_points:passive:                 78 C: tc1=0 tc2=10 tsp=2 devices=CPU0 CPU1
/proc/acpi/thermal_zone/TZ01/trip_points:active[0]:               80 C: devices=FAN1
/proc/acpi/thermal_zone/TZ01/trip_points:active[1]:               67 C: devices=FAN0
/proc/acpi/thermal_zone/TZ01/trip_points:active[2]:               55 C: devices=FAN2

I'm not sure why there are two TZ for the CPUs.

> from the log, it looks like your _PSV returns 3520, or 352.0K or 78C
> and that is reasonable,  but note that one option you have to
> workaround is to either disable or that trip point via

TZ00._PSV returns 3520 or 3590 depending on if the temp is above or below
the previous _PSV value.

> thermal.psv=-1
> or
> thermal.psv=100
> for example.
> 
> But the bigger question is why the temperature is hitting 78 --
> which is quite hot.
> Grep above will tell us if there is ACPI fan control, but I don't
> see any in the logs.  Can you hear the fans spinning?
> Do they go faster when the system heats up?
> do they work better after you blow the dust our of the fan?

The fans work and spin up under load. TZ01 got fan control but I never
see anything about TZ01 in the logs so I guess the fans are controlled by
the BIOS. The computer is new and not dusty.


/Thomas Lindroth

      reply	other threads:[~2008-10-09  7:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-06 11:23 Problem: ACPI related soft lockup on Fujitsu-Siemens AMILO Si 2636 Thomas Lindroth
2008-10-08  7:20 ` Thomas Lindroth
2008-10-08  7:42   ` Alexey Starikovskiy
2008-10-08  8:49     ` Alexey Starikovskiy
2008-10-08 10:48       ` Thomas Lindroth
2008-10-08 11:08         ` Thomas Renninger
2008-10-08 11:52           ` Alexey Starikovskiy
2008-10-08 22:19             ` Thomas Renninger
2008-10-09  1:50   ` Len Brown
2008-10-09  7:46     ` Thomas Lindroth [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48EDB6E0.8000609@gmail.com \
    --to=thomas.lindroth@gmail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.