ACPI SystemCMOS region handler rev. 2 (was Re: Impossible shutdown)
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-a...@freebsd.org [mailto:owner-freebsd-
a...@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] (0xfe0002b0f800)
[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 0xfe0002aee440), AE_NOT_EXIST (20110527/psparse-560)
ACPI Error: Method parse/execution failed
[\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfe0002b16d40), 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] (0xfe0002b15900)
[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
0xfe0002af5800), AE_NOT_EXIST (20110527/psparse-560)
ACPI Error: Method parse/execution failed [\_PTS] (Node
0xfe0002af86c0), 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
Re: ACPI SystemCMOS region handler rev. 2 (was Re: Impossible shutdown)
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-a...@freebsd.org [mailto:owner-freebsd- a...@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] (0xfe0002b0f800) [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 0xfe0002aee440), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfe0002b16d40), 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] (0xfe0002b15900) [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 0xfe0002af5800), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_PTS] (Node 0xfe0002af86c0), 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
RE: Impossible shutdown
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-a...@freebsd.org [mailto:owner-freebsd-
a...@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] (0xfe0002b0f800)
[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 0xfe0002aee440), AE_NOT_EXIST (20110527/psparse-560)
ACPI Error: Method parse/execution failed
[\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfe0002b16d40), 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] (0xfe0002b15900)
[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
0xfe0002af5800), AE_NOT_EXIST (20110527/psparse-560)
ACPI Error: Method parse/execution failed [\_PTS] (Node
0xfe0002af86c0), 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
Re: Impossible shutdown
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] (0xfe0002b0f800)
[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
0xfe0002aee440), AE_NOT_EXIST (20110527/psparse-560)
ACPI Error: Method parse/execution failed
[\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfe0002b16d40), 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] (0xfe0002b15900)
[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
0xfe0002af5800), AE_NOT_EXIST (20110527/psparse-560)
ACPI Error: Method parse/execution failed [\_PTS] (Node
0xfe0002af86c0), 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 PNPxx stuff. I'll look into it when I get some free
cycles.
cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: Impossible shutdown
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] (0xfe0002b0f800)
[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
0xfe0002aee440), AE_NOT_EXIST (20110527/psparse-560)
ACPI Error: Method parse/execution failed
[\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfe0002b16d40), 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] (0xfe0002b15900)
[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
0xfe0002af5800), AE_NOT_EXIST (20110527/psparse-560)
ACPI Error: Method parse/execution failed [\_PTS] (Node
0xfe0002af86c0), 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
index d17411e..4f341ca 100644
--- a/source/components/events/evhandler.c
+++ b/source/components/events/evhandler.c
@@ -142,6 +142,7 @@ UINT8
AcpiGbl_DefaultAddressSpaces[ACPI_NUM_DEFAULT_SPACES] =
ACPI_ADR_SPACE_SYSTEM_MEMORY,
ACPI_ADR_SPACE_SYSTEM_IO,
ACPI_ADR_SPACE_PCI_CONFIG,
+ACPI_ADR_SPACE_CMOS,
ACPI_ADR_SPACE_DATA_TABLE
};
@@ -451,9 +452,12 @@ AcpiEvInstallSpaceHandler (
*/
if ((Node-Type != ACPI_TYPE_DEVICE)
(Node-Type != ACPI_TYPE_PROCESSOR)
+(Node-Type != ACPI_TYPE_REGION)
(Node-Type != ACPI_TYPE_THERMAL)
(Node != AcpiGbl_RootNode))
{
+ACPI_DEBUG_PRINT ((ACPI_DB_OPREGION,
+Device %p not a DEVICE, PROCESSOR, REGION, THERMAL type or root
node.\n, Node));
Status = AE_BAD_PARAMETER;
goto UnlockAndExit;
}
diff --git a/source/components/executer/exregion.c
b/source/components/executer/exregion.c
index ea10a01..bfdd721 100644
--- a/source/components/executer/exregion.c
+++ b/source/components/executer/exregion.c
@@ -521,6 +521,20 @@ AcpiExPciConfigSpaceHandler (
return_ACPI_STATUS (Status);
}
+static UINT8 AcpiExCmosRead(ACPI_PHYSICAL_ADDRESS Address)
+{
+UINT32 Value32;
+
+AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8);
+AcpiHwReadPort ((ACPI_IO_ADDRESS) 0x71, Value32, 8);
+return Value32 0xFF;
+}
+
+static void AcpiExCmosWrite(ACPI_PHYSICAL_ADDRESS Address, UINT8 Value)
+{
+AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8);
+AcpiHwWritePort((ACPI_IO_ADDRESS) 0x71, (UINT32) Value, 8);
+}
/***
*
@@ -545,7 +559,7 @@ AcpiExCmosSpaceHandler (
UINT32 Function,
ACPI_PHYSICAL_ADDRESS Address,
UINT32 BitWidth,
-UINT64 *Value,
+UINT64 *Value64,
void*HandlerContext,
void*RegionContext)
{
@@ -554,7 +568,23 @@ AcpiExCmosSpaceHandler (
ACPI_FUNCTION_TRACE (ExCmosSpaceHandler);
-
+if (Address 0x80
+(Function == ACPI_READ || Function == ACPI_WRITE)
+BitWidth = 64)
+{
+UINT32 i;
+UINT8 *Value = (UINT8 *)Value64;
+
+for (i = 0; i (BitWidth + 7) / 8; ++i, ++Address, ++Value) {
+if (Function == ACPI_READ) {
+*Value = AcpiExCmosRead(Address);
+} else {
+AcpiExCmosWrite(Address, *Value);
+}
+}
+} else {
+Status = AE_BAD_PARAMETER;
+}
return_ACPI_STATUS (Status);
}
diff --git
Re: Impossible shutdown
On Thu, Jun 26, 2014 at 07:44:35AM -0400, Anthony Jenkins wrote: 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. Thanks, everyting works fine now. Even suspend, except my video driver (xf86-video-intel) that goes mad, and after resume everything is laggy. info: [drm] Changing LVDS panel from (+hsync, -vsync) to (-hsync, -vsync) info: [drm] Changing LVDS panel from (-hsync, -vsync) to (+hsync, -vsync) error: [drm:pid1170:intel_lvds_enable] *ERROR* timed out waiting for panel to power off By the way, I've tried all suspend types, but only this correctly resume the system: /etc/rc.suspend apm 1 ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: Impossible shutdown
On 06/26/2014 11:23, Bykov Vladislav wrote: On Thu, Jun 26, 2014 at 07:44:35AM -0400, Anthony Jenkins wrote: 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. Thanks, everyting works fine now. Even suspend, except my video driver (xf86-video-intel) that goes mad, and after resume everything is laggy. Hooray! Maybe I can shove it into -CURRENT... info: [drm] Changing LVDS panel from (+hsync, -vsync) to (-hsync, -vsync) info: [drm] Changing LVDS panel from (-hsync, -vsync) to (+hsync, -vsync) error: [drm:pid1170:intel_lvds_enable] *ERROR* timed out waiting for panel to power off By the way, I've tried all suspend types, but only this correctly resume the system: /etc/rc.suspend apm 1 That's wierd (and also not weird).../etc/rc.suspend (at least on my -CURRENT r267519) doesn't even appear to use the '1' argument, and it's just calling /usr/sbin/zzz with the 'apm' argument (which I believe still does an ACPI suspend). My patch is an ACPI patch anyway. People on this list have been wrangling with the Intel driver, there might be fixes for what you're seeing. Anthony ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: Impossible shutdown
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] (0xfe0002b0f800)
[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
0xfe0002aee440), AE_NOT_EXIST (20110527/psparse-560)
ACPI Error: Method parse/execution failed
[\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfe0002b16d40), 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] (0xfe0002b15900)
[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
0xfe0002af5800), AE_NOT_EXIST (20110527/psparse-560)
ACPI Error: Method parse/execution failed [\_PTS] (Node
0xfe0002af86c0), 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?
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.
Yours looks more likely portable for upstream acpica, but it also looks
potentially quite dangerous 'in the wrong hands' :)
cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
