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
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)
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.
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
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).
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.
(In reply to Alexander from comment #5) > Confirming this. Systems boots as usually except this message in journal and at boot screen.
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)
*** Bug 1415853 has been marked as a duplicate of this bug. ***
This issue still present on 4.9.5-200.fc25.x86_64
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.
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.
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?
Upstream bug is https://bugzilla.kernel.org/show_bug.cgi?id=193531
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?
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.
*********** 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.
(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
(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
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)
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
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)
(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.
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)
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.
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
Hello
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:
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
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)
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
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
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
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.
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.
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.
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.
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)
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)
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.
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
Still present in kernel 4.15.3-300.fc27.x86_64.
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.
(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.
Thanks for the analysis. I may start duping similar bugs to this one.
(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.
> (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.
(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.
(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 :).
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.
(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.
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
*** Bug 1553320 has been marked as a duplicate of this bug. ***
@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
(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.
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