From nobody@FreeBSD.org  Mon Mar 21 11:17:03 2005
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id D7A0A16A4CE
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 21 Mar 2005 11:17:03 +0000 (GMT)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id B787B43D54
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 21 Mar 2005 11:17:03 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j2LBH3hD004375
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 21 Mar 2005 11:17:03 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id j2LBH3Af004374;
	Mon, 21 Mar 2005 11:17:03 GMT
	(envelope-from nobody)
Message-Id: <200503211117.j2LBH3Af004374@www.freebsd.org>
Date: Mon, 21 Mar 2005 11:17:03 GMT
From: Juho Vuori <juho.vuori@kepa.fi>
To: freebsd-gnats-submit@FreeBSD.org
Subject: acpi thermal changes freezes HP nx6110
X-Send-Pr-Version: www-2.3

>Number:         79080
>Category:       i386
>Synopsis:       acpi thermal changes freezes HP nx6110
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-acpi
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar 21 11:20:00 GMT 2005
>Closed-Date:    Sat Jan 12 22:36:36 UTC 2008
>Last-Modified:  Sat Jan 12 22:36:36 UTC 2008
>Originator:     Juho Vuori
>Release:        5.4-PRERELEASE
>Organization:
>Environment:
FreeBSD loppa 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #3: Fri Mar 18 08:21:56 EET 2005     juho@loppa:/usr/obj/usr/src/sys/LOPPA  i386

>Description:
On HP nx6110 (intel 910gml chipset, celeron-m) and ACPI enabled:
When system temperature raises/drops above/below hw.acpi.thermal.tz0._ACx
levels the system freezes. The system freezes before the system fan gets
switched on/off by the event. If the system is compiled with 4BSD scheduler,
the freeze will last forever, with ULE scheduler, it is just a few seconds
long. It is caused by an acpi (irq9) interrupt storm. With acpi disabled,
the system works perfectly.

>How-To-Repeat:
Take HP nx 6110 laptop. Get freebsd with acpi compiled in and arange so
that the system temperature raises/drops over _ACx levels. 
>Fix:
      
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-i386->freebsd-acpi 
Responsible-Changed-By: arved 
Responsible-Changed-When: Fri Apr 22 12:29:16 GMT 2005 
Responsible-Changed-Why:  
Over to acpi Mailinglist 

http://www.freebsd.org/cgi/query-pr.cgi?pr=79080 

From: Pavel Rydvan <pryd@atlas.cz>
To: bug-followup@FreeBSD.org, juho.vuori@kepa.fi
Cc:  
Subject: Re: i386/79080: acpi thermal changes freezes HP nx6110
Date: Wed, 30 Nov 2005 14:15:49 +0100

 Hello,
 
 I am also using nx6110 and having the same problem. It also seems that 
 USB works only if ACPI is enabled (and, having no ports than USB, it 
 seems to be quite vital). Another astonishing connection is, that with 
 ACPI enabled, the notebook's touchpad started to be "tappable" (when i 
 tap to the surface, it performs a click), which never worked, but it 
 somehow started with enabling ACPI (and remains also when I disable it 
 again) -- it is out of my immagination and also out of toppic...
 
 As was told, notebook dies (when using SCHED_4BSD scheduler), or freezes 
 for approx. 2 seconds (when using SCHED_ULE), when the temperature 
 raises/drops above/below hw.acpi.thermal.tz0._ACx.
 
 There happens to appear a storm of acpi TZ_NOTIFY_TEMPERATURE messages. 
 When using SCHED_ULE, then --- after 2 seconds --- one occurence of 
 TZ_NOTIFY_LEVELS appears, then again one appearence of 
 TZ_NOTIFY_TEMPERATURE, and then the system continues in working well, 
 until another raise/drop happens.
 
 It seems that there should come some answer/action to the 
 TZ_NOTIFY_TEMPERATURE from the acpi_thermal driver, but it never happens 
 (or happens quite late). It seems to me that the answer is only "waked 
 up" (acpi_tz_signal function in acpi_thermal.c:640)  and is to be 
 performed by some other thread. I thought of moving that code "inside" 
 the actual thread, maybe it would help. But I do not understand ACPI at 
 all, so I do not know, WHAT the hw is expecting to happen:((.
 
 My "backup" idea was to set the ACx temperatures to values that cannot 
 be raised/dropped above/below, so the freezes wouldn't appear. And also 
 set some reasonable fan speed.
 
 There are 4+1 fan speeds (0=fastest, ... 3=slowest; -1=off), it is 
 possible to control their speed via sysctl hw.acpi.thermal.tz0.active=n, 
 which works well (no freeze when changing "by hand").
 
 There is following list of temperatures in hw.acpi.thermal.tz0._ACx:
 
 hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 60.0C 45.0C -1 -1 -1 -1 -1 -1
 
 If I persuaded the ntb to have the list for example  80.0C 5.0C 4.0C 
 3.0C -1 -1 -1..., than the storm perhaps never happens.
 
 It seems to me that it is somehow possible to change the values in the 
 list (but I don't know, where they are dictated by sw or hw): when the 
 temperature (for example) raises above 60.0C, the list is (somehow) 
 smartly changed to 80.0C 70.0C 55.0C 45.0C. Notice that 60.0 changed to 
 55.0, so the temperature is not going to lower below the limit 
 immediately...
 
 I have no experiences or knowledge of ACPI, I just tried to use sysctl 
 to set the _ACx, but it is read-only. Is it possible to be set by sw? 
 Has anybody idea of how to accomplish?
 
 Pavel Rydvan
 
 P.S.: Another astonishing connection is, that with ACPI enabled, the 
 notebook's touchpad started to be "tappable" (when i tap to the surface, 
 it performs a click), which never worked in FreeBSD with xorg, but it 
 somehow appeared with enabling ACPI (and remains also when I disable it 
 again) -- it is out of my immagination but it is also off topic...
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Sat Apr 28 09:11:30 UTC 2007 
State-Changed-Why:  
Is this still a problem with 6.2? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=79080 

From: Nate Lawson <nate@root.org>
To: Juho Vuori <juho.vuori@kepa.fi>
Cc: Mark Linimon <linimon@FreeBSD.org>,  freebsd-acpi@FreeBSD.org, 
 freebsd-gnats-submit@FreeBSD.org
Subject: Re: i386/79080: acpi thermal changes freezes HP nx6110
Date: Sat, 28 Apr 2007 11:37:25 -0700

 Juho Vuori wrote:
 > i don't know. The affected laptop is not running freebsd at the moment.
 > I'm afraid I can't do anything about this any time soon.
 > 
 > Juho Vuori
 > 
 > Mark Linimon wrote:
 >> Synopsis: acpi thermal changes freezes HP nx6110
 >>
 >> State-Changed-From-To: open->feedback
 >> State-Changed-By: linimon
 >> State-Changed-When: Sat Apr 28 09:11:30 UTC 2007
 >> State-Changed-Why: Is this still a problem with 6.2?
 >>
 >> http://www.freebsd.org/cgi/query-pr.cgi?pr=79080
 >
 
 If you could post a link to the ASL, that would be really helpful.  You
 can boot a live CD like http://www.freesbie.org/ even if not running
 FreeBSD.
 
 acpidump -dt | gzip -c9 > hp-nx6110.asl.gz
 
 -- 
 Nate
State-Changed-From-To: feedback->suspended 
State-Changed-By: linimon 
State-Changed-When: Sat May 5 23:37:39 UTC 2007 
State-Changed-Why:  
Suspended awaiting any further information from submitter. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=79080 

From: "Yousif Hassan" <yousif@alumni.jmu.edu>
To: <bug-followup@FreeBSD.org>,
	<juho.vuori@kepa.fi>,
	<chardon.frederic@gmail.com>
Cc:  
Subject: Re: i386/79080: acpi thermal changes freezes HP nx6110
Date: Sat, 5 Jan 2008 13:19:08 -0500

 The problem is still found in the most recent 7.0 RC code as well.
 Has something to do with a Mutex lock/unlock problem when the thermal
 zone change occurs - it doesn't appear to be an interrupt storm any
 longer.
 
 It is assuredly ACPI-related, because disabling ACPI makes the freezes
 go away.  However, this laptop does not function well without ACPI so
 it's not a good workaround.  USB devices do not work w/o ACPI, as well
 as other hardware.
 
 There are several suggested workarounds I tried, none of which resoloved
 the issue.  These included building the kernel with apic, disabling apic,
 manually changing the hw.acpi.thermal.tz0.active number (my nx6110
 seems to want to keep it at 1 no matter what), and using the ULE
 scheduler rather than the 4BSD.  Again, none of the above workarounds,
 in any combination, solved the issue.
 
 INFORMATION
 -----------
 Turning on debugging, the following appears right before the lock,
 as soon as temperature rises enough to trigger a change in the zone:
 
 acpi_tz0: _AC3: temperature 68.0 >= setpoint 45.0
 acpi_tz0: _AC2: temperature 68.0 >= setpoint 55.0
 acpi_tz0: _AC3: temperature 67.0 >= setpoint 45.0
 acpi_tz0: _AC2: temperature 67.0 >= setpoint 55.0
 ...etc...
 and then:
 ACPI Exception (utmutex-0376): AE_TIME, Thread 28 could not acquire Mutex 
 [0] [20070320]
 ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex 
 [20070320]
 ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release 
 [20070320]
 ACPI Error (exutils-0250): Could not release AML Interpreter mutex 
 [20070320]
 ACPI Exception (utmutex-0376): AE_TIME, Thread 28 could not acquire Mutex 
 [0] [20070320]
 ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex 
 [20070320]
 ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.C242] (Node 
 0xc321c220), AE_TIME
 ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.TZ1_._TMP] 
 (Node 0xc321b9c0), AE_TIME
 ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release 
 [20070320]
 ACPI Error (exutils-0250): Could not release AML Interpreter mutex 
 [20070320]
 ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.C242] (Node 
 0xc321c220), AE_TIME
 ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.TZ2_._TMP] 
 (Node 0xc321b8c0), AE_TIME
 ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release 
 [20070320]
 ACPI Error (exutils-0250): Could not release AML Interpreter mutex 
 [20070320]
 
 (the errors continue to repeat ad infinitum, and each TZ reports problems)
 
 As a result, you will eventually see:
 
 acpi_tz0: error fetching current temperature -- AE_TIME
 acpi_tz1: error fetching current temperature -- AE_TIME
 (..etc...)
 
 The interesting thing is that THIS PROBLEM DOES NOT APPEAR in FreeBSD
 6.2-RELEASE nor in any of the 6.3-RC variants.  It's unique to FreeBSD
 7, and it involves some of the new ACPI mutex code.
 
 This is definitely a regression for this particular laptop since it worked 
 well
 in 6.x - so as such, maybe it would be worthwhile to investigate this bug.
 It seems general enough that it could affect other laptop ASLs as well.
 
 The ASL dump AND a sysctl dump can be found:
 http://www.far-far-away.com/~yousif/freebsd/
 
 Please let me know if more information is needed.
 
 --Yousif 
 
State-Changed-From-To: suspended->closed 
State-Changed-By: njl 
State-Changed-When: Sat Jan 12 22:35:47 UTC 2008 
State-Changed-Why:  
Patch tested and committed.  Please cvsup if running -current.  Patch 
will be MFCd to 7.0 

http://www.freebsd.org/cgi/query-pr.cgi?pr=79080 
>Unformatted:
