Boot/shut down errors - acpi error: no pointer back to namespace node in package

[Daniel]

When starting up or shutting down my computer I'm getting a series of errors, they are all: "acpi error: no pointer back to namespace node in package 00000000 27e26079 (20210730/dsargs-301)". In front of the ACPI Error it list a number (there are several lines with the error). The numbers are: [ 0.232190], [ 0.312112], [ 0.315115], [ 0.316825], [ 0.318901], [ 0.319710], [ 0.321439], [ 0.322801], [ 0.324911], [ 0.326145].

This is then followed by two more lines: [ 1.233205] DMAR: DRHD: handling fault status reg 3, and [ 1.233292] DMAR: [DMA Read NO_PASID] Request device [3b:00.0] fault addr 0xf

Before all the above ACPI errors there is a line that says: [ 0.141891] x86/cpu: SQX disabled by BIOS.

What does this all mean and can it cause any harm?
I copied all the above errors from my phone of which I used the camera the film the startup as it is all passing to quickly to take notes and I haven't found any log files that show the same. So I might have typed a few wrong numbers where I couldn't read it properly.

Thank you.

[rab0171610]

Someone posted about this in another forum. SGX stands for "Intel Software Guard Extensions". Some additional details on this:

Intel® Software Guard Extensions (SGX) is a hardware-based isolation and memory encryption mechanism provided by modern Intel® CPUs. Normally, it is disabled in the BIOS by the manufacture of your motherboard. In order to use it, the SGX option in the BIOS must be set to Enable or Software Controlled.
By setting the option to Enable, all of the SGX instructions and resources are available to applications, making it easy to deploy SGX related program on your machine. However, in some motherboards, the only available options in the BIOS are Software Controlled and Disable. According to the official document of Intel, Software Controlled indicates that Intel SGX can be enabled by software applications, but it is not available until this occurs (called the “software opt-in”).

My suggestion is to try one of two things. First, you could consider enabling SGX in the bios as detailed above. Since the kernel is complaining that it is disabled, see if you can enable this setting.
The other thing you could try is adding the 'nosgx' boot parameter to the kernel boot parameters. If you need more guidance on how to do this, please post back and someone will guide you through the process. Otherwise, let us know if you accomplish either of those things on your own and if it fixes your problem. It can help others with the same issue.

Good Luck!

[Daniel]

I have change the setting in the BIOS for the SGX to Enabled. The previous setting was Software controlled. The change didn't have any effect and I am still getting the same errors. I also just checked the Dell website and they have an updated BIOS available for my computer, so I'll try updating to that newer version now and see if that makes a difference.

[rab0171610]

Someone posted on another forum that the bios update did indeed help with this error. Hopefully it works for you.

Good Luck!

[Daniel]

The references to errors for DMAR and SGX have dissapeared, but all the ACPI errors are still there (but preceded by different numbers). Can these ACPI errors cause any harm?

[rab0171610]

I figured that might be the case, so I did not comment on the ACPI errors. One step at a time. I do not think the errors are harmful. If I come across any info for you I will post back. I am sorry I do not have any advice at this time. I am home sick from work. If I start to feel better I will do some research for you. Good Luck.

[rab0171610]

In the meantime, someone gave advice on another forum:

The advice there was to not run in BIOS legacy mode by disabling UEFI but to run in UEFI mode instead with secure boot disabled. I haven't bothered with it myself since I have several operating systems already installed with BIOS legacy mode and I would have to reinstall everything if I wanted to switch to UEFI mode.

Apparently a lot of people have this problem and as of now it is just a warning and nothing to worry about. If you would like to try the advice above and see if it works for you, it may help suppress the messages.

[Daniel]

I already have my computer set to run in UEFI mode with secure booth disabled, it doesn't seem to make any difference for this issue.

[rab0171610]

The acpi messages are nothing to worry about. It has to do with the way Motherboard manufacturers implement acpi standards to cater to Windows operating system. When using Linux, the messages appear. Unfortunately, there is not fix for it. It is just the nature of the beast.

[mopsie]

I am also seeing the ACPI errors, which seem to have started after I upgraded from Kubuntu 21.10 to 22.04, or at least I don't remember seeing the messages in 21.10 while the system booted. I also tried upgrading my kernel from 5.15 to 5.17.5-051705-generic and I still see the errors.

rab0171610 as you mentioned , I guess this is nothing to worry about because everything on my laptop appears to be working. But I would be interested to know why these errors appear. I can't seem to find any good documentation, blogs or websites describing these errors and how to fix or hide them.

(I am not a Linux expert or programmer. I am a Linux hobbyist and don't mind reading instructions and installing the latest software or kernel, just to see how things work, what has changed or to see what breaks)


command: $journalctl -p err -b

Mai 04 10:07:21 Lenovo530S kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330)
Mai 04 10:07:21 Lenovo530S kernel: ACPI Error: Aborting method \_PR.PR01._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529)
Mai 04 10:07:21 Lenovo530S kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330)
Mai 04 10:07:21 Lenovo530S kernel: ACPI Error: Aborting method \_PR.PR02._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529)
Mai 04 10:07:21 Lenovo530S kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330)
Mai 04 10:07:21 Lenovo530S kernel: ACPI Error: Aborting method \_PR.PR03._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529)
Mai 04 10:07:21 Lenovo530S kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330)
Mai 04 10:07:21 Lenovo530S kernel: ACPI Error: Aborting method \_PR.PR04._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529)
Mai 04 10:07:21 Lenovo530S kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330)
Mai 04 10:07:21 Lenovo530S kernel: ACPI Error: Aborting method \_PR.PR05._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529)
Mai 04 10:07:21 Lenovo530S kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330)
Mai 04 10:07:21 Lenovo530S kernel: ACPI Error: Aborting method \_PR.PR06._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529)
Mai 04 10:07:21 Lenovo530S kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330)
Mai 04 10:07:21 Lenovo530S kernel: ACPI Error: Aborting method \_PR.PR07._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529)

[rab0171610]

Apparently you can blame Microsoft market dominance for this. From another forum:
[QUOTEJust to give you some background, as you probably know, ACPI is the power regulation code in your motherboard's BIOS/UEFI:

https://en.wikipedia.org/wiki/Advanc...ower_Interface

It's suppose to be a standard that any operating system can properly implement. However, in typical Microsoft fashion, MS operating systems do not follow or properly implement the ACPI standard. Instead, MS gives motherboard manufacturers their own improperly implemented ACPI code for inclusion in the motherboard BIOS/UEFI. The code runs fine with MS windows but all for other operating systems like linux there can be problems. Because of MS's market dominance, the faulty ACPI implementation from MS has become the de facto industry standard. As a result, linux and other non-MS operating systems have to reverse engineer the faulty ACPI implementation from MS. That's why you can see problems in linux with ACPI related functionality like suspend to ram, hibernate, etc.

Apparently, the ACPI related code in certain newer linux kernels has a problem with the typical BIOS/UEFI ACPI implementation on certain motherboards which is why we're getting those error messages. Even though I get those error messages at the beginning of the boot process, I've had no problems with suspend/resume or any other ACPI related issues.][/QUOTE]

[rab0171610]

Something relevant in the acpi wiki link:

Ubuntu founder Mark Shuttleworth has likened ACPI to Trojan horses. He has described proprietary firmware (ACPI-related or any other firmware) as a security risk, saying that "firmware on your device is the NSA's best friend" and calling firmware (ACPI or non-ACPI) "a Trojan horse of monumental proportions". He has pointed out that low quality, closed source firmware is a major threat to system security: "Your biggest mistake is to assume that the NSA is the only institution abusing this position of trust – in fact, it's reasonable to assume that all firmware is a cesspool of insecurity, courtesy of incompetence of the highest degree from manufacturers, and competence of the highest degree from a very wide range of such agencies." As a solution to this problem, he has called for open-source, declarative firmware (ACPI or non-ACPI), which instead of containing executable code, only describes "hardware linkage and dependencies".

A custom ACPI table called the Windows Platform Binary Table (WPBT) is used by Microsoft to allow vendors to add software into the Windows OS automatically. Some vendors, such as Lenovo and Samsung, have been caught using this feature to install harmful software such as Superfish. Windows versions older than Windows 7 do not support this feature, but alternative techniques can be used. This behavior has been compared to rootkits.

and also:

Windows operating systems use acpi.sys to access ACPI events.
. . .
Linux-based operating systems can provide access to ACPI events via acpid.

It is just how Linux interacts with the ACPI standard on the computer. It is nothing to worry about. It is an ugly side effect of running Linux on a computer built for and sold with Windows installed.