Bug 1413342 - Linux 4.9.3: ACPI Error: [_OSI] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
Summary: Linux 4.9.3: ACPI Error: [_OSI] Namespace lookup failure, AE_NOT_FOUND (20160...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 27
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1415853 1553320 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-15 06:26 UTC by Fadlun Akbar
Modified: 2019-01-09 12:54 UTC (History)
44 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-08 00:46:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
dmesg-acpi-log (12.95 KB, text/plain)
2017-01-15 06:26 UTC, Fadlun Akbar
no flags Details
Similar log messages in arch linux for kernel 4.9.6-1 (215.96 KB, text/plain)
2017-01-31 18:55 UTC, Mike C
no flags Details
Output of: cat /sys/firmware/acpi/tables/DSDT > dsdt.dat & iasl -d dsdt.dat (1.07 MB, text/plain)
2017-04-15 14:19 UTC, Simon Rowe
no flags Details
Dell XPS 15 9550 BIOS 1.6.1 dmesg output (93.27 KB, text/plain)
2018-02-22 08:57 UTC, Enrico Tagliavini
no flags Details


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 103414 0 None None None 2018-03-08 18:39:41 UTC

Internal Links: 1455232 1514937

Description Fadlun Akbar 2017-01-15 06:26:05 UTC
Created attachment 1240893 [details]
dmesg-acpi-log

Description of problem:

When I used kernel parameter acpi_osi= without any string (e.g: acpi_osi=Linux), I got some error messages:

[    0.297969] ACPI Error: [_OSI] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.298152] ACPI Error: Method parse/execution failed [\_SB.BTKL._STA] (Node ffffa0b3a84cb2f8), AE_NOT_FOUND (20160831/psparse-543)
[    0.298396] ACPI Error: [_OSI] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.298571] ACPI Error: Method parse/execution failed [\_SB.BTKL._STA] (Node ffffa0b3a84cb2f8), AE_NOT_FOUND (20160831/psparse-543)

Kernel version: 4.9.3-200.fc25.x86_64

Steps to Reproduce:
Boot 4.9.3-200.fc25.x86_64 with kernel parameter acpi_osi=

Actual results:
See attachment for full log

Expected results:
No error messages

Comment 1 Vinicius Reis 2017-01-16 11:28:39 UTC
Same issue here since 4.9.3-200.fc25.x86_64, not using acpi_osi at all.
Previous kernel did not generate these messages.

$dmesg | grep -i 'lookup'
[    0.732689] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECWT] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.732802] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECWT] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.763406] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.763586] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.763710] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.763826] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)

Comment 2 Laura Abbott 2017-01-16 18:45:14 UTC
I recommend running a bisect to figure out which commit introduced these messages for you. You could also file a bug on kernel.org since Intel maintainers are often responsive there.

Comment 3 mrh 2017-01-17 16:07:51 UTC
Another example of same issue but system fails to boot, whereas this system boots fine using 4.8.15-300:

Jan 16 20:47:40 copernicus kernel: ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20160831/dsw
Jan 16 20:47:40 copernicus kernel: ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20160831/psobject-227)
Jan 16 20:47:40 copernicus kernel: ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp08) while loading table (20160831/tbxfload-228)
Jan 16 20:47:40 copernicus kernel: ACPI Error: 1 table load failures, 8 successful (20160831/tbxfload-246)

and further down the same boot log...

Jan 16 20:47:41 copernicus kernel: amdgpu 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff
Jan 16 20:47:41 copernicus kernel: ATOM BIOS: 67DFHB.15.50.0.0.AS37
Jan 16 20:47:41 copernicus kernel: [drm] GPU post is not needed
Jan 16 20:47:41 copernicus kernel: amdgpu 0000:01:00.0: Direct firmware load for amdgpu/polaris10_mc.bin failed with error -2
Jan 16 20:47:41 copernicus kernel: mc: Failed to load firmware "amdgpu/polaris10_mc.bin"
Jan 16 20:47:41 copernicus kernel: [drm:gmc_v8_0_sw_init [amdgpu]] *ERROR* Failed to load mc firmware!
Jan 16 20:47:41 copernicus kernel: [drm:amdgpu_device_init [amdgpu]] *ERROR* sw_init of IP block <gmc_v8_0> failed -2
Jan 16 20:47:41 copernicus kernel: amdgpu 0000:01:00.0: amdgpu_init failed
Jan 16 20:47:41 copernicus kernel: amdgpu 0000:01:00.0: Fatal error during GPU init
Jan 16 20:47:41 copernicus kernel: [drm] amdgpu: finishing device.
Jan 16 20:47:41 copernicus kernel: [TTM] Memory type 2 has not been initialized
Jan 16 20:47:41 copernicus kernel: amdgpu: probe of 0000:01:00.0 failed with error -2

Boot failure

Comment 4 Vinicius Reis 2017-01-18 14:46:01 UTC
I can't do a bisect patch by patch since this  issue actually is happening on a production machine, what prevents a deep kernel compile/test/debug procedure; but I can provide any useful log needed for one working on this issue. 

What I can identify is the Fedora kernel release that introduced this issue on this machine. The last 'OK' release was 4.8.16-300.fc25.x86_64. The next release, 4.9.3-200.fc25.x86_64, introduced this issue.

Currently I can't say if something stopped to work, but as opposed to #3, the boot doesn't fail. For the sake of safety, we are booting with the previous kernel (4.8.16-300).

Comment 5 Alexander 2017-01-23 20:25:17 UTC
Confirming this.

4.9.4-100.fc24.x86_64

янв 23 23:19:08 freelancer.localdomain kernel: ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20160831/dswload-210)
янв 23 23:19:08 freelancer.localdomain kernel: ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20160831/psobject-227)
янв 23 23:19:08 freelancer.localdomain kernel: ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp08) while loading table (20160831/tbxfload-228)
янв 23 23:19:08 freelancer.localdomain kernel: ACPI Error: 1 table load failures, 8 successful (20160831/tbxfload-246)

ASUS Z170-K motherboard and Intel 6700K CPU, if this is important.

Comment 6 Alexander 2017-01-23 20:28:04 UTC
(In reply to Alexander from comment #5)
> Confirming this.

Systems boots as usually except this message in journal and at boot screen.

Comment 7 cyberalex4life 2017-01-24 16:15:03 UTC
Here's how this bug looks on my laptop: 
(Lenovo G70-80, Intel Core i7-5500U @ 2.40GHz × 4, 8GB RAM, NVidia GF 920M 2GB, 120 GB SSD OCZ-AGILITY3, 1TB HDD Western Digital WDC WD10JPCX-24UE4T0)
https://i.imgur.com/tlUVoRl.jpg
https://i.imgur.com/ZJcf811.jpg
This happens from kernel 4.9.3 I think (the first 4.9 from updates). Another issue is that resuming from hibernate ends with my screen blocked with the image before hibernate. I usually have to force it off.

I am on 4.8.6, this is the last 4.8 in repo's, and things go generally well, including hibernating.

Here's what I have in /etc/default/grub:
GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/5b099b6f-8c16-4503-bd77-a1cd8ca5a756     nouveau.modeset=0 rd.driver.blacklist=nouveau rhgb quiet"
GRUB_CMDLINE_LINUX_DEFAULT="elevator=deadline usbhid.mousepoll=4" 

Also, bumblebee-nvidia fails to compile in the actual 4.9.5 (I'm not sure about 4.9.4)

Comment 8 Laura Abbott 2017-01-24 18:58:18 UTC
*** Bug 1415853 has been marked as a duplicate of this bug. ***

Comment 9 Vinicius Reis 2017-01-25 13:18:37 UTC
This issue still present on 4.9.5-200.fc25.x86_64

Comment 10 Greta Watson 2017-01-25 18:26:10 UTC
Also fails in fedora 24 with kernel 4.9.5-100.fc24.x86_64.

Jan 25 02:15:43 sparky kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
...

System boots but spews out a bunch of error messages.

Comment 11 Vinicius Reis 2017-01-31 16:33:37 UTC
With the new 4.9.6-200.fc25.x86_64 release, a new message is shown, but I'm not sure if it is related to the ones previously reported:
[    0.287520] platform wdat_wdt: failed to claim resource 4

So now, the following messages are shown at boot time:
[    0.287520] platform wdat_wdt: failed to claim resource 4
[    0.732858] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECWT] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.732902] ACPI Error: Method parse/execution failed [\_TZ.FN00._ON] (Node ffff9be4d60eff78), AE_NOT_FOUND (20160831/psparse-543)
[    0.732971] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECWT] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.733010] ACPI Error: Method parse/execution failed [\_TZ.FN00._ON] (Node ffff9be4d60eff78), AE_NOT_FOUND (20160831/psparse-543)
[    0.755676] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.755717] ACPI Error: Method parse/execution failed [\_TZ.TZ00._TMP] (Node ffff9be4d60efcf8), AE_NOT_FOUND (20160831/psparse-543)
[    0.755838] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.755878] ACPI Error: Method parse/execution failed [\_TZ.TZ00._TMP] (Node ffff9be4d60efcf8), AE_NOT_FOUND (20160831/psparse-543)
[    0.755958] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.755997] ACPI Error: Method parse/execution failed [\_TZ.TZ01._TMP] (Node ffff9be4d60f45a0), AE_NOT_FOUND (20160831/psparse-543)
[    0.756071] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.756109] ACPI Error: Method parse/execution failed [\_TZ.TZ01._TMP] (Node ffff9be4d60f45a0), AE_NOT_FOUND (20160831/psparse-543)


After that, system boots and is usable with no noticeable issues though.

Comment 12 Mike C 2017-01-31 18:55:21 UTC
Created attachment 1246393 [details]
Similar log messages in arch linux for kernel 4.9.6-1

Given the analogous messages are also seen in a different distro this is likely an upstream bug so perhaps worth reporting at kernel bugzilla?

Comment 13 Mike C 2017-01-31 19:00:25 UTC
Upstream bug is https://bugzilla.kernel.org/show_bug.cgi?id=193531

Comment 14 Patrick O'Callaghan 2017-03-06 16:45:47 UTC
Another sufferer here, basically since F25. I see from the journal that these are not new messages, but they are now prominently displayed on the console when booting instead of being quietly added to the log. If they don't indicate a real problem, is there a way to get them to just shut up?

Comment 15 cyberalex4life 2017-03-06 22:02:37 UTC
With the possibility of being ridiculous, I admit I asked myself the same question of few years, ago. However I have not found an easy answer so I let it go. And here comes the ridiculous part: maybe they are just there to annoy people so that they'll be fixed and also to point that there's always that problem that could be the cause of other failures.
If this is the case, the hardest workaround would be a patch from someone that knows what is doing, or multiple configuration files edited/added. 
The simplest may be one hidden config file somewhere in the system... I always thought that this should be a simple info to find, but it proved not.

Comment 16 Justin M. Forbes 2017-04-11 14:56:24 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 25 kernel bugs.

Fedora 25 has now been rebased to 4.10.9-200.fc25.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26.

If you experience different issues, please open a new bug report for those.

Comment 17 Fadlun Akbar 2017-04-11 15:45:35 UTC
(In reply to Justin M. Forbes from comment #16)
> *********** MASS BUG UPDATE **************
> 
> We apologize for the inconvenience.  There is a large number of bugs to go
> through and several of them have gone stale.  Due to this, we are doing a
> mass bug update across all of the Fedora 25 kernel bugs.
> 
> Fedora 25 has now been rebased to 4.10.9-200.fc25.  Please test this kernel
> update (or newer) and let us know if you issue has been resolved or if it is
> still present with the newer kernel.
> 
> If you have moved on to Fedora 26, and are still experiencing this issue,
> please change the version to Fedora 26.
> 
> If you experience different issues, please open a new bug report for those.

The current kernel (4.10.8-200.fc25.x86_64) had solved this issue. Tested on:

System:    Host: nekodora Kernel: 4.10.8-200.fc25.x86_64 x86_64 (64 bit) Desktop: Budgie 10.2.9
           Distro: Fedora release 25 (Twenty Five)
Machine:   Device: laptop System: ASUSTeK product: X455LD v: 1.0
           Mobo: ASUSTeK model: X455LD v: 1.0 UEFI: American Megatrends v: X455LD.202 date: 06/11/2014
Battery    BAT0: charge: 13.8 Wh 63.8% condition: 21.6/37.3 Wh (58%)
CPU:       Dual core Intel Core i3-4030U (-HT-MCP-) speed/max: 799/1800 MHz
Graphics:  Card-1: Intel Haswell-ULT Integrated Graphics Controller
           Card-2: NVIDIA GF117M [GeForce 610M/710M/810M/820M / GT 620M/625M/630M/720M]
           Display Server: Fedora X.org 119.3 drivers: intel (unloaded: modesetting,fbdev,vesa)
           Resolution: 1366x768
           GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 13.0.4
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
           Card-2: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter driver: ath9k
Drives:    HDD Total Size: 500.1GB (30.0% used)
Info:      Processes: 236 Uptime: 1:50 Memory: 1828.0/5788.4MB Client: Shell (zsh) inxi: 2.3.8

Comment 18 Patrick O'Callaghan 2017-04-11 16:43:51 UTC
(In reply to Justin M. Forbes from comment #16)
> *********** MASS BUG UPDATE **************
> 
> We apologize for the inconvenience.  There is a large number of bugs to go
> through and several of them have gone stale.  Due to this, we are doing a
> mass bug update across all of the Fedora 25 kernel bugs.
> 
> Fedora 25 has now been rebased to 4.10.9-200.fc25.  Please test this kernel
> update (or newer) and let us know if you issue has been resolved or if it is
> still present with the newer kernel.
> 
> If you have moved on to Fedora 26, and are still experiencing this issue,
> please change the version to Fedora 26.
> 
> If you experience different issues, please open a new bug report for those.

Appears to be solved here, kernel 4.10.8-200.fc25.x86_64

Comment 19 Isaque Galdino 2017-04-11 17:38:34 UTC
I'm still seeing this issue:

$ uname -a
Linux fred.bedrock 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ dmesg | grep -i namespace
[    0.937396] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECWT] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.937527] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECWT] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.949988] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.950154] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.950275] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.950388] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)

Comment 20 Jia Yuan Lo 2017-04-12 03:11:22 UTC
I believe all the namespace lookup failure (in ASUS laptops) is caused by acpi_osi=

which leads to going into untested route in DSDT

Since 4.10, I no longer need acpi_osi= for my ASUS X552LD (BIOS X550LD) and fn keys and backlight are working out of box now...

You guys can try remove acpi_osi=

If it doesn't, follow https://wiki.archlinux.org/index.php/DSDT#Recompiling_it_yourself

# dnf install acpica-tools
# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
$ iasl -d dsdt.dat

Then open dsdt.dsl with a text editor and search for Windows

You should get a list of OS strings that your ACPI known to support

then you can go add to grub and test it in descending order

acpi_osi=! acpi_osi="Windows [insert version here]"

acpi_osi= should not be the workaround and acpi_osi=Linux are not advised to use either

Comment 21 Greta Watson 2017-04-12 18:02:18 UTC
My ASUS laptop has never seen this issue.

My desktop, though, not only has seen this issue, but still sees it:

~ $ uname -a
Linux sparky 4.10.9-200.fc25.x86_64 #1 SMP Mon Apr 10 14:48:16 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
~ $ dmesg | grep "ACPI Error" | head -4
[    1.218406] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    1.218463] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT2._GTF] (Node ffff8bb24f4c2618), AE_NOT_FOUND (20160930/psparse-543)
[    1.218993] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    1.219045] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT2._GTF] (Node ffff8bb24f4c2618), AE_NOT_FOUND (20160930/psparse-543)

Comment 22 Fadlun Akbar 2017-04-13 19:37:19 UTC
(In reply to Jia Yuan Lo from comment #20)
> I believe all the namespace lookup failure (in ASUS laptops) is caused by
> acpi_osi=
> 
> which leads to going into untested route in DSDT
> 
> Since 4.10, I no longer need acpi_osi= for my ASUS X552LD (BIOS X550LD) and
> fn keys and backlight are working out of box now...
> 
> You guys can try remove acpi_osi=
> 
> If it doesn't, follow
> https://wiki.archlinux.org/index.php/DSDT#Recompiling_it_yourself
> 
> # dnf install acpica-tools
> # cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
> $ iasl -d dsdt.dat
> 
> Then open dsdt.dsl with a text editor and search for Windows
> 
> You should get a list of OS strings that your ACPI known to support
> 
> then you can go add to grub and test it in descending order
> 
> acpi_osi=! acpi_osi="Windows [insert version here]"
> 
> acpi_osi= should not be the workaround and acpi_osi=Linux are not advised to
> use either

Yup, this is what I mean. With the the current kernel, I no longer need acpi_osi= too for my ASUS A455L, works great as you said.

Comment 23 Simon Rowe 2017-04-15 14:14:23 UTC
System is Alienware 13 R2 laptop running Fedora 25 (fresh net install) with updates applied:

Kernel version: 
Linux version 4.10.9-200.fc25.x86_64 (mockbuild.fedoraproject.org) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) ) #1 SMP Mon Apr 10 14:48:16 UTC 2017

journalctl -xb output ACPI errors:

ACPI Error: [\_SB_.PCI0.SAT1] Namespace lookup failure, AE_NOT_FOUND (20160930/dswload-210)
Apr 15 14:26:21 alienmoons kernel: ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20160930/psobject-227)
Apr 15 14:26:21 alienmoons kernel: ACPI Exception: AE_NOT_FOUND, (SSDT:IdeTable) while loading table (20160930/tbxfload-228)
Apr 15 14:26:21 alienmoons kernel: ACPI Error: 1 table load failures, 10 successful (20160930/tbxfload-246)

Then later on in boot messages (not sure if it is related):

ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160930/nsarguments-95)
Apr 15 14:26:21 alienmoons kernel: ACPI Warning: \_SB.PCI0.RP01.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160930/nsarguments-95)
Apr 15 14:26:21 alienmoons kernel: ACPI Warning: \_SB.PCI0.RP01.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160930/nsarguments-95)

Comment 24 Simon Rowe 2017-04-15 14:19:41 UTC
Created attachment 1271816 [details]
Output of:  cat /sys/firmware/acpi/tables/DSDT > dsdt.dat   &   iasl -d dsdt.dat

As per suggested comments in this bug report, I ran the following:

dnf install acpica-tools
cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
iasl -d dsdt.dat

Attached file is the output of the final command above - just in case it is useful to assist with working out what the issue is.

Comment 25 Panos Kavalagios 2017-04-20 14:15:31 UTC
I am also affected by this issue and there is no BIOS upgrade for my motherboard:

[    0.841257] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.841317] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT1._GTF] (Node ffffa08c0e8cb050), AE_NOT_FOUND (20160930/psparse-543)
[    0.841668] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.841726] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT0._GTF] (Node ffffa08c0e8cb348), AE_NOT_FOUND (20160930/psparse-543)
[    0.842786] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.842844] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT4._GTF] (Node ffffa08c0e8cb488), AE_NOT_FOUND (20160930/psparse-543)

and my system is:

BIOS Information
        Vendor: American Megatrends Inc.
        Version: 4.6.5
        Release Date: 12/18/2012
Base Board Information
        Manufacturer: WIBTEK
        Product Name: H61-M HDMI2 
        Version: 0.59

Comment 26 Norbert Makula 2017-04-20 21:23:58 UTC
Hello

Comment 27 Norbert Makula 2017-04-20 21:30:55 UTC
Sorry for that comment. I don't wanted send it...
I have this error too.

ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20160930/dswload-210)
ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20160930/psobject-227)
ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp08) while loading table (20160930/tbxfload-228)
ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20160930/psobject-227)
ACPI Error: 1 table load failures, 5 successful (20160930/tbxfload-246)

BIOS Information
Vendor: American Megatrends Inc.
	Version: P7.10
	Release Date: 11/30/2016

Base Board Information
	Manufacturer: ASRock
	Product Name: B150M Pro4
	Version:

Comment 28 Louis van Dyk 2017-04-22 23:29:11 UTC
Problem persists:

# uname -a
Linux fedora.localdomain 4.10.10-200.fc25.x86_64 #1 SMP Thu Apr 13 01:11:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

See below extract from dmesg:

[    0.938813] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    0.938835] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    0.938866] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    0.938887] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    0.938911] ata7: SATA link down (SStatus 0 SControl 300)
[    0.938922] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    0.938958] ata8: SATA link down (SStatus 0 SControl 300)
[    0.938960] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    0.939406] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.939482] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT3._GTF] (Node ffff8ae0ce0cff50), AE_NOT_FOUND (20160930/psparse-543)
[    0.939613] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.939688] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT5._GTF] (Node ffff8ae0ce0e6528), AE_NOT_FOUND (20160930/psparse-543)
[    0.939828] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.939920] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT1._GTF] (Node ffff8ae0ce0cfdc0), AE_NOT_FOUND (20160930/psparse-543)
[    0.940099] ata6.00: ATA-9: WDC WD40PURX-64GVNY0, 80.00A80, max UDMA/133
[    0.940101] ata6.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    0.940165] ata4.00: ATA-9: ST4000DM000-1F2168, CC54, max UDMA/133
[    0.940168] ata4.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    0.940196] ata2.00: ATA-8: ST3500418AS, CC38, max UDMA/133
[    0.940199] ata2.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32)
[    0.940756] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.940830] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT5._GTF] (Node ffff8ae0ce0e6528), AE_NOT_FOUND (20160930/psparse-543)
[    0.940976] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.941053] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT3._GTF] (Node ffff8ae0ce0cff50), AE_NOT_FOUND (20160930/psparse-543)
[    0.941228] ata6.00: configured for UDMA/133
[    0.941355] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.941430] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT1._GTF] (Node ffff8ae0ce0cfdc0), AE_NOT_FOUND (20160930/psparse-543)
[    0.941631] ata4.00: configured for UDMA/133
[    0.941701] ata2.00: configured for UDMA/133
[    0.944377] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.944632] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT2._GTF] (Node ffff8ae0ce0cf5c8), AE_NOT_FOUND (20160930/psparse-543)
[    0.944921] ata3.00: ATAPI: HL-DT-ST DVDRAM GH22NS40, NL02, max UDMA/100
[    0.945013] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.945280] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT4._GTF] (Node ffff8ae0ce0cfeb0), AE_NOT_FOUND (20160930/psparse-543)
[    0.945700] ata5.00: ATA-8: SAMSUNG HD204UI, 1AQ10001, max UDMA/133
[    0.945702] ata5.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    0.947907] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.948178] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT0._GTF] (Node ffff8ae0ce0cf898), AE_NOT_FOUND (20160930/psparse-543)
[    0.948688] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[    0.948964] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT2._GTF] (Node ffff8ae0ce0cf5c8), AE_NOT_FOUND (20160930/psparse-543)


Hardware is MSI Motherboard: Z77A-G41 (MS-7758)
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz

Comment 29 Daniele Ottolina 2017-05-01 14:46:06 UTC
Fedora 4.10.12-200.fc25.x86_64
I also had no issue with legacy kernel 4.8.6-300. No error is displayed in /var/log/boot.log.

Motherboard: Asus Maximus IV Extreme P67(B3)
CPU: Intel(R) Core(TM) i5-2500k CPU

[1.512663] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[1.512715] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT0._GTF] (Node ffff995e5e0d1a28), AE_NOT_FOUND (20160930/psargs-543)

[1.514341] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[1.514389] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT0._GTF] (Node ffff995e5e0d1a28), AE_NOT_FOUND (20160930/psargs-543)

[1.514498] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[1.514546] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT2._GTF] (Node ffff995e5e0d1230), AE_NOT_FOUND (20160930/psargs-543)

[1.518696] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359)
[1.518744] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT2._GTF] (Node ffff995e5e0d1230), AE_NOT_FOUND (20160930/psargs-543)

Comment 30 Artem S. Tashkinov 2017-05-25 10:46:06 UTC
This bug has been forever - the problem is that starting with kernel 4.9 the "quiet" option no longer hides these messages.

This is its latest reincarnation: https://bugzilla.kernel.org/show_bug.cgi?id=193531

Comment 31 Paul 2017-09-08 09:47:36 UTC
4.12.9-300.fc26.x86_64:

[    0.026841] ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20170303/dswload-210)
[    0.026846] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20170303/psobject-241)
[    0.026873] ACPI Exception: AE_NOT_FOUND, (SSDT:DELL_SFF) while loading table (20170303/tbxfload-228)
[    0.027661] ACPI Error: 1 table load failures, 9 successful (20170303/tbxfload-246)
[    1.033370] Couldn't get size: 0x800000000000000e

Comment 32 Pacho Ramos 2017-09-08 09:56:21 UTC
It's still valid for upstream kernel 4.13 (under Gentoo)... I guess it will be unresolved until https://github.com/acpica/acpica/pull/189/ is not merged

Comment 33 Guillem Liarte 2017-10-09 08:24:45 UTC
I can confirm for 4.13.4.200, I get the same error, which makes the computer to get stuck at boot, with kernel 4.13.4.200.fc26.

It will only boot with an older kernel, and by hitting CTRL+C when these messages show.

Comment 34 Fedora End Of Life 2017-11-16 19:40:27 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 35 Phil 2017-12-09 15:16:07 UTC
I’m seeing this in Fedora 27, and boot is now failing here. This is also true when booting from the rescue install.

I’m running an i5 8400 on a asrock z370 fatal1ty itx/ac board.

Ctrl+c doesn’t help me but the system is responsive to ctrl+alt+del, which restarts.

Comment 36 Fedora End Of Life 2017-12-12 10:03:16 UTC
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 37 Christopher Tubbs 2017-12-12 10:08:37 UTC
I'm still getting the following ACPI errors in F26. The comment above indicated this was still a problem in F27.

[    0.708980] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECWT] Namespace lookup failure, AE_NOT_FOUND (20170531/psargs-364)
[    0.709047] ACPI Error: Method parse/execution failed \_TZ.FN00._ON, AE_NOT_FOUND (20170531/psparse-550)
[    0.709088] acpi PNP0C0B:00: Failed to change power state to D0
[    0.709114] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECWT] Namespace lookup failure, AE_NOT_FOUND (20170531/psargs-364)
[    0.709149] ACPI Error: Method parse/execution failed \_TZ.FN00._ON, AE_NOT_FOUND (20170531/psparse-550)
[    0.709183] acpi PNP0C0B:00: Failed to set initial power state
[    0.709217] acpi PNP0C0B:00: Cannot transition from (unknown) to D3hot
[    0.719275] (NULL device *): hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
[    0.721445] thermal LNXTHERM:00: registered as thermal_zone0
[    0.721447] ACPI: Thermal Zone [THM] (25 C)
[    0.721531] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20170531/psargs-364)
[    0.721570] ACPI Error: Method parse/execution failed \_TZ.TZ00._TMP, AE_NOT_FOUND (20170531/psparse-550)
[    0.721678] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20170531/psargs-364)
[    0.721713] ACPI Error: Method parse/execution failed \_TZ.TZ00._TMP, AE_NOT_FOUND (20170531/psparse-550)
[    0.721783] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20170531/psargs-364)
[    0.721818] ACPI Error: Method parse/execution failed \_TZ.TZ01._TMP, AE_NOT_FOUND (20170531/psparse-550)
[    0.721882] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20170531/psargs-364)
[    0.721916] ACPI Error: Method parse/execution failed \_TZ.TZ01._TMP, AE_NOT_FOUND (20170531/psparse-550)

Comment 38 B H 2018-01-24 15:53:32 UTC
Issue persists in F27, system boots but I fear this might be affecting my unstable suspend to ram function.

$ uname -a
Linux Vostok 4.14.8-300.fc27.x86_64 #1 SMP Wed Dec 20 19:00:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux


 08:44:04  bhart@Vostok  ~  43s 
$ dmesg | grep lookup
[    0.028874] ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20170728/dswload-210)
[    0.028940] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20170728/psobject-252)
[    0.807188] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.813436] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.819260] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.825265] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.832267] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.838265] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.845265] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.851266] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.858270] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.864263] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.867200] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.867684] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.868144] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.868574] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)

Comment 39 Laura Abbott 2018-02-20 20:07:13 UTC
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  As kernel maintainers, we try to keep up with bugzilla but due the rate at which the upstream kernel project moves, bugs may be fixed without any indication to us. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.
 
Fedora 27 has now been rebased to 4.15.3-300.f27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you experience different issues, please open a new bug report for those.

Comment 40 jimstaffer 2018-02-20 21:59:29 UTC
I'm still seeing this in:
4.15.3-300.fc27.x86_64 #1 SMP Tue Feb 13 17:02:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Comment 41 Patrick O'Callaghan 2018-02-20 23:13:06 UTC
Still present in kernel 4.15.3-300.fc27.x86_64.

Comment 42 Enrico Tagliavini 2018-02-22 08:57:36 UTC
Created attachment 1399253 [details]
Dell XPS 15 9550 BIOS 1.6.1 dmesg output

Still present for me as well on Dell XPS 15 9550 with very latest BIOS (from few days ago) installed, version is 1.6.1.

my cmdline is

# cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.15.3-300.fc27.x86_64 root=/dev/mapper/vg_fedora-root ro rd.lvm.lv=vg_fedora/root rd.luks.uuid=luks-b9199a84-21cc-4a2c-abcd-1ef11d35b07d rd.lvm.lv=vg_fedora/swap rhgb quiet pcie_aspm=force rd.driver.blacklist=nouveau modprobe.blacklist=nouveau LANG=en_US.UTF-8 nvidia-drm.modeset=1

Note I don't use acpi_osi and I added pcie_aspm=force hoping this was helping with powersave as since this started happening I noticed a power usage increase. It didn't helped much I'm afraid.

Also note nvidia proprietary driver is not actually loaded, card is turned off by default (via bbswitch)

Attached is complete dmesg. At the very end there are additional errors which are triggered when I de-attach and re-attach the PSU of the laptop.

Comment 43 Al Stone 2018-03-07 23:02:17 UTC
(In reply to Enrico Tagliavini from comment #42)
> Created attachment 1399253 [details]
> Dell XPS 15 9550 BIOS 1.6.1 dmesg output
> 
> Still present for me as well on Dell XPS 15 9550 with very latest BIOS (from
> few days ago) installed, version is 1.6.1.
> 
> my cmdline is
> 
> # cat /proc/cmdline 
> BOOT_IMAGE=/vmlinuz-4.15.3-300.fc27.x86_64 root=/dev/mapper/vg_fedora-root
> ro rd.lvm.lv=vg_fedora/root
> rd.luks.uuid=luks-b9199a84-21cc-4a2c-abcd-1ef11d35b07d
> rd.lvm.lv=vg_fedora/swap rhgb quiet pcie_aspm=force
> rd.driver.blacklist=nouveau modprobe.blacklist=nouveau LANG=en_US.UTF-8
> nvidia-drm.modeset=1
> 
> Note I don't use acpi_osi and I added pcie_aspm=force hoping this was
> helping with powersave as since this started happening I noticed a power
> usage increase. It didn't helped much I'm afraid.
> 
> Also note nvidia proprietary driver is not actually loaded, card is turned
> off by default (via bbswitch)
> 
> Attached is complete dmesg. At the very end there are additional errors
> which are triggered when I de-attach and re-attach the PSU of the laptop.

I recommend this bug be closed.

The issue here is faulty firmware.  To begin with, whenever this message occurs in dmesg:

[    0.038356] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored

The firmware writers have done something they should not do -- they have special code in their ACPI tables specific to Linux vs Windows.  The reason they should not do this is that Linux will always reply to the _OSI(Linux) call with false.  There's a good reason for this: if Linux does not, it will end up using paths through the ACPI tables that have almost never been tested.

So, for example, in this particular case, when we look in the DSDT at the _CRS (current resource settings) method that tells the OS what resources the PCI0 device uses, we see this loveliness:

                Method (_CRS, 0, NotSerialized)
                {
                    If (OSYS < 0x07DC)
                    {
                        Return (ResourceTemplate ()
                        {
                        })
                    }

                    Name (RBUF, ResourceTemplate ()
                    {
                        GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 0x2710,
                            "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0000
                            }
                        GpioIo (Shared, PullDefault, 0x0000, 0x0000, IoRestrictionInputOnly,
                            "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0000
                            }
                    })

What this says is that there are GPIO interrupts and GPIO pins defined but only if OSYS >= 0x07DC.  If _OSI(Linux) returns true, then OSYS == 0x03e8, but for Windows it is always >= 0x07dc.  For this PCI0 device, then, two different GPIO behaviors are defined for Windows vs Linux.  Whenever I have seen this before, it is usually a workaround for some sort of hardware failure.

The net result is that *if* these ACPI tables have been fully tested on Linux, they have been tested with _OSI(Linux) == true which is a non-standard change to the upstream kernel and needs to be supported by whoever made that change.
Or, the only other possibility, because of the specific errors being reported with the Fedora kernel, it is highly unlikely that these ACPI tables have been tested with a regular upstream kernel.  Either way, there's not much the kernel can do to compensate for errors in the firmware supplied to it.

Just a side note to add a little fuel to the fire:

[    0.000000] ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20170831/dswload-210)

The object named, HS11, is only defined if PCHS (a field in a memory region) is set to 1 (one).  Setting up this memory region properly is the responsibility of the firmware; the kernel is only doing what it was told to do.  In this case, it's expecting to get what looks like an address from HS11 but for some reason, the firmware has not set PCHS to 1 so that HS11 is not being defined.  Again, this is faulty firmware.

You may be able to mitigate some of the messages by supplying acpi_osi=Linux on the kernel command line, but I would *not* recommend it.  Just a quick reading of some of the DSDT indicates that at a minimum PCI functionality would be degraded, and I suspect other problems will occur; this is precisely why the kernel expects _OSI(Linux) to be false -- we know the Windows firmware paths get tested, so we know they will work, but any other paths are generally suspect.

Comment 44 Laura Abbott 2018-03-08 00:46:10 UTC
Thanks for the analysis. I may start duping similar bugs to this one.

Comment 45 Jeffrey Walton 2018-03-08 01:17:50 UTC
(In reply to Al Stone from comment #43)
> (In reply to Enrico Tagliavini from comment #42)
> > Created attachment 1399253 [details]
> > Dell XPS 15 9550 BIOS 1.6.1 dmesg output
> > 
> > Still present for me as well on Dell XPS 15 9550 with very latest BIOS (from
> > few days ago) installed, version is 1.6.1.
> > 
> > my cmdline is
> > 
> > # cat /proc/cmdline 
> > BOOT_IMAGE=/vmlinuz-4.15.3-300.fc27.x86_64 root=/dev/mapper/vg_fedora-root
> > ro rd.lvm.lv=vg_fedora/root
> > rd.luks.uuid=luks-b9199a84-21cc-4a2c-abcd-1ef11d35b07d
> > rd.lvm.lv=vg_fedora/swap rhgb quiet pcie_aspm=force
> > rd.driver.blacklist=nouveau modprobe.blacklist=nouveau LANG=en_US.UTF-8
> > nvidia-drm.modeset=1
> > 
> > Note I don't use acpi_osi and I added pcie_aspm=force hoping this was
> > helping with powersave as since this started happening I noticed a power
> > usage increase. It didn't helped much I'm afraid.
> > 
> > Also note nvidia proprietary driver is not actually loaded, card is turned
> > off by default (via bbswitch)
> > 
> > Attached is complete dmesg. At the very end there are additional errors
> > which are triggered when I de-attach and re-attach the PSU of the laptop.
> 
> I recommend this bug be closed.
> 
> The issue here is faulty firmware.  To begin with, whenever this message
> occurs in dmesg:
> 
> [    0.038356] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
> 
> The firmware writers have done something they should not do -- they have
> special code in their ACPI tables specific to Linux vs Windows.  The reason
> they should not do this is that Linux will always reply to the _OSI(Linux)
> call with false.  There's a good reason for this: if Linux does not, it will
> end up using paths through the ACPI tables that have almost never been
> tested.
> ...

Good info here.

Would it be possible to output a diagnostic to dmesg with (1) BIOS/UEFI manufacture name; and (2) a message stating to update the BIOS/UEFI.

A canonical reference to a doc that goes over what Al said would probably squash most future bug reports so Laura will not have to tend to them.

Without the dmesg the bug reports will probably continue to flow.

Comment 46 Hal Murphy 2018-03-08 11:47:21 UTC
> (2) a message stating to update the BIOS/UEFI.

This happens with fully updated BIOS so above will be confusing. Maybe tell users to contact manufacturer instead as it's the right place to complain.

Comment 47 Christopher Tubbs 2018-03-08 15:27:13 UTC
(In reply to Hal Murphy from comment #46)
> This happens with fully updated BIOS so above will be confusing. Maybe tell
> users to contact manufacturer instead as it's the right place to complain.

I'm not sure what good that will do. Has anybody had success contacting a manufacturer to report a problem which is only observed in Linux? Every time I've tried, the response typically indicates "not our problem", and for good reason: it's typically the job of the OS to support the hardware, not the hardware to support the OS. There are no incentives for a hardware manufacturer to fix a problem which appears only in Linux.

Comment 48 Al Stone 2018-03-08 15:53:33 UTC
(In reply to Jeffrey Walton from comment #45)
> (In reply to Al Stone from comment #43)
> > (In reply to Enrico Tagliavini from comment #42)
> > > Created attachment 1399253 [details]
> > > Dell XPS 15 9550 BIOS 1.6.1 dmesg output
> > > 
> > > Still present for me as well on Dell XPS 15 9550 with very latest BIOS (from
[snip...] 
> > The issue here is faulty firmware.  To begin with, whenever this message
> > occurs in dmesg:
> > 
> > [    0.038356] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
> > 
> > The firmware writers have done something they should not do -- they have
> > special code in their ACPI tables specific to Linux vs Windows.  The reason
> > they should not do this is that Linux will always reply to the _OSI(Linux)
> > call with false.  There's a good reason for this: if Linux does not, it will
> > end up using paths through the ACPI tables that have almost never been
> > tested.
> > ...
> 
> Good info here.
> 
> Would it be possible to output a diagnostic to dmesg with (1) BIOS/UEFI
> manufacture name; and (2) a message stating to update the BIOS/UEFI.
 
Possible, but unlikely.  This is an issue that upstream Linux dealt with years ago with the "Firmware Bug" dmesg -- the problem is that the kernel cannot tell how bad the bug is; it could be completely innocuous or it could disable whole swaths of functionality.  All we know for sure, until someone sits down and looks at the ACPI tables in detail, is that the tables are suspect.  A firmware update may or may not be warranted.  If you have some specific ideas on what you'd like to see, though, do send a patch upstream and try to improve what's there.

> A canonical reference to a doc that goes over what Al said would probably
> squash most future bug reports so Laura will not have to tend to them.
 
I highly recommend reading the source code in drivers/acpi/osi.c, starting somewhere about line 151.  The comment there describes the issue and the solution chosen by Linux.  I reckon that's just about as canonical as you can get.

> Without the dmesg the bug reports will probably continue to flow.

My experience with this is that the bugs do continue to flow; but, these are fairly unusual now.  A decade or more ago they were much more frequent as vendors tried to figure out this Linux thing.  Not so much, these days.  For example, I did some searching through Fedora bugs and only found two such reports, both of the them pointing to the same firmware writers -- not bad for an entire distro :).

Comment 49 Patrick O'Callaghan 2018-03-08 15:55:42 UTC
I'd be satisfied with just lowering the category of error so it doesn't scream at me every time I boot. Since there isn't anything I can do about it, it seems rather redundant. Formerly these errors still existed but didn't make themselves so prominent, so I'd be happy to go back to that state of affairs if it's practical.

Comment 50 Al Stone 2018-03-08 15:58:46 UTC
(In reply to Christopher Tubbs from comment #47)
> (In reply to Hal Murphy from comment #46)
> > This happens with fully updated BIOS so above will be confusing. Maybe tell
> > users to contact manufacturer instead as it's the right place to complain.
> 
> I'm not sure what good that will do. Has anybody had success contacting a
> manufacturer to report a problem which is only observed in Linux? Every time
> I've tried, the response typically indicates "not our problem", and for good
> reason: it's typically the job of the OS to support the hardware, not the
> hardware to support the OS. There are no incentives for a hardware
> manufacturer to fix a problem which appears only in Linux.

It all depends on the vendor.  I have had success in getting changes.  It can, however, take a lot of patience and perseverance.

In this case in particular, Dell sells the XPS line specifically as a Linux laptop on their web site.  I suspect they'll be much more motivated than most.

Comment 51 Pacho Ramos 2018-03-08 16:08:35 UTC
This was reported to Dell some time ago... but for now there is no much activity
https://www.dell.com/community/Linux-General/DELL-Inspiron-5567-MCE-Errors-On-Boot-Linux-Kernel/m-p/5163980

Comment 52 Laura Abbott 2018-03-08 16:59:55 UTC
*** Bug 1553320 has been marked as a duplicate of this bug. ***

Comment 53 Sergio Basto 2018-03-08 18:39:41 UTC
@Al Stone 
You got here [1] the DSDT of my Toshiba laptop, the main problem is not the warnings but that it fails to active screen on resume, I can workaround it by closing and open lid ...

So I'm looking for a way to fix resume from suspend, try to load a custom DSDT is possible ? and with an fixed DSDT can we fix the resume ? or probably not ? where should I look ? kernel , intel-drv , drm , etc etc ?  

Thanks,

[1]
https://bugs.freedesktop.org/show_bug.cgi?id=103414

Comment 54 Al Stone 2018-03-08 19:37:35 UTC
(In reply to Sergio Monteiro Basto from comment #53)
> @Al Stone 
> You got here [1] the DSDT of my Toshiba laptop, the main problem is not the
> warnings but that it fails to active screen on resume, I can workaround it
> by closing and open lid ...
> 
> So I'm looking for a way to fix resume from suspend, try to load a custom
> DSDT is possible ? and with an fixed DSDT can we fix the resume ? or
> probably not ? where should I look ? kernel , intel-drv , drm , etc etc ?  
> 
> Thanks,
> 
> [1]
> https://bugs.freedesktop.org/show_bug.cgi?id=103414

It is possible to use a custom DSDT by adding it to the initrd; iirc, this is documented in the kernel source tree under Documentation/ somewhere.

Try the very latest upstream kernel first.  There were some changes for detecting lid open/close that were added really recently in drivers/acpi in the kernel, specifically affecting Toshiba laptops when trying to resume.  I don't know whether that will solve the problem or not, but it does sound similar.  If it doesn't solve the problem, that's where I would start looking -- in the kernel suspend/resume code, and making sure the graphics driver is notified on resume.

Comment 55 Enrico Tagliavini 2018-03-09 15:58:53 UTC
If anybody is interested I reported the issue for Dell XPS 15 9550 on the Dell forum [1]

[1] https://www.dell.com/community/Linux-General/Lot-of-ACPI-errors-on-XPS-15-9550-with-latest-firmwares/td-p/6030414


Note You need to log in before you can comment on or make changes to this bug.