Page MenuHomeSolus

systemd-journal runaway log entries on skylake motherboard
Closed, WontfixPublic

Description

Shortly after installing Solus 1.2 stable on a new computer, I noticed that systemd-journal was using ~12% of my cpu(100% of a single core) writing several thousand items/second to logs. A system update using "sudo eopkg up" and the 4.7 kernel did not appear to resolve the issue.

Here are the log entries, these 2 lines are repeated ~2k times/second while the computer is turned on.

ACPI Error: [PGRT] Namespace lookup failure, AE_NOT_FOUND (20150930/psargs-359)
ACPI Error: Method parse/execution failed [\_GPE._L6F] (Node ffff8808554c22d0), AE_NOT_FOUND (20150930/psparse-542)

I was able to locate a similar report at this link https://bugzilla.kernel.org/show_bug.cgi?id=105491 which I think may be related. The motherboard in question is an AsRock Z170M Extreme4 with the latest version p1.70(http://www.asrock.com/mb/Intel/Z170M%20Extreme4/index.us.asp?cat=Download&os=BIOS) of the BIOS. Unfortunately the newer versions of BIOS mentioned in the bugzilla.kernel.org link are not available for this specific model. I suspect that the root problem is in the BIOS, but am not sure and reporting here as requested. Thanks.

EDIT: I was able to replicate this same issue using the latest linux mint 18 using a live usb, so this issue is not specific to Solus.

Event Timeline

Is this still a problem on the latest kernel?

The issue was present on the absolutely latest versions of both Solus and Mint as of early August 2016, and probably every other systemd based linux distro. The problem was a bug in the AsRock bios, not a kernel issue.

After this report I later found out that that AsRock had fully been aware of the problem since Jan/Feb, but did not fix it because Linux isn't a supported platform.

Unfortunately, I can no longer test because I no longer have the motherboard.

DataDrake claimed this task.

Since this appears to be an upstream kernel issue and the original author no longer has the hardware for testing, closing this.