Impossible shutdown

[John Baldwin]

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