From owner-freebsd-acpi@FreeBSD.ORG Sat Jul 5 12:38:11 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA11EBCB for ; Sat, 5 Jul 2014 12:38:11 +0000 (UTC) Received: from nm12-vm7.access.bullet.mail.bf1.yahoo.com (nm12-vm7.access.bullet.mail.bf1.yahoo.com [216.109.114.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59ED2254B for ; Sat, 5 Jul 2014 12:38:11 +0000 (UTC) Received: from [66.196.81.164] by nm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jul 2014 12:31:14 -0000 Received: from [98.138.226.244] by tm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jul 2014 12:31:14 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 05 Jul 2014 12:31:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1404563474; bh=QA1ntKlDcHYQWZwxPFX7PAvpfGtnELU5oa7QbY7W3ZQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YBn3t3LDFH7AXL7FOl+sLghmU+B+PeSuJGYkVp4D6ygWf045RQ/OjA5eKZK2SZ2uU0z7OWaqSm7J+poC5MB0HJs2yx1z2ICFdzetmZyyeI/3HQVmRWTN23VystOLqV0u81V7H+22HGqcsIWeSYjKDxPdPvwCxgn5WEXjY+JV+U8= X-Yahoo-Newman-Id: 494213.95372.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: I65yd6wVM1lbPjFXAXQ3aQ5GbTfagn3y0HLMEjMeRPJqU30 WRkIj5kbGtMPEVi1bsw0g8xJ_.Mky_aSgD0lH_OYFVJTSUYdBd_NekjezI6i zIiMaYNmouYQgoZVlheR8l9Q.Rg802Ut77OCk352VFMDwAU1L.xshRalLy1V cSOVQBvYH7_5a497ufHxj9G2DUWcnnB2Zl1knA1TVJr1r1xEzqlLhun5WKYu zaHP30CpGgIfTj0gU8dvXdoWie.sK3x6ZeR4mRlI1U2sufX0Bac5DmAJRpbG 9quG5Qngun.36SzFPLGZ57X_4RJpwYvockeuJiWREy5d5TPdLnTzwOcbY06u fKzbbhBdIbDSoxtLw8GyxmAyVUtb62EXFQPaYa7vF_7C.anQkabNVYB61Mlt 9PNiGflAUTHWMlP8TpRggwDWeO6byqeHjjx1uqFIvkUKjOqkTmaBwga23Ye. UK1xHzEPACg6X2CHPRt2vYhKRYKqkVSMXtJReaeLmtv.03BwpdHSan2RuJfy PrskV6zmjDnrpl5l78fZlgcO_XSBmQKAJRod2TNvUL3LSdf_v X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [192.168.1.134] (Anthony.B.Jenkins@99.62.101.19 with plain [98.138.84.52]) by smtp115.sbc.mail.ne1.yahoo.com with SMTP; 05 Jul 2014 12:31:14 +0000 UTC Message-ID: <53B7F010.3030902@att.net> Date: Sat, 05 Jul 2014 08:31:12 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Moore, Robert" , John Baldwin , "freebsd-acpi@freebsd.org" Subject: Re: ACPI SystemCMOS region handler rev. 2 (was Re: Impossible shutdown) References: <20140625222911.GA34447@hellgate.Dlink> <20140627143031.P50382@sola.nimnet.asn.au> <53ADD8B9.5060401@att.net> <201406301043.55003.jhb@freebsd.org> <94F2FBAB4432B54E8AACC7DFDE6C92E37D1BE9E7@ORSMSX112.amr.corp.intel.com> <53B7E9A0.3040608@att.net> In-Reply-To: <53B7E9A0.3040608@att.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bykov Vladislav , Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 12:38:11 -0000 What error should the address region handler return for ACPI_WRITE attempts to RTC current date/time registers? >From ACPIspec50.pdf section 5.5.2.4.1 "CMOS Protocols": "All bytes of CMOS that are related to the current time, day, date, month, year and century are read-only." I return AE_BAD_PARAMETER for other failed handler argument checks. I guess I could also return that for bad writes...just seems something like AE_ACCESS might be more appropriate. Also, any opinion as to whether accesses to SystemCMOS region greater than 8 bits wide should be allowed? I don't remember my particular machine trying to access anything wider than 8 bits in this region. I'd probably have to lock multibyte accesses, meaning rewriting the current byte-only I/O functions and adding checks for multibyte write accesses to datetime registers. Thanks, Anthony On 07/05/2014 08:03, Anthony Jenkins wrote: > How about this (attached) patch to atrtc.c? I threw this together (not sure about limiting the width to 8 bits, I can make it more) and backed out my patch to acpica and I can still power down my machine properly (haven't tried suspend/resume yet due to backlight issue). But this seems to be the Right Thing To Do (TM). > > Anthony > > On 07/02/2014 17:11, Moore, Robert wrote: >> The host detects the PNP IDs. Therefore, it needs to recognize the PNP ID for system CMOS and install a driver which in turn installs a handler for the SystemCMOS address space. >> >> >>> -----Original Message----- >>> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>> acpi@freebsd.org] On Behalf Of John Baldwin >>> Sent: Monday, June 30, 2014 7:44 AM >>> To: freebsd-acpi@freebsd.org >>> Cc: Anthony Jenkins; Bykov Vladislav; Ian Smith >>> Subject: Re: Impossible shutdown >>> >>> On Friday, June 27, 2014 4:48:57 pm Anthony Jenkins wrote: >>>> On 06/27/2014 01:16, Ian Smith wrote: >>>>> On Thu, 26 Jun 2014 07:44:35 -0400, Anthony Jenkins wrote: >>>>> > On 06/25/2014 18:29, Bykov Vladislav wrote: >>>>> > > Hello. >>>>> > > >>>>> > > I have a problem with ACPI on HP Envy 4 that causes in >>>>> impossible >>> shutdown. It >>>>> > > reaches an error while prepairing to shutdown, and reboots the >>> machine. >>>>> > > >>>>> > > I already did sent a bug report about 2-3 months ago, but >>>>> things >>> doesn't seems >>>>> > > to move on. >>>>> > > >>>>> > > Here's an error when booting the machine: >>>>> > > >>>>> > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b0f800) >>> [SystemCMOS] (20110527/evregion-421) >>>>> > > ACPI Error: Region SystemCMOS (ID=5) has no handler >>> (20110527/exfldio-310) >>>>> > > ACPI Error: Method parse/execution failed [\134_SB_.WMID.ESDT] >>> (Node 0xfffffe0002aee440), AE_NOT_EXIST (20110527/psparse-560) >>>>> > > ACPI Error: Method parse/execution failed >>> [\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfffffe0002b16d40), AE_NOT_EXIST >>> (20110527/psparse-560) >>>>> > > acpi_ec0: evaluation of query method _Q42 failed: AE_NOT_EXIST >>>>> > > >>>>> > > And here's the one when I'm trying to shut it down: >>>>> > > >>>>> > > usbus2: Controller shutdown complete >>>>> > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b15900) >>> [SystemCMOS] (20110527/evregion-421) >>>>> > > ACPI Error: Region SystemCMOS (ID=5) has no handler >>> (20110527/exfldio-310) >>>>> > > ACPI Error: Method parse/execution failed [\_SB_.WMID.ESDT] >>> (Node >>> 0xfffffe0002af5800), AE_NOT_EXIST (20110527/psparse-560) >>>>> > > ACPI Error: Method parse/execution failed [\_PTS] (Node >>> 0xfffffe0002af86c0), AE_NOT_EXIST (20110527/psparse-560) >>>>> > > acpi0: AcpiEnterSleepStatePrep failed - AE_NOT_EXIST >>>>> > > Rebooting... >>>>> > > >>>>> > > I've tried FreeBSD 9, FreeBSD 10, and -CURRENT. All have the >>>>> same >>> problem. >>>>> > >>>>> > Here's a case where my patch to implement the SystemCMOS region >>>>>> handler should help; it allows my HP Envy to power down and allows >>>>> it > to suspend/resume except the LCD backlight doesn't come back >>>>> when > resuming. Biggest problem with the patch IMHO is I'm >>>>> stealing > ("borrowing") from the real time clock (RTC) I/O region, >>>>> but I don't > think we have an "actual" FreeBSD driver for that. >>>>> > >>>>> > Reposting here, or search this list for "Naive implementation of >>>>>> AcpiExCmosSpaceHandler", let me know if it doesn't apply cleanly >>>>> to > your version of FreeBSD . I've posted it upstream to the >>>>> acpica > mailing list, but no response. >>>>> > >>>>> > diff --git a/source/components/events/evhandler.c >>> b/source/components/events/evhandler.c >>>>> Interesting. I wonder if this is needed for reading the RTC for the >>>>> time on boot, and writing it back on shutdown - which I would have >>>>> thought too generic to have left out on any machine? Or is this >>> perhaps >>>>> retrieving at boot then restoring at shutdown some other system- >>> specific >>>>> information in NVRAM? >>>> It's the latter; they (presumably the BIOS ACPI shutdown/resume methods) >>> are >>> just reading/writing locations in the non-volatile CMOS storage, which >>> just >>> happens to be shared with the RTC. The RTC proper has some 16 bytes of >>> registers which represent the real time clock - the rest are presumably >>> storage, though the platform could probably do whatever it wants with >>> various >>> locations. >>>>> If the latter, then the usage in /sys/dev/acpi_support/acpi_ibm.c >>>>> revealed below might illustrate another way of dealing with this? >>>>> >>>>> % find /sys/ -type f -exec egrep -H 'rtcin|writertc' {} \; | grep -v >>> drm_mode_set_crtcinfo >>>>> shows everything using the rtcin() and writertc() functions, >>> implemented >>>>> for x86 at least in /sys/x86/isa/atrtc.c .. but I have no idea whether >>>>> you can access those functions from where / when you're tinkering >>> here. >>>> This is the way I think it's /supposed/ to be done - from my skimming of >>> one >>> of the ACPI specs, there's a PNP identifier for the CMOS/RTC device. If >>> that >>> identifier is probed, the OS should install a SystemCMOS region handler >>> (which >>> would use the I/O methods of the RTC driver which takes care of >>> locking/consistency). >>>>> Yours looks more likely portable for upstream acpica, but it also >>> looks >>>>> potentially quite dangerous 'in the wrong hands' :) >>>> Personally I don't think my patch can live upstream in acpica-land >>> because >>> it can step on the toes of an existing OS CMOS/RTC driver talking to the >>> RTC >>> I/O ports. I just don't know how to do all this with our rtc driver yet, >>> particularly the PNPxxxxxx stuff. I'll look into it when I get some free >>> cycles. >>> >>> Probably the "right" thing to do for ACPICA is to have CMOS accesses call >>> out >>> to a set of AcpiOs* hooks that the OS-dependent layer provides (would be >>> in >>> sys/dev/acpica/Osd/*). See how the PCI config space accesses work for an >>> example. I would ask on the ACPICA mailing list (jkim@ can point you at >>> it) >>> for feedback on what approach they would prefer. >>> >>> -- >>> John Baldwin >>> _______________________________________________ >>> 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" >>