ACPI errors

Bug #1877870 reported by Goncalves-st
12
This bug affects 3 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Hi,

i have a bunch of acpi errors showing up on the log. this one repeats a lot:

ACPI BIOS Error (bug): Failure creating named object [\_SB.PCI0.XHC.RHUB.SS09._UPC], AE_ALREADY_EXISTS (20190816/dswload2-323)

my bios is updated (from windows, on april 3, 2020)

currently running ubuntu 20.04 with kernel 5.4.0-29-generic

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-29-generic 5.4.0-29.33
ProcVersionSignature: Ubuntu 5.4.0-29.33-generic 5.4.30
Uname: Linux 5.4.0-29-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: pkillpeers 1879 F.... pulseaudio
 /dev/snd/controlC0: pkillpeers 1879 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Sun May 10 16:24:50 2020
InstallationDate: Installed on 2020-05-07 (3 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 0408:5300 Quanta Computer, Inc. HP Wide Vision HD Camera
 Bus 001 Device 002: ID 046d:c07e Logitech, Inc. G402 Gaming Mouse
 Bus 001 Device 004: ID 8087:0aaa Intel Corp.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: HP OMEN by HP Laptop 15-dc0xxx
ProcFB: 0 EFI VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-29-generic root=UUID=c93b8267-6fe4-492f-ad94-1252537b50fb ro
RelatedPackageVersions:
 linux-restricted-modules-5.4.0-29-generic N/A
 linux-backports-modules-5.4.0-29-generic N/A
 linux-firmware 1.187
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/23/2020
dmi.bios.vendor: AMI
dmi.bios.version: F.12
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 84DB
dmi.board.vendor: HP
dmi.board.version: 93.24
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAMI:bvrF.12:bd03/23/2020:svnHP:pnOMENbyHPLaptop15-dc0xxx:pvr:rvnHP:rn84DB:rvr93.24:cvnHP:ct10:cvrChassisVersion:
dmi.product.family: 103C_5335KV HP OMEN
dmi.product.name: OMEN by HP Laptop 15-dc0xxx
dmi.product.sku: 4ML16EA#AB9
dmi.sys.vendor: HP

Revision history for this message
Goncalves-st (goncalves-st) wrote :
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Alex Hung (alexhung) wrote :

This is usually the result of duplicated name declaration in ACPI BIOS, and there are usually no harms.

An ACPI dump (sudo acpidump > acpi.log) will be helpful for further analysis.

Revision history for this message
Goncalves-st (goncalves-st) wrote :

Hi!
thanks a bunch for showing interest!
I decided to make a fresh install, so no other tweaks/apps could mess with the logs.
apt full-upgrade , reboot and here's the log.
cheers

Revision history for this message
Alex Hung (alexhung) wrote :

ACPI consists of many tables. Two types of them are DSDT and SSDT.

DSDT is mandatory, and SSDTs are addon to DSDT and are optional. SSDT is / can be loaded according to hardware config during boot time. In the case of this system, the ACPI objects that are erroneous are both declared in DSDT and a SSDT (i.e. SSDT6 if you extract from acpi.log). It seems to be that contents of SSDT6 are almost copied to DSDT and it should not be loaded at all.

Fortunately, most of the duplicated objects (methods) are very similar, if not identical, to their clones in DSDT. When kernel parses SSDT6, it found these objects already exist and stopped loading them. This does not cause functional loss so there is nothing to worry about.

A fix must be done in BIOS, but a workaround is to modify SSDT6 and override it with ACPI override by Linux kernel; however, the later would "taint" the kernel and it would also be a overkill when nothing is broken.

Revision history for this message
Goncalves-st (goncalves-st) wrote :

Ok, although i'm not as technical as you, i think i understand. So, as i'm not detecting any hardware issue, i can assume there's nothing to be solved here, right?
thanks for the time you spent analyzing :)
cheers and have a nice day

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.