Bug 198167
|
Description
Jorge Martínez López
2017-12-14 20:31:34 UTC
Jorge, can you can run acpidump on your board and attach an acpidump here please? Created attachment 261191 [details]
acpidump
acpidump as requested.
what's the latest kernel without the error messages? please attach the full dmesg output. The last Fedora kernel with no error is 4.13.16-302. Created attachment 261245 [details]
dmesg
And now with the dmesg attached.
Hi Jorge, Aside from ACPI errors, are you seeing any other sideffects caused from these errors? Hello Erik, Not as far as I'm aware, I thought the computer was not able to get to sleep but this seems not to be happening so might be unrelated. I'll keep an eye on it. I think the errors might be preventing the Fedora's offline upgrades from working, I'll monitor that as well. I forgot to ask - which kernel version did you use before 4.14? Never mind, I found the information. It was 4.13. This firmware was broken to begin with and changes between 4.13 and 4.14 emitted a firmware error that was somehow suppressed before 4.13... The dmesg contains errors regarding LNK[A-D]. These are actual errors because your ACPI tables does not contain definitions for those objects. It's likely that these errors have been hiding this entire time and some ACPICA change made this error appear in your dmesg. I will try to find the change that made these errors appear to confirm my hypothesis. So I'm not sure if this is related but it seems my computer wakes up all of the sudden. When I left home this morning I suspended the computer but two hours later it came back online again. I'll upload the logs and a new dmesg in case it helps. Created attachment 261277 [details]
Journal logs around the sleep and wake times
Journal logs.
Created attachment 261279 [details]
dmesg output
See this also on my GA-970A-UD3 w/ AMD Athlon(tm) II X3 455 Processor Me too: AMD FX(tm)-6300 Six-Core Processor (GA-780T-D3L) dmesg -l err|grep 'Could not find/resolve named package element: LNK. (20170728/dspkginit-381)' -c 44 the error is repeated 44 kernel 4.14.8 cpu: AMD FX(tm)-8320 motherboard: GA-990XA-UD3 Same Here:
Motherboard:
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: GA-MA770-UD3
BIOS:
Vendor: Award Software International, Inc.
Version: F9g
Release Date: 07/08/2010
Kernel
Linux Quadraped-wired 4.14.8-200.fc26.x86_64 #1 SMP
Wed Dec 20 19:05:23 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Error count: (same as Vikb observed):
Quadraped: dmesg -l err|grep 'Could not find/resolve
named package element: LNK. (20170728/dspkginit-381)' -c
44
/proc/cpuinfo includes:
vendor_id : AuthenticAMD
cpu family : 16
model : 4
model name : AMD Phenom(tm) II X4 940 Processor
stepping : 2
microcode : 0x10000db
dmesg | less reveals:
[ 0.029076] ACPI: Added _OSI(Processor Device)
[ 0.029077] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.029077] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.030888] ACPI Exception: Could not find/resolve named package element: LNKC (20170728/dspkginit-381)
[ 0.030934] ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381)
[ 0.030976] ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381)
[ 0.031005] ACPI Exception: Could not find/resolve named package element: LNKB (20170728/dspkginit-381)
[ 0.031077] ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381)
....
[ 0.034084] ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381)
[ 0.037118] ACPI: Interpreter enabled
[ 0.037140] ACPI: (supports S0 S3 S4 S5)
[ 0.037142] ACPI: Using IOAPIC for interrupt routing
[ 0.037212] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.037334] ACPI: Enabled 5 GPEs in block 00 to 1F
[ 0.041254] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.041259] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 0.041263] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
[ 0.041461] PCI host bridge to bus 0000:00
[ 0.041463] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
[ 0.041464] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
[ 0.041465] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[ 0.041467] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff window]
[ 0.041468] pci_bus 0000:00: root bus resource [mem 0xcff00000-0xfebfffff window]
[ 0.041469] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.041477] pci 0000:00:00.0: [1002:5957] type 00 class 0x060000
[ 0.041491] pci 0000:00:00.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
[ 0.041569] pci 0000:00:02.0: [1002:5978] type 01 class 0x060400
[ 0.041585] pci 0000:00:02.0: enabling Extended Tags
[ 0.041605] pci 0000:00:02.0: PME# supported from D0 D3hot D3cold
[ 0.041678] pci 0000:00:05.0: [1002:597b] type 01 class 0x060400
[ 0.041692] pci 0000:00:05.0: enabling Extended Tags
[ 0.041710] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[ 0.041776] pci 0000:00:06.0: [1002:597c] type 01 class 0x060400
Thanks! JW
Hi All, Thanks for reporting this issue. Please post your acpidump like Jorge did. It might be caused by a different issue than the one Jorge was having. It doesn't look like Fedora has acpidump so I built it from source but it doesn't seem to work: $ sudo acpidump ACPI tables were not found. If you know location of RSD PTR table (from dmesg, etc), supply it with either --addr or -a option I built the 20071116 source which was the latest listed from: https://01.org/linux-acpi/utilities My fault, it's now provided by the acpica-tools package but it's a symlink to acpidump-acpica... Created attachment 273375 [details]
acpidump from my GA-970A-UD3
Created attachment 273377 [details]
ACPI Dump from GA-MA770-UD3 on 4.14.8-300.
Output from acpidump on kernel 4.14.8-300.fc27.x86_64
Created attachment 273433 [details]
Acpidump Gigabyte GA-MA790X-UD4 AMD Phenom II X4 940 4.14.11-1-ARCH
Same here as well. Gigabyte GA-MA790X-UD4 and a AMD Phenom II X4 940 Processor ACPI dump from 4.14.11-1-ARCH enclosed above Created attachment 273447 [details]
ACPIDUMP ga78lmt-usb3
Same problem here on Arch Linux.
Gigabyte GA78lmt-usb3
AMD FX 4350
Kernel 4.14.11
[ 0.174462] ACPI Exception: Could not find/resolve named package element: LNKC (20170728/dspkginit-381)
[ 0.174473] ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381)
[ 0.174482] ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381)
[ 0.174490] ACPI Exception: Could not find/resolve named package element: LNKB (20170728/dspkginit-381)
[ 0.174527] ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381)
[ 0.174535] ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381)
[ 0.174543] ACPI Exception: Could not find/resolve named package element: LNKB (20170728/dspkginit-381)
[ 0.174550] ACPI Exception: Could not find/resolve named package element: LNKC (20170728/dspkginit-381)
[ 0.174586] ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381)
[ 0.174594] ACPI Exception: Could not find/resolve named package element: LNKB (20170728/dspkginit-381)
[ 0.174602] ACPI Exception: Could not find/resolve named package element: LNKC (20170728/dspkginit-381)
[ 0.174610] ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381)
[ 0.174645] ACPI Exception: Could not find/resolve named package element: LNKB (20170728/dspkginit-381)
[ 0.174653] ACPI Exception: Could not find/resolve named package element: LNKC (20170728/dspkginit-381)
[ 0.174662] ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381)
[ 0.174671] ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381)
[ 0.174706] ACPI Exception: Could not find/resolve named package element: LNKC (20170728/dspkginit-381)
[ 0.174715] ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381)
[ 0.174724] ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381)
[ 0.174732] ACPI Exception: Could not find/resolve named package element: LNKB (20170728/dspkginit-381)
[ 0.174768] ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381)
[ 0.174776] ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381)
[ 0.174784] ACPI Exception: Could not find/resolve named package element: LNKB (20170728/dspkginit-381)
[ 0.174792] ACPI Exception: Could not find/resolve named package element: LNKC (20170728/dspkginit-381)
[ 0.174827] ACPI Exception: Could not find/resolve named package element: LNKB (20170728/dspkginit-381)
[ 0.174836] ACPI Exception: Could not find/resolve named package element: LNKC (20170728/dspkginit-381)
[ 0.174844] ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381)
[ 0.174852] ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381)
[ 0.174887] ACPI Exception: Could not find/resolve named package element: LNKC (20170728/dspkginit-381)
[ 0.174895] ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381)
[ 0.174903] ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381)
[ 0.174911] ACPI Exception: Could not find/resolve named package element: LNKB (20170728/dspkginit-381)
[ 0.174947] ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381)
[ 0.174955] ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381)
[ 0.174964] ACPI Exception: Could not find/resolve named package element: LNKB (20170728/dspkginit-381)
[ 0.174972] ACPI Exception: Could not find/resolve named package element: LNKC (20170728/dspkginit-381)
[ 0.175007] ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381)
[ 0.175015] ACPI Exception: Could not find/resolve named package element: LNKB (20170728/dspkginit-381)
[ 0.175024] ACPI Exception: Could not find/resolve named package element: LNKC (20170728/dspkginit-381)
[ 0.175032] ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381)
Created attachment 273483 [details] Gigabyte_GA-770TA-UD3 Hello, I've got the same message since I updated to kernel 4.14.10 (on mageia 6 x86_64). Gigabyte GA-770TA-UD3 ( https://www.gigabyte.com/Motherboard/GA-770TA-UD3-rev-10#sp ) AMD Phenom II X4 955 linux 4.14.10 My acpidump is attached. Thanks Julien Siema, Same issue here. My dmidecode and acpidump Created attachment 273497 [details]
Gigabyte - GA-MA770T-UD3P - dmidecode -q
Created attachment 273499 [details]
Gigabyte - GA-MA770T-UD3P - acpidump
Hi all,
It seems like all of these ACPI tables exhibit the same problem.
Here's the issue:
LNKA, LNKB, LNKC, and LNKD are not defined in your ACPI tables. They are declared using externals at the top of the DSDT like so:
DefinitionBlock ("", "DSDT", 1, "GBT ", "GBTUACPI", 0x00001000)
{
External (LNKA, UnknownObj)
External (LNKB, UnknownObj)
External (LNKC, UnknownObj)
External (LNKD, UnknownObj)
This external means that LNKA, LNKB, LNKC, and LNKD are declared in a separate ACPI table. However, the actual definition of this object does not exist in any of the ACPI tables..
I am not a kernel specialist. I assume they are missing in the hardware firmware? Does it mean you need to define it (probably only for these boards) in the kernel? It's missing in the firmware. The best thing to do is to contact firmware vendors and proceed from there. (In reply to Erik Schmauss from comment #32) > It's missing in the firmware. The best thing to do is to contact firmware > vendors and proceed from there. This wont work for Dell. Same (or similar) errors on Precision 5510 (and a few more as they use a loot of methods and fields which are undefined anywhere) More background info: - http://en.community.dell.com/techcenter/os-applications/f/4613/t/20010662 - http://en.community.dell.com/techcenter/os-applications/f/4457/t/20006889 ======== ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381) ACPI Exception: Could not find/resolve named package element: LNKB (20170728/dspkginit-381) ACPI Exception: Could not find/resolve named package element: LNKC (20170728/dspkginit-381) ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381) ======== I already fight few months with several levels of Dell employees and final result was only final comment: ======== At this time BIOS team has confirmed that these errors do not impact device or OS functionality, that the presence of these errors in logs is due to the change in logging policy set in the linux kernel, that the acpi functions causing errors to be seen are part of the dell proprietary power management interface, and that kernel support of these calls is not needed. To-date this appears to be working as designed and the logs are an expected function of kernel logging behavior and firmware design. Any further investigation would have to be based exclusively on the evidence of reproducible OS or hardware symptoms and or failures. ====== After that they stop respondingo to e-mails at all ;( (In reply to Marcin Kurek from comment #33) > (In reply to Erik Schmauss from comment #32) > > It's missing in the firmware. The best thing to do is to contact firmware > > vendors and proceed from there. > > This wont work for Dell. Same (or similar) errors on Precision 5510 (and a > few more as they use a loot of methods and fields which are undefined > anywhere) More background info: > > - http://en.community.dell.com/techcenter/os-applications/f/4613/t/20010662 The errors mentioned here is actually a different set of errors and have been around for a long time. I've just re-opened bug 109511 for these and attached a patch to lower the loglevel of errors while loading the extra ACPI tables from error to warning, which should fix the original set of errors showing on the console during boot. > ======== > ACPI Exception: Could not find/resolve named package element: LNKA > (20170728/dspkginit-381) > ACPI Exception: Could not find/resolve named package element: LNKB > (20170728/dspkginit-381) > ACPI Exception: Could not find/resolve named package element: LNKC > (20170728/dspkginit-381) > ACPI Exception: Could not find/resolve named package element: LNKD > (20170728/dspkginit-381) > ======== This new set however is not affected by the patch I've attach to bug 109511. But I do believe that we should fix it in the same manner, of the extra check introduced in 4.14 which prints these messages triggers on a lot of machines and there is nothing on the kernel side we can do to fix this, then these messages really should be logged with a log-level of warning, not error. Created attachment 273551 [details] attachment-14592-0.html Rather than squelching the logging at boot time, should we just note it. How should the boot process identity something that's not implemented? Saying it's broken seems too judgemental. On Jan 11, 2018 2:37 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=198167 > > --- Comment #34 from Hans de Goede (jwrdegoede@fedoraproject.org) --- > (In reply to Marcin Kurek from comment #33) > > (In reply to Erik Schmauss from comment #32) > > > It's missing in the firmware. The best thing to do is to contact > firmware > > > vendors and proceed from there. > > > > This wont work for Dell. Same (or similar) errors on Precision 5510 (and > a > > few more as they use a loot of methods and fields which are undefined > > anywhere) More background info: > > > > - http://en.community.dell.com/techcenter/os-applications/f/ > 4613/t/20010662 > > The errors mentioned here is actually a different set of errors and have > been > around for a long time. > > I've just re-opened bug 109511 for these and attached a patch to lower the > loglevel of errors while loading the extra ACPI tables from error to > warning, > which should fix the original set of errors showing on the console during > boot. > > > ======== > > ACPI Exception: Could not find/resolve named package element: LNKA > > (20170728/dspkginit-381) > > ACPI Exception: Could not find/resolve named package element: LNKB > > (20170728/dspkginit-381) > > ACPI Exception: Could not find/resolve named package element: LNKC > > (20170728/dspkginit-381) > > ACPI Exception: Could not find/resolve named package element: LNKD > > (20170728/dspkginit-381) > > ======== > > This new set however is not affected by the patch I've attach to bug > 109511. > But I do believe that we should fix it in the same manner, of the extra > check > introduced in 4.14 which prints these messages triggers on a lot of > machines > and there is nothing on the kernel side we can do to fix this, then these > messages really should be logged with a log-level of warning, not error. > > -- > You are receiving this mail because: > You are on the CC list for the bug. (In reply to westerj from comment #35) > Rather than squelching the logging at boot time, should we just note it. > How should the boot process identity something that's not implemented? > Saying it's broken seems too judgemental. I'm not sure what you're actually trying to say here. How do you want the kernel behavior to change ? Created attachment 273557 [details] [PATCH 1/2] ACPICA: acpi_ds_resolve_package_element: Use proper status when logging exception Here is a set of 2 patches fixing this as well as bug 109511. Created attachment 273559 [details]
[PATCH 2/2] ACPICA: Log failing to find symbols in the tables as warnings
Created attachment 273565 [details] attachment-15327-0.html Sounds like the message is interpreted as an error , something is broken. Can it be reported as found and not used. When I parse boot logs I focus on things that appear broken, and skip over things that are merely found . On Jan 12, 2018 6:41 AM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=198167 > > --- Comment #38 from Hans de Goede (jwrdegoede@fedoraproject.org) --- > Created attachment 273559 [details] > --> https://bugzilla.kernel.org/attachment.cgi?id=273559&action=edit > [PATCH 2/2] ACPICA: Log failing to find symbols in the tables as warnings > > -- > You are receiving this mail because: > You are on the CC list for the bug. I think it's an error if the AML interpreter encounters an undefined name. I would expect the same from other programming language interpreters. I believe it's better to face the reality rather than lowering the severity of these messages. This means that we will get more bug reports of the same issue but this also gives us more data points in convincing firmware developers to improve their ASL code. (In reply to Erik Schmauss from comment #40) > I think it's an error if the AML interpreter encounters an undefined name. From an AML interpreter POV, sure I agree, but as mentioned in the commit message there is nothing the user, or the ACPICA code can do about these errors, so throwing them in the face of the user *every* *beeping* boot as a log-level of error does is anything but helpful. > I would expect the same from other programming language interpreters. Interpreters not so much actually, e.g. python will happily run files with unresolved / unavailable names as long as you don't actually enter any code paths referencing the unresolved names, anyways AML is special in various ways so I don't think comparing it to other languages is useful. > I believe it's better to face the reality rather than lowering the severity > of > these messages. This means that we will get more bug reports of the same > issue but this also gives us more data points in convincing firmware > developers to improve their ASL code. I'm sorry but I really don't buy into this whole we need to annoy our users so that they bug their hardware vendor to get their firmware fixed thing. We've been playing at that games for years and it *simply* *does* *not* *work*. Also this is not going to fix all the firmware with unresolved names already out there. We really need to get rid of throwing these errors in users face every boot. Users find them very annoying, as can be witnessed from the amount of people quickly adding themselves to the Cc of this bug. Note I'm not advocating to completely silence these errors, I'm merely lowering the level at which we log them to warning to get them out of users face. Maybe we need to make this log level lowering Linux specific somehow? E.g. add a n ACPI_MSG_AE_NOT_FOUND #define which linux can set to ACPI_MSG_WARNING and which can be automatically set to ACPI_MSG_ERROR when not defined by the OS code ? Either way we really need to fix this, if this will not be fixed in the ACPICA upstream code you are very likely just causing downstream distros such as Fedora to start applying a downstream patch for this as the current behavior simply is unacceptable. Created attachment 273837 [details] attachment-12292-0.html As an OS Admin (at this point, one of my hats) I have to defend every boot message that makes it appear that something is broken during OS qualification. Found XXXXXX - not configured/not used Is easier to explain than XXXXXX broken due to flying monkey saturation. For all the facilities available at boot time - how should something unused/unneeded be differentiated from something that is deleterious? If we want to inspire hardware vendors to port all bells and whistle services to Linux, we can observe and report, and let the magic happen. My $.02 - JW *# Make the best of your time and facilities #* On Tue, Jan 23, 2018 at 2:23 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=198167 > > --- Comment #41 from Hans de Goede (jwrdegoede@fedoraproject.org) --- > (In reply to Erik Schmauss from comment #40) > > I think it's an error if the AML interpreter encounters an undefined > name. > > From an AML interpreter POV, sure I agree, but as mentioned in the commit > message there is nothing the user, or the ACPICA code can do about these > errors, so throwing them in the face of the user *every* *beeping* boot as > a > log-level of error does is anything but helpful. > > > I would expect the same from other programming language interpreters. > > Interpreters not so much actually, e.g. python will happily run files with > unresolved / unavailable names as long as you don't actually enter any code > paths referencing the unresolved names, anyways AML is special in various > ways > so I don't think comparing it to other languages is useful. > > > I believe it's better to face the reality rather than lowering the > severity > > of > > these messages. This means that we will get more bug reports of the same > > issue but this also gives us more data points in convincing firmware > > developers to improve their ASL code. > > I'm sorry but I really don't buy into this whole we need to annoy our > users so > that they bug their hardware vendor to get their firmware fixed thing. > We've > been playing at that games for years and it *simply* *does* *not* *work*. > Also > this is not going to fix all the firmware with unresolved names already out > there. > > We really need to get rid of throwing these errors in users face every > boot. > Users find them very annoying, as can be witnessed from the amount of > people > quickly adding themselves to the Cc of this bug. Note I'm not advocating to > completely silence these errors, I'm merely lowering the level at which we > log > them to warning to get them out of users face. > > Maybe we need to make this log level lowering Linux specific somehow? E.g. > add > a > n ACPI_MSG_AE_NOT_FOUND #define which linux can set to ACPI_MSG_WARNING and > which can be automatically set to ACPI_MSG_ERROR when not defined by the OS > code ? > > Either way we really need to fix this, if this will not be fixed in the > ACPICA > upstream code you are very likely just causing downstream distros such as > Fedora to start applying a downstream patch for this as the current > behavior > simply is unacceptable. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > I'm facing those errors, too w/ 4.14: ACPI Exception: Could not find/resolve named package element: LNKC (20170728/dspkginit-381) ACPI Exception: Could not find/resolve named package element: LNKD (20170728/dspkginit-381) ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381) ACPI Exception: Could not find/resolve named package element: LNKB (20170728/dspkginit-381) Board: Gigabyte Technology Co., Ltd. GA-990XA-UD3/GA-990XA-UD3, BIOS F14b 01/24/2013 CPU: AMD FX(tm)-8350 Eight-Core Processor Created attachment 273841 [details]
acpidump for GA-990XA-UD3
Similar harmless issue here due "External (_PR_.CPU0, UnknownObj)" in AML. ACPI Exception: Could not find/resolve named package element: \_PR_.CPU0 (20170728/dspkginit-381) Old board ASUS M2N32-SLI Deluxe (v1603 BIOS) (In reply to Hans de Goede from comment #41) > (In reply to Erik Schmauss from comment #40) > > I think it's an error if the AML interpreter encounters an undefined name. > > From an AML interpreter POV, sure I agree, but as mentioned in the commit > message there is nothing the user, or the ACPICA code can do about these > errors, so throwing them in the face of the user *every* *beeping* boot as a > log-level of error does is anything but helpful. > > > I would expect the same from other programming language interpreters. > > Interpreters not so much actually, e.g. python will happily run files with > unresolved / unavailable names as long as you don't actually enter any code > paths referencing the unresolved names, anyways AML is special in various > ways so I don't think comparing it to other languages is useful. > > > I believe it's better to face the reality rather than lowering the severity > > of > > these messages. This means that we will get more bug reports of the same > > issue but this also gives us more data points in convincing firmware > > developers to improve their ASL code. > > I'm sorry but I really don't buy into this whole we need to annoy our users > so that they bug their hardware vendor to get their firmware fixed thing. > We've been playing at that games for years and it *simply* *does* *not* > *work*. Also this is not going to fix all the firmware with unresolved names > already out there. Yes, I agree that it does not fix existing firmware. > > We really need to get rid of throwing these errors in users face every boot. > Users find them very annoying, as can be witnessed from the amount of people > quickly adding themselves to the Cc of this bug. Note I'm not advocating to > completely silence these errors, I'm merely lowering the level at which we > log them to warning to get them out of users face. > > Maybe we need to make this log level lowering Linux specific somehow? E.g. > add a > n ACPI_MSG_AE_NOT_FOUND #define which linux can set to ACPI_MSG_WARNING and > which can be automatically set to ACPI_MSG_ERROR when not defined by the OS > code ? I think a Linux specific solution might be a good approach. We would like to keep the error message as it is on ACPICA. > > Either way we really need to fix this, if this will not be fixed in the > ACPICA upstream code you are very likely just causing downstream distros > such as Fedora to start applying a downstream patch for this as the current > behavior simply is unacceptable. Hi, Another solution that we are considering is to provide an option (either command line or a config option) to change the package element resolution time. One option would be to keep the current configuration. The other would be to delay the package resolution as late as possible (until the object is needed). Hi, (In reply to Erik Schmauss from comment #47) > Hi, > > Another solution that we are considering is to provide an option (either > command line or a config option) to change the package element resolution > time. One option would be to keep the current configuration. The other would > be to delay the package resolution as late as possible (until the object is > needed). I've actually been thinking about proposing this as a possible solution myself, downside is that we do not know if it will actually fix this until we try it and it will likely be quit a bit of work to implement this. Have you looked at the existing troublesome DSDTs and tried to envision if this will fix the problem there? Both those here, as well as the XPS dstd in bug 109511 ? I will also attach the dstd of my personal workstation here, which has a similar problem. Regards, Hans Created attachment 273891 [details]
DSDT of asrock-B150M-Pro4S-D3 which has similar problems
Hi, (In reply to Hans de Goede from comment #48) > Hi, > > (In reply to Erik Schmauss from comment #47) > > Hi, > > > > Another solution that we are considering is to provide an option (either > > command line or a config option) to change the package element resolution > > time. One option would be to keep the current configuration. The other > would > > be to delay the package resolution as late as possible (until the object is > > needed). > > I've actually been thinking about proposing this as a possible solution > myself, downside is that we do not know if it will actually fix this until > we try it > and it will likely be quit a bit of work to implement this. These LNKA-LNKD messages first appeared when we initially added the support for forward referenced package objects. Adding this support meant that we were evaluating all package objects regardless of whether if they were being used or not. We are currently working on adding support for forward referenced package objects within module-level code. You can track the effort here: https://bugs.acpica.org/show_bug.cgi?id=963 Once we finish this, we can implement an option to resolve package elements only when they are needed. This feature is in a very similar part of the code base that we are working on now. > > Have you looked at the existing troublesome DSDTs and tried to envision if > this will fix the problem there? Both those here, as well as the XPS dstd in > bug 109511 ? These will fix the LNKA-LNKD issues that I've seen here but will not fix 109511. The difference between this bug and 109511 is that 109511 is an error that is emitted from the AML interpreter when EVAC is referenced by a control method _ON that is being executed. The errors that we see in this bug happens at load time and appears when even when the objects are not in use. > > I will also attach the dstd of my personal workstation here, which has a > similar problem. Could you post the acpidump? > > Regards, > > Hans Hi, Thank you for looking into this. (In reply to Erik Schmauss from comment #50) > These will fix the LNKA-LNKD issues that I've seen here but will not fix > 109511. The difference between this bug and 109511 is that 109511 is an > error that is emitted from the AML interpreter when EVAC is referenced by a > control method _ON that is being executed. The errors that we see in this > bug happens at load time and appears when even when the objects are not in > use. Ah, ok, so we will still need something like my patches then to also silence (log at lower level) the boot time errors being shown to users in cases like bug 109511. When I have some time I will respin my patch to make lowering the log-level of AE_NOT_FOUND optional. Note that my first patch should still be applied, it is a generic fix for the logging involved in the LNKA-D stuff using the wrong status to log. > > I will also attach the dstd of my personal workstation here, which has a > > similar problem. > > Could you post the acpidump? I've already posted it, see comment 49. Regards, Hans Hi, (In reply to Hans de Goede from comment #51) > Hi, > > Thank you for looking into this. > > (In reply to Erik Schmauss from comment #50) > > These will fix the LNKA-LNKD issues that I've seen here but will not fix > > 109511. The difference between this bug and 109511 is that 109511 is an > > error that is emitted from the AML interpreter when EVAC is referenced by a > > control method _ON that is being executed. The errors that we see in this > > bug happens at load time and appears when even when the objects are not in > > use. > > Ah, ok, so we will still need something like my patches then to also silence > (log at lower level) the boot time errors being shown to users in cases like > bug 109511. When I have some time I will respin my patch to make lowering > the log-level of AE_NOT_FOUND optional. > > Note that my first patch should still be applied, it is a generic fix for > the logging involved in the LNKA-D stuff using the wrong status to log. > > > > I will also attach the dstd of my personal workstation here, which has a > > > similar problem. > > > > Could you post the acpidump? > > I've already posted it, see comment 49. Sorry, I should have been more clear. Could you post the entire acpidump? It would be easier to diagnose your issue if I have the entire acpidump (not just the dsdt) as well as a dmesg. > > Regards, > > Hans Hi Jorge, (In reply to Jorge Martínez López from comment #5) > The last Fedora kernel with no error is 4.13.16-302. I'm really curious about how this kernel. Could you possibly post the dmesg from this kernel? It turns out that we have been emitting these errors since at least the year 2014... (In reply to Erik Schmauss from comment #53) > Hi Jorge, > > (In reply to Jorge Martínez López from comment #5) > > The last Fedora kernel with no error is 4.13.16-302. > > I'm really curious about how this kernel. Could you possibly post the dmesg > from this kernel? It turns out that we have been emitting these errors since > at least the year 2014... Hello Erik, Unfortunately that kernel RPM is gone from my system (fedora only keeps 3). Do you want me to reinstall it? If you think it'll help... Greetings, Jorge (In reply to Jorge Martínez López from comment #54) > Unfortunately that kernel RPM is gone from my system (fedora only keeps 3). > Do you want me to reinstall it? If you think it'll help... You can still get from fedora koji: https://koji.fedoraproject.org/koji/buildinfo?buildID=1006497 Created attachment 273935 [details]
dmesg for release 4.13.16
(In reply to Erik Schmauss from comment #53) > Hi Jorge, > > (In reply to Jorge Martínez López from comment #5) > > The last Fedora kernel with no error is 4.13.16-302. > > I'm really curious about how this kernel. Could you possibly post the dmesg > from this kernel? It turns out that we have been emitting these errors since > at least the year 2014... Hi Erik, dmesg uploaded as requested. I can confirm there were no errors in the screen. Created attachment 273955 [details]
asrock-B150M-Pro4S-D3 acpidump
Created attachment 273957 [details] Boot dmesg for asrock-B150M-Pro4S-D3 (In reply to Erik Schmauss from comment #52) > Sorry, I should have been more clear. Could you post the entire acpidump? It > would be easier to diagnose your issue if I have the entire acpidump (not > just the dsdt) as well as a dmesg. Here you go. (In reply to Hans de Goede from comment #59) > Created attachment 273957 [details] > Boot dmesg for asrock-B150M-Pro4S-D3 The message [ 0.000000] ACPI: Core revision 20170831 [ 0.000000] ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20170831/dswload-210) [ 0.000000] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20170831/psobject-252) [ 0.000000] ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp08) while loading table (20170831/tbxfload-228) [ 0.000000] ACPI Error: 1 table load failures, 5 successful (20170831/tbxfload-246) Comes from module level code support. We are currently working on fixing this issue right now. > > (In reply to Erik Schmauss from comment #52) > > Sorry, I should have been more clear. Could you post the entire acpidump? > It > > would be easier to diagnose your issue if I have the entire acpidump (not > > just the dsdt) as well as a dmesg. > > Here you go. *** Bug 198561 has been marked as a duplicate of this bug. *** Just an update, I am in the process of bisecting this between 4.13 and 4.14... Hi, We've identified the issue and we have submitted patches to suppress these AE_NOT_FOUND messages. I tested this locally on QEMU with a DSDT containing code that points to undefined names and I did not see errors. I was in a bit of a rush to get this for 4.16. If anyone would like to try it, you can apply the following patches on top of 4.16-rc1... Created attachment 274193 [details]
patch 1/3
Created attachment 274195 [details]
patch 2/3
Created attachment 274197 [details]
patch 3/3
I believe this issue can be resolved by the above patches. Closing This is NOT resolved as of today and continues with up to 4.16.7 kernel Created attachment 276069 [details]
acpi dump
Hi, kernel 4.18.6 ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKA (20180531/dspkginit-414) ..... I returned the kernel 4.13.16 :( Problem is not solved! I rolled the kernel back to 4.1. This did not solve the problem.. Is it problem GPU or motherboard compatibility? I did not find a software solution and I'm going to update the hardware. What kind of hardware does this problem depend on? (In reply to karpo518 from comment #72) > I rolled the kernel back to 4.1. This did not solve the problem.. Is it > problem GPU or motherboard compatibility? I did not find a software solution > and I'm going to update the hardware. What kind of hardware does this > problem depend on? These errors are typically harmless, they are a bit annoying but usually they do not cause any actual problems. Are you actually having any issues with your system other then the error messages ? If your system works fine otherwise then there is no need to change it. > Are you actually having any issues with your system other then the error
> messages ?
My monitor disabled after switching Linux Mint 19 in the grub. I can boot Linux Mint with software rendering only. Windows 10 starts without problems.
My cinnamon DE does not start. I think, it is not depends with acpi, becouse i get a lot of other errors too. I will analyze my syslog for fix it. I beg to pardon me. "Problem is not solved!" — me too (GA-780T-D3L) Created attachment 278899 [details]
Patch to ignore package resolution errors
I wasn't clear about my "fix". We've talked about this before and there are lots of LNKA-LNKD errors that don't get resolved. These issues are known to be harmless so we've provided the option for users to ignore these errors. You can apply this patch to ignore these errors but we'll set the default to have these errors turned on for now. If you are experiencing actual problems, they may be due to issues other than package resolution of LNKA-LNKD.
GIGABYTE's eSupport refused to help at this topic. My motherboard GA-770TA-UD3 (Revision 1.0) is "End Of Life" and the correction of BIOS Ver. F4B would be to expensive for them. After switching from (S1)POS to (S3)STR in the BIOS configuration the parallel installed MS Windows 10 at my computer isn't able to standby nor to hibernate, too. Now I'm back to the value (S1)POS for 'ACPI Suspend Type' at the 'Power Management Setup' within Awards CMOS Setup Utility. Because of this EASYLY _ignorable_ *problemo*, I'm still using Debian 9 as primary operating system and not Debian 10 for my desktop (tasks). Gigabyte Technology Co., Ltd." "GA-MA790FXT-UD5P" Award Software International, Inc."BIOS version:"F8n" PCI_INTERFACE_FROM_DATABASE=VGA controller ID_VENDOR_FROM_DATABASE=NVIDIA Corporation ID_MODEL_FROM_DATABASE=GK104 [GeForce GTX 760] Debian Buster kernel 4.19.0-6-amd64 I have the same error when the system boot. ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKA (20180810/dspkginit-414) I had to change the BIOS option from s3 to s1. With s3 (STR) when the system come from standby, I received the error: EXT4-fs error (device sdb1): In older versions of Debian, suspend to ram it worked fine. (In reply to Angelo SdR from comment #80) > Gigabyte Technology Co., Ltd." "GA-MA790FXT-UD5P" > Award Software International, Inc."BIOS version:"F8n" > PCI_INTERFACE_FROM_DATABASE=VGA controller > ID_VENDOR_FROM_DATABASE=NVIDIA Corporation > ID_MODEL_FROM_DATABASE=GK104 [GeForce GTX 760] > > Debian Buster kernel 4.19.0-6-amd64 > > I have the same error when the system boot. > > ACPI Error: AE_NOT_FOUND, While resolving a named reference package element > - LNKA (20180810/dspkginit-414) > > I had to change the BIOS option from s3 to s1. With s3 (STR) when the system > come from standby, I received the error: EXT4-fs error (device sdb1): > > In older versions of Debian, suspend to ram it worked fine. I have solved the problem mentioned above about suspend to ram by not using the controller: [JMicron Technology Corp. JMB363 SATA / IDE Controller (rev 02)]. It seems that it doesn't work well with Debian or with Arch. In fact connecting the HDD to the other controller SATA controller: Advanced Micro Devices, Inc. [AMD / ATI] SB7x0 / SB8x0 / SB9x0 SATA Controller [AHCI mode] Suspend to Ram (s3) works perfectly. I still see the message in Debian ACPI Error: AE_NOT_FOUND, While resolving a named reference package element > - LNKA (20180810 / dspkginit-414) While in Arch it is simply hidden. Why are you still bothering with reporting bugs here? It is blatantly obvious from the history and age of this report that no one at all is interested in any troubleshooting and resolving that? Created attachment 285669 [details] attachment-3658-0.html What are the expectations for errors reported during boot process? What constitutes an error and what is just noise? If this is only important on other motherboards? When i look at a system boot report, no one wants to see an ever growing list of reported errors. On Sun, Oct 27, 2019, 8:22 PM <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=198167 > > --- Comment #82 from infove (info@vintageelectronics.ca) --- > Why are you still bothering with reporting bugs here? > It is blatantly obvious from the history and age of this report that no > one at > all is interested in any troubleshooting and resolving that? > > -- > You are receiving this mail because: > You are on the CC list for the bug. (In reply to infove from comment #82) > Why are you still bothering with reporting bugs here? > It is blatantly obvious from the history and age of this report that no one > at all is interested in any troubleshooting and resolving that? I wanted to report what I found out about the controller because maybe it can also help those who have a Gigabyte motherboard with AMD 7 series chipset with 2 different controllers like mine. Maybe Marco Kluth who recently wrote the post in September may find the info useful. Also say that Debian has 4.19.0-6 and Arch 5.3.7 so, as I said in the previous post, the ACPI error continues and the incompatibility with the controller "JMB363 SATA / IDE Controller" also (as for Suspend to Ram). |