From owner-freebsd-acpi@FreeBSD.ORG Sun Mar 4 13:45:47 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42DF316A401; Sun, 4 Mar 2007 13:45:47 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id D798513C4A5; Sun, 4 Mar 2007 13:45:46 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id BB7676E3D2; Mon, 5 Mar 2007 00:45:41 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 75CB827407; Mon, 5 Mar 2007 00:45:44 +1100 (EST) Date: Mon, 5 Mar 2007 00:45:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Stefan Ehmann In-Reply-To: <200703041359.52213.shoesoft@gmx.net> Message-ID: <20070305004000.B17935@delplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <200703021619.33755.shoesoft@gmx.net> <20070304230346.O7298@besplex.bde.org> <200703041359.52213.shoesoft@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org, bde@freebsd.org Subject: Re: notebook freezes 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, 04 Mar 2007 13:45:47 -0000 [Trying to redirect this from current to acpi.] On Sun, 4 Mar 2007, Stefan Ehmann wrote: > On Sunday 04 March 2007 13:27, Bruce Evans wrote: >> On Fri, 2 Mar 2007, Stefan Ehmann wrote: >>> On Thursday 01 March 2007 16:12, Stefan Ehmann wrote: >>>> My few days old -current freezes if I press Fn-F6 (this is the >>>> combination to adjust display brightness) if I've done a suspend/resume >>>> before. Directly after boot it works fine. >>> >>> ... >>> So I did a binary search. >>> >>> src/sys/i386/isa/clock.c r1.231 causes my notebook to freeze. >>> >>> Reverting this change in a CURRENT from today fixes the problem. >>> >>> The notebook is still pingable in this state. I experienced some other >>> random hangs recently but don't know yet if those are related. >> >> Oops. If suspend/resume clobbers the RTC state (which we already have code >> to restore), then it can clobber the RTC index (which even the restoral >> code assumes is unclobbered). Try this fix. >> >> %%% >> Index: clock.c >> =================================================================== >> RCS file: /home/ncvs/src/sys/i386/isa/clock.c,v >> retrieving revision 1.234 >> diff -u -2 -r1.234 clock.c >> --- clock.c 4 Mar 2007 04:55:19 -0000 1.234 >> +++ clock.c 4 Mar 2007 11:58:00 -0000 >> @@ -580,4 +582,5 @@ >> /* Restore all of the RTC's "status" (actually, control) registers. */ >> /* XXX locking is needed for RTC access. */ >> + rtc_reg = -1; >> writertc(RTC_STATUSB, RTCSB_24HR); >> writertc(RTC_STATUSA, rtc_statusa); >> %%% >> >> A similar fix might be needed for amd64, but amd64 doesn't have a resume >> hook for putting it in. The RTC index might get clobbered even if the >> data registers aren't. >> >> I don't know how any of this works with ACPI. AFAIK (not far), the resume >> hook is only called for APM. > > Yes, rtc_restore() doesn't get called. So the patch changes nothing for me. > > Stefan Bruce From owner-freebsd-acpi@FreeBSD.ORG Sun Mar 4 16:11:18 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7BFD16A408 for ; Sun, 4 Mar 2007 16:11:18 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 2804213C491 for ; Sun, 4 Mar 2007 16:11:17 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so978024ugh for ; Sun, 04 Mar 2007 08:11:17 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=CgoPsshM5tr5BoMpkJhZKqAaG0y6Mp1W7d37zjEByZJ/aTErj22n5HYpgvXtwuncNDwtJUKtopDtVp9uwwauP/nGjCpxtwg9NNa1jq4ULizJeYqONgg8cJPoU/nftHvfW6tzPydw5NuC0ABrzfvZ4PrgxmJmFZYBUi6ImMxAUYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Dq7U34z8btAJnxz6Lgo5TFL3GY2y0ul0xrMouGeUM8Wgxgt2aVvzuRbkY3d98qCIgr4V3Btw3lvg19/8Z7QRDeV0AN6Q9oUf6XF7YFlpbDGrgA43dMLjAOn+G5/uysAxp+O0VRN++97ZYWVSRNEse9/5kagvC6qvu7LAs+cRQr8= Received: by 10.66.239.18 with SMTP id m18mr8132552ugh.1173023106754; Sun, 04 Mar 2007 07:45:06 -0800 (PST) Received: by 10.66.237.17 with HTTP; Sun, 4 Mar 2007 07:45:06 -0800 (PST) Message-ID: <755cb9fc0703040745v546a3e57r8e2f794c6879d430@mail.gmail.com> Date: Sun, 4 Mar 2007 15:45:06 +0000 From: "Alexandre Vieira" To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Acer Aspire 1640 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, 04 Mar 2007 16:11:18 -0000 Hi folks, I'm being spamed with ACPI error messages in an Acer Aspire 1640 laptop. FreeBSD blackpearl 6.2-STABLE FreeBSD 6.2-STABLE #0: Thu Mar 1 00:23:47 WET 2007 root@blackpearl:/usr/obj/usr/src/sys/blackpearl i386 Kernel is striped down for my hardware, but no fancy options. You can find the acpidump -t -d output here: http://nullpt.googlepages.com/Acer_Aspire_1640.asl Verbose dmesg w/ acpi enabled: http://nullpt.googlepages.com/messages_acpi_enabled.txt Verbose dmesg w/ acpi disabled: http://nullpt.googlepages.com/messages_acpi_disabled.txt The ACPI errors i'm getting: http://nullpt.googlepages.com/example_acpi_error.txt Sysct hw.acpi: http://nullpt.googlepages.com/sysctl.hw.acpi.txt Any help is apreciated. Thanks in advance. Regards, Alexandre From owner-freebsd-acpi@FreeBSD.ORG Sun Mar 4 20:20:25 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C095016A400 for ; Sun, 4 Mar 2007 20:20:25 +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 A4E1A13C49D for ; Sun, 4 Mar 2007 20:20:25 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 47632 invoked from network); 4 Mar 2007 20:13:59 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 4 Mar 2007 20:13:59 -0000 Message-ID: <45EB28A1.5010803@root.org> Date: Sun, 04 Mar 2007 12:14:25 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Bruce Evans References: <200703011612.07110.shoesoft@gmx.net> <200703021619.33755.shoesoft@gmx.net> <20070304230346.O7298@besplex.bde.org> <200703041359.52213.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> In-Reply-To: <20070305004000.B17935@delplex.bde.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Stefan Ehmann Subject: Re: notebook freezes 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, 04 Mar 2007 20:20:25 -0000 Bruce Evans wrote: > [Trying to redirect this from current to acpi.] > > On Sun, 4 Mar 2007, Stefan Ehmann wrote: > >> On Sunday 04 March 2007 13:27, Bruce Evans wrote: >>> On Fri, 2 Mar 2007, Stefan Ehmann wrote: >>>> On Thursday 01 March 2007 16:12, Stefan Ehmann wrote: >>>>> My few days old -current freezes if I press Fn-F6 (this is the >>>>> combination to adjust display brightness) if I've done a >>>>> suspend/resume >>>>> before. Directly after boot it works fine. >>>> >>>> ... >>>> So I did a binary search. >>>> >>>> src/sys/i386/isa/clock.c r1.231 causes my notebook to freeze. >>>> >>>> Reverting this change in a CURRENT from today fixes the problem. >>>> >>>> The notebook is still pingable in this state. I experienced some other >>>> random hangs recently but don't know yet if those are related. >>> >>> Oops. If suspend/resume clobbers the RTC state (which we already >>> have code >>> to restore), then it can clobber the RTC index (which even the restoral >>> code assumes is unclobbered). Try this fix. >>> >>> %%% >>> Index: clock.c >>> =================================================================== >>> RCS file: /home/ncvs/src/sys/i386/isa/clock.c,v >>> retrieving revision 1.234 >>> diff -u -2 -r1.234 clock.c >>> --- clock.c 4 Mar 2007 04:55:19 -0000 1.234 >>> +++ clock.c 4 Mar 2007 11:58:00 -0000 >>> @@ -580,4 +582,5 @@ >>> /* Restore all of the RTC's "status" (actually, control) >>> registers. */ >>> /* XXX locking is needed for RTC access. */ >>> + rtc_reg = -1; >>> writertc(RTC_STATUSB, RTCSB_24HR); >>> writertc(RTC_STATUSA, rtc_statusa); >>> %%% >>> >>> A similar fix might be needed for amd64, but amd64 doesn't have a resume >>> hook for putting it in. The RTC index might get clobbered even if the >>> data registers aren't. >>> >>> I don't know how any of this works with ACPI. AFAIK (not far), the >>> resume >>> hook is only called for APM. >> >> Yes, rtc_restore() doesn't get called. So the patch changes nothing >> for me. Bruce's patch should work if you add "device pmtimer" to your kernel config. That will allow pmtimer_resume() to call timer_restore() which calls rtc_restore(). If that works for you, Bruce can commit it modulo style bugs. ;-) -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Mar 4 22:09:43 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77B6416A404 for ; Sun, 4 Mar 2007 22:09:43 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id C8C0A13C441 for ; Sun, 4 Mar 2007 22:09:42 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 04 Mar 2007 21:43:00 -0000 X-Provags-ID: V01U2FsdGVkX18/OVYTk/8/0fLlrhfwHer/MPKF3fUCcc2ChlAcUa WfIBml8f718DTz From: Stefan Ehmann To: Nate Lawson Date: Sun, 4 Mar 2007 22:42:57 +0100 User-Agent: KMail/1.9.5 References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> In-Reply-To: <45EB28A1.5010803@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703042242.58748.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: freebsd-acpi@freebsd.org, Bruce Evans Subject: Re: notebook freezes 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, 04 Mar 2007 22:09:43 -0000 On Sunday 04 March 2007 21:14, Nate Lawson wrote: > Bruce Evans wrote: > > [Trying to redirect this from current to acpi.] > > > > On Sun, 4 Mar 2007, Stefan Ehmann wrote: > >> On Sunday 04 March 2007 13:27, Bruce Evans wrote: ... > >>> Oops. If suspend/resume clobbers the RTC state (which we already > >>> have code > >>> to restore), then it can clobber the RTC index (which even the restoral > >>> code assumes is unclobbered). Try this fix. ... > >>> I don't know how any of this works with ACPI. AFAIK (not far), the > >>> resume > >>> hook is only called for APM. > >> > >> Yes, rtc_restore() doesn't get called. So the patch changes nothing > >> for me. > > Bruce's patch should work if you add "device pmtimer" to your kernel > config. That will allow pmtimer_resume() to call timer_restore() which > calls rtc_restore(). > > If that works for you, Bruce can commit it modulo style bugs. ;-) Oops, seems I somehow screwed up Bruce's patch on first try (pmtimer was already in my config). Probably the aftermath of the lunar eclipse :) On my second try, timer_restore really gets called and it also fixes my problem. Thanks! From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 04:21:06 2007 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F65516A401 for ; Mon, 5 Mar 2007 04:21:06 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 9E1CF13C428 for ; Mon, 5 Mar 2007 04:21:05 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 0D4F13280AD; Mon, 5 Mar 2007 15:21:04 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id C53148C06; Mon, 5 Mar 2007 15:21:02 +1100 (EST) Date: Mon, 5 Mar 2007 15:21:01 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Stefan Ehmann In-Reply-To: <200703042242.58748.shoesoft@gmx.net> Message-ID: <20070305142926.O2780@besplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@FreeBSD.org Subject: Re: notebook freezes 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, 05 Mar 2007 04:21:06 -0000 On Sun, 4 Mar 2007, Stefan Ehmann wrote: > On Sunday 04 March 2007 21:14, Nate Lawson wrote: >> Bruce Evans wrote: >>> [Trying to redirect this from current to acpi.] >>> >>> On Sun, 4 Mar 2007, Stefan Ehmann wrote: >>>> On Sunday 04 March 2007 13:27, Bruce Evans wrote: > ... >>>>> Oops. If suspend/resume clobbers the RTC state (which we already >>>>> have code >>>>> to restore), then it can clobber the RTC index (which even the restoral >>>>> code assumes is unclobbered). Try this fix. > ... >>>>> I don't know how any of this works with ACPI. AFAIK (not far), the >>>>> resume >>>>> hook is only called for APM. >>>> >>>> Yes, rtc_restore() doesn't get called. So the patch changes nothing >>>> for me. >> >> Bruce's patch should work if you add "device pmtimer" to your kernel >> config. That will allow pmtimer_resume() to call timer_restore() which >> calls rtc_restore(). >> >> If that works for you, Bruce can commit it modulo style bugs. ;-) Ha, some mailer mangled all the tabs inconsistently after I sent it. In the original version, there are only some style bugs in nearby comments that I wrote long ago. (The comments are misformatted and have rotted, but still provided hints that there are may be problems in the locking. I don't the current locking of individual RTC accesses since that just asks for races in sets of accesses.) > Oops, seems I somehow screwed up Bruce's patch on first try (pmtimer was > already in my config). Probably the aftermath of the lunar eclipse :) > > On my second try, timer_restore really gets called and it also fixes my > problem. Could you add some RTC accesses to determine exactly what state is inconsistent? Something like the following: cur_rtc_reg = inb(IO_RTC); /* Sloppy locking. */ printf("cur_rtc_reg = %02x, rtc_reg = %02x\n", cur_rtc_reg, rtc_reg); rtc_reg = -1; cur_rtc_statusa = rtcin(RTC_STATUSA); printf(...); cur_rtc_statusb = rtcin(RTC_STATUSB); printf(...); Where should such cghecks be put in acpi code if a hook like pmtimer's is not available or not understood? Where do timer updates on suspend/resume happen for acpi? Someday I need to figure out why my laptop (HP nx6325) clobbers the time when its lid is closed. Suspend stuff mostly doesn't doesn't work. In particular, closing the lid doesn't even turn off the screen, but it does clobber the time given by the acpi timecounter by almost exactly 1 second. The TSC timecounter doesn't lose like this but it loses in other ways. Opening the lid doesn't change the time. I don't have pmtimer configured, but pmtimer would mess up the time even more because the RTC drifts relative to the correct time and inittodr() doesn't sync with the RTC so it is always off by an average of -0.5 seconds. Bruce From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 08:52:09 2007 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 033E316A400 for ; Mon, 5 Mar 2007 08:52:09 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 5425113C428 for ; Mon, 5 Mar 2007 08:52:08 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 05 Mar 2007 08:52:06 -0000 X-Provags-ID: V01U2FsdGVkX19jJ8RaDRhj19mqTEh86BOiDv8YvewvZfdYpy+FQs Kld5yqV6fls7Yx From: Stefan Ehmann To: Bruce Evans In-Reply-To: <20070305142926.O2780@besplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> Content-Type: text/plain Date: Mon, 05 Mar 2007 09:52:04 +0100 Message-Id: <1173084724.1850.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-acpi@FreeBSD.org Subject: Re: notebook freezes 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, 05 Mar 2007 08:52:09 -0000 On Mon, 2007-03-05 at 15:21 +1100, Bruce Evans wrote: > On Sun, 4 Mar 2007, Stefan Ehmann wrote: > > Oops, seems I somehow screwed up Bruce's patch on first try (pmtimer was > > already in my config). Probably the aftermath of the lunar eclipse :) > > > > On my second try, timer_restore really gets called and it also fixes my > > problem. > > Could you add some RTC accesses to determine exactly what state is > inconsistent? Something like the following: > > cur_rtc_reg = inb(IO_RTC); /* Sloppy locking. */ > printf("cur_rtc_reg = %02x, rtc_reg = %02x\n", cur_rtc_reg, rtc_reg); > rtc_reg = -1; > cur_rtc_statusa = rtcin(RTC_STATUSA); > printf(...); > cur_rtc_statusb = rtcin(RTC_STATUSB); > printf(...); > Putting this on top of rtc_resume, I get this on resume (all values are hexadecimal): cur_rtc_reg = ff, rtc_reg = 0c cur_rtc_statusa = 29 cur_rtc_statusb = 42 From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 09:39:31 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A4CF16A401 for ; Mon, 5 Mar 2007 09:39:31 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 19C7113C428 for ; Mon, 5 Mar 2007 09:39:31 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id DBF5010D175; Mon, 5 Mar 2007 20:39:23 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 912462740A; Mon, 5 Mar 2007 20:39:26 +1100 (EST) Date: Mon, 5 Mar 2007 20:39:24 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Stefan Ehmann In-Reply-To: <1173084724.1850.3.camel@localhost> Message-ID: <20070305201904.K21224@delplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> <1173084724.1850.3.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org Subject: Re: notebook freezes 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, 05 Mar 2007 09:39:31 -0000 On Mon, 5 Mar 2007, Stefan Ehmann wrote: > On Mon, 2007-03-05 at 15:21 +1100, Bruce Evans wrote: >> On Sun, 4 Mar 2007, Stefan Ehmann wrote: >>> Oops, seems I somehow screwed up Bruce's patch on first try (pmtimer was >>> already in my config). Probably the aftermath of the lunar eclipse :) >>> >>> On my second try, timer_restore really gets called and it also fixes my >>> problem. >> >> Could you add some RTC accesses to determine exactly what state is >> inconsistent? Something like the following: >> >> cur_rtc_reg = inb(IO_RTC); /* Sloppy locking. */ >> printf("cur_rtc_reg = %02x, rtc_reg = %02x\n", cur_rtc_reg, rtc_reg); >> rtc_reg = -1; >> cur_rtc_statusa = rtcin(RTC_STATUSA); >> printf(...); >> cur_rtc_statusb = rtcin(RTC_STATUSB); >> printf(...); >> > > Putting this on top of rtc_resume, I get this on resume (all values are > hexadecimal): > > cur_rtc_reg = ff, rtc_reg = 0c > cur_rtc_statusa = 29 > cur_rtc_statusb = 42 Thanks. 29 and 42 are unclobbered, but ff is just invalid. Maybe it is what the BIOS writes to indicate invalidity. 0xc is the register usually accessed (RTC_INTR). Now I want to know what is the result of using this invalid index. Read through this index using inb(IO_RTC + 1) and rtcin(rtc_reg) before changing rtc_reg (the results should be the same). On my VIA amd64 system, the result of rtcin(0xff) is 0xff. Probably nothing there. This is is the worst possible result, since it ensures the problem pointed out in my commit of the initial fix -- rtcintr() will spin forever if it is called before rtc_restore(), waiting for one of the const bits in the 0xff result to become unset. I now have a completely different acpi problem to ask about. My HP nx6325 now shuts down an instant after booting FreeBSD with a 1 week old kernel, since the tz2 temperature is misdetected as 3413.3 degrees C. All temperatures seemed to be detected correctly in 3+ week old kernels. Only batter battery misdetection that caused shutdowns (less cleanly via panics) in the old kernels. Bruce From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 09:56:54 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D77016A401 for ; Mon, 5 Mar 2007 09:56:54 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 23DE513C481 for ; Mon, 5 Mar 2007 09:56:54 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 89A1E5A0732; Mon, 5 Mar 2007 20:56:53 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id B23608C02; Mon, 5 Mar 2007 20:56:52 +1100 (EST) Date: Mon, 5 Mar 2007 20:56:50 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Stefan Ehmann In-Reply-To: <20070305201904.K21224@delplex.bde.org> Message-ID: <20070305205433.O21398@delplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> <1173084724.1850.3.camel@localhost> <20070305201904.K21224@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org Subject: misdetection of tz2 temperature (was: notebook freezes) 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, 05 Mar 2007 09:56:54 -0000 On Mon, 5 Mar 2007, Bruce Evans wrote: > I now have a completely different acpi problem to ask about. My HP > nx6325 now shuts down an instant after booting FreeBSD with a 1 week > old kernel, since the tz2 temperature is misdetected as 3413.3 degrees > C. All temperatures seemed to be detected correctly in 3+ week old > kernels. Only batter battery misdetection that caused shutdowns (less > cleanly via panics) in the old kernels. This seems to be fixed in -current. Bruce From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 10:40:57 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 926B216A401 for ; Mon, 5 Mar 2007 10:40:57 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id F014C13C4A8 for ; Mon, 5 Mar 2007 10:40:56 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 05 Mar 2007 10:40:55 -0000 X-Provags-ID: V01U2FsdGVkX18sNigEQtws3lgOQe8yjwFPmkrOEz2OI5citB1wkz 5irRbF0Cyc3ID6 From: Stefan Ehmann To: Bruce Evans In-Reply-To: <20070305201904.K21224@delplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> <1173084724.1850.3.camel@localhost> <20070305201904.K21224@delplex.bde.org> Content-Type: text/plain Date: Mon, 05 Mar 2007 11:40:49 +0100 Message-Id: <1173091249.1276.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-acpi@freebsd.org Subject: Re: notebook freezes 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, 05 Mar 2007 10:40:57 -0000 On Mon, 2007-03-05 at 20:39 +1100, Bruce Evans wrote: > On Mon, 5 Mar 2007, Stefan Ehmann wrote: > > > On Mon, 2007-03-05 at 15:21 +1100, Bruce Evans wrote: > >> On Sun, 4 Mar 2007, Stefan Ehmann wrote: > >>> Oops, seems I somehow screwed up Bruce's patch on first try (pmtimer was > >>> already in my config). Probably the aftermath of the lunar eclipse :) > >>> > >>> On my second try, timer_restore really gets called and it also fixes my > >>> problem. > >> > >> Could you add some RTC accesses to determine exactly what state is > >> inconsistent? Something like the following: > >> > >> cur_rtc_reg = inb(IO_RTC); /* Sloppy locking. */ > >> printf("cur_rtc_reg = %02x, rtc_reg = %02x\n", cur_rtc_reg, rtc_reg); > >> rtc_reg = -1; > >> cur_rtc_statusa = rtcin(RTC_STATUSA); > >> printf(...); > >> cur_rtc_statusb = rtcin(RTC_STATUSB); > >> printf(...); > >> > > > > Putting this on top of rtc_resume, I get this on resume (all values are > > hexadecimal): > > > > cur_rtc_reg = ff, rtc_reg = 0c > > cur_rtc_statusa = 29 > > cur_rtc_statusb = 42 > > Thanks. 29 and 42 are unclobbered, but ff is just invalid. Maybe it is > what the BIOS writes to indicate invalidity. 0xc is the register usually > accessed (RTC_INTR). > > Now I want to know what is the result of using this invalid index. > Read through this index using inb(IO_RTC + 1) and rtcin(rtc_reg) before > changing rtc_reg (the results should be the same). On my VIA amd64 > system, the result of rtcin(0xff) is 0xff. Probably nothing there. > This is is the worst possible result, since it ensures the problem > pointed out in my commit of the initial fix -- rtcintr() will spin > forever if it is called before rtc_restore(), waiting for one of > the const bits in the 0xff result to become unset. It's 0xc8 here. From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 11:07:56 2007 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97B3516A401 for ; Mon, 5 Mar 2007 11:07:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6BA5113C48E for ; Mon, 5 Mar 2007 11:07:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l25B7u4n037369 for ; Mon, 5 Mar 2007 11:07:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l25B7tms037365 for freebsd-acpi@FreeBSD.org; Mon, 5 Mar 2007 11:07:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Mar 2007 11:07:55 GMT Message-Id: <200703051107.l25B7tms037365@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 05 Mar 2007 11:07:56 -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/55822 acpi No ACPI power off with SMP kernel o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/64002 acpi acpi problem o i386/67273 acpi [hang] system hangs with acpi and Xfree o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/79080 acpi acpi thermal changes freezes HP nx6110 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/106924 acpi ACPI resume returns g_vfs_done() errors and kernel pan 11 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 kern/73823 acpi [feature request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys f kern/90871 acpi ACPI problems with ASUS A8N-VM-CSM o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI o i386/97468 acpi [acpi] ACPI on ASUS A7V hangs on shutdown -p (power of o kern/98171 acpi [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop o i386/102343 acpi ACPI error o kern/103365 acpi [acpi] acpi poweroff doesn't work with geli device att o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/108488 acpi ACPI-1304: *** Error: Method execution failed o kern/108581 acpi sysctl: hw.acpi.cpu.cx_lowest: Invalid argument o kern/108695 acpi [ACPI]: Fatal trap 9: general protection fault when in o kern/109207 acpi ACPI Promlem 15 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 11:09:27 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3B2C16A400 for ; Mon, 5 Mar 2007 11:09:27 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4B52C13C4BE for ; Mon, 5 Mar 2007 11:09:27 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 154EB1110A5; Mon, 5 Mar 2007 22:09:22 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 68DA327406; Mon, 5 Mar 2007 22:09:24 +1100 (EST) Date: Mon, 5 Mar 2007 22:08:25 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Stefan Ehmann In-Reply-To: <20070305205433.O21398@delplex.bde.org> Message-ID: <20070305215821.Y16645@besplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> <1173084724.1850.3.camel@localhost> <20070305201904.K21224@delplex.bde.org> <20070305205433.O21398@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org Subject: Re: misdetection of tz2 temperature (was: notebook freezes) 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, 05 Mar 2007 11:09:27 -0000 On Mon, 5 Mar 2007, Bruce Evans wrote: > On Mon, 5 Mar 2007, Bruce Evans wrote: > >> I now have a completely different acpi problem to ask about. My HP >> nx6325 now shuts down an instant after booting FreeBSD with a 1 week >> old kernel, since the tz2 temperature is misdetected as 3413.3 degrees >> C. All temperatures seemed to be detected correctly in 3+ week old >> kernels. Only batter battery misdetection that caused shutdowns (less >> cleanly via panics) in the old kernels. > > This seems to be fixed in -current. Actually, -current just reboots after 10 minutes instead of instantly. Soon after booting, sysctl -a | grep acpi says: % debug.acpi.semaphore_debug: 0 % debug.acpi.acpi_ca_version: 20051021 % debug.acpi.do_powerstate: 1 % debug.acpi.ec.burst: 1 % debug.acpi.ec.poll_time: 500 % debug.acpi.ec.timeout: 500 % debug.acpi.resume_beep: 0 % hw.acpi.supported_sleep_state: S3 S4 S5 % hw.acpi.power_button_state: S5 % hw.acpi.sleep_button_state: S3 % hw.acpi.lid_switch_state: NONE % hw.acpi.standby_state: S1 % hw.acpi.suspend_state: S3 % hw.acpi.sleep_delay: 1 % hw.acpi.s4bios: 1 % hw.acpi.verbose: 0 % hw.acpi.disable_on_reboot: 0 % hw.acpi.handle_reboot: 0 % hw.acpi.reset_video: 0 % hw.acpi.cpu.cx_lowest: C1 % hw.acpi.battery.life: 100 % hw.acpi.battery.time: -1 % hw.acpi.battery.state: 0 % hw.acpi.battery.units: 2 % hw.acpi.battery.info_expire: 5 % hw.acpi.acline: 0 % hw.acpi.thermal.min_runtime: 0 % hw.acpi.thermal.polling_rate: 10 % hw.acpi.thermal.user_override: 0 % hw.acpi.thermal.tz0.temperature: 50.0C % hw.acpi.thermal.tz0.active: 3 % hw.acpi.thermal.tz0.passive_cooling: 1 % hw.acpi.thermal.tz0.thermal_flags: 0 % hw.acpi.thermal.tz0._PSV: 95.0C % hw.acpi.thermal.tz0._HOT: -1 % hw.acpi.thermal.tz0._CRT: 105.0C % hw.acpi.thermal.tz0._ACx: 75.0C 65.0C 55.0C 40.0C -1 -1 -1 -1 -1 -1 % hw.acpi.thermal.tz1.temperature: 49.0C % hw.acpi.thermal.tz1.active: -1 % hw.acpi.thermal.tz1.passive_cooling: 0 % hw.acpi.thermal.tz1.thermal_flags: 0 % hw.acpi.thermal.tz1._PSV: 90.0C % hw.acpi.thermal.tz1._HOT: -1 % hw.acpi.thermal.tz1._CRT: 100.0C % hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 % hw.acpi.thermal.tz2.temperature: 3414.3C !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! % hw.acpi.thermal.tz2.active: -1 % hw.acpi.thermal.tz2.passive_cooling: 0 % hw.acpi.thermal.tz2.thermal_flags: 9 % hw.acpi.thermal.tz2._PSV: 50.0C % hw.acpi.thermal.tz2._HOT: -1 % hw.acpi.thermal.tz2._CRT: 100.0C % hw.acpi.thermal.tz2._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 % machdep.acpi_timer_freq: 3579545 % machdep.acpi_root: 1015088 % dev.acpi.0.%desc: HP 0944 % dev.acpi.0.%driver: acpi % dev.acpi.0.%parent: nexus0 % dev.acpi_sysresource.0.%desc: System Resource % dev.acpi_sysresource.0.%driver: acpi_sysresource % dev.acpi_sysresource.0.%location: handle=\_SB_.C011 % dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C01 _UID=0 % dev.acpi_sysresource.0.%parent: acpi0 % dev.acpi_sysresource.1.%desc: System Resource % dev.acpi_sysresource.1.%driver: acpi_sysresource % dev.acpi_sysresource.1.%location: handle=\_SB_.C074.C0E3.C330 % dev.acpi_sysresource.1.%pnpinfo: _HID=PNP0C02 _UID=2 % dev.acpi_sysresource.1.%parent: acpi0 % dev.acpi_sysresource.2.%desc: System Resource % dev.acpi_sysresource.2.%driver: acpi_sysresource % dev.acpi_sysresource.2.%location: handle=\_SB_.C074.C32E % dev.acpi_sysresource.2.%pnpinfo: _HID=PNP0C02 _UID=1 % dev.acpi_sysresource.2.%parent: acpi0 % dev.acpi_sysresource.3.%desc: System Resource % dev.acpi_sysresource.3.%driver: acpi_sysresource % dev.acpi_sysresource.3.%location: handle=\_SB_.C315 % dev.acpi_sysresource.3.%pnpinfo: _HID=PNP0C02 _UID=0 % dev.acpi_sysresource.3.%parent: acpi0 % dev.acpi_timer.0.%desc: 32-bit timer at 3.579545MHz % dev.acpi_timer.0.%driver: acpi_timer % dev.acpi_timer.0.%location: unknown % dev.acpi_timer.0.%pnpinfo: unknown % dev.acpi_timer.0.%parent: acpi0 % dev.acpi_ec.0.%desc: Embedded Controller: GPE 0x11 % dev.acpi_ec.0.%driver: acpi_ec % dev.acpi_ec.0.%location: handle=\_SB_.C074.C0E3.C149 % dev.acpi_ec.0.%pnpinfo: _HID=PNP0C09 _UID=0 % dev.acpi_ec.0.%parent: acpi0 % dev.pci_link.0.%parent: acpi0 % dev.pci_link.1.%parent: acpi0 % dev.pci_link.2.%parent: acpi0 % dev.pci_link.3.%parent: acpi0 % dev.pci_link.4.%parent: acpi0 % dev.pci_link.5.%parent: acpi0 % dev.pci_link.6.%parent: acpi0 % dev.pci_link.7.%parent: acpi0 % dev.cpu.0.%parent: acpi0 % dev.cpu.1.%parent: acpi0 % dev.acpi_perf.0.%driver: acpi_perf % dev.acpi_perf.0.%parent: cpu0 % dev.acpi_perf.1.%driver: acpi_perf % dev.acpi_perf.1.%parent: cpu1 % dev.acpi_throttle.0.%desc: ACPI CPU Throttling % dev.acpi_throttle.0.%driver: acpi_throttle % dev.acpi_throttle.0.%parent: cpu0 % dev.acpi_throttle.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 % dev.pcib.0.%parent: acpi0 % dev.battery.0.%parent: acpi0 % dev.battery.1.%parent: acpi0 % dev.acpi_acad.0.%desc: AC Adapter % dev.acpi_acad.0.%driver: acpi_acad % dev.acpi_acad.0.%location: handle=\_SB_.C1BD % dev.acpi_acad.0.%pnpinfo: _HID=ACPI0003 _UID=0 % dev.acpi_acad.0.%parent: acpi0 % dev.acpi_button.0.%desc: Sleep Button % dev.acpi_button.0.%driver: acpi_button % dev.acpi_button.0.%location: handle=\_SB_.C25A % dev.acpi_button.0.%pnpinfo: _HID=PNP0C0E _UID=0 % dev.acpi_button.0.%parent: acpi0 % dev.acpi_lid.0.%desc: Control Method Lid Switch % dev.acpi_lid.0.%driver: acpi_lid % dev.acpi_lid.0.%location: handle=\_SB_.C25B % dev.acpi_lid.0.%pnpinfo: _HID=PNP0C0D _UID=0 % dev.acpi_lid.0.%parent: acpi0 % dev.acpi_tz.0.%desc: Thermal Zone % dev.acpi_tz.0.%driver: acpi_tz % dev.acpi_tz.0.%location: handle=\_TZ_.TZ1_ % dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 % dev.acpi_tz.0.%parent: acpi0 % dev.acpi_tz.1.%desc: Thermal Zone % dev.acpi_tz.1.%driver: acpi_tz % dev.acpi_tz.1.%location: handle=\_TZ_.TZ2_ % dev.acpi_tz.1.%pnpinfo: _HID=none _UID=0 % dev.acpi_tz.1.%parent: acpi0 % dev.acpi_tz.2.%desc: Thermal Zone % dev.acpi_tz.2.%driver: acpi_tz % dev.acpi_tz.2.%location: handle=\_TZ_.TZ3_ % dev.acpi_tz.2.%pnpinfo: _HID=none _UID=0 % dev.acpi_tz.2.%parent: acpi0 % dev.npxisa.0.%parent: acpi0 % dev.attimer.0.%parent: acpi0 % dev.attimer.1.%parent: acpi0 % dev.atdma.0.%parent: acpi0 % dev.speaker.0.%parent: acpi0 % dev.atkbdc.0.%parent: acpi0 % dev.psmcpnp.0.%parent: acpi0 % dev.atpic.0.%parent: acpi0 % dev.ppc.0.%parent: acpi0 My kernel doesn't have any known related modules except acpi itself, and my doesn't do any known configuration of acpi. Bruce From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 19:04:45 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6432F16A401 for ; Mon, 5 Mar 2007 19:04:45 +0000 (UTC) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.freebsd.org (Postfix) with ESMTP id 376F513C4BC for ; Mon, 5 Mar 2007 19:04:45 +0000 (UTC) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 8578FD800; Mon, 5 Mar 2007 13:31:14 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id 27A2E61C8A; Mon, 5 Mar 2007 13:31:20 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <17900.25080.59757.122204@canoe.dclg.ca> Date: Mon, 5 Mar 2007 13:31:20 -0500 To: Nate Lawson In-Reply-To: <45E75C67.5050107@root.org> References: <8af9710703010127r64733012h20859ff9a61967bd@mail.gmail.com> <45E75C67.5050107@root.org> X-Mailer: VM 7.17 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid Cc: freebsd-acpi@freebsd.org Subject: Re: umass driver doesn't rescan the bus 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, 05 Mar 2007 19:04:45 -0000 >>>>> "Nate" =3D=3D Nate Lawson writes: Nate> Micha=C5=82 Frynas wrote: >> I've got a small problem when trying to configure the devd daemon >> to work with umass driver. Here's what I'm trying to achive: I >> configured the devd to handle the nomatch event as follows: >>=20 >> nomatch 100 { match "vendor" "[ven_id]"; match "product" >> "[prod_id]"; match "release" "[rel_id]"; action "if ! kldstat -n >> umass; then kldload umass; fi"; }; >>=20 >> detach 100 { device-name "umass[0-9]+"; action "if kldstat -n >> umass; then kldunload; fi"; }; [...] Nate> This is not at all an ACPI question but I think I can answer it. Nate> umass isn't a device type, it's a transfer method for SCSI or Nate> ATA devices. In most cases devices are SCSI and thus the da [...] Nate> Solution: load umass at boot. Actually, this is a fundamental flaw in our USB driver stack. If a new driver comes available that is able to better handle a device, it cannot. The converse is also true: If a device has properties of a more complex driver, it will attach to the more complex driver and you cannot use simple (pass) driver methods to access it. It almost seems as if something along the lines of geom is required for usb. ie: drivers that allow each level of the device be opened and stack on top of each other without stupid performance penalties. Dave. --=20 =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=3D=3D=3D=3D=3D= =3D=3D=3D=3D |David Gilbert, Independent Contractor. | Two things can be = | |Mail: dave@daveg.ca | equal if and only if t= hey | |http://daveg.ca | are precisely opposit= e. | =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=3DGLO=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 21:49:02 2007 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 604E616A402 for ; Mon, 5 Mar 2007 21:49:02 +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 490DE13C49D for ; Mon, 5 Mar 2007 21:49:02 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 9708 invoked from network); 5 Mar 2007 21:19:08 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 5 Mar 2007 21:19:08 -0000 Message-ID: <45EC8969.8060405@root.org> Date: Mon, 05 Mar 2007 13:19:37 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Bruce Evans References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> In-Reply-To: <20070305142926.O2780@besplex.bde.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Stefan Ehmann Subject: Re: notebook freezes 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, 05 Mar 2007 21:49:02 -0000 Bruce Evans wrote: > On Sun, 4 Mar 2007, Stefan Ehmann wrote: > >> On Sunday 04 March 2007 21:14, Nate Lawson wrote: >>> Bruce Evans wrote: >>>> [Trying to redirect this from current to acpi.] >>>> >>>> On Sun, 4 Mar 2007, Stefan Ehmann wrote: >>>>> On Sunday 04 March 2007 13:27, Bruce Evans wrote: >> ... >>>>>> Oops. If suspend/resume clobbers the RTC state (which we already >>>>>> have code >>>>>> to restore), then it can clobber the RTC index (which even the >>>>>> restoral >>>>>> code assumes is unclobbered). Try this fix. >> ... >>>>>> I don't know how any of this works with ACPI. AFAIK (not far), the >>>>>> resume >>>>>> hook is only called for APM. >>>>> >>>>> Yes, rtc_restore() doesn't get called. So the patch changes nothing >>>>> for me. >>> >>> Bruce's patch should work if you add "device pmtimer" to your kernel >>> config. That will allow pmtimer_resume() to call timer_restore() which >>> calls rtc_restore(). >>> >>> If that works for you, Bruce can commit it modulo style bugs. ;-) > > Ha, some mailer mangled all the tabs inconsistently after I sent it. In > the original version, there are only some style bugs in nearby comments > that I wrote long ago. (The comments are misformatted and have rotted, > but still provided hints that there are may be problems in the locking. > I don't the current locking of individual RTC accesses since that just > asks for races in sets of accesses.) > >> Oops, seems I somehow screwed up Bruce's patch on first try (pmtimer was >> already in my config). Probably the aftermath of the lunar eclipse :) >> >> On my second try, timer_restore really gets called and it also fixes my >> problem. > > Could you add some RTC accesses to determine exactly what state is > inconsistent? Something like the following: > > cur_rtc_reg = inb(IO_RTC); /* Sloppy locking. */ > printf("cur_rtc_reg = %02x, rtc_reg = %02x\n", cur_rtc_reg, rtc_reg); > rtc_reg = -1; > cur_rtc_statusa = rtcin(RTC_STATUSA); > printf(...); > cur_rtc_statusb = rtcin(RTC_STATUSB); > printf(...); > > Where should such cghecks be put in acpi code if a hook like pmtimer's > is not available or not understood? I don't understand. Every driver implements a DEVICE_RESUME() method and that is responsible for figuring out the device-specific issues for properly restoring the hw from any state, likely all state lost. > Where do timer updates on suspend/resume happen for acpi? pmtimer handles both (see NOTES) since DEVICE_RESUME() is called from both apm and acpi. > Someday I > need to figure out why my laptop (HP nx6325) clobbers the time when > its lid is closed. Suspend stuff mostly doesn't doesn't work. In > particular, closing the lid doesn't even turn off the screen, but it > does clobber the time given by the acpi timecounter by almost exactly > 1 second. The TSC timecounter doesn't lose like this but it loses in > other ways. Opening the lid doesn't change the time. I don't have > pmtimer configured, but pmtimer would mess up the time even more because > the RTC drifts relative to the correct time and inittodr() doesn't > sync with the RTC so it is always off by an average of -0.5 seconds. No idea -- is something running in SMM for a long time? I seem to remember you had access to an oscilloscope. Check out the cpu pin SMACT# when you close the lid. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 21:50:28 2007 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8981C16A508 for ; Mon, 5 Mar 2007 21:50:28 +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 5861113C441 for ; Mon, 5 Mar 2007 21:50:28 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 9839 invoked from network); 5 Mar 2007 21:20:47 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 5 Mar 2007 21:20:47 -0000 Message-ID: <45EC89CD.5050907@root.org> Date: Mon, 05 Mar 2007 13:21:17 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Stefan Ehmann References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> <1173084724.1850.3.camel@localhost> In-Reply-To: <1173084724.1850.3.camel@localhost> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: notebook freezes 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, 05 Mar 2007 21:50:28 -0000 Stefan Ehmann wrote: > On Mon, 2007-03-05 at 15:21 +1100, Bruce Evans wrote: >> On Sun, 4 Mar 2007, Stefan Ehmann wrote: >>> Oops, seems I somehow screwed up Bruce's patch on first try (pmtimer was >>> already in my config). Probably the aftermath of the lunar eclipse :) >>> >>> On my second try, timer_restore really gets called and it also fixes my >>> problem. >> Could you add some RTC accesses to determine exactly what state is >> inconsistent? Something like the following: >> >> cur_rtc_reg = inb(IO_RTC); /* Sloppy locking. */ >> printf("cur_rtc_reg = %02x, rtc_reg = %02x\n", cur_rtc_reg, rtc_reg); >> rtc_reg = -1; >> cur_rtc_statusa = rtcin(RTC_STATUSA); >> printf(...); >> cur_rtc_statusb = rtcin(RTC_STATUSB); >> printf(...); >> > > Putting this on top of rtc_resume, I get this on resume (all values are > hexadecimal): > > cur_rtc_reg = ff, rtc_reg = 0c > cur_rtc_statusa = 29 > cur_rtc_statusb = 42 Yes, that's what I expected. Reads from uninitialized regions of the southbridge usually return all 1's. PCI config registers usually show the same thing on resume until reprogrammed. The solution is to not assume anything about the state of the RTC in the resume method and always reprogram all the registers as if it was coming up from hard power off. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 21:56:15 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DEA416A400 for ; Mon, 5 Mar 2007 21:56:15 +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 5BD8A13C4AA for ; Mon, 5 Mar 2007 21:56:15 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 10634 invoked from network); 5 Mar 2007 21:27:16 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 5 Mar 2007 21:27:16 -0000 Message-ID: <45EC8B53.3010409@root.org> Date: Mon, 05 Mar 2007 13:27:47 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Bruce Evans References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> <1173084724.1850.3.camel@localhost> <20070305201904.K21224@delplex.bde.org> <20070305205433.O21398@delplex.bde.org> In-Reply-To: <20070305205433.O21398@delplex.bde.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: misdetection of tz2 temperature 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, 05 Mar 2007 21:56:15 -0000 [Stefan removed from cc] Bruce Evans wrote: > On Mon, 5 Mar 2007, Bruce Evans wrote: > >> I now have a completely different acpi problem to ask about. My HP >> nx6325 now shuts down an instant after booting FreeBSD with a 1 week >> old kernel, since the tz2 temperature is misdetected as 3413.3 degrees >> C. All temperatures seemed to be detected correctly in 3+ week old >> kernels. Only batter battery misdetection that caused shutdowns (less >> cleanly via panics) in the old kernels. > > This seems to be fixed in -current. I recently committed a major reworking of the embedded controller driver. See this message: http://lists.freebsd.org/pipermail/freebsd-current/2007-February/069525.html See this message for a list of things to try. The goal is to diagnose why the EC is timing out. The thermal misdetection is only a symptom. http://lists.freebsd.org/pipermail/freebsd-current/2007-February/069577.html The one I think would be most helpful is increasing the total time spent waiting, but I would appreciate your help seeing what combo of polling/total timeout works for you. debug.acpi.ec.timeout=1000 # 1 sec total Thanks, -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 22:09:16 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6CEA16A404 for ; Mon, 5 Mar 2007 22:09:16 +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 A343B13C461 for ; Mon, 5 Mar 2007 22:09:16 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 12072 invoked from network); 5 Mar 2007 21:41:16 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 5 Mar 2007 21:41:16 -0000 Message-ID: <45EC8E9A.7030702@root.org> Date: Mon, 05 Mar 2007 13:41:46 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Bruce Evans References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> <1173084724.1850.3.camel@localhost> <20070305201904.K21224@delplex.bde.org> <20070305205433.O21398@delplex.bde.org> <20070305215821.Y16645@besplex.bde.org> In-Reply-To: <20070305215821.Y16645@besplex.bde.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: misdetection of tz2 temperature 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, 05 Mar 2007 22:09:16 -0000 Bruce Evans wrote: > On Mon, 5 Mar 2007, Bruce Evans wrote: > >> On Mon, 5 Mar 2007, Bruce Evans wrote: >> >>> I now have a completely different acpi problem to ask about. My HP >>> nx6325 now shuts down an instant after booting FreeBSD with a 1 week >>> old kernel, since the tz2 temperature is misdetected as 3413.3 degrees >>> C. All temperatures seemed to be detected correctly in 3+ week old >>> kernels. Only batter battery misdetection that caused shutdowns (less >>> cleanly via panics) in the old kernels. >> >> This seems to be fixed in -current. > > Actually, -current just reboots after 10 minutes instead of instantly. I've committed a patch that checks the _TMP level for sanity so that should solve the symptom (premature shutdown). I hope you can help me keep analyzing the EC timeout that is the real issue. Thanks, -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 22:26:08 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA78216A407 for ; Mon, 5 Mar 2007 22:26:08 +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 86BB913C4A8 for ; Mon, 5 Mar 2007 22:26:08 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga02.intel.com with ESMTP; 05 Mar 2007 14:26:08 -0800 Received: from orsmsx335.jf.intel.com ([10.22.226.40]) by orsmga001.jf.intel.com with ESMTP; 05 Mar 2007 14:26:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.14,251,1170662400"; d="scan'208"; a="204224935:sNHT20740727" Received: from orsmsx415.amr.corp.intel.com ([10.22.226.49]) by orsmsx335.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 14:26:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Mar 2007 14:26:06 -0800 Message-ID: In-Reply-To: <200703012314.37530.joao@matik.com.br> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Error: Handler for [SystemMemory] returned AE_AML_ALIGNMENT Thread-Index: AcdccI/73WvDBhx0SV+3AZmkXc00vADBIlEQ From: "Moore, Robert" To: "JoaoBR" , X-OriginalArrivalTime: 05 Mar 2007 22:26:08.0132 (UTC) FILETIME=[45452440:01C75F75] Cc: Subject: RE: Error: Handler for [SystemMemory] returned AE_AML_ALIGNMENT 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, 05 Mar 2007 22:26:08 -0000 This exception happens when 1) Executing on a platform that does not support non-aligned memory = transfer 2) an operation region request is misaligned What system is this running on? #ifdef ACPI_MISALIGNMENT_NOT_SUPPORTED /* * Hardware does not support non-aligned data transfers, we must = verify * the request. */ (void) AcpiUtShortDivide ((ACPI_INTEGER) Address, Length, NULL, = &Remainder); if (Remainder !=3D 0) { return_ACPI_STATUS (AE_AML_ALIGNMENT); } #endif > -----Original Message----- > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > acpi@freebsd.org] On Behalf Of JoaoBR > Sent: Thursday, March 01, 2007 6:15 PM > To: freebsd-acpi@freebsd.org > Subject: Error: Handler for [SystemMemory] returned AE_AML_ALIGNMENT >=20 > Hi > somebody has an advice for me, should I do something about this erro? >=20 > ACPI-0501: *** Error: Handler for [SystemMemory] returned > AE_AML_ALIGNMENT > ACPI-1304: *** Error: Method execution failed [\\_SB_.MEM_._CRS] = (Node > 0xffffff0000806cc0), AE_AML_ALIGNMENT > ACPI-0239: *** Error: Method execution failed [\\_SB_.MEM_._CRS] = (Node > 0xffffff0000806cc0), AE_AML_ALIGNMENT > can't fetch resources for \\_SB_.MEM_ - AE_AML_ALIGNMENT >=20 >=20 > -- > thank's > Jo=E3o >=20 >=20 >=20 >=20 >=20 >=20 >=20 > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > segura. > Service fornecido pelo Datacenter Matik = https://datacenter.matik.com.br > _______________________________________________ > 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 Mar 6 15:39:52 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7519016A400 for ; Tue, 6 Mar 2007 15:39:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id A22E213C4A5 for ; Tue, 6 Mar 2007 15:39:51 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 l26FdevG011726; Tue, 6 Mar 2007 10:39:41 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Tue, 6 Mar 2007 10:27:01 -0500 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200703061027.01809.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 06 Mar 2007 10:39:43 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2745/Tue Mar 6 08:59:40 2007 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: "Moore, Robert" Subject: Re: Error: Handler for [SystemMemory] returned AE_AML_ALIGNMENT 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, 06 Mar 2007 15:39:52 -0000 On Monday 05 March 2007 17:26, Moore, Robert wrote: > This exception happens when > 1) Executing on a platform that does not support non-aligned memory trans= fer > 2) an operation region request is misaligned >=20 > What system is this running on? >=20 > #ifdef ACPI_MISALIGNMENT_NOT_SUPPORTED > /* > * Hardware does not support non-aligned data transfers, we must veri= fy > * the request. > */ > (void) AcpiUtShortDivide ((ACPI_INTEGER) Address, Length, NULL,=20 &Remainder); > if (Remainder !=3D 0) > { > return_ACPI_STATUS (AE_AML_ALIGNMENT); > } > #endif I think there were some older versions (5.x maybe?) of FreeBSD where this=20 #define was on for FreeBSD/amd64. What version of FreeBSD is this? > > -----Original Message----- > > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > > acpi@freebsd.org] On Behalf Of JoaoBR > > Sent: Thursday, March 01, 2007 6:15 PM > > To: freebsd-acpi@freebsd.org > > Subject: Error: Handler for [SystemMemory] returned AE_AML_ALIGNMENT > >=20 > > Hi > > somebody has an advice for me, should I do something about this erro? > >=20 > > ACPI-0501: *** Error: Handler for [SystemMemory] returned > > AE_AML_ALIGNMENT > > ACPI-1304: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (N= ode > > 0xffffff0000806cc0), AE_AML_ALIGNMENT > > ACPI-0239: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (N= ode > > 0xffffff0000806cc0), AE_AML_ALIGNMENT > > can't fetch resources for \\_SB_.MEM_ - AE_AML_ALIGNMENT > >=20 > >=20 > > -- > > thank's > > Jo=E3o > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > > segura. > > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > > _______________________________________________ > > 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" > _______________________________________________ > 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" >=20 =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 6 15:40:04 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E22216A402 for ; Tue, 6 Mar 2007 15:40:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2F2B513C428 for ; Tue, 6 Mar 2007 15:40:04 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 l26FdevH011726; Tue, 6 Mar 2007 10:39:50 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Tue, 6 Mar 2007 10:27:24 -0500 User-Agent: KMail/1.9.1 References: <200703011612.07110.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> <45EC8969.8060405@root.org> In-Reply-To: <45EC8969.8060405@root.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200703061027.25387.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 06 Mar 2007 10:39:54 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2745/Tue Mar 6 08:59:40 2007 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: Stefan Ehmann Subject: Re: notebook freezes 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, 06 Mar 2007 15:40:04 -0000 On Monday 05 March 2007 16:19, Nate Lawson wrote: > > Where do timer updates on suspend/resume happen for acpi? > > pmtimer handles both (see NOTES) since DEVICE_RESUME() is called from > both apm and acpi. pmtimer should be on by default in 7 I think. It is for amd64 already IIRC, just not for i386. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 6 17:33:31 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E01416A411 for ; Tue, 6 Mar 2007 17:33:31 +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 F09BA13C4C2 for ; Tue, 6 Mar 2007 17:33:30 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 36407 invoked from network); 6 Mar 2007 16:56:44 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 6 Mar 2007 16:56:44 -0000 Message-ID: <45ED9D71.5040904@root.org> Date: Tue, 06 Mar 2007 08:57:21 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: John Baldwin References: <200703011612.07110.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> <45EC8969.8060405@root.org> <200703061027.25387.jhb@freebsd.org> In-Reply-To: <200703061027.25387.jhb@freebsd.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Stefan Ehmann Subject: Re: notebook freezes 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, 06 Mar 2007 17:33:31 -0000 John Baldwin wrote: > On Monday 05 March 2007 16:19, Nate Lawson wrote: >>> Where do timer updates on suspend/resume happen for acpi? >> pmtimer handles both (see NOTES) since DEVICE_RESUME() is called from >> both apm and acpi. > > pmtimer should be on by default in 7 I think. It is for amd64 already IIRC, > just not for i386. > Yeah, I see it in GENERIC. His issue was just driver error with the patch. The patch has been committed. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 6 18:09:54 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B8DA16A402 for ; Tue, 6 Mar 2007 18:09:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id E075F13C4AC for ; Tue, 6 Mar 2007 18:09:53 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 l26I9ofl012599; Tue, 6 Mar 2007 13:09:50 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nate Lawson Date: Tue, 6 Mar 2007 13:10:10 -0500 User-Agent: KMail/1.9.1 References: <200703011612.07110.shoesoft@gmx.net> <200703061027.25387.jhb@freebsd.org> <45ED9D71.5040904@root.org> In-Reply-To: <45ED9D71.5040904@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703061310.11346.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]); Tue, 06 Mar 2007 13:09:51 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2747/Tue Mar 6 10:49:25 2007 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, Stefan Ehmann Subject: Re: notebook freezes 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, 06 Mar 2007 18:09:54 -0000 On Tuesday 06 March 2007 11:57, Nate Lawson wrote: > John Baldwin wrote: > > On Monday 05 March 2007 16:19, Nate Lawson wrote: > >>> Where do timer updates on suspend/resume happen for acpi? > >> pmtimer handles both (see NOTES) since DEVICE_RESUME() is called from > >> both apm and acpi. > > > > pmtimer should be on by default in 7 I think. It is for amd64 already IIRC, > > just not for i386. > > > > Yeah, I see it in GENERIC. His issue was just driver error with the > patch. The patch has been committed. I'm saying in general that pmtimer should really not be optional. It's a small amount of code, so there isn't really anything gained by leaving it out. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 7 04:57:37 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3729416A400 for ; Wed, 7 Mar 2007 04:57:37 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id B657113C4B5 for ; Wed, 7 Mar 2007 04:57:36 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id 5B7D15A7E30; Wed, 7 Mar 2007 15:57:33 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 6E03827404; Wed, 7 Mar 2007 15:57:31 +1100 (EST) Date: Wed, 7 Mar 2007 15:57:19 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Nate Lawson In-Reply-To: <45EC8969.8060405@root.org> Message-ID: <20070307155444.G28283@delplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> <45EC8969.8060405@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org, Stefan Ehmann Subject: Re: notebook freezes 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, 07 Mar 2007 04:57:37 -0000 On Mon, 5 Mar 2007, Nate Lawson wrote: > Bruce Evans wrote: >> Could you add some RTC accesses to determine exactly what state is >> inconsistent? Something like the following: >> >> cur_rtc_reg = inb(IO_RTC); /* Sloppy locking. */ >> printf("cur_rtc_reg = %02x, rtc_reg = %02x\n", cur_rtc_reg, rtc_reg); >> rtc_reg = -1; >> cur_rtc_statusa = rtcin(RTC_STATUSA); >> printf(...); >> cur_rtc_statusb = rtcin(RTC_STATUSB); >> printf(...); >> >> Where should such cghecks be put in acpi code if a hook like pmtimer's >> is not available or not understood? > > I don't understand. Every driver implements a DEVICE_RESUME() method > and that is responsible for figuring out the device-specific issues for > properly restoring the hw from any state, likely all state lost. I didn't know that there was a generic device resume hook. clock.c already has one, but it is bogus. It is just bus_generic_resume, but the "clock" driver (which names itself inconsistently as attimer[01]) has no children, so bus_generic_resume is a no-op. It partially knows that it is wrong and annotates its suspend/resume methods with a comment saying what they should do. Also, the attimer part of clock.c is only compiled if isa is configured, and seems to only by attached if the system supports PnP. pmtimer seems to have been reduced to just a hack to work around these bugs. It doesn't depend on isa or PnP, and does very little except use what should be clock.c's private suspend/resume methods. Grepping for bus_generic_resume seems to show a couple of other leaf devices using these. >> Where do timer updates on suspend/resume happen for acpi? > > pmtimer handles both (see NOTES) since DEVICE_RESUME() is called from > both apm and acpi. So part of a complete fix is to merge the "i386" pmtimer.c into the i386 and amd64 clock.c's, make it unconditional or conditional on acpi | apm (messy with modules), and remove it? I'm not sure how to remove the conditionals on isa and PnP. >> Someday I >> need to figure out why my laptop (HP nx6325) clobbers the time when >> its lid is closed. Suspend stuff mostly doesn't doesn't work. In >> particular, closing the lid doesn't even turn off the screen, but it >> does clobber the time given by the acpi timecounter by almost exactly >> 1 second. The TSC timecounter doesn't lose like this but it loses in >> other ways. Opening the lid doesn't change the time. I don't have >> pmtimer configured, but pmtimer would mess up the time even more because >> the RTC drifts relative to the correct time and inittodr() doesn't >> sync with the RTC so it is always off by an average of -0.5 seconds. > > No idea -- is something running in SMM for a long time? I seem to > remember you had access to an oscilloscope. Check out the cpu pin > SMACT# when you close the lid. No, I don't have an oscilloscope. The time difference seems to be too precise to be caused by anything outside of FreeBSD. According to ntpdate -q every second: % server 192.168.2.7, stratum 6, offset -19.000175, delay 0.02568 % 7 Mar 15:17:47 ntpdate[7122]: step time server 192.168.2.7 offset -19.000175 sec The clock was stepped 19 seconds by 19 previous lid closings. % server 192.168.2.7, stratum 6, offset -19.000174, delay 0.02568 % 7 Mar 15:17:48 ntpdate[7124]: step time server 192.168.2.7 offset -19.000174 sec % server 192.168.2.7, stratum 6, offset -19.000174, delay 0.02568 % 7 Mar 15:17:49 ntpdate[7126]: step time server 192.168.2.7 offset -19.000174 sec % server 192.168.2.7, stratum 6, offset -19.000174, delay 0.02568 % 7 Mar 15:17:50 ntpdate[7128]: step time server 192.168.2.7 offset -19.000174 sec % server 192.168.2.7, stratum 6, offset -19.000173, delay 0.02568 % 7 Mar 15:17:51 ntpdate[7130]: step time server 192.168.2.7 offset -19.000173 sec % server 192.168.2.7, stratum 6, offset -19.000174, delay 0.02568 % 7 Mar 15:17:52 ntpdate[7132]: step time server 192.168.2.7 offset -19.000174 sec % server 192.168.2.7, stratum 6, offset -19.000175, delay 0.02568 % 7 Mar 15:17:53 ntpdate[7134]: step time server 192.168.2.7 offset -19.000175 sec The relative clocks are drifting at < 1 ppm. The server timercounter is ACPI-fast and the client timecounter is TSC. Both are synced to a local ntp server. Contrary to what I said before, the TSC timecounter on the server also jumps by 1 second (but with jitter +- 200 msec due to SMP etc.) when the lid is closed. % server 192.168.2.7, stratum 6, offset -20.000179, delay 0.02568 % 7 Mar 15:17:56 ntpdate[7136]: step time server 192.168.2.7 offset -20.000179 sec 1 more lid closing stepped the relative clocks by -1 second - 4uS. % server 192.168.2.7, stratum 6, offset -20.000177, delay 0.02568 % 7 Mar 15:17:57 ntpdate[7138]: step time server 192.168.2.7 offset -20.000177 sec 2 of the 4 uS was apparently jitter. ntp is very unlikely to have started fixing up the 1-second jump or even the previous 19 1-second jumps yet. % server 192.168.2.7, stratum 6, offset -20.000177, delay 0.02568 % 7 Mar 15:17:58 ntpdate[7140]: step time server 192.168.2.7 offset -20.000177 sec % server 192.168.2.7, stratum 6, offset -20.000178, delay 0.02568 % 7 Mar 15:17:59 ntpdate[7142]: step time server 192.168.2.7 offset -20.000178 sec % server 192.168.2.7, stratum 6, offset -20.000179, delay 0.02568 % 7 Mar 15:18:00 ntpdate[7144]: step time server 192.168.2.7 offset -20.000179 sec % server 192.168.2.7, stratum 6, offset -20.000180, delay 0.02568 % 7 Mar 15:18:01 ntpdate[7146]: step time server 192.168.2.7 offset -20.000180 sec % server 192.168.2.7, stratum 6, offset -20.000178, delay 0.02568 % 7 Mar 15:18:02 ntpdate[7148]: step time server 192.168.2.7 offset -20.000178 sec % server 192.168.2.7, stratum 6, offset -20.000179, delay 0.02568 % 7 Mar 15:18:03 ntpdate[7150]: step time server 192.168.2.7 offset -20.000179 sec % server 192.168.2.7, stratum 6, offset -21.000182, delay 0.02568 % 7 Mar 15:18:05 ntpdate[7152]: step time server 192.168.2.7 offset -21.000182 sec Another lid closing: -1 second - 3uS. % server 192.168.2.7, stratum 6, offset -21.000180, delay 0.02568 % 7 Mar 15:18:06 ntpdate[7154]: step time server 192.168.2.7 offset -21.000180 sec 2 uS jitter for the second lid closing too. % server 192.168.2.7, stratum 6, offset -21.000179, delay 0.02568 % 7 Mar 15:18:07 ntpdate[7156]: step time server 192.168.2.7 offset -21.000179 sec % server 192.168.2.7, stratum 6, offset -21.000180, delay 0.02568 % 7 Mar 15:18:08 ntpdate[7158]: step time server 192.168.2.7 offset -21.000180 sec % server 192.168.2.7, stratum 6, offset -21.000180, delay 0.02568 % 7 Mar 15:18:09 ntpdate[7160]: step time server 192.168.2.7 offset -21.000180 sec Closing the lid is not completely broken. It (or pressing the screen switch) turns the screen off, and opening the lid turns the screen back on. The above output covers 2 lid openings and shows <= 2 uS of glitches for openings. pmtimer is not configured, and rtc_restore() us not called. Bruce From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 7 05:14:41 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C15F016A400; Wed, 7 Mar 2007 05:14:41 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 8AD1913C481; Wed, 7 Mar 2007 05:14:41 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 1D38B5A3CF3; Wed, 7 Mar 2007 16:14:40 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 010008C1F; Wed, 7 Mar 2007 16:14:38 +1100 (EST) Date: Wed, 7 Mar 2007 16:14:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Baldwin In-Reply-To: <200703061310.11346.jhb@freebsd.org> Message-ID: <20070307155745.X28283@delplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <200703061027.25387.jhb@freebsd.org> <45ED9D71.5040904@root.org> <200703061310.11346.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org, Stefan Ehmann Subject: Re: notebook freezes 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, 07 Mar 2007 05:14:41 -0000 On Tue, 6 Mar 2007, John Baldwin wrote: > On Tuesday 06 March 2007 11:57, Nate Lawson wrote: >> John Baldwin wrote: >>> On Monday 05 March 2007 16:19, Nate Lawson wrote: >>>>> Where do timer updates on suspend/resume happen for acpi? >>>> pmtimer handles both (see NOTES) since DEVICE_RESUME() is called from >>>> both apm and acpi. >>> >>> pmtimer should be on by default in 7 I think. It is for amd64 already > IIRC, >>> just not for i386. Actually, for amd64, neither pmtimer nor suspend/resume methods in clock.c exist. >> Yeah, I see it in GENERIC. His issue was just driver error with the >> patch. The patch has been committed. > > I'm saying in general that pmtimer should really not be optional. It's a > small amount of code, so there isn't really anything gained by leaving it > out. I agree. I forgot to ask about the problem of interrupts racing with resume. What stops an interrupt occurring before the resume methods (the device method and all the ones above it) complete? I don't know of any locking to prevent this or any way to detect this short of checking for magic garbage in device registers that have garbage in them because the registers are unmapped or just clobbered. Can suspend happen asynchronously, so that it is possible for resume to deadlock on a resource locked by somthing which was interrupted for the suspend? Bruce From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 7 06:08:11 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F6E316A403 for ; Wed, 7 Mar 2007 06:08:11 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id E404B13C442 for ; Wed, 7 Mar 2007 06:08:10 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 87C535A7C84; Wed, 7 Mar 2007 17:08:09 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 129FE8C26; Wed, 7 Mar 2007 17:08:07 +1100 (EST) Date: Wed, 7 Mar 2007 17:08:06 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Nate Lawson In-Reply-To: <45EC8B53.3010409@root.org> Message-ID: <20070307163524.T28409@delplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> <1173084724.1850.3.camel@localhost> <20070305201904.K21224@delplex.bde.org> <20070305205433.O21398@delplex.bde.org> <45EC8B53.3010409@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org Subject: Re: misdetection of tz2 temperature 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, 07 Mar 2007 06:08:11 -0000 On Mon, 5 Mar 2007, Nate Lawson wrote: > [Stefan removed from cc] > > Bruce Evans wrote: >> On Mon, 5 Mar 2007, Bruce Evans wrote: >> >>> I now have a completely different acpi problem to ask about. My HP >>> nx6325 now shuts down an instant after booting FreeBSD with a 1 week >>> old kernel, since the tz2 temperature is misdetected as 3413.3 degrees >>> C. All temperatures seemed to be detected correctly in 3+ week old >>> kernels. Only batter battery misdetection that caused shutdowns (less >>> cleanly via panics) in the old kernels. >> >> This seems to be fixed in -current. > > I recently committed a major reworking of the embedded controller > driver. See this message: > > http://lists.freebsd.org/pipermail/freebsd-current/2007-February/069525.html > > See this message for a list of things to try. The goal is to diagnose > why the EC is timing out. The thermal misdetection is only a symptom. > > http://lists.freebsd.org/pipermail/freebsd-current/2007-February/069577.html > > The one I think would be most helpful is increasing the total time spent > waiting, but I would appreciate your help seeing what combo of > polling/total timeout works for you. > > debug.acpi.ec.timeout=1000 # 1 sec total Changing ec.timeout to 1000 or 10000 and changing ec.poll_time to 100 or 10000 had no visible effect. I don't seem to be getting any timeouts. Setting ec.burst=0 fixes the problem according to the the "_TMP value is absurd" messages. Diffs between output of "sysctl -a | grep acpi" between an old kernel without the problem and a new kernel with the problem: % --- old Mon Mar 5 22:18:52 2007 % +++ new Wed Mar 7 16:39:12 2007 % @@ -2 +2 @@ % -debug.acpi.acpi_ca_version: 0x20051021 % +debug.acpi.acpi_ca_version: 20051021 % @@ -3,0 +4,3 @@ % +debug.acpi.ec.burst: 1 % +debug.acpi.ec.poll_time: 500 % +debug.acpi.ec.timeout: 500 % @@ -23 +26 @@ % -hw.acpi.acline: 1 % +hw.acpi.acline: 0 Another bug. AC is connected. % @@ -27,2 +30,2 @@ % -hw.acpi.thermal.tz0.temperature: 45.0C % -hw.acpi.thermal.tz0.active: 3 % +hw.acpi.thermal.tz0.temperature: 71.0C % +hw.acpi.thermal.tz0.active: 1 Probably correct. % @@ -34,2 +37,2 @@ % -hw.acpi.thermal.tz0._ACx: 75.0C 65.0C 55.0C 15.9C -1 -1 -1 -1 -1 -1 % -hw.acpi.thermal.tz1.temperature: 43.0C % +hw.acpi.thermal.tz0._ACx: 75.0C 60.0C 50.0C 40.0C -1 -1 -1 -1 -1 -1 % +hw.acpi.thermal.tz1.temperature: 56.0C 15.9C seems too low. % @@ -43 +46 @@ % -hw.acpi.thermal.tz2.temperature: 29.5C % +hw.acpi.thermal.tz2.temperature: 16.0C 16.0C is too low. Room temperature is 26C. Before the absurd values were ignored, 3400+C was printed here. Now the only evidence of the absurd values is the messages about them. % @@ -94,0 +98 @@ % +dev.cpu.1.%parent: acpi0 % @@ -96,0 +101,2 @@ % +dev.acpi_perf.1.%driver: acpi_perf % +dev.acpi_perf.1.%parent: cpu1 After setting ec.burst to 0, with no changes to timeouts, only one more "absurd" message has been printed after 20 minutes, so the message seems to have been for old state. Diffs from this change: % --- z3 Wed Mar 7 16:39:12 2007 % +++ z4 Wed Mar 7 16:42:09 2007 % @@ -4 +4 @@ % -debug.acpi.ec.burst: 1 % +debug.acpi.ec.burst: 0 % @@ -30,2 +30,2 @@ % -hw.acpi.thermal.tz0.temperature: 71.0C % -hw.acpi.thermal.tz0.active: 1 % +hw.acpi.thermal.tz0.temperature: 52.0C % +hw.acpi.thermal.tz0.active: 2 % @@ -37,2 +37,2 @@ % -hw.acpi.thermal.tz0._ACx: 75.0C 60.0C 50.0C 40.0C -1 -1 -1 -1 -1 -1 % -hw.acpi.thermal.tz1.temperature: 56.0C % +hw.acpi.thermal.tz0._ACx: 75.0C 65.0C 50.0C 40.0C -1 -1 -1 -1 -1 -1 % +hw.acpi.thermal.tz1.temperature: 55.0C Probably correct. % @@ -46 +46 @@ % -hw.acpi.thermal.tz2.temperature: 16.0C % +hw.acpi.thermal.tz2.temperature: 30.7C Possibly correct. 30.7C still seems low. ISTR tz2 usually being too low in old kernels, but that may have only been the 15.9C ACx value. With ec.burst=0, ec.timeout=3 seems to work but ec.timeout.2 causes AE_NO_HARDWARE_RESPONSE errors. With ec.burst=1, ec.timeout=2 seems to work but ec.timeout=1 causes AE_NO_HARDWARE_RESPONSE errors. Toggling physical AC power doesn't change "hw.acpi.acline: 0". ISTR that this used to work. Bruce From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 7 16:24:42 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2146B16A404 for ; Wed, 7 Mar 2007 16:24:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 5BC6713C4BD for ; Wed, 7 Mar 2007 16:24:41 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 l27GOUM1020245; Wed, 7 Mar 2007 11:24:33 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Bruce Evans Date: Wed, 7 Mar 2007 10:53:44 -0500 User-Agent: KMail/1.9.1 References: <200703011612.07110.shoesoft@gmx.net> <200703061310.11346.jhb@freebsd.org> <20070307155745.X28283@delplex.bde.org> In-Reply-To: <20070307155745.X28283@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703071053.45439.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, 07 Mar 2007 11:24:33 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2763/Wed Mar 7 08:14:49 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,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, Stefan Ehmann Subject: Re: notebook freezes 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, 07 Mar 2007 16:24:42 -0000 On Wednesday 07 March 2007 00:14, Bruce Evans wrote: > On Tue, 6 Mar 2007, John Baldwin wrote: > > > On Tuesday 06 March 2007 11:57, Nate Lawson wrote: > >> John Baldwin wrote: > >>> On Monday 05 March 2007 16:19, Nate Lawson wrote: > >>>>> Where do timer updates on suspend/resume happen for acpi? > >>>> pmtimer handles both (see NOTES) since DEVICE_RESUME() is called from > >>>> both apm and acpi. > >>> > >>> pmtimer should be on by default in 7 I think. It is for amd64 already > > IIRC, > >>> just not for i386. > > Actually, for amd64, neither pmtimer nor suspend/resume methods in clock.c > exist. Hmm, well that should be fixed. > >> Yeah, I see it in GENERIC. His issue was just driver error with the > >> patch. The patch has been committed. > > > > I'm saying in general that pmtimer should really not be optional. It's a > > small amount of code, so there isn't really anything gained by leaving it > > out. > > I agree. > > I forgot to ask about the problem of interrupts racing with resume. > What stops an interrupt occurring before the resume methods (the device > method and all the ones above it) complete? I don't know of any locking > to prevent this or any way to detect this short of checking for magic > garbage in device registers that have garbage in them because the > registers are unmapped or just clobbered. Can suspend happen > asynchronously, so that it is possible for resume to deadlock on a > resource locked by somthing which was interrupted for the suspend? I don't think there is stuff in there to protect against locks being held. However, each device is supposed to turn its device off in it's device_suspend() method and then turn it back on in device_resume() which should resolve problems with garbage registers and spurious interrupts. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 8 07:32:49 2007 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1964816A485; Thu, 8 Mar 2007 07:32:49 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id D4D1A13C428; Thu, 8 Mar 2007 07:32:48 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 6C6295A0FC7; Thu, 8 Mar 2007 18:32:47 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 68F688C05; Thu, 8 Mar 2007 18:32:46 +1100 (EST) Date: Thu, 8 Mar 2007 18:32:44 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin In-Reply-To: <200703071053.45439.jhb@freebsd.org> Message-ID: <20070308183232.F3026@besplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <200703061310.11346.jhb@freebsd.org> <20070307155745.X28283@delplex.bde.org> <200703071053.45439.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@FreeBSD.org, Stefan Ehmann Subject: Re: notebook freezes 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, 08 Mar 2007 07:32:49 -0000 On Wed, 7 Mar 2007, John Baldwin wrote: > On Wednesday 07 March 2007 00:14, Bruce Evans wrote: >> I forgot to ask about the problem of interrupts racing with resume. >> What stops an interrupt occurring before the resume methods (the device >> method and all the ones above it) complete? I don't know of any locking >> to prevent this or any way to detect this short of checking for magic >> garbage in device registers that have garbage in them because the >> registers are unmapped or just clobbered. Can suspend happen >> asynchronously, so that it is possible for resume to deadlock on a >> resource locked by somthing which was interrupted for the suspend? > > I don't think there is stuff in there to protect against locks being held. > However, each device is supposed to turn its device off in it's > device_suspend() method and then turn it back on in device_resume() which > should resolve problems with garbage registers and spurious interrupts. pmtimer doesn't do this of course. Turning of RTC interrupts is easy, but turning off i8254 interrupts seems to require bus_teardown_intr(). Bruce From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 8 08:14:31 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F17F16A401 for ; Thu, 8 Mar 2007 08:14:31 +0000 (UTC) (envelope-from Helko.Glathe@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by mx1.freebsd.org (Postfix) with ESMTP id B66E213C4A5 for ; Thu, 8 Mar 2007 08:14:30 +0000 (UTC) (envelope-from Helko.Glathe@freenet.de) Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.67) (envelope-from ) id 1HPCop-0003ud-By for freebsd-acpi@freebsd.org; Thu, 08 Mar 2007 08:13:43 +0100 Received: from e178192222.adsl.alicedsl.de ([85.178.192.222]:61828 helo=[192.168.1.3]) by mx8.freenet.de with esmtpsa (ID Helko.Glathe@freenet.de) (TLSv1:AES256-SHA:256) (port 465) (Exim 4.67 #1) id 1HPCop-0006bR-5S for freebsd-acpi@freebsd.org; Thu, 08 Mar 2007 08:13:43 +0100 Message-ID: <45EFB6C9.4060502@freenet.de> Date: Thu, 08 Mar 2007 08:10:01 +0100 From: Helko Glathe Organization: private User-Agent: Thunderbird 1.5.0.9 (X11/20070302) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: ACPI errors on Samsung Q35 Notebook X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Helko.Glathe@freenet.de List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2007 08:14:31 -0000 Hi! I've installed the system: FreeBSD 6.2-RELEASE-p1. The Notebook is a Samsung Q35 Calvin T5500 Core 2 Duo. Booting the system, I get acpi errors like "acpi_bus_number: can't get _ADR": ************************************************************************ dmesg-output: Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE-p1 #2: Sun Feb 25 11:45:02 CET 2007 kater@FreeBSD_TWS29:/usr/obj/usr/src/sys/MYKERNEL62 WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz (1662.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe39d,CX16,,> AMD Features=0x20000000 AMD Features2=0x1 Cores per package: 2 real memory = 1063845888 (1014 MB) avail memory = 1031843840 (984 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: port 0x1800-0x1807 mem 0xd8100000-0xd817ffff,0xc0000000-0xcfffffff,0xd8200000-0xd823ffff irq 16 at device 2.0 on pci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M drmsub0: : (child of agp_i810.c) on agp0 info: [drm] AGP at 0xd8100000 0MB info: [drm] Initialized i915 1.4.0 20060119 pci0: at device 2.1 (no driver attached) pcm0: mem 0xd8240000-0xd8243fff irq 22 at device 27.0 on pci0 pcib1: irq 17 at device 28.0 on pci0 pci2: on pcib1 wpi0: mem 0xd4000000-0xd4000fff irq 16 at device 0.0 on pci2 bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc failed to align memory properly. channel 1 pwr1 0x0086 pwr2 0x0086 channel 2 pwr1 0x0086 pwr2 0x0087 channel 3 pwr1 0x009f pwr2 0x009f channel 4 pwr1 0x009f pwr2 0x00a0 channel 5 pwr1 0x0000 pwr2 0x0000 channel 6 pwr1 0x0082 pwr2 0x0082 channel 7 pwr1 0x0082 pwr2 0x0082 channel 8 pwr1 0x007a pwr2 0x0078 channel 9 pwr1 0x0078 pwr2 0x007b channel 10 pwr1 0x0000 pwr2 0x0000 channel 11 pwr1 0x0004 pwr2 0x0004 channel 12 pwr1 0xfffd pwr2 0xfffd channel 13 pwr1 0x0004 pwr2 0x0004 channel 14 pwr1 0xfffd pwr2 0xfffd wpi0: Ethernet address: 00:18:de:10:8e:63 wpi0: [GIANT-LOCKED] pcib2: irq 16 at device 28.1 on pci0 pci3: on pcib2 uhci0: port 0x1820-0x183f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib3: at device 30.0 on pci0 pci5: on pcib3 bfe0: mem 0xd8000000-0xd8001fff irq 22 at device 5.0 on pci5 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:13:77:27:bc:5f bfe0: [GIANT-LOCKED] pci5: at device 9.0 (no driver attached) fwohci0: mem 0xd8002000-0xd80027ff at device 9.1 on pci5 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:f0:41:01:03:c0:a3 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:f0:03:c0:a3 fwe0: Ethernet address: 02:00:f0:03:c0:a3 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci5: at device 9.2 (no driver attached) pci5: at device 9.3 (no driver attached) pci5: at device 9.4 (no driver attached) pci5: at device 9.5 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: flags 0x3000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xdc000-0xdffff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM), rev 1.10/3.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. ugen0: Broadcom Corp BCM92045NMD, rev 2.00/1.00, addr 2 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. ad0: 88119MB at ata0-master UDMA100 acd0: DVDR at ata0-slave UDMA33 pcm0: pcm0: SMP: AP CPU #1 Launched! cd0 at ata0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Trying to mount root from ufs:/dev/ad0s1a ************************************************************************ sysctl hw.acpi-output: hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_supported: C1/1 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% hw.acpi.acline: 1 hw.acpi.battery.life: 100 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 45.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 95.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 95.0C hw.acpi.thermal.tz0._ACx: 55.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1.temperature: 45.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 0 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: -1 hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 95.0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 ************************************************************************ Is it possible to fix this? Thanks in advance, Helko From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 8 16:44:05 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F6C616A400 for ; Thu, 8 Mar 2007 16:44:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 48CEC13C4CE for ; Thu, 8 Mar 2007 16:44:05 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 l28Gi2Co028698; Thu, 8 Mar 2007 11:44:02 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Thu, 8 Mar 2007 10:23:45 -0500 User-Agent: KMail/1.9.1 References: <200703011612.07110.shoesoft@gmx.net> <200703071053.45439.jhb@freebsd.org> <20070308183232.F3026@besplex.bde.org> In-Reply-To: <20070308183232.F3026@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703081023.45976.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]); Thu, 08 Mar 2007 11:44:03 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2778/Thu Mar 8 11:20:58 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Stefan Ehmann Subject: Re: notebook freezes 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, 08 Mar 2007 16:44:05 -0000 On Thursday 08 March 2007 02:32, Bruce Evans wrote: > On Wed, 7 Mar 2007, John Baldwin wrote: > > > On Wednesday 07 March 2007 00:14, Bruce Evans wrote: > >> I forgot to ask about the problem of interrupts racing with resume. > >> What stops an interrupt occurring before the resume methods (the device > >> method and all the ones above it) complete? I don't know of any locking > >> to prevent this or any way to detect this short of checking for magic > >> garbage in device registers that have garbage in them because the > >> registers are unmapped or just clobbered. Can suspend happen > >> asynchronously, so that it is possible for resume to deadlock on a > >> resource locked by somthing which was interrupted for the suspend? > > > > I don't think there is stuff in there to protect against locks being held. > > However, each device is supposed to turn its device off in it's > > device_suspend() method and then turn it back on in device_resume() which > > should resolve problems with garbage registers and spurious interrupts. > > pmtimer doesn't do this of course. Turning of RTC interrupts is easy, > but turning off i8254 interrupts seems to require bus_teardown_intr(). Since the clocks aren't a new-bus device anyway, we can make them explicitly be suspended and resumed while interrupts are disabled for x86. -- John Baldwin