Date: Wed, 2 Jul 2014 21:11:55 +0000 From: "Moore, Robert" <robert.moore@intel.com> To: John Baldwin <jhb@freebsd.org>, "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org> Cc: Anthony Jenkins <Anthony.B.Jenkins@att.net>, Bykov Vladislav <envolyse@gmail.com>, Ian Smith <smithi@nimnet.asn.au> Subject: RE: Impossible shutdown Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E37D1BE9E7@ORSMSX112.amr.corp.intel.com> In-Reply-To: <201406301043.55003.jhb@freebsd.org> References: <20140625222911.GA34447@hellgate.Dlink> <20140627143031.P50382@sola.nimnet.asn.au> <53ADD8B9.5060401@att.net> <201406301043.55003.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
The host detects the PNP IDs. Therefore, it needs to recognize the PNP ID f=
or system CMOS and install a driver which in turn installs a handler for th=
e 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
>=20
> 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=3D5) 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=3D5) 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 whethe=
r
> > > 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 o=
f
> 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.
>=20
> 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.
>=20
> --
> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?94F2FBAB4432B54E8AACC7DFDE6C92E37D1BE9E7>