Bug 209222

Summary:	11.0-CURRENT -r298793 automatic shutdown for "kernel: ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20160422/evevent-323)" and more under virtual box
Product:	Base System	Reporter:	Mark Millard <marklmi26-fbsd>
Component:	bin	Assignee:	freebsd-acpi (Nobody) <acpi>
Status:	Closed FIXED
Severity:	Affects Some People	CC:	jhb, jkim
Priority:	---	Keywords:	patch
Version:	CURRENT
Hardware:	Any
OS:	Any

Description Mark Millard 2016-05-03 06:01:17 UTC

I just upgraded my amd64 11.0-CURRENT that runs under virtual box on Mac OS X to -r298793. This was via buildworld buildkernel then installing them, like normal.

The result is about 10-11 minutes after starting to boot FreeBSD shuts down with for example:
(the root login line is just to give an idea of the time frame after the login prompt)

May  2 21:52:18 FreeBSDx64 login: ROOT LOGIN (root) ON ttyv0
May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20160422/evevent-323)
May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for fixed event - RealTimeClock (4), disabling (20160422/evevent-323)
May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 01, disabling event (20160422/evgpe-834)
May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 03, disabling event (20160422/evgpe-834)
May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 04, disabling event (20160422/evgpe-834)
May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 05, disabling event (20160422/evgpe-834)
May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 06, disabling event (20160422/evgpe-834)
May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 07, disabling event (20160422/evgpe-834)
May  2 22:01:45 FreeBSDx64 kernel: .
May  2 22:01:45 FreeBSDx64 afpd[652]: AFP Server shutting down
May  2 22:01:45 FreeBSDx64 cnid_metad[654]: shutting down on SIGTERM
May  2 22:01:45 FreeBSDx64 netatalk[639]: Netatalk AFP server exiting
May  2 22:01:46 FreeBSDx64 kernel: .
May  2 22:01:47 FreeBSDx64 kernel: , 576.
May  2 22:01:47 FreeBSDx64 syslogd: exiting on signal 15

Comment 1 Mark Millard 2016-05-03 07:14:20 UTC

(In reply to Mark Millard from comment #0)

I duplicated the directory tree that held the virtual machine on Mac OS X before booting to install the kernel and world. This was running -r297769.

When I boot the -r297769 virtual machine instead of the -r298793 one the problem does not occur.

Both -r297769 and -r298793 11.0-'s have /usr/ports -r414369 and the ports were built before the -r298793 buildworld/buildkernel was done. And both -r297769 and -r298793 11.0's are running under the same vintage of Virtual Box (5.0.20 r106931).

So what is different is just the FreeBSD vintage.

11.0's -r297769 virtual machine does contain the buildworld/buildkernel /usr/obj material for -r298793, it is just not installed.

Comment 2 Mark Millard 2016-05-03 17:42:55 UTC

A list reply by Guillermo Garc?a Rojas reports:

I'm having the same issue with downloaded ISO from Monday May 2nd under VirtualBox same version.

It happens at 10 minutes after system is started.



So it is not just me that sees the issue.

Comment 3 Mark Millard 2016-05-03 20:11:04 UTC

In the lists John Baldwin reports:

This was already covered in an earlier thread.  r298838 has the fix /
workaround.

-- 
John Baldwin


So I've updated /usr/src to -r298990 and am rebuilding. It will be a while before I can confirm/deny the status of the result for my context.

Comment 4 Mark Millard 2016-05-03 20:21:06 UTC

(In reply to Mark Millard from comment #3)

In reply to John B. Jung-uk Kim wrote that there now is an upstream patch available:



FYI, the upstream was notified and a patch is available from here:

https://github.com/acpica/acpica/pull/138

Jung-uk Kim



So maybe this bug (209222) should stick around to be tied to having the upstream fix in place, not just a work around.

Comment 5 Mark Millard 2016-05-06 23:59:23 UTC

11.0-CURRENT -r298990 has proven to no have this problem: so the work-around seems to be working.

But so far as I know the upstream change for an actual fix is still not applied.

Comment 6 Mark Millard 2016-06-13 06:41:56 UTC

(In reply to Mark Millard from comment #5)

As of 11.0 -r301815 the problem is still gone.

I do not know if the upstream patch was ever applied but if not it may be that the work around is the final 11.0 code for the issue.

This leaves me unclear on if this should be closed as fixed for 11.0 or left open to indicate that the upstream patch should still be considered someday in 11.0-STABLE (and 11.x for 0<x) once 11.0-STABLE exists.

Comment 7 John Baldwin freebsd_committer

2016-06-24 21:23:41 UTC

I think this is fine to be closed.