From owner-freebsd-acpi@FreeBSD.ORG Sun Jan 6 00:47:19 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A71F16A417 for ; Sun, 6 Jan 2008 00:47:19 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id E134413C455 for ; Sun, 6 Jan 2008 00:47:18 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 54787 invoked from network); 6 Jan 2008 00:47:20 -0000 Received: from c-98-207-236-172.hsd1.ca.comcast.net (HELO ?172.16.250.113?) (nate-mail@98.207.236.172) by root.org with ESMTPA; 6 Jan 2008 00:47:20 -0000 Message-ID: <47802510.3040203@root.org> Date: Sat, 05 Jan 2008 16:47:12 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: John Baldwin References: <200712311556.lBVFuVZf030567@freefall.freebsd.org> <477916E0.2090702@root.org> <200712311243.18123.jhb@freebsd.org> In-Reply-To: <200712311243.18123.jhb@freebsd.org> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 00:47:19 -0000 John Baldwin wrote: > np. Btw, on another note, I've finally tracked down the weird hangs my laptop > has on updated HEAD to something in the GPE handling related to updates to > ACPI in the past year. I'm still digging, but you can look at > www.freebsd.org/~jhb/gpe/ and use the modified schedgraph.py there on the > ktr5.out to see what happens when my laptop stops running userland processes. > It appears to be spending all its time running a GPE handler for a thermal > event. Thanks for digging into this. I reviewed this and am trying to figure out why the _L00 handler never completes. It keeps getting preempted by the next one. To help track this down, try removing these two lines from the _L00 method and recompile your ASL: Acquire (\_TZ.C173, 0xFFFF) ... Release (\_TZ.C173) For others who have this problem, instructions on how to recompile and load your custom ASL can be found here (11.16.4 and 5): http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html > My asl is at the same URL as acpi.nc6220, it's less helpful than > usual as HP has taken the unusual step of apparently running it through an > obfuscator. Compaq's done that for years. -Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Jan 6 20:19:03 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD7A816A418 for ; Sun, 6 Jan 2008 20:19:03 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: from coruscant.far-far-away.us (coruscant.far-far-away.us [70.91.196.65]) by mx1.freebsd.org (Postfix) with SMTP id 6B80A13C43E for ; Sun, 6 Jan 2008 20:19:03 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: (qmail 22193 invoked from network); 6 Jan 2008 15:12:59 -0500 Received: from kamino.far-far-away.us (HELO kamino) (192.168.0.9) by coruscant.far-far-away.us with SMTP; 6 Jan 2008 15:12:59 -0500 Message-ID: From: "Yousif Hassan" To: "Nate Lawson" References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org> <200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> In-Reply-To: <47802510.3040203@root.org> Date: Sun, 6 Jan 2008 15:18:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: freebsd-acpi@FreeBSD.org Subject: Re: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yousif Hassan List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 20:19:03 -0000 Nate wrote: > Thanks for digging into this. I reviewed this and am trying to figure > out why the _L00 handler never completes. It keeps getting preempted by > the next one. To help track this down, try removing these two lines > from the _L00 method and recompile your ASL: > > Acquire (\_TZ.C173, 0xFFFF) > ... > Release (\_TZ.C173) > > For others who have this problem, instructions on how to recompile and > load your custom ASL can be found here (11.16.4 and 5): > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html I'm not sure if my situation is exactly what you're referring to in this note, but since my laptop is also an HP (nx6110), and since it also hangs during thermal zone changes, I tried your suggestion. It didn't help, unfortunately. I still get mutex problems when the thermal zone increases. My ASL did not have precisely the Acquire call you listed, but it did have a similar one in method _L00 called Acquire (\_TZ.C170, 0xFFFF) and Release (\_TZ.C170). Also this pair of calls was also found in one other place (further down) in the ASL. I only removed the first pair in the method you instructed. FWIW, here are the debug error messages when the machine hangs: 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 ... etc ... I put more info into PR 79080. Let me know if you want me to try anything else. --Yousif From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 08:24:27 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A09E716A479; Mon, 7 Jan 2008 08:24:27 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 425D613C4E3; Mon, 7 Jan 2008 08:24:27 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m078OR0x049723; Mon, 7 Jan 2008 08:24:27 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m078ORD6049719; Mon, 7 Jan 2008 08:24:27 GMT (envelope-from remko) Date: Mon, 7 Jan 2008 08:24:27 GMT Message-Id: <200801070824.m078ORD6049719@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-acpi@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/119356: [acpi]: i386 ACPI wakeup not work due resource exhaustion X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 08:24:27 -0000 Old Synopsis: i386 ACPI wakeup not work due resource exhaustion New Synopsis: [acpi]: i386 ACPI wakeup not work due resource exhaustion Responsible-Changed-From-To: freebsd-i386->freebsd-acpi Responsible-Changed-By: remko Responsible-Changed-When: Mon Jan 7 08:24:04 UTC 2008 Responsible-Changed-Why: Reassign to acpi team http://www.freebsd.org/cgi/query-pr.cgi?pr=119356 From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 11:06:55 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D4F416A418 for ; Mon, 7 Jan 2008 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0647613C45D for ; Mon, 7 Jan 2008 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m07B6soq061684 for ; Mon, 7 Jan 2008 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m07B6sbK061680 for freebsd-acpi@FreeBSD.org; Mon, 7 Jan 2008 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Jan 2008 11:06:54 GMT Message-Id: <200801071106.m07B6sbK061680@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 11:06:55 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 s i386/79080 acpi acpi thermal changes freezes HP nx6110 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/114113 acpi [patch] ACPI kernel panic during S3 suspend / resume o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o amd64/115011 acpi ACPI problem ,reboot system down. o kern/116169 acpi [PATCH] acpi_ibm => psm0 not found problem o kern/116939 acpi PCI-to-PCI misconfigured for bus three and can not see o i386/117918 acpi HP dc5750 will only boot with ACPI disabled o bin/118973 acpi [acpi]: Kernel panic with acpi boot o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust 20 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 o i386/72179 acpi [acpi] [patch] Inconsistent apm(8) output regarding th o kern/73823 acpi [feature request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o kern/89411 acpi [acpi] acpiconf bug o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI o kern/98171 acpi [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop o kern/103365 acpi [acpi] acpi poweroff doesn't work with geli device att o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o bin/109760 acpi [acpi]: [modules] kldunload acpi_video - crash o kern/111591 acpi [acpi] dev.acpi_ibm.0.events returns I/O error (regres o kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/114165 acpi Dell C810 - ACPI problem o kern/114649 acpi [patch][acpi] panic: recursed on non-recursive mutex o kern/114722 acpi [acpi] [patch] Nearly duplicate p-state entries report o kern/117605 acpi [acpi] request for debug.cpufreq.highest 21 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 11:54:28 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 688D216A417 for ; Mon, 7 Jan 2008 11:54:28 +0000 (UTC) (envelope-from vader@lavabit.com) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 494E513C457 for ; Mon, 7 Jan 2008 11:54:28 +0000 (UTC) (envelope-from vader@lavabit.com) Received: from jean.lavabit.com (unknown [192.168.111.1]) by karen.lavabit.com (Postfix) with ESMTP id 45F17C8899 for ; Mon, 7 Jan 2008 05:29:56 -0600 (CST) Received: from 127.0.0.1 (230.133.132.202.dynamic.ttn.net [202.132.133.230]) by lavabit.com with ESMTP id 6QABIFOUTA7G for ; Mon, 07 Jan 2008 05:29:56 -0600 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=FjfqKuNg9AQ2YwmIcFkHPpuE3HeNu0pBE/rM6/6/n0A3Lw3RiOaRk8pjfSZWvCxd2+X8TQMioD5SkTwPu1yplbXmiYO+yenFOIZcROyFEI1esOsRS/TrEjFyizdJWiKbbmbLFZ5jxzUyLcoQEkH4ZRJVvCX5pldro5+XK1JbYMU=; h=Date:From:To:Subject:Reply-To:Sender:Disposition-Notification-To:X-Confirm-Reading-To:Message-Id:MIME-Version:X-Priority:X-MSMail-Priority:Content-Type:Content-Transfer-Encoding:X-Mailer; Date: Mon, 07 Jan 2008 19:29:55 +0800 From: To: freebsd-acpi@FreeBSD.org Sender: Message-Id: <20080107184553.C533.A838D848@lavabit.com> MIME-Version: 1.0 X-Priority: 1 X-MSMail-Priority: High Content-Type: text/plain; charset="BIG5" Content-Transfer-Encoding: 8bit X-Mailer: Becky! ver. 2.44 [tw] X-Mailman-Approved-At: Mon, 07 Jan 2008 12:21:40 +0000 Cc: Subject: ACPI problem on EPOX MVP3C2 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vader@lavabit.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 11:54:28 -0000 Dear sir, First of all, apology for my poor English. I have a EPOX MVP3C2 mainboard, running FreeBSD 7.0 ( in fact, I will use it for Freenas) while enabling ACPI, there're some troubles: 1. the NICs, 3C905C-TXM or RTL8139 / RTL8169, won't work, always get the "watchdog timeout" responding,. 2. the floppy disc (FD0) will be gone, too. 3. Maybe there're other problems, but I only notice 2 as above for now. Other suspicious problems suppose to be listed on below records. Here're the info I follow your instruction to record 1. dmesg with ACPI enable http://vader.hopto.org/freenas/acpi/acpiondmesg.txt devices in /DEV/ (FD0 is lost) http://vader.hopto.org/freenas/acpi/acpiondev.txt 2. dmesg with ACPI disable http://vader.hopto.org/freenas/acpi/acpioffdmesg.txt devices in /DEV/ (no ACPI, but FD0 is back) http://vader.hopto.org/freenas/acpi/acpioffdev.txt 3. out put from sysctl hw.acpi http://vader.hopto.org/freenas/acpi/hw-acpi.txt 4.ACPI Source Language dump http://vader.hopto.org/freenas/acpi/root-mvp3c2.asl and the other ACPI dump under DOS, hope would be useful http://vader.hopto.org/freenas/acpi/dosacpidump.txt I can disable ACPI then everything will be smooth, however, the system won't be shutdown totally by the shutdown command or ACPI button, I must turn on monitor to confirm shutdown being completed then turn off the power switch. Please help me, If need any additional info, please tell me, Thank you in advanced! Best regards, From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 13:15:54 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E08DA16A418 for ; Mon, 7 Jan 2008 13:15:54 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [78.128.192.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5C813C4D3 for ; Mon, 7 Jan 2008 13:15:53 +0000 (UTC) (envelope-from dan@obluda.cz) X-Envelope-From: dan@obluda.cz Received: from kgw.obluda.cz (openvpn.ms.mff.cuni.cz [195.113.20.87]) by smtp1.kolej.mff.cuni.cz (8.13.8/8.13.8) with ESMTP id m07CuIac008339 for ; Mon, 7 Jan 2008 13:56:19 +0100 (CET) (envelope-from dan@obluda.cz) Message-ID: <47822172.3050409@obluda.cz> Date: Mon, 07 Jan 2008 13:56:18 +0100 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.11) Gecko/20071204 SeaMonkey/1.1.7 MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org References: <20080107184553.C533.A838D848@lavabit.com> In-Reply-To: <20080107184553.C533.A838D848@lavabit.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: ACPI problem on EPOX MVP3C2 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 13:15:55 -0000 vader@lavabit.com napsal/wrote, On 01/07/08 12:29: > 2. the floppy disc (FD0) will be gone, too. I had a problem "no floppy with ACPI" also a few years ago. The problem has been caused by errors within AML. The fix for my problem - dump&disassemble DSDT, correct the syntax errors, compile. Force OS to use tables from file instead of BIOS internals. Hope it help. Dan From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 18:08:47 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BCF816A469 for ; Mon, 7 Jan 2008 18:08:47 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4597613C457 for ; Mon, 7 Jan 2008 18:08:47 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 54282 invoked from network); 7 Jan 2008 18:08:47 -0000 Received: from adsl-71-141-123-117.dsl.snfc21.pacbell.net (HELO ?192.168.1.77?) (nate-mail@71.141.123.117) by root.org with ESMTPA; 7 Jan 2008 18:08:47 -0000 Message-ID: <47826AAA.6040101@root.org> Date: Mon, 07 Jan 2008 10:08:42 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Moore, Robert" References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 18:08:47 -0000 Bob, thanks for the reply. That's exactly what my investigation is showing also. It appears we're still on 20070320 so I'm not sure why this would affect us though. Perhaps a similar change was already present? In any case, we should see if an import fixes this. Thanks, Nate Moore, Robert wrote: > This sounds suspiciously like the changes we made to the Notify() > handling last year. We attempted to make the notify handler run > synchronously with the caller to Notify(), but this created more > problems than it solved. We ended up returning the behavior of Notify > handlers to be asynchronous: > > > > 19 October 2007. Summary of changes for version 20071019: > > 1) ACPI CA Core Subsystem: > > Reverted a change to Notify handling that was introduced in version > 20070508. This version changed the Notify handling from asynchronous to > fully synchronous (Device driver Notify handling with respect to the > Notify > ASL operator). It was found that this change caused more problems than > it > solved and was removed by most users. > > > > >> -----Original Message----- >> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >> acpi@freebsd.org] On Behalf Of Yousif Hassan >> Sent: Sunday, January 06, 2008 12:18 PM >> To: Nate Lawson >> Cc: freebsd-acpi@FreeBSD.org >> Subject: Re: GPE handler livelock >> >> Nate wrote: >>> Thanks for digging into this. I reviewed this and am trying to > figure >>> out why the _L00 handler never completes. It keeps getting preempted > by >>> the next one. To help track this down, try removing these two lines >>> from the _L00 method and recompile your ASL: >>> >>> Acquire (\_TZ.C173, 0xFFFF) >>> ... >>> Release (\_TZ.C173) >>> >>> For others who have this problem, instructions on how to recompile > and >>> load your custom ASL can be found here (11.16.4 and 5): >>> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.htm > l >> I'm not sure if my situation is exactly what you're referring to in >> this note, but since my laptop is also an HP (nx6110), and since it > also >> hangs during thermal zone changes, I tried your suggestion. It didn't >> help, unfortunately. I still get mutex problems when the thermal zone >> increases. My ASL did not have precisely the Acquire call you listed, >> but it did have a similar one in method _L00 called >> Acquire (\_TZ.C170, 0xFFFF) and Release (\_TZ.C170). Also this pair >> of calls was also found in one other place (further down) in the ASL. >> I only removed the first pair in the method you instructed. >> FWIW, here are the debug error messages when the machine hangs: >> >> 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 >> ... etc ... >> >> I put more info into PR 79080. >> >> Let me know if you want me to try anything else. >> --Yousif >> >> _______________________________________________ >> freebsd-acpi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 18:29:03 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3222316A41B for ; Mon, 7 Jan 2008 18:29:03 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id F1F9E13C461 for ; Mon, 7 Jan 2008 18:29:02 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 07 Jan 2008 10:00:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.24,254,1196668800"; d="scan'208";a="360991296" Received: from orsmsx335.jf.intel.com ([10.22.226.40]) by azsmga001.ch.intel.com with ESMTP; 07 Jan 2008 09:47:33 -0800 Received: from orsmsx415.amr.corp.intel.com ([10.22.226.49]) by orsmsx335.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 09:47:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jan 2008 09:47:29 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GPE handler livelock Thread-Index: AchQoWg+zeEXOKA5RX2GXXN27UeJDwAs0f6w References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> From: "Moore, Robert" To: "Yousif Hassan" , "Nate Lawson" X-OriginalArrivalTime: 07 Jan 2008 17:47:30.0489 (UTC) FILETIME=[60024290:01C85155] Cc: freebsd-acpi@FreeBSD.org Subject: RE: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 18:29:03 -0000 This sounds suspiciously like the changes we made to the Notify() handling last year. We attempted to make the notify handler run synchronously with the caller to Notify(), but this created more problems than it solved. We ended up returning the behavior of Notify handlers to be asynchronous: 19 October 2007. Summary of changes for version 20071019: 1) ACPI CA Core Subsystem: Reverted a change to Notify handling that was introduced in version=20 20070508. This version changed the Notify handling from asynchronous to=20 fully synchronous (Device driver Notify handling with respect to the Notify=20 ASL operator). It was found that this change caused more problems than it=20 solved and was removed by most users. >-----Original Message----- >From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >acpi@freebsd.org] On Behalf Of Yousif Hassan >Sent: Sunday, January 06, 2008 12:18 PM >To: Nate Lawson >Cc: freebsd-acpi@FreeBSD.org >Subject: Re: GPE handler livelock > >Nate wrote: >> Thanks for digging into this. I reviewed this and am trying to figure >> out why the _L00 handler never completes. It keeps getting preempted by >> the next one. To help track this down, try removing these two lines >> from the _L00 method and recompile your ASL: >> >> Acquire (\_TZ.C173, 0xFFFF) >> ... >> Release (\_TZ.C173) >> >> For others who have this problem, instructions on how to recompile and >> load your custom ASL can be found here (11.16.4 and 5): >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.htm l > >I'm not sure if my situation is exactly what you're referring to in >this note, but since my laptop is also an HP (nx6110), and since it also >hangs during thermal zone changes, I tried your suggestion. It didn't >help, unfortunately. I still get mutex problems when the thermal zone >increases. My ASL did not have precisely the Acquire call you listed, >but it did have a similar one in method _L00 called >Acquire (\_TZ.C170, 0xFFFF) and Release (\_TZ.C170). Also this pair >of calls was also found in one other place (further down) in the ASL. >I only removed the first pair in the method you instructed. >FWIW, here are the debug error messages when the machine hangs: > >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 >... etc ... > >I put more info into PR 79080. > >Let me know if you want me to try anything else. >--Yousif > >_______________________________________________ >freebsd-acpi@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 18:35:38 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30BAF16A419 for ; Mon, 7 Jan 2008 18:35:38 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mx1.freebsd.org (Postfix) with ESMTP id EFDD313C45D for ; Mon, 7 Jan 2008 18:35:37 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 07 Jan 2008 10:35:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.24,254,1196668800"; d="scan'208";a="250685498" Received: from orsmsx335.jf.intel.com ([10.22.226.40]) by orsmga002.jf.intel.com with ESMTP; 07 Jan 2008 10:34:30 -0800 Received: from orsmsx415.amr.corp.intel.com ([10.22.226.49]) by orsmsx335.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 10:34:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jan 2008 10:34:30 -0800 Message-ID: In-Reply-To: <47826AAA.6040101@root.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GPE handler livelock Thread-Index: AchRWK+kS0mPCWanQMSVSP41LXXSUgAAqShw References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> <47826AAA.6040101@root.org> From: "Moore, Robert" To: "Nate Lawson" , "Alexey Starikovskiy" X-OriginalArrivalTime: 07 Jan 2008 18:34:30.0684 (UTC) FILETIME=[F0F9DDC0:01C8515B] Cc: freebsd-acpi@FreeBSD.org Subject: RE: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 18:35:38 -0000 No changes that I know of before 20070508. You'll need to figure out why you are getting another GPE before the _Lxx method completes. There was something like this on Linux with an HP machine, perhaps Alexey can help. As I recall, there was something nasty happening where the TZ trip points had to be reset before the Notify() handler completed, but this ended up causing another GPE, etc. etc. Bob >-----Original Message----- >From: Nate Lawson [mailto:nate@root.org] >Sent: Monday, January 07, 2008 10:09 AM >To: Moore, Robert >Cc: Yousif Hassan; freebsd-acpi@FreeBSD.org >Subject: Re: GPE handler livelock > >Bob, thanks for the reply. That's exactly what my investigation is >showing also. It appears we're still on 20070320 so I'm not sure why >this would affect us though. Perhaps a similar change was already >present? In any case, we should see if an import fixes this. > >Thanks, >Nate > >Moore, Robert wrote: >> This sounds suspiciously like the changes we made to the Notify() >> handling last year. We attempted to make the notify handler run >> synchronously with the caller to Notify(), but this created more >> problems than it solved. We ended up returning the behavior of Notify >> handlers to be asynchronous: >> >> >> >> 19 October 2007. Summary of changes for version 20071019: >> >> 1) ACPI CA Core Subsystem: >> >> Reverted a change to Notify handling that was introduced in version >> 20070508. This version changed the Notify handling from asynchronous to >> fully synchronous (Device driver Notify handling with respect to the >> Notify >> ASL operator). It was found that this change caused more problems than >> it >> solved and was removed by most users. >> >> >> >> >>> -----Original Message----- >>> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>> acpi@freebsd.org] On Behalf Of Yousif Hassan >>> Sent: Sunday, January 06, 2008 12:18 PM >>> To: Nate Lawson >>> Cc: freebsd-acpi@FreeBSD.org >>> Subject: Re: GPE handler livelock >>> >>> Nate wrote: >>>> Thanks for digging into this. I reviewed this and am trying to >> figure >>>> out why the _L00 handler never completes. It keeps getting preempted >> by >>>> the next one. To help track this down, try removing these two lines >>>> from the _L00 method and recompile your ASL: >>>> >>>> Acquire (\_TZ.C173, 0xFFFF) >>>> ... >>>> Release (\_TZ.C173) >>>> >>>> For others who have this problem, instructions on how to recompile >> and >>>> load your custom ASL can be found here (11.16.4 and 5): >>>> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.htm >> l >>> I'm not sure if my situation is exactly what you're referring to in >>> this note, but since my laptop is also an HP (nx6110), and since it >> also >>> hangs during thermal zone changes, I tried your suggestion. It didn't >>> help, unfortunately. I still get mutex problems when the thermal zone >>> increases. My ASL did not have precisely the Acquire call you listed, >>> but it did have a similar one in method _L00 called >>> Acquire (\_TZ.C170, 0xFFFF) and Release (\_TZ.C170). Also this pair >>> of calls was also found in one other place (further down) in the ASL. >>> I only removed the first pair in the method you instructed. >>> FWIW, here are the debug error messages when the machine hangs: >>> >>> 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 >>> ... etc ... >>> >>> I put more info into PR 79080. >>> >>> Let me know if you want me to try anything else. >>> --Yousif >>> >>> _______________________________________________ >>> freebsd-acpi@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > >-- >Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 19:02:56 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C456B16A420 for ; Mon, 7 Jan 2008 19:02:56 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8FAEA13C448 for ; Mon, 7 Jan 2008 19:02:56 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 74917 invoked from network); 7 Jan 2008 19:02:57 -0000 Received: from adsl-71-141-123-117.dsl.snfc21.pacbell.net (HELO ?192.168.1.77?) (nate-mail@71.141.123.117) by root.org with ESMTPA; 7 Jan 2008 19:02:57 -0000 Message-ID: <4782775A.6090404@root.org> Date: Mon, 07 Jan 2008 11:02:50 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Alexey Starikovskiy References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> <47826AAA.6040101@root.org> <47827291.60405@suse.de> <478272C3.5080704@suse.de> In-Reply-To: <478272C3.5080704@suse.de> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, "Moore, Robert" Subject: Re: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 19:02:56 -0000 Great, thanks both of you. I'll rework this for FreeBSD and repost. Alexey Starikovskiy wrote: > Here is the patch... > Alexey Starikovskiy wrote: >> I proposed this patch some time ago, it moves _Lxx enabling to the end >> of Notify queue, thus all notifies must complete before event becomes >> enabled again. >> Hope it is readable to non-Linux people... >> >> Regards, >> Alex. >> >> Moore, Robert wrote: >>> No changes that I know of before 20070508. >>> >>> You'll need to figure out why you are getting another GPE before the >>> _Lxx method completes. There was something like this on Linux with an HP >>> machine, perhaps Alexey can help. >>> >>> As I recall, there was something nasty happening where the TZ trip >>> points had to be reset before the Notify() handler completed, but this >>> ended up causing another GPE, etc. etc. >>> >>> Bob >>> >>> >>>> -----Original Message----- >>>> From: Nate Lawson [mailto:nate@root.org] >>>> Sent: Monday, January 07, 2008 10:09 AM >>>> To: Moore, Robert >>>> Cc: Yousif Hassan; freebsd-acpi@FreeBSD.org >>>> Subject: Re: GPE handler livelock >>>> >>>> Bob, thanks for the reply. That's exactly what my investigation is >>>> showing also. It appears we're still on 20070320 so I'm not sure why >>>> this would affect us though. Perhaps a similar change was already >>>> present? In any case, we should see if an import fixes this. >>>> >>>> Thanks, >>>> Nate >>>> >>>> Moore, Robert wrote: >>>>> This sounds suspiciously like the changes we made to the Notify() >>>>> handling last year. We attempted to make the notify handler run >>>>> synchronously with the caller to Notify(), but this created more >>>>> problems than it solved. We ended up returning the behavior of Notify >>>>> handlers to be asynchronous: >>>>> >>>>> >>>>> >>>>> 19 October 2007. Summary of changes for version 20071019: >>>>> >>>>> 1) ACPI CA Core Subsystem: >>>>> >>>>> Reverted a change to Notify handling that was introduced in version >>>>> 20070508. This version changed the Notify handling from asynchronous >>> to >>>>> fully synchronous (Device driver Notify handling with respect to the >>>>> Notify >>>>> ASL operator). It was found that this change caused more problems >>> than >>>>> it >>>>> solved and was removed by most users. >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>>>>> acpi@freebsd.org] On Behalf Of Yousif Hassan >>>>>> Sent: Sunday, January 06, 2008 12:18 PM >>>>>> To: Nate Lawson >>>>>> Cc: freebsd-acpi@FreeBSD.org >>>>>> Subject: Re: GPE handler livelock >>>>>> >>>>>> Nate wrote: >>>>>>> Thanks for digging into this. I reviewed this and am trying to >>>>> figure >>>>>>> out why the _L00 handler never completes. It keeps getting >>> preempted >>>>> by >>>>>>> the next one. To help track this down, try removing these two >>> lines >>>>>>> from the _L00 method and recompile your ASL: >>>>>>> >>>>>>> Acquire (\_TZ.C173, 0xFFFF) >>>>>>> ... >>>>>>> Release (\_TZ.C173) >>>>>>> >>>>>>> For others who have this problem, instructions on how to recompile >>>>> and >>>>>>> load your custom ASL can be found here (11.16.4 and 5): >>>>>>> >>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.htm >>>>> l >>>>>> I'm not sure if my situation is exactly what you're referring to in >>>>>> this note, but since my laptop is also an HP (nx6110), and since it >>>>> also >>>>>> hangs during thermal zone changes, I tried your suggestion. It >>> didn't >>>>>> help, unfortunately. I still get mutex problems when the thermal >>> zone >>>>>> increases. My ASL did not have precisely the Acquire call you >>> listed, >>>>>> but it did have a similar one in method _L00 called >>>>>> Acquire (\_TZ.C170, 0xFFFF) and Release (\_TZ.C170). Also this pair >>>>>> of calls was also found in one other place (further down) in the >>> ASL. >>>>>> I only removed the first pair in the method you instructed. >>>>>> FWIW, here are the debug error messages when the machine hangs: >>>>>> >>>>>> 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 >>>>>> ... etc ... >>>>>> >>>>>> I put more info into PR 79080. >>>>>> >>>>>> Let me know if you want me to try anything else. >>>>>> --Yousif >>>>>> >>>>>> _______________________________________________ >>>>>> freebsd-acpi@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>>>>> To unsubscribe, send any mail to >>> "freebsd-acpi-unsubscribe@freebsd.org" >>>> -- >>>> Nate >> >> > -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 19:03:55 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E69C16A473 for ; Mon, 7 Jan 2008 19:03:55 +0000 (UTC) (envelope-from astarikovskiy@suse.de) Received: from emea5-mh.id5.novell.com (charybdis-ext.suse.de [195.135.221.2]) by mx1.freebsd.org (Postfix) with ESMTP id B026113C45B for ; Mon, 7 Jan 2008 19:03:54 +0000 (UTC) (envelope-from astarikovskiy@suse.de) Received: from [192.168.101.12] ([149.44.162.75]) by emea5-mh.id5.novell.com with ESMTP; Mon, 07 Jan 2008 19:42:42 +0100 Message-ID: <47827291.60405@suse.de> Date: Mon, 07 Jan 2008 21:42:25 +0300 From: Alexey Starikovskiy User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "Moore, Robert" References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> <47826AAA.6040101@root.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 19:03:55 -0000 I proposed this patch some time ago, it moves _Lxx enabling to the end of Notify queue, thus all notifies must complete before event becomes enabled again. Hope it is readable to non-Linux people... Regards, Alex. Moore, Robert wrote: > No changes that I know of before 20070508. > > You'll need to figure out why you are getting another GPE before the > _Lxx method completes. There was something like this on Linux with an HP > machine, perhaps Alexey can help. > > As I recall, there was something nasty happening where the TZ trip > points had to be reset before the Notify() handler completed, but this > ended up causing another GPE, etc. etc. > > Bob > > >> -----Original Message----- >> From: Nate Lawson [mailto:nate@root.org] >> Sent: Monday, January 07, 2008 10:09 AM >> To: Moore, Robert >> Cc: Yousif Hassan; freebsd-acpi@FreeBSD.org >> Subject: Re: GPE handler livelock >> >> Bob, thanks for the reply. That's exactly what my investigation is >> showing also. It appears we're still on 20070320 so I'm not sure why >> this would affect us though. Perhaps a similar change was already >> present? In any case, we should see if an import fixes this. >> >> Thanks, >> Nate >> >> Moore, Robert wrote: >>> This sounds suspiciously like the changes we made to the Notify() >>> handling last year. We attempted to make the notify handler run >>> synchronously with the caller to Notify(), but this created more >>> problems than it solved. We ended up returning the behavior of Notify >>> handlers to be asynchronous: >>> >>> >>> >>> 19 October 2007. Summary of changes for version 20071019: >>> >>> 1) ACPI CA Core Subsystem: >>> >>> Reverted a change to Notify handling that was introduced in version >>> 20070508. This version changed the Notify handling from asynchronous > to >>> fully synchronous (Device driver Notify handling with respect to the >>> Notify >>> ASL operator). It was found that this change caused more problems > than >>> it >>> solved and was removed by most users. >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>>> acpi@freebsd.org] On Behalf Of Yousif Hassan >>>> Sent: Sunday, January 06, 2008 12:18 PM >>>> To: Nate Lawson >>>> Cc: freebsd-acpi@FreeBSD.org >>>> Subject: Re: GPE handler livelock >>>> >>>> Nate wrote: >>>>> Thanks for digging into this. I reviewed this and am trying to >>> figure >>>>> out why the _L00 handler never completes. It keeps getting > preempted >>> by >>>>> the next one. To help track this down, try removing these two > lines >>>>> from the _L00 method and recompile your ASL: >>>>> >>>>> Acquire (\_TZ.C173, 0xFFFF) >>>>> ... >>>>> Release (\_TZ.C173) >>>>> >>>>> For others who have this problem, instructions on how to recompile >>> and >>>>> load your custom ASL can be found here (11.16.4 and 5): >>>>> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.htm >>> l >>>> I'm not sure if my situation is exactly what you're referring to in >>>> this note, but since my laptop is also an HP (nx6110), and since it >>> also >>>> hangs during thermal zone changes, I tried your suggestion. It > didn't >>>> help, unfortunately. I still get mutex problems when the thermal > zone >>>> increases. My ASL did not have precisely the Acquire call you > listed, >>>> but it did have a similar one in method _L00 called >>>> Acquire (\_TZ.C170, 0xFFFF) and Release (\_TZ.C170). Also this pair >>>> of calls was also found in one other place (further down) in the > ASL. >>>> I only removed the first pair in the method you instructed. >>>> FWIW, here are the debug error messages when the machine hangs: >>>> >>>> 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 >>>> ... etc ... >>>> >>>> I put more info into PR 79080. >>>> >>>> Let me know if you want me to try anything else. >>>> --Yousif >>>> >>>> _______________________________________________ >>>> freebsd-acpi@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>>> To unsubscribe, send any mail to > "freebsd-acpi-unsubscribe@freebsd.org" >> -- >> Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 19:03:55 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA89F16A417 for ; Mon, 7 Jan 2008 19:03:55 +0000 (UTC) (envelope-from astarikovskiy@suse.de) Received: from emea5-mh.id5.novell.com (charybdis-ext.suse.de [195.135.221.2]) by mx1.freebsd.org (Postfix) with ESMTP id B01F713C447 for ; Mon, 7 Jan 2008 19:03:54 +0000 (UTC) (envelope-from astarikovskiy@suse.de) Received: from [192.168.101.12] ([149.44.162.75]) by emea5-mh.id5.novell.com with ESMTP; Mon, 07 Jan 2008 19:43:31 +0100 Message-ID: <478272C3.5080704@suse.de> Date: Mon, 07 Jan 2008 21:43:15 +0300 From: Alexey Starikovskiy User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "Moore, Robert" References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> <47826AAA.6040101@root.org> <47827291.60405@suse.de> In-Reply-To: <47827291.60405@suse.de> Content-Type: multipart/mixed; boundary="------------080009060006020206020005" Cc: freebsd-acpi@FreeBSD.org Subject: Re: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 19:03:55 -0000 This is a multi-part message in MIME format. --------------080009060006020206020005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here is the patch... Alexey Starikovskiy wrote: > I proposed this patch some time ago, it moves _Lxx enabling to the end > of Notify queue, thus all notifies must complete before event becomes > enabled again. > Hope it is readable to non-Linux people... > > Regards, > Alex. > > Moore, Robert wrote: >> No changes that I know of before 20070508. >> >> You'll need to figure out why you are getting another GPE before the >> _Lxx method completes. There was something like this on Linux with an HP >> machine, perhaps Alexey can help. >> >> As I recall, there was something nasty happening where the TZ trip >> points had to be reset before the Notify() handler completed, but this >> ended up causing another GPE, etc. etc. >> >> Bob >> >> >>> -----Original Message----- >>> From: Nate Lawson [mailto:nate@root.org] >>> Sent: Monday, January 07, 2008 10:09 AM >>> To: Moore, Robert >>> Cc: Yousif Hassan; freebsd-acpi@FreeBSD.org >>> Subject: Re: GPE handler livelock >>> >>> Bob, thanks for the reply. That's exactly what my investigation is >>> showing also. It appears we're still on 20070320 so I'm not sure why >>> this would affect us though. Perhaps a similar change was already >>> present? In any case, we should see if an import fixes this. >>> >>> Thanks, >>> Nate >>> >>> Moore, Robert wrote: >>>> This sounds suspiciously like the changes we made to the Notify() >>>> handling last year. We attempted to make the notify handler run >>>> synchronously with the caller to Notify(), but this created more >>>> problems than it solved. We ended up returning the behavior of Notify >>>> handlers to be asynchronous: >>>> >>>> >>>> >>>> 19 October 2007. Summary of changes for version 20071019: >>>> >>>> 1) ACPI CA Core Subsystem: >>>> >>>> Reverted a change to Notify handling that was introduced in version >>>> 20070508. This version changed the Notify handling from asynchronous >> to >>>> fully synchronous (Device driver Notify handling with respect to the >>>> Notify >>>> ASL operator). It was found that this change caused more problems >> than >>>> it >>>> solved and was removed by most users. >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>>>> acpi@freebsd.org] On Behalf Of Yousif Hassan >>>>> Sent: Sunday, January 06, 2008 12:18 PM >>>>> To: Nate Lawson >>>>> Cc: freebsd-acpi@FreeBSD.org >>>>> Subject: Re: GPE handler livelock >>>>> >>>>> Nate wrote: >>>>>> Thanks for digging into this. I reviewed this and am trying to >>>> figure >>>>>> out why the _L00 handler never completes. It keeps getting >> preempted >>>> by >>>>>> the next one. To help track this down, try removing these two >> lines >>>>>> from the _L00 method and recompile your ASL: >>>>>> >>>>>> Acquire (\_TZ.C173, 0xFFFF) >>>>>> ... >>>>>> Release (\_TZ.C173) >>>>>> >>>>>> For others who have this problem, instructions on how to recompile >>>> and >>>>>> load your custom ASL can be found here (11.16.4 and 5): >>>>>> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.htm >>>> l >>>>> I'm not sure if my situation is exactly what you're referring to in >>>>> this note, but since my laptop is also an HP (nx6110), and since it >>>> also >>>>> hangs during thermal zone changes, I tried your suggestion. It >> didn't >>>>> help, unfortunately. I still get mutex problems when the thermal >> zone >>>>> increases. My ASL did not have precisely the Acquire call you >> listed, >>>>> but it did have a similar one in method _L00 called >>>>> Acquire (\_TZ.C170, 0xFFFF) and Release (\_TZ.C170). Also this pair >>>>> of calls was also found in one other place (further down) in the >> ASL. >>>>> I only removed the first pair in the method you instructed. >>>>> FWIW, here are the debug error messages when the machine hangs: >>>>> >>>>> 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 >>>>> ... etc ... >>>>> >>>>> I put more info into PR 79080. >>>>> >>>>> Let me know if you want me to try anything else. >>>>> --Yousif >>>>> >>>>> _______________________________________________ >>>>> freebsd-acpi@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>>>> To unsubscribe, send any mail to >> "freebsd-acpi-unsubscribe@freebsd.org" >>> -- >>> Nate > > --------------080009060006020206020005 Content-Type: text/x-patch; name="defer_enabling_of_level_gpe.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="defer_enabling_of_level_gpe.patch" ACPI: Defer enabling of level GPE until all pending notifies done From: Alexey Starikovskiy Level GPE should not be enabled until all work caused by it is done, e.g. all Notify() methods are completed. This could be accomplished by appending enable_gpe function to the end of notify queue. Signed-off-by: Alexey Starikovskiy --- drivers/acpi/events/evgpe.c | 17 +++++++++++++---- drivers/acpi/osl.c | 42 ++++++++---------------------------------- 2 files changed, 21 insertions(+), 38 deletions(-) diff --git a/drivers/acpi/events/evgpe.c b/drivers/acpi/events/evgpe.c index e22f4a9..b4509f9 100644 --- a/drivers/acpi/events/evgpe.c +++ b/drivers/acpi/events/evgpe.c @@ -501,6 +501,7 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info * gpe_xrupt_list) * an interrupt handler. * ******************************************************************************/ +static void acpi_ev_asynch_enable_gpe(void *context); static void ACPI_SYSTEM_XFACE acpi_ev_asynch_execute_gpe_method(void *context) { @@ -576,22 +577,30 @@ static void ACPI_SYSTEM_XFACE acpi_ev_asynch_execute_gpe_method(void *context) method_node))); } } + /* Defer enabling of GPE until all notify handlers are done */ + acpi_os_execute(OSL_NOTIFY_HANDLER, acpi_ev_asynch_enable_gpe, + gpe_event_info); + return_VOID; +} - if ((local_gpe_event_info.flags & ACPI_GPE_XRUPT_TYPE_MASK) == +static void acpi_ev_asynch_enable_gpe(void *context) +{ + struct acpi_gpe_event_info *gpe_event_info = context; + acpi_status status; + if ((gpe_event_info->flags & ACPI_GPE_XRUPT_TYPE_MASK) == ACPI_GPE_LEVEL_TRIGGERED) { /* * GPE is level-triggered, we clear the GPE status bit after * handling the event. */ - status = acpi_hw_clear_gpe(&local_gpe_event_info); + status = acpi_hw_clear_gpe(gpe_event_info); if (ACPI_FAILURE(status)) { return_VOID; } } /* Enable this GPE */ - - (void)acpi_hw_write_gpe_enable_reg(&local_gpe_event_info); + (void)acpi_hw_write_gpe_enable_reg(gpe_event_info); return_VOID; } diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index aabc6ca..6816ac6 100644 --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -625,25 +625,6 @@ static void acpi_os_execute_deferred(struct work_struct *work) dpc->function(dpc->context); kfree(dpc); - /* Yield cpu to notify thread */ - cond_resched(); - - return; -} - -static void acpi_os_execute_notify(struct work_struct *work) -{ - struct acpi_os_dpc *dpc = container_of(work, struct acpi_os_dpc, work); - - if (!dpc) { - printk(KERN_ERR PREFIX "Invalid (NULL) context\n"); - return; - } - - dpc->function(dpc->context); - - kfree(dpc); - return; } @@ -667,7 +648,7 @@ acpi_status acpi_os_execute(acpi_execute_type type, { acpi_status status = AE_OK; struct acpi_os_dpc *dpc; - + struct workqueue_struct *queue; ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "Scheduling function [%p(%p)] for deferred execution.\n", function, context)); @@ -691,20 +672,13 @@ acpi_status acpi_os_execute(acpi_execute_type type, dpc->function = function; dpc->context = context; - if (type == OSL_NOTIFY_HANDLER) { - INIT_WORK(&dpc->work, acpi_os_execute_notify); - if (!queue_work(kacpi_notify_wq, &dpc->work)) { - status = AE_ERROR; - kfree(dpc); - } - } else { - INIT_WORK(&dpc->work, acpi_os_execute_deferred); - if (!queue_work(kacpid_wq, &dpc->work)) { - ACPI_DEBUG_PRINT((ACPI_DB_ERROR, - "Call to queue_work() failed.\n")); - status = AE_ERROR; - kfree(dpc); - } + INIT_WORK(&dpc->work, acpi_os_execute_deferred); + queue = (type == OSL_NOTIFY_HANDLER) ? kacpi_notify_wq : kacpid_wq; + if (!queue_work(queue, &dpc->work)) { + ACPI_DEBUG_PRINT((ACPI_DB_ERROR, + "Call to queue_work() failed.\n")); + status = AE_ERROR; + kfree(dpc); } return_ACPI_STATUS(status); } --------------080009060006020206020005-- From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 20:07:14 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81C0016A477 for ; Mon, 7 Jan 2008 20:07:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 1C93F13C455 for ; Mon, 7 Jan 2008 20:07:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 227632899-1834499 for multiple; Mon, 07 Jan 2008 15:05:30 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m07K6pQv073323; Mon, 7 Jan 2008 15:07:05 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nate Lawson Date: Mon, 7 Jan 2008 14:07:40 -0500 User-Agent: KMail/1.9.6 References: <200712311556.lBVFuVZf030567@freefall.freebsd.org> <200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> In-Reply-To: <47802510.3040203@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801071407.40473.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 07 Jan 2008 15:07:05 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5420/Mon Jan 7 09:34:42 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 20:07:14 -0000 On Saturday 05 January 2008 07:47:12 pm Nate Lawson wrote: > John Baldwin wrote: > > np. Btw, on another note, I've finally tracked down the weird hangs my laptop > > has on updated HEAD to something in the GPE handling related to updates to > > ACPI in the past year. I'm still digging, but you can look at > > www.freebsd.org/~jhb/gpe/ and use the modified schedgraph.py there on the > > ktr5.out to see what happens when my laptop stops running userland processes. > > It appears to be spending all its time running a GPE handler for a thermal > > event. > > Thanks for digging into this. I reviewed this and am trying to figure > out why the _L00 handler never completes. It keeps getting preempted by > the next one. To help track this down, try removing these two lines > from the _L00 method and recompile your ASL: > > Acquire (\_TZ.C173, 0xFFFF) > ... > Release (\_TZ.C173) > > For others who have this problem, instructions on how to recompile and > load your custom ASL can be found here (11.16.4 and 5): > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html Err, taskqueue threads run tasks synchronously, it's just running repeatedly, almost as if the GPE never turns off once it is asserted. If you grab ktr6.out and the latest schedgraph.py it adds extra handling for tracking ACPI mutexes. It gives each Mutex its own line in the display showing when it is held, contested, or idle. The mutexes are never contested, so I don't think that is the issue. When I get some more time I'm going to instrument the GPE enabling/disabling stuff. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 21:39:20 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED61116A419 for ; Mon, 7 Jan 2008 21:39:19 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id B31BE13C457 for ; Mon, 7 Jan 2008 21:39:19 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 20739 invoked from network); 7 Jan 2008 21:39:20 -0000 Received: from adsl-76-200-162-190.dsl.pltn13.sbcglobal.net (HELO ?192.168.1.84?) (nate-mail@76.200.162.190) by root.org with ESMTPA; 7 Jan 2008 21:39:20 -0000 Message-ID: <47829C03.3010802@root.org> Date: Mon, 07 Jan 2008 13:39:15 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: Alexey Starikovskiy References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> <47826AAA.6040101@root.org> <47827291.60405@suse.de> <478272C3.5080704@suse.de> In-Reply-To: <478272C3.5080704@suse.de> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, "Moore, Robert" Subject: Re: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 21:39:20 -0000 Alex, I had one question about your approach. It maintains two single-thread task queues (kacpid and kacpi_notify). It inserts each type of event on its own queue. So there is no strict ordering of handling notifies in priority to other acpi tasks unless you're assuming something about the linux task priority model. Do you have any expectation that notify tasks run before other tasks (perhaps by a special priority assigned to the kacpi_notify work queue)? In FreeBSD, we have a single task queue. However, we prioritize events in the queue in the following order (highest to lowest priority): * GPE * EC/global lock * Notify * Debugger If an event is inserted on the queue with a higher priority and a previous event has not started executing yet, this priority determines the order of insertion. Thus if GPEs keep arriving, the Notify won't be executed until they're done. Thanks, Nate Alexey Starikovskiy wrote: > Here is the patch... > Alexey Starikovskiy wrote: >> I proposed this patch some time ago, it moves _Lxx enabling to the end >> of Notify queue, thus all notifies must complete before event becomes >> enabled again. >> Hope it is readable to non-Linux people... >> >> Regards, >> Alex. >> >> Moore, Robert wrote: >>> No changes that I know of before 20070508. >>> >>> You'll need to figure out why you are getting another GPE before the >>> _Lxx method completes. There was something like this on Linux with an HP >>> machine, perhaps Alexey can help. >>> >>> As I recall, there was something nasty happening where the TZ trip >>> points had to be reset before the Notify() handler completed, but this >>> ended up causing another GPE, etc. etc. >>> >>> Bob >>> >>> >>>> -----Original Message----- >>>> From: Nate Lawson [mailto:nate@root.org] >>>> Sent: Monday, January 07, 2008 10:09 AM >>>> To: Moore, Robert >>>> Cc: Yousif Hassan; freebsd-acpi@FreeBSD.org >>>> Subject: Re: GPE handler livelock >>>> >>>> Bob, thanks for the reply. That's exactly what my investigation is >>>> showing also. It appears we're still on 20070320 so I'm not sure why >>>> this would affect us though. Perhaps a similar change was already >>>> present? In any case, we should see if an import fixes this. >>>> >>>> Thanks, >>>> Nate >>>> >>>> Moore, Robert wrote: >>>>> This sounds suspiciously like the changes we made to the Notify() >>>>> handling last year. We attempted to make the notify handler run >>>>> synchronously with the caller to Notify(), but this created more >>>>> problems than it solved. We ended up returning the behavior of Notify >>>>> handlers to be asynchronous: >>>>> >>>>> >>>>> >>>>> 19 October 2007. Summary of changes for version 20071019: >>>>> >>>>> 1) ACPI CA Core Subsystem: >>>>> >>>>> Reverted a change to Notify handling that was introduced in version >>>>> 20070508. This version changed the Notify handling from asynchronous >>> to >>>>> fully synchronous (Device driver Notify handling with respect to the >>>>> Notify >>>>> ASL operator). It was found that this change caused more problems >>> than >>>>> it >>>>> solved and was removed by most users. >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>>>>> acpi@freebsd.org] On Behalf Of Yousif Hassan >>>>>> Sent: Sunday, January 06, 2008 12:18 PM >>>>>> To: Nate Lawson >>>>>> Cc: freebsd-acpi@FreeBSD.org >>>>>> Subject: Re: GPE handler livelock >>>>>> >>>>>> Nate wrote: >>>>>>> Thanks for digging into this. I reviewed this and am trying to >>>>> figure >>>>>>> out why the _L00 handler never completes. It keeps getting >>> preempted >>>>> by >>>>>>> the next one. To help track this down, try removing these two >>> lines >>>>>>> from the _L00 method and recompile your ASL: >>>>>>> >>>>>>> Acquire (\_TZ.C173, 0xFFFF) >>>>>>> ... >>>>>>> Release (\_TZ.C173) >>>>>>> >>>>>>> For others who have this problem, instructions on how to recompile >>>>> and >>>>>>> load your custom ASL can be found here (11.16.4 and 5): >>>>>>> >>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.htm >>>>> l From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 21:57:57 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81CA416A419 for ; Mon, 7 Jan 2008 21:57:57 +0000 (UTC) (envelope-from astarikovskiy@suse.de) Received: from emea5-mh.id5.novell.com (charybdis-ext.suse.de [195.135.221.2]) by mx1.freebsd.org (Postfix) with ESMTP id AF2E613C457 for ; Mon, 7 Jan 2008 21:57:56 +0000 (UTC) (envelope-from astarikovskiy@suse.de) Received: from [192.168.101.12] ([149.44.162.75]) by emea5-mh.id5.novell.com with ESMTP; Mon, 07 Jan 2008 22:57:53 +0100 Message-ID: <4782A051.3050107@suse.de> Date: Tue, 08 Jan 2008 00:57:37 +0300 From: Alexey Starikovskiy User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Nate Lawson References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> <47826AAA.6040101@root.org> <47827291.60405@suse.de> <478272C3.5080704@suse.de> <47829C03.3010802@root.org> In-Reply-To: <47829C03.3010802@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, "Moore, Robert" Subject: Re: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 21:57:57 -0000 Nate, There are no debugger events in Linux, and all other deferred execution happens in kacpid (GPE, EC and GL included). Notify events used to be executed on this same queue until we noticed deadlocks with HP machines. All events are not prioritized in any way -- it is a simple FIFO. To avoid deadlock, we moved notify events to separate queue, but it had a drawback of enabling level GPE too early, thus I inserted a reschedule call to each completion on first queue, giving the notify queue chance to complete. Later, I was reminded that this approach is not bulletproof, so enabling of the level events was moved to notify queue as well. As it happens after all notify events for the gpe event were called, (but, probably, not executed), enabling of GPE will be deferred until these notify events have chance to complete. So, essentially, we had no priority for any event, but now notify event could preempt execution of any other event, and level GPE event does a flush of notify queue. Hope this helps, Alex. Nate Lawson wrote: > Alex, > > I had one question about your approach. It maintains two single-thread > task queues (kacpid and kacpi_notify). It inserts each type of event on > its own queue. So there is no strict ordering of handling notifies in > priority to other acpi tasks unless you're assuming something about the > linux task priority model. Do you have any expectation that notify > tasks run before other tasks (perhaps by a special priority assigned to > the kacpi_notify work queue)? > > In FreeBSD, we have a single task queue. However, we prioritize events > in the queue in the following order (highest to lowest priority): > > * GPE > * EC/global lock > * Notify > * Debugger > > If an event is inserted on the queue with a higher priority and a > previous event has not started executing yet, this priority determines > the order of insertion. Thus if GPEs keep arriving, the Notify won't be > executed until they're done. > > Thanks, > Nate > > Alexey Starikovskiy wrote: >> Here is the patch... >> Alexey Starikovskiy wrote: >>> I proposed this patch some time ago, it moves _Lxx enabling to the end >>> of Notify queue, thus all notifies must complete before event becomes >>> enabled again. >>> Hope it is readable to non-Linux people... >>> >>> Regards, >>> Alex. >>> >>> Moore, Robert wrote: >>>> No changes that I know of before 20070508. >>>> >>>> You'll need to figure out why you are getting another GPE before the >>>> _Lxx method completes. There was something like this on Linux with an HP >>>> machine, perhaps Alexey can help. >>>> >>>> As I recall, there was something nasty happening where the TZ trip >>>> points had to be reset before the Notify() handler completed, but this >>>> ended up causing another GPE, etc. etc. >>>> >>>> Bob >>>> >>>> >>>>> -----Original Message----- >>>>> From: Nate Lawson [mailto:nate@root.org] >>>>> Sent: Monday, January 07, 2008 10:09 AM >>>>> To: Moore, Robert >>>>> Cc: Yousif Hassan; freebsd-acpi@FreeBSD.org >>>>> Subject: Re: GPE handler livelock >>>>> >>>>> Bob, thanks for the reply. That's exactly what my investigation is >>>>> showing also. It appears we're still on 20070320 so I'm not sure why >>>>> this would affect us though. Perhaps a similar change was already >>>>> present? In any case, we should see if an import fixes this. >>>>> >>>>> Thanks, >>>>> Nate >>>>> >>>>> Moore, Robert wrote: >>>>>> This sounds suspiciously like the changes we made to the Notify() >>>>>> handling last year. We attempted to make the notify handler run >>>>>> synchronously with the caller to Notify(), but this created more >>>>>> problems than it solved. We ended up returning the behavior of Notify >>>>>> handlers to be asynchronous: >>>>>> >>>>>> >>>>>> >>>>>> 19 October 2007. Summary of changes for version 20071019: >>>>>> >>>>>> 1) ACPI CA Core Subsystem: >>>>>> >>>>>> Reverted a change to Notify handling that was introduced in version >>>>>> 20070508. This version changed the Notify handling from asynchronous >>>> to >>>>>> fully synchronous (Device driver Notify handling with respect to the >>>>>> Notify >>>>>> ASL operator). It was found that this change caused more problems >>>> than >>>>>> it >>>>>> solved and was removed by most users. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>>>>>> acpi@freebsd.org] On Behalf Of Yousif Hassan >>>>>>> Sent: Sunday, January 06, 2008 12:18 PM >>>>>>> To: Nate Lawson >>>>>>> Cc: freebsd-acpi@FreeBSD.org >>>>>>> Subject: Re: GPE handler livelock >>>>>>> >>>>>>> Nate wrote: >>>>>>>> Thanks for digging into this. I reviewed this and am trying to >>>>>> figure >>>>>>>> out why the _L00 handler never completes. It keeps getting >>>> preempted >>>>>> by >>>>>>>> the next one. To help track this down, try removing these two >>>> lines >>>>>>>> from the _L00 method and recompile your ASL: >>>>>>>> >>>>>>>> Acquire (\_TZ.C173, 0xFFFF) >>>>>>>> ... >>>>>>>> Release (\_TZ.C173) >>>>>>>> >>>>>>>> For others who have this problem, instructions on how to recompile >>>>>> and >>>>>>>> load your custom ASL can be found here (11.16.4 and 5): >>>>>>>> >>>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.htm >>>>>> l > From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 23:47:56 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85AD616A418 for ; Mon, 7 Jan 2008 23:47:56 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 5039413C448 for ; Mon, 7 Jan 2008 23:47:56 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 50812 invoked from network); 7 Jan 2008 23:47:57 -0000 Received: from adsl-76-200-162-190.dsl.pltn13.sbcglobal.net (HELO ?192.168.1.84?) (nate-mail@76.200.162.190) by root.org with ESMTPA; 7 Jan 2008 23:47:57 -0000 Message-ID: <4782BA24.8030703@root.org> Date: Mon, 07 Jan 2008 15:47:48 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: Alexey Starikovskiy References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> <47826AAA.6040101@root.org> <47827291.60405@suse.de> <478272C3.5080704@suse.de> <47829C03.3010802@root.org> <4782A051.3050107@suse.de> In-Reply-To: <4782A051.3050107@suse.de> X-Enigmail-Version: 0.95.5 Content-Type: multipart/mixed; boundary="------------070305010103020303040108" Cc: freebsd-acpi@FreeBSD.org, "Moore, Robert" Subject: Re: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 23:47:56 -0000 This is a multi-part message in MIME format. --------------070305010103020303040108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This makes sense. For the _L00 method in question, it runs 2 notifies before it completes. So in our queue, that would be: T1: GPE:_L00 [_LOO method runs, GPE removed] [_L00 queues 2 more Notifies] T2: Notify, Notify [_L00 completes] Right now, there is nothing in our code to synchronize _L00's completion with completion of the Notifys. In fact, _L00 finishes before the Notifys run. Also, if another GPE comes in while this GPE is running, it will be queued in front of the Notifys and so would execute first. So I think with just your evgpe.c change, we will defer re-enabling the GPE until after the queued Notifys complete since the re-enable task will be queued at the same priority. The only remaining concern I have is if another GPE comes in before one or both Notifys run, it will be inserted at the head of the queue. So as a hack, I'm setting the priority of these to be equal. Yousif, please try the attached patch and don't load a custom ASL. Thanks, Nate Alexey Starikovskiy wrote: > Nate, > > There are no debugger events in Linux, and all other deferred execution > happens > in kacpid (GPE, EC and GL included). Notify events used to be executed > on this same > queue until we noticed deadlocks with HP machines. All events are not > prioritized in > any way -- it is a simple FIFO. To avoid deadlock, we moved notify > events to separate queue, > but it had a drawback of enabling level GPE too early, thus I inserted a > reschedule call to each completion on first queue, giving the notify > queue chance to complete. > Later, I was reminded that this approach is not bulletproof, so enabling > of the level events was > moved to notify queue as well. As it happens after all notify events for > the gpe event were called, > (but, probably, not executed), enabling of GPE will be deferred until > these notify events have chance to > complete. > > So, essentially, we had no priority for any event, but now notify event > could preempt execution of > any other event, and level GPE event does a flush of notify queue. > > Hope this helps, > Alex. > > Nate Lawson wrote: >> Alex, >> >> I had one question about your approach. It maintains two single-thread >> task queues (kacpid and kacpi_notify). It inserts each type of event on >> its own queue. So there is no strict ordering of handling notifies in >> priority to other acpi tasks unless you're assuming something about the >> linux task priority model. Do you have any expectation that notify >> tasks run before other tasks (perhaps by a special priority assigned to >> the kacpi_notify work queue)? >> >> In FreeBSD, we have a single task queue. However, we prioritize events >> in the queue in the following order (highest to lowest priority): >> >> * GPE >> * EC/global lock >> * Notify >> * Debugger >> >> If an event is inserted on the queue with a higher priority and a >> previous event has not started executing yet, this priority determines >> the order of insertion. Thus if GPEs keep arriving, the Notify won't be >> executed until they're done. >> >> Thanks, >> Nate >> >> Alexey Starikovskiy wrote: >>> Here is the patch... >>> Alexey Starikovskiy wrote: >>>> I proposed this patch some time ago, it moves _Lxx enabling to the end >>>> of Notify queue, thus all notifies must complete before event becomes >>>> enabled again. >>>> Hope it is readable to non-Linux people... >>>> >>>> Regards, >>>> Alex. >>>> >>>> Moore, Robert wrote: >>>>> No changes that I know of before 20070508. >>>>> >>>>> You'll need to figure out why you are getting another GPE before the >>>>> _Lxx method completes. There was something like this on Linux with >>>>> an HP >>>>> machine, perhaps Alexey can help. >>>>> >>>>> As I recall, there was something nasty happening where the TZ trip >>>>> points had to be reset before the Notify() handler completed, but this >>>>> ended up causing another GPE, etc. etc. >>>>> >>>>> Bob >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Nate Lawson [mailto:nate@root.org] >>>>>> Sent: Monday, January 07, 2008 10:09 AM >>>>>> To: Moore, Robert >>>>>> Cc: Yousif Hassan; freebsd-acpi@FreeBSD.org >>>>>> Subject: Re: GPE handler livelock >>>>>> >>>>>> Bob, thanks for the reply. That's exactly what my investigation is >>>>>> showing also. It appears we're still on 20070320 so I'm not sure why >>>>>> this would affect us though. Perhaps a similar change was already >>>>>> present? In any case, we should see if an import fixes this. >>>>>> >>>>>> Thanks, >>>>>> Nate >>>>>> >>>>>> Moore, Robert wrote: >>>>>>> This sounds suspiciously like the changes we made to the Notify() >>>>>>> handling last year. We attempted to make the notify handler run >>>>>>> synchronously with the caller to Notify(), but this created more >>>>>>> problems than it solved. We ended up returning the behavior of >>>>>>> Notify >>>>>>> handlers to be asynchronous: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 19 October 2007. Summary of changes for version 20071019: >>>>>>> >>>>>>> 1) ACPI CA Core Subsystem: >>>>>>> >>>>>>> Reverted a change to Notify handling that was introduced in version >>>>>>> 20070508. This version changed the Notify handling from asynchronous >>>>> to >>>>>>> fully synchronous (Device driver Notify handling with respect to the >>>>>>> Notify >>>>>>> ASL operator). It was found that this change caused more problems >>>>> than >>>>>>> it >>>>>>> solved and was removed by most users. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>>>>>>> acpi@freebsd.org] On Behalf Of Yousif Hassan >>>>>>>> Sent: Sunday, January 06, 2008 12:18 PM >>>>>>>> To: Nate Lawson >>>>>>>> Cc: freebsd-acpi@FreeBSD.org >>>>>>>> Subject: Re: GPE handler livelock >>>>>>>> >>>>>>>> Nate wrote: >>>>>>>>> Thanks for digging into this. I reviewed this and am trying to >>>>>>> figure >>>>>>>>> out why the _L00 handler never completes. It keeps getting >>>>> preempted >>>>>>> by >>>>>>>>> the next one. To help track this down, try removing these two >>>>> lines >>>>>>>>> from the _L00 method and recompile your ASL: >>>>>>>>> >>>>>>>>> Acquire (\_TZ.C173, 0xFFFF) >>>>>>>>> ... >>>>>>>>> Release (\_TZ.C173) >>>>>>>>> >>>>>>>>> For others who have this problem, instructions on how to recompile >>>>>>> and >>>>>>>>> load your custom ASL can be found here (11.16.4 and 5): >>>>>>>>> >>>>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.htm >>>>> >>>>>>> l >> --------------070305010103020303040108 Content-Type: text/x-patch; name="defer_gpe1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="defer_gpe1.diff" Index: sys/dev/acpica/Osd/OsdSchedule.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/Osd/OsdSchedule.c,v retrieving revision 1.39 diff -u -r1.39 OsdSchedule.c --- sys/dev/acpica/Osd/OsdSchedule.c 22 Mar 2007 18:16:41 -0000 1.39 +++ sys/dev/acpica/Osd/OsdSchedule.c 7 Jan 2008 23:46:47 -0000 @@ -114,7 +114,7 @@ pri = 5; break; case OSL_NOTIFY_HANDLER: - pri = 3; + pri = 10; // XXX testing break; case OSL_DEBUGGER_THREAD: pri = 0; Index: sys/contrib/dev/acpica/evgpe.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/dev/acpica/evgpe.c,v retrieving revision 1.1.1.12 diff -u -r1.1.1.12 evgpe.c --- sys/contrib/dev/acpica/evgpe.c 22 Mar 2007 17:23:30 -0000 1.1.1.12 +++ sys/contrib/dev/acpica/evgpe.c 7 Jan 2008 21:17:28 -0000 @@ -123,6 +123,10 @@ /* Local prototypes */ +static void +AcpiEvAsynchEnableGpe ( + void *Context); + static void ACPI_SYSTEM_XFACE AcpiEvAsynchExecuteGpeMethod ( void *Context); @@ -684,14 +688,26 @@ } } - if ((LocalGpeEventInfo.Flags & ACPI_GPE_XRUPT_TYPE_MASK) == + /* Defer enabling of GPE until all notify handlers are done */ + AcpiOsExecute(OSL_NOTIFY_HANDLER, AcpiEvAsynchEnableGpe, GpeEventInfo); + return_VOID; +} + +static void +AcpiEvAsynchEnableGpe ( + void *Context) +{ + ACPI_GPE_EVENT_INFO *GpeEventInfo = (void *) Context; + ACPI_STATUS Status; + + if ((GpeEventInfo->Flags & ACPI_GPE_XRUPT_TYPE_MASK) == ACPI_GPE_LEVEL_TRIGGERED) { /* * GPE is level-triggered, we clear the GPE status bit after * handling the event. */ - Status = AcpiHwClearGpe (&LocalGpeEventInfo); + Status = AcpiHwClearGpe (GpeEventInfo); if (ACPI_FAILURE (Status)) { return_VOID; @@ -700,7 +716,7 @@ /* Enable this GPE */ - (void) AcpiHwWriteGpeEnableReg (&LocalGpeEventInfo); + (void) AcpiHwWriteGpeEnableReg (GpeEventInfo); return_VOID; } --------------070305010103020303040108-- From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 8 03:21:36 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19D4F16A41B for ; Tue, 8 Jan 2008 03:21:36 +0000 (UTC) (envelope-from stephenbh@hotmail.com) Received: from bay0-omc2-s40.bay0.hotmail.com (bay0-omc2-s40.bay0.hotmail.com [65.54.246.176]) by mx1.freebsd.org (Postfix) with ESMTP id 075A813C465 for ; Tue, 8 Jan 2008 03:21:35 +0000 (UTC) (envelope-from stephenbh@hotmail.com) Received: from BAY106-W8 ([65.54.161.108]) by bay0-omc2-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jan 2008 19:09:36 -0800 Message-ID: X-Originating-IP: [203.206.139.6] From: Stephen Butler To: Date: Tue, 8 Jan 2008 03:09:36 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jan 2008 03:09:36.0119 (UTC) FILETIME=[E60D0070:01C851A3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: First Step to fixing ACPI problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 03:21:36 -0000 Hello everyone, =20 I have installed freebsd 6.2 onto a 2002 model acer travelmate 250. =20 And have the following problem, =20 When booting the laptop If I dont disable ACPI mode then it freezes and can= only be shutdown by holding the power button in for about 6 seconds. =20 Disabling acpi in /boot/loader.conf takes care of the problem. =20 However this leaves me guessing when the battery is going to die and I loos= e some work. =20 Please let me know what info I need to post so I can get the ball rolling o= n this problem =20 kind Regards, Steve. _________________________________________________________________ Overpaid or Underpaid? Check our comprehensive Salary Centre http://a.ninemsn.com.au/b.aspx?URL=3Dhttp%3A%2F%2Fcontent%2Emycareer%2Ecom%= 2Eau%2Fsalary%2Dcentre%3Fs%5Fcid%3D595810&_t=3D766724125&_r=3DHotmail_Email= _Tagline_MyCareer_Oct07&_m=3DEXT= From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 8 10:09:36 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 080DA16A420 for ; Tue, 8 Jan 2008 10:09:36 +0000 (UTC) (envelope-from candyshop999@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.250]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9FC13C461 for ; Tue, 8 Jan 2008 10:09:35 +0000 (UTC) (envelope-from candyshop999@gmail.com) Received: by hs-out-2122.google.com with SMTP id h53so373193hsh.11 for ; Tue, 08 Jan 2008 02:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=18Vp4O5oP6uMbPye7zhiJuF3MlVX5XdSuNr/5SrAKvM=; b=X9cZt2vqfMV5KeQOcsjoxsYTqWkZ/dzddvRAGjTP6Y+jb17+OrEALYhLY0EBlMNxb3V9iog+32aV9eXHL1wnj+0RHG5ImyALJpcd7nbzvs2Ddik98MpYWVdESlJHoKnn0DmwGfXU9R4cMWdJ9O86PTYOjnjf3n5dduh2flLzVFY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=RMPxr6n3Y1W5WgN0PC4e/XQ9LkBvsMA9kGDxzGoj2dHxpWLkMf6XuCw0ie0nk3Aup86EMOyhFBtiwHU3lxRhIAX9RwEfpNAzRvABHUyfaTE02MyPzMOmbHg7KatjTXuYwkLbcQHqnSPYs9N93NnJMhWBtDr5fNXPeomODyR/UBY= Received: by 10.151.83.12 with SMTP id k12mr315951ybl.7.1199785380467; Tue, 08 Jan 2008 01:43:00 -0800 (PST) Received: by 10.150.156.8 with HTTP; Tue, 8 Jan 2008 01:43:00 -0800 (PST) Message-ID: Date: Tue, 8 Jan 2008 11:43:00 +0200 From: "Super Star" To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Liberty League International, Easy Marketing Methods with Letters, Post Cards, Referrals and Testimonials X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 10:09:36 -0000 Liberty League International, Easy Marketing Methods with Letters, Post Cards, Referrals and Testimonials Easy Direct Marketing Methods for Insurance Agencies This Month: Strategies for Letters, Post Cards, Newsletters, Testimonials, Referrals. Selling insurance is tough: too many agents selling too few clients, and ouch - trying to show value when all you are selling is a piece of paper that no one really thinks he needs... until it's too late. But you knew all that. Here's how to get more business and keep the customers you have. Send a "Thank you for your business" letter. I'll bet you ten bucks that I know the last piece of correspondence your customer received from you or your providers: it was a bill. Right? OK - 99 out of 100 of you pay up. Break this cycle of insurance bills with somethin= g refreshing. Send a bottle of champagne. Just kidding. Send that bottle to me, Schramsberg/NAPA is just fine. To your clients and prospects, send a couple of refreshing "Thank you" letters. Spend the 74=A2 To keep customers happier and longer, twice a year send them a letter simpl= y thanking them for being a customer. Let them know their business is appreciated. Paint a picture of your firm on high alert 24 hours a day: if they need you - you'll be there. Let them know you appreciate their busines= s and that you are eagerly waiting to serve them. Your customer retention rat= e will soar. Your customers will be happier; therefore, your customers will b= e your customers, longer. As for me, I'm still waiting for that bottle of Schramsberg. Now I'm not talking about the pre-printed "Thank You" card you get from you= r accountant each Christmas. Ugh. That's close to worthless (don't tell your accountant, I'll start getting nasty letters). I'm talking about a real, bonafide letter. Signed personally by you, or at least someone who works with you who is willing to sign all those letters with your name in a blue pen. Yes - twice a year. Cough it up: postage 74=A2. That's not much of a c= ost to retain a customer. Do you know what other agencies call your best customers? Prospects. I personally think a letter is the cheapest customer retention strategy you can use, and the most effective. Hummmm... cheapest; most effective. See, nice guy that I am, I started off this article with my best tip first. It's all downhill from here. Or is it? Don't start a Newsletter. That's right, don't. You've got to be crazy to start a newsletter. 90% of the ones I get are terrible: no direction, poor copy, lousy photos... everyone's dressed. Nothing like that Hooter's newsletter I, er, a friend o= f mine signed up for 2 years ago. What? What do you mean you don't think there's continually fresh and interesting news from a restaurant chain? Most newsletters are written with no clear objectives, and some just ramble on in a dialog "about" and "by" the president... like someone cared about his babble on the new boat he just bought. In reality - where I virtually think we are - newsletters are just a lot of work. They may start out with some enthusiasm, but soon become the drudgery of month after month of hard work, eventually assigned to someone as a thankless job no one really wants to do. Without lively copy, great design, consistent frequency and timely delivery, newsletters lose all effect of branding and building customer loyalty. Case in point: Q. The number one priority of a newsletter? A. It must be read. To be read it must be fascinating and interesting beyond belief. Remember, if it ain't read, it ain't working. See my article on newsletters elsewhere on this site. Or visit www.dobkin.com for this and other articles of marketing tips I've written. Instead, create a series of post cards. That's right, slightly oversized 5-1/2" x 8-1/2" post cards print nicely 2-out of an 8-1/2" x 11" sheet. Spend some time on graphics and copy to mak= e them really interesting and clever. Since I just mentioned "newsletter," I know some readers are now hell-bent on creating a newsletter, so you guys can title your post card "The World's Tiniest Newsletter." Then design it like a tiny newsletter. Well, I hope that made your day. Still stuck on newsletters? Call this number and complain: 610-642-683. If I really cared, I'd have given you the last number, which is 2. It's our fax machine. Or at least the fax machine of our competitor. Post cards can look good printed simply in one or two colors... so they can be inexpensive to print. While I don't mind one color printing, I do always prefer an upscale sheet of paper (like bright-white Cambric Linen). Don't use glossy stock unless your post card is printed in 4 colors, as the post office mail sorting rollers will leave black marks on it. Mail post cards once a month to every 6 weeks for consistency, or to maintain Top-of-Mind awareness. Write about anything... as long as it's interesting. The limitations of space ensure the brevity of copy; this generally will make sure the card remains interesting to a good degree. Somewhere, somehow on the card, say "Call for a quick quote!" to encourage people to call. If the objective of the card is to generate a call and it doesn't, it didn't work, did it?. Supersize the phone number and follow it by a longish laundry list of all the types of insurance your firm offers (o= r that you can get for your customers). If it's a long list - and it should b= e - set the list in small type - and print it on the lower portion of the bottom of the card. Here's an example: Since you live in Nebraska, boat insurance probably isn'= t your main livelihood, or flood insurance either, so most of your customers probably don't know you can get these kinds of coverage for them along with their tractor insurance. By listing all the kinds of insurance policies you sell on this card, all your customers who own boats (both of them) will get the message that they can call you for a quote. Other customers and prospects will see what they need also - and call for quotes, too. The list of services is not the main message in the card, but it lets clients know that you offer a full depth of different products, and they ca= n get all their insurance quoted and placed by a quick phone call to your office. Remember, if you don't get calls from your post cards, and thus additional business - they didn't work. Then let me guess: Your mailings went into your "we tried direct mail and it didn't work" file. How unfortunate. Know who's getting those phone calls if you're not? Your competitors. Their post cards went into their "Holy Cow! Look how much mone= y we made from this little post card mailing!" file. Why are phone calls so important?All your business starts with a phone call= . Any time you can make the phone ring - especially for a quote, you have the opportunity to generate a sale, or perform a service for your customer. Either way, if you look at this more closely as an opportunity, you'll find a phone conversation is a great way to increase a client's loyalty and endear them even more deeply to you and your company. If you can get the phone to ring from a mailed piece, the piece is a total success, even if you didn't get any business at that exact moment. Here's why I say this: I've been in direct marketing for... OH MY GOD AM I THAT OL= D ALREADY!. Anyhow, it's tough to sell something from a sheet of paper, especially insurance, which is sometimes tough to sell anywhere, even in a stuck elevator for 12 hours with 6 doctors whose medical malpractice policies have an ex-date of tomorrow. Come to think of it, if you want a business decision from a doctor you'll have to ask his office manager or hi= s wife. Either way, a "yes" answer will take a month. By trying to sell something directly from a sheet of paper, you get no feedback, no buying signals. You can't tell where the hot buttons of your clients are. When do you back off? When do you press for a close? All this may come subconsciously when you're selling in person, but I assure you a lot of thought has to go into a printed piece to get to these specific area= s with just the right timing, correct pace and selling proposition to close a sale from a flyer that you sent in the mail. Armed with the knowledge that it's very difficult to sell anything off the page, don't even think about trying to sell anything from your mail piece. The objective of 99% of the letters, mailers, post cards and brochures I create for clients don't sell anything -- the objective is simply to generate a phone call. My client is the one that does all of the selling. With your brochure, you do the selling when they call. Face the further fact: create letters and mailers with the sole objective o= f making the phone ring. When the phone rings - the piece worked. Voila. Now we know it was successful. Then you sell the client. For an article I've written on post cards, just drop me a letter requesting it: Jeff Dobkin, P.O. Box 100, Merion Station, PA 19066. No, an email won't work. I'd like to make sure you really want it and an email won't show me this - I don't want to get 5,000 emails requesting stuff like the last time I offered something free on the Internet. Ugh. OK, let's get back to more tips about your post card mailings. Sending post cards every four to six weeks keeps your agency in "Top of Mind" awareness of your clients. When they need new policies, or a quote... when they have friends that need insurance services -- they'll think of you. Whoa. When they have friends??? Can you say "referrals?" Referrals and Testimonials I don't know about you, but I hate asking people for referrals. So here's a way to get them, and how to use testimonials in your marketing. It's even tough for me to write a personal letter asking for a referral without sounding like a bleeding heart solicitation piece I once wrote for the "Friends of Kaballah" association who needed money for guns, but... a post card can serve this function just right. www.libertyleagueinternational.info www.libertyleagueconference.com www.beyondfreedom.com From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 8 10:14:44 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAD1B16A41A for ; Tue, 8 Jan 2008 10:14:44 +0000 (UTC) (envelope-from candyshop999@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.243]) by mx1.freebsd.org (Postfix) with ESMTP id 90EB013C447 for ; Tue, 8 Jan 2008 10:14:44 +0000 (UTC) (envelope-from candyshop999@gmail.com) Received: by hs-out-2122.google.com with SMTP id h53so374402hsh.11 for ; Tue, 08 Jan 2008 02:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=8XxHq0OL4YDdermm7iFkVTMrLVjdd3bMi485L8zLRG4=; b=WJk9Vr+AHH9g8FR3GS5QKhJBwKK155Y++aHUdft72D5z1elBN+kj7jsVVswWaI4bLJ8ZlBnte3bpDqo6mhsRJJjcL+ajSAl6STxsw5h2/cqo1QTynRVEVNtLBBzq5psQ7uIy/PVTr+MHiEAh1H68w4PzCs5WGnso0DF3ja4XLQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=T2VMOOSCN/lhQWALonpB/31KorKWRDhdD9Yuoivv43qOs3Y+xznzQZjLEa9duGBVdioOojFS9+0zr1pdlhChm2HDKE4Mx8L2s2nhtMkgy/JuAXKOsBgpRzMeu3vOPDDdpbBXOt+CxpMe/wwfmpmWNhr5T08Lez2uSVZo5iA9r80= Received: by 10.150.216.8 with SMTP id o8mr3039523ybg.68.1199787284275; Tue, 08 Jan 2008 02:14:44 -0800 (PST) Received: by 10.150.156.8 with HTTP; Tue, 8 Jan 2008 02:14:44 -0800 (PST) Message-ID: Date: Tue, 8 Jan 2008 12:14:44 +0200 From: "Super Star" To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Five Point Capital, Fitness Equipments You Need For Your Own Home Gym X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 10:14:44 -0000 Five Point Capital, Fitness Equipments You Need For Your Own Home Gym Do you dream of having that perfect well-toned body, but you don't have the time or motivation to go to the nearest fitness center? If that's the case, why not consider buying some fitness equipments and converting your house into a gym? Setting up a gym at your own home is easy to accomplish. No need to buy every fitness equipment you can get your hands on, as you'll spend more than it's necessary and you won't have space at home for all those fitness equipments. The first thing you should do is find out what fitness equipments you need for your personal gym. Here are some fitness equipment suggestions to get you started: - Dumbbell set: most come in 5 lbs, 8 lbs, and 12 lbs weight size. Make sure to pick a pair that has rubber handle grip. A good quality dumbbell should be inexpensive, should not roll away when placed down on the floor and should come with its own rack. - Barbell set: this set often comes included with the dumbbells and also comes in different weight levels. Barbells are a good addition to dumbbells because as you get stronger from lifting dumbbells you want to progress on to lifting the heavier barbells to give your body a different workout. Barbells work various parts of your body such as the upper- and the mid-sections. Barbells can also increase your body stamina. - Steps: steps are available in different height levels. They provide good aerobics and muscle-strengthening workout. - Exercise balls. they help improve your balance and you body core strength. Exercise balls are widely used for abdominal workouts. For intermediate users the exercise ball can be used together with a weight bench to workout the stabilizer muscles while doing bench presses. Exercise balls can also be used for pushups, back extensions and lower body exercises. - Weight lifting glove set: it helps protect your hands during weight training. It helps prevent swollen hands and rough calluses. A solid pair of weight lifting gloves is made from fabric that is comfortable and also allows sweat from the hand to evaporate so that the weights are less likely to slip out of your hands while weight training. - Ankle weights: they are considered one of the cheaper fitness equipment. Ankle weights are commonly used for body toning and muscular endurance training so as to prevent muscle injury in the lower region. - Exercise mat: it can be used for floor workouts. Try not to workout on your house carpet in case you slip and injure yourself. Make sure that you select a no-slip mat. Having a gym with these fitness equipments in your house is much more economical and you'll now have all the time in the world for workout activities. For a more comprehensive look at Fitness Equipments, visit Susan's site at and . Susan also enjoys writing on a wide range of topics at . From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 8 12:40:34 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B589C16A468 for ; Tue, 8 Jan 2008 12:40:34 +0000 (UTC) (envelope-from candyshop999@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8905513C44B for ; Tue, 8 Jan 2008 12:40:34 +0000 (UTC) (envelope-from candyshop999@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so2700430wxd.7 for ; Tue, 08 Jan 2008 04:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=JuUG7m+hdG8xbx675Iacv2pcKly0Cx2Uc3KpkEYCN+k=; b=rhfpt066U0sIruYVh5kp65zMsbv8SSN1+bUY5M0NYBCxc4+b3b8+lRgMkqxHvE1RoxCL3vLAWR1+Z40XCo4LcvQRETz46QvAeAOHpJY96ot9Ut4mjOD71ssz8MgXQ25G+5dL3xHfC3n4DOkaOk3yJJNVKvFMW02Irbjp/cOddro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=kZvmdRQeNvL6cLnHR4RPl7Z58RVtrWU5XKJBL4PJ2mS8DQSyzRrOOI1E9UMiHGhrNsMGOhoq2sQrYFj68p/2LFLAH6mtT2mzAGroZiKg0zM6Nj3BWEEEHsXdu7XSkIADG7ZtYMqizlHNqueRQfYfAz73T94NyL+iXrWz0mrC9xE= Received: by 10.150.218.10 with SMTP id q10mr5903795ybg.50.1199796033167; Tue, 08 Jan 2008 04:40:33 -0800 (PST) Received: by 10.150.156.8 with HTTP; Tue, 8 Jan 2008 04:40:33 -0800 (PST) Message-ID: Date: Tue, 8 Jan 2008 14:40:33 +0200 From: "Super Star" To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: =?windows-1252?q?Wendy_Stevens_Nashville=2C_Differentiation_=96_?= =?windows-1252?q?Smart_Marketing_Strategies_for_the_Solo_Entrepren?= =?windows-1252?q?eur?= X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 12:40:34 -0000 Wendy Stevens Nashville Tennesee, Differentiation =96 Smart Marketing Strategies for the Solo Entrepreneur Wendy Stevens Franklin Tennesee Are you ever frustrated or hesitant when you talk to prospective customers because you can't readily explain why they should come to you rather than g= o to your competitors? Sure, you might have your 30-second elevator speech, but then they ask you that dreaded question, "So what makes you different?" Then, all those self-doubts creep in, and you just aren't sure what to say. Differentiation can boost confidence--yours in yourself and that prospectiv= e customer's confidence in you! -- *Dif-fer-en-ti-ate* v. tr. To perceive or show the difference in or between; discriminate. -- In business terms, to differentiate means to create a benefit that customer= s perceive as being of greater value to them than what they can get elsewhere= . It's not enough for you to be different--a potential customer has to take note of the difference and must feel that the difference somehow fits their need better. (Other words that mean virtually the same thing: Competitive Advantage; Unique Selling Proposition; or Value Proposition.) As you are building your business, you can use differentiation to attract more customers. Once you have momentum, differentiation allows you to charg= e a higher price because you are delivering more value to your customers. Mak= e a point to evaluate and adjust your differentiation methods at least annually. The various methods of differentiating your businesses fall into four general categories: *Price Differentiation * *Focus Differentiation * *Product/Service Differentiation * *Customer Service Differentiation* * Price Differentiation* Differentiating on price is probably the most common and easily understood method. HOWEVER, for Solo Entrepreneurs, caution is in order. On the one hand, potential customers might expect a lower price from you than from you= r larger competition because they perceive you as having less overhead, etc. On the other hand, cheaper prices can evoke perceptions of lower quality, a less-stable business, etc. And if you compete on price against competitors with deeper pockets, you can price yourself right into bankruptcy. Be creative with this differentiator by competing on something other than straight price. For example, you might offer: - *More value*--offer more products or services for the same price. - *Freebies* --accessories, companion products, free upgrades, and coupons for future purchases. - *Free shipping*, etc.--convenience sells, especially when it is free! - *Discounts*--includes offering regular sales, coupons, etc. (see cautions above) *Focus Differentiation* For Solo Entrepreneurs, this is the most important method of differentiation, and in many ways, the easiest. Why? Because as a Solo Entrepreneur, you simply can't be everything to everybody, so you must pick a specific way to focus your business. Once you have done that, you have an automatic advantage over larger companies because you can become more of an expert in that one field --and you can build close relationships with key customers that will be hard to duplicate. For example, you might differentiate yourself through: - *Location*--take advantage your closeness to prospective customers. - *Customer specialization*--be very specific about what characteristics your customers will have=97for example, racing bicycle enthusiasts or companies with a spiritual conscience. - *Customer relationships*--know customers really well, form partnerships with them, and get them to speak for you! - *Affinity relationships*--associate your product/service with a well-know= n person or organization. - *One-stop shopping*--offer everything your target market needs, in your area of expertise. - *Wide selection* (within your niche)=97although this one may seem to be t= he opposite of focus--the key is to be very specific in one dimension and very broad in another. *Product/Service Offering Differentiation* How much you are able to differentiate your product or service offering wil= l vary based on what type of business you are in. For instance, if you are in a highly regulated business, your options may be limited. Explore a totally new market or type of product or service, however, and the possibilities abound. The key to successful differentiation in this category, again, is t= o know your customers, really, really well. Talk to them often, and you will know what they need most and be able to offer it, long before your competitors know what is happening. For example, your product or service could stand out in one of these ways: - *Quality*--create a product or service that is exceptional in one or more ways. Examples: Lasts longer - *Better* - *Easier to use* - *Safer* - *New/First*--be the first one to offer something in your location/field. - *Features/Options*--offer lots of choices, unusual combinations, or solve a problem for a customer in a way no one else does. - *Customization*--as a Solo Entrepreneur, you may be able to more easily handle special orders than big, mass-market competitors. *Customer Service Differentiation* Have you noticed how customer service seems to be out of vogue these days? This situation makes excellent customer service a great opportunity for differentiation and another natural advantage for Solo Entrepreneurs that already know what's important to their customers. Build your reputation on making customers feel really good about doing business with you. Works grea= t with referral marketing, too. Examples: - *Deliver fast*--next day, or one-hour--make it faster than customers thin= k possible. - *Unique channel*--offer a service over the phone or Internet instead of i= n person or in their office rather than yours. - *Service-delight customers!*--it may seem expensive to offer exceptional service--but it pays off in word-of-mouth advertising. - *Before/during/after-sales support*--provide technical or other support t= o customers using your product. You might use joint ventures to provide that support--but customers will perceive it as being from you! - *Guarantee/warranty*--offer 100% money-back, or free replacement parts. - *YOU*--offer yourself, your unique blend of talents and skills, to attrac= t customers. Make sure they get access to you, too! *Keys to Successful Differentiation:* - Know your customers, really, really well. - Pick a blend of differentiation methods that, in the eyes of your customers, truly sets you apart. - Talk about your differentiation in terms of customer benefits. - Tell everyone about what differentiates you--often. - Keep your differentiation fresh by listening for changing customer needs. Copyright 2002-2003, Terri Zwierzynski, Accel Innovation, Inc. _________ Terri Zwierzynski is a coach to small business owners and Solo Entrepreneurs. She is also the CEI (Conductor of Extraordinary Ideas) at Solo-E.com and the author of 136 Ways To Market Your Small Business. Terri is an MBA honors graduate from UNC-Chapel Hill. Terri has been coaching for over 10 years in a variety of settings, including 6 years as a senior-level coach and consultant for a Fortune 500 company. She opened her private coaching practice in 2001. You can reach Terri at http://www.TerriZ.com. _________ ***** Find more articles like this at http://www.Solo-E.com=96 Keeping Solo Entrepreneurs Juiced in Business and in Life. Our team of Solo Entrepreneurs are comprised of small business experts who support others in finding business success with the flexibility and freedom to have a life, too. Network with other freelancers, self-employed and Solo Entrepreneurs in our forums, enjoy our articles and newsletter, and find other online training opportunities. ***** From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 8 14:21:26 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4115416A41A for ; Tue, 8 Jan 2008 14:21:26 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: from coruscant.far-far-away.us (coruscant.far-far-away.us [70.91.196.65]) by mx1.freebsd.org (Postfix) with SMTP id F249813C457 for ; Tue, 8 Jan 2008 14:21:25 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: (qmail 39197 invoked from network); 8 Jan 2008 09:15:20 -0500 Received: from pknat1.passkey.com (HELO ?192.168.16.179?) (68.162.198.134) by coruscant.far-far-away.us with SMTP; 8 Jan 2008 09:15:20 -0500 From: Yousif Hassan To: Stephen Butler In-Reply-To: References: Content-Type: text/plain Date: Tue, 08 Jan 2008 09:21:25 -0500 Message-Id: <1199802085.1815.11.camel@alderaan.far-far-away.us> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: First Step to fixing ACPI problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 14:21:26 -0000 Have you checked out Chapter 11.6 of the FreeBSD handbook? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html --Y On Tue, 2008-01-08 at 03:09 +0000, Stephen Butler wrote: > Hello everyone, > > I have installed freebsd 6.2 onto a 2002 model acer travelmate 250. > > And have the following problem, > > When booting the laptop If I dont disable ACPI mode then it freezes and can only be shutdown by holding the power button in for about 6 seconds. > > Disabling acpi in /boot/loader.conf takes care of the problem. > > However this leaves me guessing when the battery is going to die and I loose some work. > > Please let me know what info I need to post so I can get the ball rolling on this problem > > kind Regards, > Steve. > _________________________________________________________________ > Overpaid or Underpaid? Check our comprehensive Salary Centre > http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fcontent%2Emycareer%2Ecom%2Eau%2Fsalary%2Dcentre%3Fs%5Fcid%3D595810&_t=766724125&_r=Hotmail_Email_Tagline_MyCareer_Oct07&_m=EXT_______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 8 17:23:44 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B6B716A41A for ; Tue, 8 Jan 2008 17:23:44 +0000 (UTC) (envelope-from vader@lavabit.com) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 5374113C4E5 for ; Tue, 8 Jan 2008 17:23:44 +0000 (UTC) (envelope-from vader@lavabit.com) Received: from julie.lavabit.com (unknown [192.168.111.2]) by karen.lavabit.com (Postfix) with ESMTP id E39EBC8425 for ; Tue, 8 Jan 2008 11:23:44 -0600 (CST) Received: from 127.0.0.1 (230.133.132.202.dynamic.ttn.net [202.132.133.230]) by lavabit.com with ESMTP id VE2HWQXR8MW5 for ; Tue, 08 Jan 2008 11:23:43 -0600 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=L8y5iDEq0VMyAUMDHoR8U0mGUJ1jgS8tOGyuuzz6hynP3BA3GijJVbqHS5CMzA9NFfhbP2OMJIjK6BSWu0lwR86UK3HtXVC99+xsDMHvM8JDcwJuDUp6tEdKyOWu/MWb3oMFkYI/bYuz0B5EL14SzF/xYJIMwGDULMUdP0DsZBs=; h=Date:From:To:Subject:Reply-To:Sender:Disposition-Notification-To:X-Confirm-Reading-To:Message-Id:MIME-Version:X-Priority:X-MSMail-Priority:Content-Type:Content-Transfer-Encoding:X-Mailer; Date: Wed, 09 Jan 2008 01:23:43 +0800 From: To: freebsd-acpi@FreeBSD.org Sender: Message-Id: <20080109012326.72F1.A838D848@lavabit.com> MIME-Version: 1.0 X-Priority: 1 X-MSMail-Priority: High Content-Type: text/plain; charset="BIG5" Content-Transfer-Encoding: 8bit X-Mailer: Becky! ver. 2.44 [tw] X-Mailman-Approved-At: Tue, 08 Jan 2008 09:27:20 -0800 Cc: Subject: ACPI problem on EPOX MVP3C2 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vader@lavabit.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 17:23:44 -0000 Hi! First of all, apology for my poor English. I have a EPOX MVP3C2 mainboard, running FreeBSD 7.0 ( in fact, I will use it for Freenas) , while enabling ACPI, there're some troubles: 1. the NICs, 3C905C-TXM or RTL8139 / RTL8169, won't work, always get the "watchdog timeout" responding,. 2. the floppy disc (FD0) will be gone, too. 3. Maybe there're other problems, but I only notice 2 as above for now. Other suspicious problems suppose to be listed on below records. Here're the info I follow your instruction to record 1. dmesg with ACPI enable http://vader.hopto.org/freenas/acpi/acpiondmesg.txt devices in /DEV/ (FD0 is gone) http://vader.hopto.org/freenas/acpi/acpiondev.txt 2. dmesg with ACPI disable http://vader.hopto.org/freenas/acpi/acpioffdmesg.txt devices in /DEV/ (no ACPI, but FD0 is back) http://vader.hopto.org/freenas/acpi/acpioffdev.txt 3. output from sysctl hw.acpi http://vader.hopto.org/freenas/acpi/hw-acpi.txt 4.ACPI Source Language dump http://vader.hopto.org/freenas/acpi/root-mvp3c2.asl and the other ACPI dump under DOS, hope would be useful http://vader.hopto.org/freenas/acpi/dosacpidump.txt I can disable ACPI, then everything will be smooth, however, the system won't be shutdown totally by the shutdown command or ACPI button, I must turn on monitor to confirm shutdown procedure being completed, then turn off the power switch. Please help me, If need any additional info, please tell me, Thanks! A BSD newbie. From owner-freebsd-acpi@FreeBSD.ORG Wed Jan 9 12:39:43 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D9DF16A418; Wed, 9 Jan 2008 12:39:43 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 611A613C4E1; Wed, 9 Jan 2008 12:39:43 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m09Cdhgt031868; Wed, 9 Jan 2008 12:39:43 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m09CdhNW031864; Wed, 9 Jan 2008 12:39:43 GMT (envelope-from linimon) Date: Wed, 9 Jan 2008 12:39:43 GMT Message-Id: <200801091239.m09CdhNW031864@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-acpi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: i386/119485: 6.3 RC2 boot only CD hangs in dell d830 - 'ACPI autoload failed' X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 12:39:43 -0000 Synopsis: 6.3 RC2 boot only CD hangs in dell d830 - 'ACPI autoload failed' Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 9 12:39:15 UTC 2008 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=119485 From owner-freebsd-acpi@FreeBSD.ORG Wed Jan 9 17:16:38 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D401516A41B; Wed, 9 Jan 2008 17:16:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 3E40F13C4EA; Wed, 9 Jan 2008 17:16:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 227892361-1834499 for multiple; Wed, 09 Jan 2008 12:17:49 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m09HGPAF093783; Wed, 9 Jan 2008 12:16:25 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Wed, 9 Jan 2008 11:42:46 -0500 User-Agent: KMail/1.9.6 References: <200801091239.m09CdhNW031864@freefall.freebsd.org> In-Reply-To: <200801091239.m09CdhNW031864@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801091142.49391.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 09 Jan 2008 12:16:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5458/Wed Jan 9 10:35:39 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-bugs@freebsd.org, re@freebsd.org, linimon@freebsd.org Subject: Re: i386/119485: 6.3 RC2 boot only CD hangs in dell d830 - 'ACPI autoload failed' X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 17:16:38 -0000 On Wednesday 09 January 2008 07:39:43 am linimon@freebsd.org wrote: > Synopsis: 6.3 RC2 boot only CD hangs in dell d830 - 'ACPI autoload failed' > > Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi > Responsible-Changed-By: linimon > Responsible-Changed-When: Wed Jan 9 12:39:15 UTC 2008 > Responsible-Changed-Why: > reclassify. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=119485 This does not look like an ACPI error at all but probably a release process error. Is acpi.ko not being included on the boot CD perhaps? Or perhaps it wasn't able to load the kernel correctly (that would explain the missing 'pci' module since 'pci' is part of the kernel). -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 10 09:26:33 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E63B816A418 for ; Thu, 10 Jan 2008 09:26:33 +0000 (UTC) (envelope-from candyshop999@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.241]) by mx1.freebsd.org (Postfix) with ESMTP id 7E02B13C474 for ; Thu, 10 Jan 2008 09:26:33 +0000 (UTC) (envelope-from candyshop999@gmail.com) Received: by hs-out-2122.google.com with SMTP id h53so650286hsh.11 for ; Thu, 10 Jan 2008 01:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=uXTYQIzNt0xopy1RDRrCJw/RE9EhaM/4gyAfLm8dUZ8=; b=tKyF4CJo/gjVkTGCDi+aXaXxCMyO3THW6yHdvwxdtulTE/OBOCWPtRC+9EOFAJpsHvrYAmCribsO75FVyDhJz19lopSPFFnQq1valYsPoNHhckNEshdDZSoVl1L8UGFObb+jnRFaGaeXxM6me6olrEOgjpvjb+klZTgw/28uBOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=AYVrJ4BOZo6ja6ol9u6ebu/lbbwCsVupWXTlzo2bX/BNzoQHPsSC78X4oMxRmsdWBTo2+WRvgzdz27+Pi+Q0eevU4euyqRGcWaMTYKVwZ8GNvNylDc4I2ZhdJPsm9Tn3CUjLznRhyPs08QlGkyREyi/9qeau81uH+8MqluURry8= Received: by 10.150.181.11 with SMTP id d11mr693998ybf.3.1199957192623; Thu, 10 Jan 2008 01:26:32 -0800 (PST) Received: by 10.150.156.8 with HTTP; Thu, 10 Jan 2008 01:26:32 -0800 (PST) Message-ID: Date: Thu, 10 Jan 2008 11:26:32 +0200 From: "Super Star" To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Dan Shonka, Fantasy Football Explodes into Fiction X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 09:26:34 -0000 Dan Shonka, Fantasy Football Explodes into Fiction http://www.ourlads.com Fifteen years ago, my friends and I wanted to get involved in fantasy sports. We had heard of Rotisserie baseball, the game where you select major leaguers and use their statistics for your own fantasy team. Most of us preferred football over baseball, so we did a little research and decided to create a fantasy football league. Now, we're entering our 16th season, with 20 of the most rabid football nuts anywhere, competing for pride and a small monetary prize each year. We're not alone, of course. Over 15 million Americans play fantasy football, a game that uses the statistics of professional football players for personal, fantasy teams. During the last decade, this game has erupted, like a volcano. There are hundreds of web sites, dedicated to it. Magazines litter the newsstands in June and July, all dedicated to providing the best information possible about players from the National Football League, as well as offering "expert" prognostication as to which players will benefit your fantasy team the most, based on their performances on the gridiron each Sunday. There are even radio and TV shows, dedicated to discussion of fantasy football and the NFL players that dot each team's roster. If you know someone who loves football, chances are he or she is part of a fantasy football league. My own participation has initiated a new experience. As a writer, I'm always looking for a new idea, something unique, and fantasy football has given it to me. A work of fiction. For years, while I was busy writing how-to books and articles, I dreamed, as most authors do, of writing the great American novel. When that didn't come, I just wanted something different; something I thought would interest a large audience. It finally hit me -- a work of fiction, based on fantasy football. It's called The League. Suspense, conspiracy and fantasy football combine for the first-ever published work of fiction that has a back drop of America's favorite game. Here's to a dream come true and a hope that 15 million Americans love The League as much as I do. Learn more about it at www.sportsnovels.com. Mark Barnes has published several how-to books on real estate finance, Internet business, and self-publishing. Recently, he has expanded his horizons into the fiction world, with his suspense-thriller, The League, presented by DNA Press. The League is available at Amazon.com, DNA Press, Sportsnovels.com and will be in book stores this summer. Mark is currently working on his second novel, another sports-related suspense thriller. Mark Barnes resides in a suburb of Cleveland with his wife, Mollie and two small children. From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 10 13:01:16 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC1C516A481 for ; Thu, 10 Jan 2008 13:01:16 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: from coruscant.far-far-away.us (coruscant.far-far-away.us [70.91.196.65]) by mx1.freebsd.org (Postfix) with SMTP id 13C7713C469 for ; Thu, 10 Jan 2008 13:01:15 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: (qmail 59834 invoked from network); 10 Jan 2008 07:55:09 -0500 Received: from kamino.far-far-away.us (HELO kamino) (192.168.0.9) by coruscant.far-far-away.us with SMTP; 10 Jan 2008 07:55:09 -0500 Message-ID: From: "Yousif Hassan" To: "Nate Lawson" , "Alexey Starikovskiy" References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> <47826AAA.6040101@root.org> <47827291.60405@suse.de> <478272C3.5080704@suse.de> <47829C03.3010802@root.org> <4782A051.3050107@suse.de> <4782BA24.8030703@root.org> In-Reply-To: <4782BA24.8030703@root.org> Date: Thu, 10 Jan 2008 07:57:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: freebsd-acpi@FreeBSD.org, "Moore, Robert" Subject: Re: GPE handler livelock [fixed?] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yousif Hassan List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 13:01:16 -0000 Nate, everyone: Well guess what? The patch appears to WORK!!!! I tested it first with a normal startup with ACPI enabled, and it didn't freeze. Not satisfied, I turned on verbose booting to watch the thermal change messages, and in fact, for the first time, 7.0 successfully changed AC states and TZ zones on this laptop. Still not satisfied, I began some tasks that generate lots of heat (say, compiling the kernel), and watched as the temperature rose. No freeze. So, I'd like to give a huge thank-you to Nate and the gang, and cautiously, I'd like to say congratulations, too. I'm happy to run any additional tests you need to confirm. Is this fix too late for 7.0 or is it a candidate for an RC? I'd definitely be willing to test any new release w/ this fix to make sure it works out-of-the-box. --Yousif ----- Original Message ----- From: "Nate Lawson" To: "Alexey Starikovskiy" Cc: "Moore, Robert" ; "Yousif Hassan" ; Sent: Monday, January 07, 2008 6:47 PM Subject: Re: GPE handler livelock > This makes sense. For the _L00 method in question, it runs 2 notifies > before it completes. So in our queue, that would be: > > T1: GPE:_L00 > [_LOO method runs, GPE removed] > [_L00 queues 2 more Notifies] > T2: Notify, Notify > [_L00 completes] > > Right now, there is nothing in our code to synchronize _L00's completion > with completion of the Notifys. In fact, _L00 finishes before the > Notifys run. Also, if another GPE comes in while this GPE is running, > it will be queued in front of the Notifys and so would execute first. > > So I think with just your evgpe.c change, we will defer re-enabling the > GPE until after the queued Notifys complete since the re-enable task > will be queued at the same priority. > > The only remaining concern I have is if another GPE comes in before one > or both Notifys run, it will be inserted at the head of the queue. So > as a hack, I'm setting the priority of these to be equal. > > Yousif, please try the attached patch and don't load a custom ASL. > > Thanks, > Nate > > Alexey Starikovskiy wrote: >> Nate, >> >> There are no debugger events in Linux, and all other deferred execution >> happens >> in kacpid (GPE, EC and GL included). Notify events used to be executed >> on this same >> queue until we noticed deadlocks with HP machines. All events are not >> prioritized in >> any way -- it is a simple FIFO. To avoid deadlock, we moved notify >> events to separate queue, >> but it had a drawback of enabling level GPE too early, thus I inserted a >> reschedule call to each completion on first queue, giving the notify >> queue chance to complete. >> Later, I was reminded that this approach is not bulletproof, so enabling >> of the level events was >> moved to notify queue as well. As it happens after all notify events for >> the gpe event were called, >> (but, probably, not executed), enabling of GPE will be deferred until >> these notify events have chance to >> complete. >> >> So, essentially, we had no priority for any event, but now notify event >> could preempt execution of >> any other event, and level GPE event does a flush of notify queue. >> >> Hope this helps, >> Alex. >> >> Nate Lawson wrote: >>> Alex, >>> >>> I had one question about your approach. It maintains two single-thread >>> task queues (kacpid and kacpi_notify). It inserts each type of event on >>> its own queue. So there is no strict ordering of handling notifies in >>> priority to other acpi tasks unless you're assuming something about the >>> linux task priority model. Do you have any expectation that notify >>> tasks run before other tasks (perhaps by a special priority assigned to >>> the kacpi_notify work queue)? >>> >>> In FreeBSD, we have a single task queue. However, we prioritize events >>> in the queue in the following order (highest to lowest priority): >>> >>> * GPE >>> * EC/global lock >>> * Notify >>> * Debugger >>> >>> If an event is inserted on the queue with a higher priority and a >>> previous event has not started executing yet, this priority determines >>> the order of insertion. Thus if GPEs keep arriving, the Notify won't be >>> executed until they're done. >>> >>> Thanks, >>> Nate >>> >>> Alexey Starikovskiy wrote: >>>> Here is the patch... >>>> Alexey Starikovskiy wrote: >>>>> I proposed this patch some time ago, it moves _Lxx enabling to the end >>>>> of Notify queue, thus all notifies must complete before event becomes >>>>> enabled again. >>>>> Hope it is readable to non-Linux people... >>>>> >>>>> Regards, >>>>> Alex. >>>>> >>>>> Moore, Robert wrote: >>>>>> No changes that I know of before 20070508. >>>>>> >>>>>> You'll need to figure out why you are getting another GPE before the >>>>>> _Lxx method completes. There was something like this on Linux with >>>>>> an HP >>>>>> machine, perhaps Alexey can help. >>>>>> >>>>>> As I recall, there was something nasty happening where the TZ trip >>>>>> points had to be reset before the Notify() handler completed, but >>>>>> this >>>>>> ended up causing another GPE, etc. etc. >>>>>> >>>>>> Bob >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Nate Lawson [mailto:nate@root.org] >>>>>>> Sent: Monday, January 07, 2008 10:09 AM >>>>>>> To: Moore, Robert >>>>>>> Cc: Yousif Hassan; freebsd-acpi@FreeBSD.org >>>>>>> Subject: Re: GPE handler livelock >>>>>>> >>>>>>> Bob, thanks for the reply. That's exactly what my investigation is >>>>>>> showing also. It appears we're still on 20070320 so I'm not sure >>>>>>> why >>>>>>> this would affect us though. Perhaps a similar change was already >>>>>>> present? In any case, we should see if an import fixes this. >>>>>>> >>>>>>> Thanks, >>>>>>> Nate >>>>>>> >>>>>>> Moore, Robert wrote: >>>>>>>> This sounds suspiciously like the changes we made to the Notify() >>>>>>>> handling last year. We attempted to make the notify handler run >>>>>>>> synchronously with the caller to Notify(), but this created more >>>>>>>> problems than it solved. We ended up returning the behavior of >>>>>>>> Notify >>>>>>>> handlers to be asynchronous: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 19 October 2007. Summary of changes for version 20071019: >>>>>>>> >>>>>>>> 1) ACPI CA Core Subsystem: >>>>>>>> >>>>>>>> Reverted a change to Notify handling that was introduced in version >>>>>>>> 20070508. This version changed the Notify handling from >>>>>>>> asynchronous >>>>>> to >>>>>>>> fully synchronous (Device driver Notify handling with respect to >>>>>>>> the >>>>>>>> Notify >>>>>>>> ASL operator). It was found that this change caused more problems >>>>>> than >>>>>>>> it >>>>>>>> solved and was removed by most users. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>>>>>>>> acpi@freebsd.org] On Behalf Of Yousif Hassan >>>>>>>>> Sent: Sunday, January 06, 2008 12:18 PM >>>>>>>>> To: Nate Lawson >>>>>>>>> Cc: freebsd-acpi@FreeBSD.org >>>>>>>>> Subject: Re: GPE handler livelock >>>>>>>>> >>>>>>>>> Nate wrote: >>>>>>>>>> Thanks for digging into this. I reviewed this and am trying to >>>>>>>> figure >>>>>>>>>> out why the _L00 handler never completes. It keeps getting >>>>>> preempted >>>>>>>> by >>>>>>>>>> the next one. To help track this down, try removing these two >>>>>> lines >>>>>>>>>> from the _L00 method and recompile your ASL: >>>>>>>>>> >>>>>>>>>> Acquire (\_TZ.C173, 0xFFFF) >>>>>>>>>> ... >>>>>>>>>> Release (\_TZ.C173) >>>>>>>>>> >>>>>>>>>> For others who have this problem, instructions on how to >>>>>>>>>> recompile >>>>>>>> and >>>>>>>>>> load your custom ASL can be found here (11.16.4 and 5): >>>>>>>>>> >>>>>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.htm >>>>>> >>>>>>>> l >>> > > -------------------------------------------------------------------------------- > Index: sys/dev/acpica/Osd/OsdSchedule.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/acpica/Osd/OsdSchedule.c,v > retrieving revision 1.39 > diff -u -r1.39 OsdSchedule.c > --- sys/dev/acpica/Osd/OsdSchedule.c 22 Mar 2007 18:16:41 -0000 1.39 > +++ sys/dev/acpica/Osd/OsdSchedule.c 7 Jan 2008 23:46:47 -0000 > @@ -114,7 +114,7 @@ > pri = 5; > break; > case OSL_NOTIFY_HANDLER: > - pri = 3; > + pri = 10; // XXX testing > break; > case OSL_DEBUGGER_THREAD: > pri = 0; > Index: sys/contrib/dev/acpica/evgpe.c > =================================================================== > RCS file: /home/ncvs/src/sys/contrib/dev/acpica/evgpe.c,v > retrieving revision 1.1.1.12 > diff -u -r1.1.1.12 evgpe.c > --- sys/contrib/dev/acpica/evgpe.c 22 Mar 2007 17:23:30 -0000 1.1.1.12 > +++ sys/contrib/dev/acpica/evgpe.c 7 Jan 2008 21:17:28 -0000 > @@ -123,6 +123,10 @@ > > /* Local prototypes */ > > +static void > +AcpiEvAsynchEnableGpe ( > + void *Context); > + > static void ACPI_SYSTEM_XFACE > AcpiEvAsynchExecuteGpeMethod ( > void *Context); > @@ -684,14 +688,26 @@ > } > } > > - if ((LocalGpeEventInfo.Flags & ACPI_GPE_XRUPT_TYPE_MASK) == > + /* Defer enabling of GPE until all notify handlers are done */ > + AcpiOsExecute(OSL_NOTIFY_HANDLER, AcpiEvAsynchEnableGpe, > GpeEventInfo); > + return_VOID; > +} > + > +static void > +AcpiEvAsynchEnableGpe ( > + void *Context) > +{ > + ACPI_GPE_EVENT_INFO *GpeEventInfo = (void *) Context; > + ACPI_STATUS Status; > + > + if ((GpeEventInfo->Flags & ACPI_GPE_XRUPT_TYPE_MASK) == > ACPI_GPE_LEVEL_TRIGGERED) > { > /* > * GPE is level-triggered, we clear the GPE status bit after > * handling the event. > */ > - Status = AcpiHwClearGpe (&LocalGpeEventInfo); > + Status = AcpiHwClearGpe (GpeEventInfo); > if (ACPI_FAILURE (Status)) > { > return_VOID; > @@ -700,7 +716,7 @@ > > /* Enable this GPE */ > > - (void) AcpiHwWriteGpeEnableReg (&LocalGpeEventInfo); > + (void) AcpiHwWriteGpeEnableReg (GpeEventInfo); > return_VOID; > } > > From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 10 15:45:14 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1691216A41A for ; Thu, 10 Jan 2008 15:45:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B020C13C467 for ; Thu, 10 Jan 2008 15:45:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 9071D1A3C1A; Thu, 10 Jan 2008 07:25:56 -0800 (PST) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Thu, 10 Jan 2008 10:15:29 -0500 User-Agent: KMail/1.9.7 References: <200712311556.lBVFuVZf030567@freefall.freebsd.org> <4782A051.3050107@suse.de> <4782BA24.8030703@root.org> In-Reply-To: <4782BA24.8030703@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801101015.29669.jhb@freebsd.org> Cc: Alexey Starikovskiy , "Moore, Robert" Subject: Re: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 15:45:14 -0000 On Monday 07 January 2008 06:47:48 pm Nate Lawson wrote: > This makes sense. For the _L00 method in question, it runs 2 notifies > before it completes. So in our queue, that would be: > > T1: GPE:_L00 > [_LOO method runs, GPE removed] > [_L00 queues 2 more Notifies] > T2: Notify, Notify > [_L00 completes] > > Right now, there is nothing in our code to synchronize _L00's completion > with completion of the Notifys. In fact, _L00 finishes before the > Notifys run. Also, if another GPE comes in while this GPE is running, > it will be queued in front of the Notifys and so would execute first. > > So I think with just your evgpe.c change, we will defer re-enabling the > GPE until after the queued Notifys complete since the re-enable task > will be queued at the same priority. > > The only remaining concern I have is if another GPE comes in before one > or both Notifys run, it will be inserted at the head of the queue. So > as a hack, I'm setting the priority of these to be equal. > > Yousif, please try the attached patch and don't load a custom ASL. This patch appears to work for me in my testing. I think this might also explain the weird hangs I reported seeing when running on battery with powerd on older kernels, but I haven't tested that case yet. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 10 15:56:25 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BA4B16A417 for ; Thu, 10 Jan 2008 15:56:25 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id 5955C13C459 for ; Thu, 10 Jan 2008 15:56:24 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 10 Jan 2008 07:54:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.24,267,1196668800"; d="scan'208";a="283095795" Received: from orsmsx334.jf.intel.com ([10.22.226.45]) by fmsmga002.fm.intel.com with ESMTP; 10 Jan 2008 07:53:28 -0800 Received: from orsmsx415.amr.corp.intel.com ([10.22.226.49]) by orsmsx334.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 07:54:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Jan 2008 07:53:16 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GPE handler livelock [fixed?] Thread-Index: AchTiUeLz6GxwdkQTS23flA3PBzpwAAFwjAg References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org><47802510.3040203@root.org><47826AAA.6040101@root.org><47827291.60405@suse.de> <478272C3.5080704@suse.de><47829C03.3010802@root.org> <4782A051.3050107@suse.de><4782BA24.8030703@root.org> From: "Moore, Robert" To: "Yousif Hassan" , "Nate Lawson" , "Alexey Starikovskiy" X-OriginalArrivalTime: 10 Jan 2008 15:54:06.0110 (UTC) FILETIME=[0785ABE0:01C853A1] Cc: freebsd-acpi@FreeBSD.org Subject: RE: GPE handler livelock [fixed?] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 15:56:25 -0000 This is great news. Special thanks to Alexey. We've been going around and around for almost 2 years attempting to solve these kinds of notify/GPE issues. It sounds like we may have solved the issue(s). We will of course integrate the changes that were made to the core ACPICA code. Bob >-----Original Message----- >From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >acpi@freebsd.org] On Behalf Of Yousif Hassan >Sent: Thursday, January 10, 2008 4:57 AM >To: Nate Lawson; Alexey Starikovskiy >Cc: freebsd-acpi@FreeBSD.org; Moore, Robert >Subject: Re: GPE handler livelock [fixed?] > >Nate, everyone: > >Well guess what? The patch appears to WORK!!!! > >I tested it first with a normal startup with ACPI enabled, and it didn't >freeze. >Not satisfied, I turned on verbose booting to watch the thermal change >messages, >and in fact, for the first time, 7.0 successfully changed AC states and TZ >zones >on this laptop. > >Still not satisfied, I began some tasks that generate lots of heat (say, >compiling the kernel), and watched as the temperature rose. No freeze. > >So, I'd like to give a huge thank-you to Nate and the gang, and cautiously, >I'd like to say congratulations, too. > >I'm happy to run any additional tests you need to confirm. > >Is this fix too late for 7.0 or is it a candidate for an RC? I'd >definitely >be >willing to test any new release w/ this fix to make sure it works >out-of-the-box. > >--Yousif > >----- Original Message ----- >From: "Nate Lawson" >To: "Alexey Starikovskiy" >Cc: "Moore, Robert" ; "Yousif Hassan" >; >Sent: Monday, January 07, 2008 6:47 PM >Subject: Re: GPE handler livelock > > >> This makes sense. For the _L00 method in question, it runs 2 notifies >> before it completes. So in our queue, that would be: >> >> T1: GPE:_L00 >> [_LOO method runs, GPE removed] >> [_L00 queues 2 more Notifies] >> T2: Notify, Notify >> [_L00 completes] >> >> Right now, there is nothing in our code to synchronize _L00's completion >> with completion of the Notifys. In fact, _L00 finishes before the >> Notifys run. Also, if another GPE comes in while this GPE is running, >> it will be queued in front of the Notifys and so would execute first. >> >> So I think with just your evgpe.c change, we will defer re-enabling the >> GPE until after the queued Notifys complete since the re-enable task >> will be queued at the same priority. >> >> The only remaining concern I have is if another GPE comes in before one >> or both Notifys run, it will be inserted at the head of the queue. So >> as a hack, I'm setting the priority of these to be equal. >> >> Yousif, please try the attached patch and don't load a custom ASL. >> >> Thanks, >> Nate >> >> Alexey Starikovskiy wrote: >>> Nate, >>> >>> There are no debugger events in Linux, and all other deferred execution >>> happens >>> in kacpid (GPE, EC and GL included). Notify events used to be executed >>> on this same >>> queue until we noticed deadlocks with HP machines. All events are not >>> prioritized in >>> any way -- it is a simple FIFO. To avoid deadlock, we moved notify >>> events to separate queue, >>> but it had a drawback of enabling level GPE too early, thus I inserted a >>> reschedule call to each completion on first queue, giving the notify >>> queue chance to complete. >>> Later, I was reminded that this approach is not bulletproof, so enabling >>> of the level events was >>> moved to notify queue as well. As it happens after all notify events for >>> the gpe event were called, >>> (but, probably, not executed), enabling of GPE will be deferred until >>> these notify events have chance to >>> complete. >>> >>> So, essentially, we had no priority for any event, but now notify event >>> could preempt execution of >>> any other event, and level GPE event does a flush of notify queue. >>> >>> Hope this helps, >>> Alex. >>> >>> Nate Lawson wrote: >>>> Alex, >>>> >>>> I had one question about your approach. It maintains two single-thread >>>> task queues (kacpid and kacpi_notify). It inserts each type of event >on >>>> its own queue. So there is no strict ordering of handling notifies in >>>> priority to other acpi tasks unless you're assuming something about the >>>> linux task priority model. Do you have any expectation that notify >>>> tasks run before other tasks (perhaps by a special priority assigned to >>>> the kacpi_notify work queue)? >>>> >>>> In FreeBSD, we have a single task queue. However, we prioritize events >>>> in the queue in the following order (highest to lowest priority): >>>> >>>> * GPE >>>> * EC/global lock >>>> * Notify >>>> * Debugger >>>> >>>> If an event is inserted on the queue with a higher priority and a >>>> previous event has not started executing yet, this priority determines >>>> the order of insertion. Thus if GPEs keep arriving, the Notify won't >be >>>> executed until they're done. >>>> >>>> Thanks, >>>> Nate >>>> >>>> Alexey Starikovskiy wrote: >>>>> Here is the patch... >>>>> Alexey Starikovskiy wrote: >>>>>> I proposed this patch some time ago, it moves _Lxx enabling to the >end >>>>>> of Notify queue, thus all notifies must complete before event becomes >>>>>> enabled again. >>>>>> Hope it is readable to non-Linux people... >>>>>> >>>>>> Regards, >>>>>> Alex. >>>>>> >>>>>> Moore, Robert wrote: >>>>>>> No changes that I know of before 20070508. >>>>>>> >>>>>>> You'll need to figure out why you are getting another GPE before the >>>>>>> _Lxx method completes. There was something like this on Linux with >>>>>>> an HP >>>>>>> machine, perhaps Alexey can help. >>>>>>> >>>>>>> As I recall, there was something nasty happening where the TZ trip >>>>>>> points had to be reset before the Notify() handler completed, but >>>>>>> this >>>>>>> ended up causing another GPE, etc. etc. >>>>>>> >>>>>>> Bob >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Nate Lawson [mailto:nate@root.org] >>>>>>>> Sent: Monday, January 07, 2008 10:09 AM >>>>>>>> To: Moore, Robert >>>>>>>> Cc: Yousif Hassan; freebsd-acpi@FreeBSD.org >>>>>>>> Subject: Re: GPE handler livelock >>>>>>>> >>>>>>>> Bob, thanks for the reply. That's exactly what my investigation is >>>>>>>> showing also. It appears we're still on 20070320 so I'm not sure >>>>>>>> why >>>>>>>> this would affect us though. Perhaps a similar change was already >>>>>>>> present? In any case, we should see if an import fixes this. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Nate >>>>>>>> >>>>>>>> Moore, Robert wrote: >>>>>>>>> This sounds suspiciously like the changes we made to the Notify() >>>>>>>>> handling last year. We attempted to make the notify handler run >>>>>>>>> synchronously with the caller to Notify(), but this created more >>>>>>>>> problems than it solved. We ended up returning the behavior of >>>>>>>>> Notify >>>>>>>>> handlers to be asynchronous: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 19 October 2007. Summary of changes for version 20071019: >>>>>>>>> >>>>>>>>> 1) ACPI CA Core Subsystem: >>>>>>>>> >>>>>>>>> Reverted a change to Notify handling that was introduced in >version >>>>>>>>> 20070508. This version changed the Notify handling from >>>>>>>>> asynchronous >>>>>>> to >>>>>>>>> fully synchronous (Device driver Notify handling with respect to >>>>>>>>> the >>>>>>>>> Notify >>>>>>>>> ASL operator). It was found that this change caused more problems >>>>>>> than >>>>>>>>> it >>>>>>>>> solved and was removed by most users. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>>>>>>>>> acpi@freebsd.org] On Behalf Of Yousif Hassan >>>>>>>>>> Sent: Sunday, January 06, 2008 12:18 PM >>>>>>>>>> To: Nate Lawson >>>>>>>>>> Cc: freebsd-acpi@FreeBSD.org >>>>>>>>>> Subject: Re: GPE handler livelock >>>>>>>>>> >>>>>>>>>> Nate wrote: >>>>>>>>>>> Thanks for digging into this. I reviewed this and am trying to >>>>>>>>> figure >>>>>>>>>>> out why the _L00 handler never completes. It keeps getting >>>>>>> preempted >>>>>>>>> by >>>>>>>>>>> the next one. To help track this down, try removing these two >>>>>>> lines >>>>>>>>>>> from the _L00 method and recompile your ASL: >>>>>>>>>>> >>>>>>>>>>> Acquire (\_TZ.C173, 0xFFFF) >>>>>>>>>>> ... >>>>>>>>>>> Release (\_TZ.C173) >>>>>>>>>>> >>>>>>>>>>> For others who have this problem, instructions on how to >>>>>>>>>>> recompile >>>>>>>>> and >>>>>>>>>>> load your custom ASL can be found here (11.16.4 and 5): >>>>>>>>>>> >>>>>>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi- >debug.htm >>>>>>> >>>>>>>>> l >>>> >> >> > > >----------------------------------------------------------------------- ---- >----- > > >> Index: sys/dev/acpica/Osd/OsdSchedule.c >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> RCS file: /home/ncvs/src/sys/dev/acpica/Osd/OsdSchedule.c,v >> retrieving revision 1.39 >> diff -u -r1.39 OsdSchedule.c >> --- sys/dev/acpica/Osd/OsdSchedule.c 22 Mar 2007 18:16:41 -0000 1.39 >> +++ sys/dev/acpica/Osd/OsdSchedule.c 7 Jan 2008 23:46:47 -0000 >> @@ -114,7 +114,7 @@ >> pri =3D 5; >> break; >> case OSL_NOTIFY_HANDLER: >> - pri =3D 3; >> + pri =3D 10; // XXX testing >> break; >> case OSL_DEBUGGER_THREAD: >> pri =3D 0; >> Index: sys/contrib/dev/acpica/evgpe.c >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> RCS file: /home/ncvs/src/sys/contrib/dev/acpica/evgpe.c,v >> retrieving revision 1.1.1.12 >> diff -u -r1.1.1.12 evgpe.c >> --- sys/contrib/dev/acpica/evgpe.c 22 Mar 2007 17:23:30 -0000 1.1.1.12 >> +++ sys/contrib/dev/acpica/evgpe.c 7 Jan 2008 21:17:28 -0000 >> @@ -123,6 +123,10 @@ >> >> /* Local prototypes */ >> >> +static void >> +AcpiEvAsynchEnableGpe ( >> + void *Context); >> + >> static void ACPI_SYSTEM_XFACE >> AcpiEvAsynchExecuteGpeMethod ( >> void *Context); >> @@ -684,14 +688,26 @@ >> } >> } >> >> - if ((LocalGpeEventInfo.Flags & ACPI_GPE_XRUPT_TYPE_MASK) =3D=3D >> + /* Defer enabling of GPE until all notify handlers are done */ >> + AcpiOsExecute(OSL_NOTIFY_HANDLER, AcpiEvAsynchEnableGpe, >> GpeEventInfo); >> + return_VOID; >> +} >> + >> +static void >> +AcpiEvAsynchEnableGpe ( >> + void *Context) >> +{ >> + ACPI_GPE_EVENT_INFO *GpeEventInfo =3D (void *) Context; >> + ACPI_STATUS Status; >> + >> + if ((GpeEventInfo->Flags & ACPI_GPE_XRUPT_TYPE_MASK) =3D=3D >> ACPI_GPE_LEVEL_TRIGGERED) >> { >> /* >> * GPE is level-triggered, we clear the GPE status bit after >> * handling the event. >> */ >> - Status =3D AcpiHwClearGpe (&LocalGpeEventInfo); >> + Status =3D AcpiHwClearGpe (GpeEventInfo); >> if (ACPI_FAILURE (Status)) >> { >> return_VOID; >> @@ -700,7 +716,7 @@ >> >> /* Enable this GPE */ >> >> - (void) AcpiHwWriteGpeEnableReg (&LocalGpeEventInfo); >> + (void) AcpiHwWriteGpeEnableReg (GpeEventInfo); >> return_VOID; >> } >> >> > >_______________________________________________ >freebsd-acpi@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 10 16:25:17 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9E7C16A417 for ; Thu, 10 Jan 2008 16:25:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E116F13C46E for ; Thu, 10 Jan 2008 16:25:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 4BF871A4D89; Thu, 10 Jan 2008 08:22:22 -0800 (PST) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Thu, 10 Jan 2008 11:24:17 -0500 User-Agent: KMail/1.9.7 References: <200712311556.lBVFuVZf030567@freefall.freebsd.org> <4782BA24.8030703@root.org> <200801101015.29669.jhb@freebsd.org> In-Reply-To: <200801101015.29669.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801101124.18406.jhb@freebsd.org> Cc: Alexey Starikovskiy , "Moore, Robert" Subject: Re: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 16:25:18 -0000 On Thursday 10 January 2008 10:15:29 am John Baldwin wrote: > On Monday 07 January 2008 06:47:48 pm Nate Lawson wrote: > > This makes sense. For the _L00 method in question, it runs 2 notifies > > before it completes. So in our queue, that would be: > > > > T1: GPE:_L00 > > [_LOO method runs, GPE removed] > > [_L00 queues 2 more Notifies] > > T2: Notify, Notify > > [_L00 completes] > > > > Right now, there is nothing in our code to synchronize _L00's completion > > with completion of the Notifys. In fact, _L00 finishes before the > > Notifys run. Also, if another GPE comes in while this GPE is running, > > it will be queued in front of the Notifys and so would execute first. > > > > So I think with just your evgpe.c change, we will defer re-enabling the > > GPE until after the queued Notifys complete since the re-enable task > > will be queued at the same priority. > > > > The only remaining concern I have is if another GPE comes in before one > > or both Notifys run, it will be inserted at the head of the queue. So > > as a hack, I'm setting the priority of these to be equal. > > > > Yousif, please try the attached patch and don't load a custom ASL. > > This patch appears to work for me in my testing. I think this might also > explain the weird hangs I reported seeing when running on battery with > powerd on older kernels, but I haven't tested that case yet. Update to note that it did not fix the issue I have with powerd. However debug.cpufreq.lowest does seem to help my issues with powerd. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Sat Jan 12 22:33:01 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B1A816A417 for ; Sat, 12 Jan 2008 22:33:01 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 09C3D13C459 for ; Sat, 12 Jan 2008 22:33:00 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 13070 invoked from network); 12 Jan 2008 22:33:01 -0000 Received: from ppp-71-139-9-226.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.9.226) by root.org with ESMTPA; 12 Jan 2008 22:33:01 -0000 Message-ID: <47894019.50200@root.org> Date: Sat, 12 Jan 2008 14:32:57 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: "Moore, Robert" References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org><47802510.3040203@root.org><47826AAA.6040101@root.org><47827291.60405@suse.de> <478272C3.5080704@suse.de><47829C03.3010802@root.org> <4782A051.3050107@suse.de><4782BA24.8030703@root.org> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexey Starikovskiy , freebsd-acpi@FreeBSD.org Subject: Re: GPE handler livelock [fixed?] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2008 22:33:01 -0000 Thanks all. I've committed the patch with a few style fixes. Please cvsup and test if you run -current or apply the patch I posted to the freebsd-current mailing list if you run 7.0. -Nate Moore, Robert wrote: > This is great news. > > Special thanks to Alexey. We've been going around and around for almost > 2 years attempting to solve these kinds of notify/GPE issues. It sounds > like we may have solved the issue(s). > > We will of course integrate the changes that were made to the core > ACPICA code. > > Bob > > >> -----Original Message----- >> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >> acpi@freebsd.org] On Behalf Of Yousif Hassan >> Sent: Thursday, January 10, 2008 4:57 AM >> To: Nate Lawson; Alexey Starikovskiy >> Cc: freebsd-acpi@FreeBSD.org; Moore, Robert >> Subject: Re: GPE handler livelock [fixed?] >> >> Nate, everyone: >> >> Well guess what? The patch appears to WORK!!!! >> >> I tested it first with a normal startup with ACPI enabled, and it > didn't >> freeze. >> Not satisfied, I turned on verbose booting to watch the thermal change >> messages, >> and in fact, for the first time, 7.0 successfully changed AC states and > TZ >> zones >> on this laptop. >> >> Still not satisfied, I began some tasks that generate lots of heat > (say, >> compiling the kernel), and watched as the temperature rose. No freeze. >> >> So, I'd like to give a huge thank-you to Nate and the gang, and > cautiously, >> I'd like to say congratulations, too. >> >> I'm happy to run any additional tests you need to confirm. >> >> Is this fix too late for 7.0 or is it a candidate for an RC? I'd >> definitely >> be >> willing to test any new release w/ this fix to make sure it works >> out-of-the-box. >> >> --Yousif >> >> ----- Original Message ----- >> From: "Nate Lawson" >> To: "Alexey Starikovskiy" >> Cc: "Moore, Robert" ; "Yousif Hassan" >> ; >> Sent: Monday, January 07, 2008 6:47 PM >> Subject: Re: GPE handler livelock >> >> >>> This makes sense. For the _L00 method in question, it runs 2 > notifies >>> before it completes. So in our queue, that would be: >>> >>> T1: GPE:_L00 >>> [_LOO method runs, GPE removed] >>> [_L00 queues 2 more Notifies] >>> T2: Notify, Notify >>> [_L00 completes] >>> >>> Right now, there is nothing in our code to synchronize _L00's > completion >>> with completion of the Notifys. In fact, _L00 finishes before the >>> Notifys run. Also, if another GPE comes in while this GPE is > running, >>> it will be queued in front of the Notifys and so would execute first. >>> >>> So I think with just your evgpe.c change, we will defer re-enabling > the >>> GPE until after the queued Notifys complete since the re-enable task >>> will be queued at the same priority. >>> >>> The only remaining concern I have is if another GPE comes in before > one >>> or both Notifys run, it will be inserted at the head of the queue. > So >>> as a hack, I'm setting the priority of these to be equal. >>> >>> Yousif, please try the attached patch and don't load a custom ASL. >>> >>> Thanks, >>> Nate >>> >>> Alexey Starikovskiy wrote: >>>> Nate, >>>> >>>> There are no debugger events in Linux, and all other deferred > execution >>>> happens >>>> in kacpid (GPE, EC and GL included). Notify events used to be > executed >>>> on this same >>>> queue until we noticed deadlocks with HP machines. All events are > not >>>> prioritized in >>>> any way -- it is a simple FIFO. To avoid deadlock, we moved notify >>>> events to separate queue, >>>> but it had a drawback of enabling level GPE too early, thus I > inserted a >>>> reschedule call to each completion on first queue, giving the notify >>>> queue chance to complete. >>>> Later, I was reminded that this approach is not bulletproof, so > enabling >>>> of the level events was >>>> moved to notify queue as well. As it happens after all notify events > for >>>> the gpe event were called, >>>> (but, probably, not executed), enabling of GPE will be deferred > until >>>> these notify events have chance to >>>> complete. >>>> >>>> So, essentially, we had no priority for any event, but now notify > event >>>> could preempt execution of >>>> any other event, and level GPE event does a flush of notify queue. >>>> >>>> Hope this helps, >>>> Alex. >>>> >>>> Nate Lawson wrote: >>>>> Alex, >>>>> >>>>> I had one question about your approach. It maintains two > single-thread >>>>> task queues (kacpid and kacpi_notify). It inserts each type of > event >> on >>>>> its own queue. So there is no strict ordering of handling notifies > in >>>>> priority to other acpi tasks unless you're assuming something about > the >>>>> linux task priority model. Do you have any expectation that notify >>>>> tasks run before other tasks (perhaps by a special priority > assigned to >>>>> the kacpi_notify work queue)? >>>>> >>>>> In FreeBSD, we have a single task queue. However, we prioritize > events >>>>> in the queue in the following order (highest to lowest priority): >>>>> >>>>> * GPE >>>>> * EC/global lock >>>>> * Notify >>>>> * Debugger >>>>> >>>>> If an event is inserted on the queue with a higher priority and a >>>>> previous event has not started executing yet, this priority > determines >>>>> the order of insertion. Thus if GPEs keep arriving, the Notify > won't >> be >>>>> executed until they're done. >>>>> >>>>> Thanks, >>>>> Nate >>>>> >>>>> Alexey Starikovskiy wrote: >>>>>> Here is the patch... >>>>>> Alexey Starikovskiy wrote: >>>>>>> I proposed this patch some time ago, it moves _Lxx enabling to > the >> end >>>>>>> of Notify queue, thus all notifies must complete before event > becomes >>>>>>> enabled again. >>>>>>> Hope it is readable to non-Linux people... >>>>>>> >>>>>>> Regards, >>>>>>> Alex. >>>>>>> >>>>>>> Moore, Robert wrote: >>>>>>>> No changes that I know of before 20070508. >>>>>>>> >>>>>>>> You'll need to figure out why you are getting another GPE before > the >>>>>>>> _Lxx method completes. There was something like this on Linux > with >>>>>>>> an HP >>>>>>>> machine, perhaps Alexey can help. >>>>>>>> >>>>>>>> As I recall, there was something nasty happening where the TZ > trip >>>>>>>> points had to be reset before the Notify() handler completed, > but >>>>>>>> this >>>>>>>> ended up causing another GPE, etc. etc. >>>>>>>> >>>>>>>> Bob >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Nate Lawson [mailto:nate@root.org] >>>>>>>>> Sent: Monday, January 07, 2008 10:09 AM >>>>>>>>> To: Moore, Robert >>>>>>>>> Cc: Yousif Hassan; freebsd-acpi@FreeBSD.org >>>>>>>>> Subject: Re: GPE handler livelock >>>>>>>>> >>>>>>>>> Bob, thanks for the reply. That's exactly what my > investigation is >>>>>>>>> showing also. It appears we're still on 20070320 so I'm not > sure >>>>>>>>> why >>>>>>>>> this would affect us though. Perhaps a similar change was > already >>>>>>>>> present? In any case, we should see if an import fixes this. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Nate >>>>>>>>> >>>>>>>>> Moore, Robert wrote: >>>>>>>>>> This sounds suspiciously like the changes we made to the > Notify() >>>>>>>>>> handling last year. We attempted to make the notify handler > run >>>>>>>>>> synchronously with the caller to Notify(), but this created > more >>>>>>>>>> problems than it solved. We ended up returning the behavior of >>>>>>>>>> Notify >>>>>>>>>> handlers to be asynchronous: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 19 October 2007. Summary of changes for version 20071019: >>>>>>>>>> >>>>>>>>>> 1) ACPI CA Core Subsystem: >>>>>>>>>> >>>>>>>>>> Reverted a change to Notify handling that was introduced in >> version >>>>>>>>>> 20070508. This version changed the Notify handling from >>>>>>>>>> asynchronous >>>>>>>> to >>>>>>>>>> fully synchronous (Device driver Notify handling with respect > to >>>>>>>>>> the >>>>>>>>>> Notify >>>>>>>>>> ASL operator). It was found that this change caused more > problems >>>>>>>> than >>>>>>>>>> it >>>>>>>>>> solved and was removed by most users. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>>>>>>>>>> acpi@freebsd.org] On Behalf Of Yousif Hassan >>>>>>>>>>> Sent: Sunday, January 06, 2008 12:18 PM >>>>>>>>>>> To: Nate Lawson >>>>>>>>>>> Cc: freebsd-acpi@FreeBSD.org >>>>>>>>>>> Subject: Re: GPE handler livelock >>>>>>>>>>> >>>>>>>>>>> Nate wrote: >>>>>>>>>>>> Thanks for digging into this. I reviewed this and am trying > to >>>>>>>>>> figure >>>>>>>>>>>> out why the _L00 handler never completes. It keeps getting >>>>>>>> preempted >>>>>>>>>> by >>>>>>>>>>>> the next one. To help track this down, try removing these > two >>>>>>>> lines >>>>>>>>>>>> from the _L00 method and recompile your ASL: >>>>>>>>>>>> >>>>>>>>>>>> Acquire (\_TZ.C173, 0xFFFF) >>>>>>>>>>>> ... >>>>>>>>>>>> Release (\_TZ.C173) >>>>>>>>>>>> >>>>>>>>>>>> For others who have this problem, instructions on how to >>>>>>>>>>>> recompile >>>>>>>>>> and >>>>>>>>>>>> load your custom ASL can be found here (11.16.4 and 5): >>>>>>>>>>>> >>>>>>>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi- >> debug.htm >>>>>>>>>> l From owner-freebsd-acpi@FreeBSD.ORG Sat Jan 12 22:36:36 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88AB716A41A; Sat, 12 Jan 2008 22:36:36 +0000 (UTC) (envelope-from njl@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EFFD413C458; Sat, 12 Jan 2008 22:36:35 +0000 (UTC) (envelope-from njl@FreeBSD.org) Received: from freefall.freebsd.org (njl@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0CMaZq7085024; Sat, 12 Jan 2008 22:36:35 GMT (envelope-from njl@freefall.freebsd.org) Received: (from njl@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0CMaYJu085020; Sat, 12 Jan 2008 22:36:34 GMT (envelope-from njl) Date: Sat, 12 Jan 2008 22:36:34 GMT Message-Id: <200801122236.m0CMaYJu085020@freefall.freebsd.org> To: juho.vuori@kepa.fi, njl@FreeBSD.org, freebsd-acpi@FreeBSD.org From: njl@FreeBSD.org Cc: Subject: Re: i386/79080: acpi thermal changes freezes HP nx6110 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2008 22:36:36 -0000 Synopsis: acpi thermal changes freezes HP nx6110 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