HP EliteBook 745 G5 (Ryzen 2500U) fails to boot unless `mce=off` is set on command line
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Fix Released
|
Medium
|
|||
linux (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Bionic |
Fix Released
|
Medium
|
Unassigned | ||
Cosmic |
Won't Fix
|
Undecided
|
Unassigned | ||
Disco |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
=== SRU Justification ===
[Impact]
System doesn't boot without "mce=off".
[Fix]
Quote from the commit log:
"Clear the "Counter Present" bit in the Instruction Fetch bank's
MCA_MISC0 register. This will prevent enabling MCA thresholding on this
bank which will prevent the high interrupt rate due to this error."
[Test]
The affected user reported these commits fix the issue.
[Regression Potential]
Low. Upstream stable commits. I don't see any regression on my
unaffected AMD systems.
=== Original Bug Report ===
My new Elitebook, with the latest bios 1.03.01, refuses to boot any kernel later than 4.10 unless mce=off is appended to the kernel command line. As in, there are no kernel messages at all after grub (yes, quiet and splash were removed from the command line). Perhaps it crashes before the efifb kicks in?
System operates fine if mce=off is added to the kernel command line (and iommu=soft, but that's a separate issue, and fails with kernel output in that case).
I opened upstream bug here : https:/
I bisected the problem down to this commit (and the few before it, which also added extra MCE output, but didn't actually crash):
18807ddb7f8
commit 18807ddb7f88d4a
Author: Yazen Ghannam <email address hidden>
Date: Tue Nov 15 15:13:53 2016 -0600
x86/mce/AMD: Reset Threshold Limit after logging error
The error count field in MCA_MISC does not get reset by hardware when the
threshold has been reached. Software is expected to reset it. Currently,
the threshold limit only gets reset during init or when a user writes to
sysfs.
If the user is not monitoring threshold interrupts and resetting
the limit then the user will only see 1 interrupt when the limit is first
hit. So if, for example, the limit is set to 10 then only 1 interrupt will
be recorded after 10 errors even if 100 errors have occurred. The user may
then assume that only 10 errors have occurred.
There are threads online about this being related to the latest bios. The upstream bug has acpidump attached.
ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: linux-image-
ProcVersionSign
Uname: Linux 4.18.0-8-generic x86_64
ApportVersion: 2.20.10-0ubuntu11
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/pcmC1D0p: john 2015 F...m pulseaudio
/dev/snd/
CurrentDesktop: ubuntu:GNOME
Date: Fri Oct 5 23:24:45 2018
InstallationDate: Installed on 2018-09-30 (5 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Beta amd64 (20180927)
Lsusb:
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: HP HP EliteBook 745 G5
ProcEnviron:
TERM=xterm-
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=
RelatedPackageV
linux-
linux-
linux-firmware 1.175
RfKill:
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
SourcePackage: linux
StagingDrivers: r8822be
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/26/2018
dmi.bios.vendor: HP
dmi.bios.version: Q81 Ver. 01.03.01
dmi.board.name: 83D5
dmi.board.vendor: HP
dmi.board.version: KBC Version 08.47.00
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.modalias: dmi:bvnHP:
dmi.product.family: 103C_5336AN HP EliteBook
dmi.product.name: HP EliteBook 745 G5
dmi.product.sku: 2MG23AV
dmi.sys.vendor: HP
Changed in linux: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
Changed in linux: | |
status: | Confirmed → Fix Released |
Changed in linux (Ubuntu): | |
status: | Confirmed → Fix Released |
description: | updated |
Changed in linux (Ubuntu Cosmic): | |
status: | New → Won't Fix |
Changed in linux (Ubuntu Bionic): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Disco): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Bionic): | |
status: | New → Fix Committed |
tags: |
added: verification-done-bionic removed: verification-needed-bionic |
tags: |
added: verification-done-xenial removed: verification-needed-xenial |
Changed in linux (Ubuntu Disco): | |
status: | Fix Committed → Won't Fix |
Created attachment 278845
ACPI dump
New HP EliteBook 745 G5, BIOS version 1.03.01. Ryzen PRO 2500u.
Booting any modern kernel (4.10+) hangs at boot on this system with no kernel messages displayed unless you disable MCE support (via mce=off).
Knowing Debian's 4.9 kernel boots fine, I bisected Linus's tree, and it appears this commit is the culprit:
18807ddb7f8 8d4ac3797302baf b18143d573e66f is the first bad commit c3797302bafb181 43d573e66f
commit 18807ddb7f88d4a
Author: Yazen Ghannam <email address hidden>
Date: Tue Nov 15 15:13:53 2016 -0600
x86/mce/AMD: Reset Threshold Limit after logging error
The error count field in MCA_MISC does not get reset by hardware when the
threshold has been reached. Software is expected to reset it. Currently,
the threshold limit only gets reset during init or when a user writes to
sysfs.
If the user is not monitoring threshold interrupts and resetting
the limit then the user will only see 1 interrupt when the limit is first
hit. So if, for example, the limit is set to 10 then only 1 interrupt will
be recorded after 10 errors even if 100 errors have occurred. The user may
then assume that only 10 errors have occurred.
.. although the previous few commits to this one also are all related to MCE support on AMD systems, so it may be a culmination of a few commits.