Bug 198167 - ACPI Exception: Could not find/resolve named package element - Gigabyte GA-890GPA-UD3H, AMD Phenom II X6 1055T
Summary: ACPI Exception: Could not find/resolve named package element - Gigabyte GA-89...
Status: RESOLVED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Erik Kaneda
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-14 20:31 UTC by Jorge Martínez López
Modified: 2022-07-13 18:48 UTC (History)
24 users (show)

See Also:
Kernel Version: 4.14.3
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
acpidump (159.77 KB, text/plain)
2017-12-15 09:05 UTC, Jorge Martínez López
Details
dmesg (81.28 KB, text/plain)
2017-12-18 19:08 UTC, Jorge Martínez López
Details
Journal logs around the sleep and wake times (13.27 KB, text/plain)
2017-12-20 19:10 UTC, Jorge Martínez López
Details
dmesg output (134.51 KB, text/plain)
2017-12-20 19:11 UTC, Jorge Martínez López
Details
acpidump from my GA-970A-UD3 (268.22 KB, text/plain)
2018-01-03 00:12 UTC, Richard
Details
ACPI Dump from GA-MA770-UD3 on 4.14.8-300. (138.96 KB, text/plain)
2018-01-03 02:55 UTC, westerj
Details
Acpidump Gigabyte GA-MA790X-UD4 AMD Phenom II X4 940 4.14.11-1-ARCH (115.63 KB, text/plain)
2018-01-06 07:28 UTC, Martin Sand
Details
ACPIDUMP ga78lmt-usb3 (138.77 KB, text/plain)
2018-01-07 00:42 UTC, Allen
Details
Gigabyte_GA-770TA-UD3 (149.97 KB, text/plain)
2018-01-08 19:40 UTC, Julien
Details
Gigabyte - GA-MA770T-UD3P - dmidecode -q (11.90 KB, text/plain)
2018-01-09 14:26 UTC, Yann-Kaelig
Details
Gigabyte - GA-MA770T-UD3P - acpidump (139.52 KB, text/plain)
2018-01-09 14:27 UTC, Yann-Kaelig
Details
[PATCH 1/2] ACPICA: acpi_ds_resolve_package_element: Use proper status when logging exception (1.34 KB, patch)
2018-01-12 11:40 UTC, Hans de Goede
Details | Diff
[PATCH 2/2] ACPICA: Log failing to find symbols in the tables as warnings (3.73 KB, patch)
2018-01-12 11:41 UTC, Hans de Goede
Details | Diff
acpidump for GA-990XA-UD3 (296.13 KB, text/plain)
2018-01-24 07:56 UTC, Klaus Mueller
Details
DSDT of asrock-B150M-Pro4S-D3 which has similar problems (1.07 MB, text/plain)
2018-01-27 14:12 UTC, Hans de Goede
Details
dmesg for release 4.13.16 (76.07 KB, text/plain)
2018-01-30 20:22 UTC, Jorge Martínez López
Details
asrock-B150M-Pro4S-D3 acpidump (794.79 KB, application/octet-stream)
2018-02-01 12:40 UTC, Hans de Goede
Details
Boot dmesg for asrock-B150M-Pro4S-D3 (70.09 KB, text/plain)
2018-02-01 12:41 UTC, Hans de Goede
Details
patch 1/3 (9.88 KB, application/mbox)
2018-02-15 22:07 UTC, Erik Kaneda
Details
patch 2/3 (11.65 KB, application/mbox)
2018-02-15 22:07 UTC, Erik Kaneda
Details
patch 3/3 (3.66 KB, application/mbox)
2018-02-15 22:07 UTC, Erik Kaneda
Details
acpi dump (232.42 KB, text/plain)
2018-05-19 17:34 UTC, infove
Details
Patch to ignore package resolution errors (572 bytes, patch)
2018-10-02 23:16 UTC, Erik Kaneda
Details | Diff

Description Jorge Martínez López 2017-12-14 20:31:34 UTC
Since Fedora (27) moved to 4.14 I have observed the following error messages at boot:


ACPI: Added _OSI(Processor Aggregator Device)
ACPI: Actual Package length (1) is larger than NumElements field (0), truncated
ACPI: Actual Package length (1) is larger than NumElements field (0), truncated
ACPI: Actual Package length (1) is larger than NumElements field (0), truncated
ACPI: Actual Package length (1) is larger than NumElements field (0), truncated
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)

Motherboard: Gigabyte GA-890GPA-UD3H
Processor: AMD Phenom II X6 1055T

Please let me know if you need any additional information.
Comment 1 Jorge Martínez López 2017-12-14 20:32:34 UTC
Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1524599
Comment 2 Hans de Goede 2017-12-15 07:47:31 UTC
Jorge, can you can run acpidump on your board and attach an acpidump here please?
Comment 3 Jorge Martínez López 2017-12-15 09:05:22 UTC
Created attachment 261191 [details]
acpidump

acpidump as requested.
Comment 4 Zhang Rui 2017-12-18 13:52:39 UTC
what's the latest kernel without the error messages?

please attach the full dmesg output.
Comment 5 Jorge Martínez López 2017-12-18 19:08:07 UTC
The last Fedora kernel with no error is 4.13.16-302.
Comment 6 Jorge Martínez López 2017-12-18 19:08:56 UTC
Created attachment 261245 [details]
dmesg

And now with the dmesg attached.
Comment 7 Erik Kaneda 2017-12-19 00:07:49 UTC
Hi Jorge,

Aside from ACPI errors, are you seeing any other sideffects caused from these errors?
Comment 8 Jorge Martínez López 2017-12-19 20:51:08 UTC
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.
Comment 9 Erik Kaneda 2017-12-20 01:03:08 UTC
I forgot to ask - which kernel version did you use before 4.14?
Comment 10 Erik Kaneda 2017-12-20 01:28:17 UTC
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.
Comment 11 Jorge Martínez López 2017-12-20 19:09:36 UTC
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.
Comment 12 Jorge Martínez López 2017-12-20 19:10:26 UTC
Created attachment 261277 [details]
Journal logs around the sleep and wake times

Journal logs.
Comment 13 Jorge Martínez López 2017-12-20 19:11:16 UTC
Created attachment 261279 [details]
dmesg output
Comment 14 Richard 2017-12-22 19:23:55 UTC
See this also on my GA-970A-UD3 w/ AMD Athlon(tm) II X3 455 Processor
Comment 15 Yury Martynov 2017-12-23 14:38:31 UTC
Me too: AMD FX(tm)-6300 Six-Core Processor (GA-780T-D3L)
Comment 16 vikb 2017-12-25 17:31:23 UTC
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
Comment 17 westerj 2017-12-27 16:20:07 UTC
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
Comment 18 Erik Kaneda 2018-01-02 21:12:20 UTC
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.
Comment 19 Richard 2018-01-02 23:59:07 UTC
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
Comment 20 Richard 2018-01-03 00:12:11 UTC
My fault, it's now provided by the acpica-tools package but it's a symlink to acpidump-acpica...
Comment 21 Richard 2018-01-03 00:12:51 UTC
Created attachment 273375 [details]
acpidump from my GA-970A-UD3
Comment 22 westerj 2018-01-03 02:55:52 UTC
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
Comment 23 Martin Sand 2018-01-06 07:28:37 UTC
Created attachment 273433 [details]
Acpidump Gigabyte GA-MA790X-UD4 AMD Phenom II X4 940 4.14.11-1-ARCH
Comment 24 Martin Sand 2018-01-06 07:29:09 UTC
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
Comment 25 Allen 2018-01-07 00:42:27 UTC
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)
Comment 26 Julien 2018-01-08 19:40:40 UTC
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
Comment 27 Yann-Kaelig 2018-01-09 14:04:53 UTC
Siema,

Same issue here.
My dmidecode and acpidump
Comment 28 Yann-Kaelig 2018-01-09 14:26:28 UTC
Created attachment 273497 [details]
Gigabyte - GA-MA770T-UD3P - dmidecode -q
Comment 29 Yann-Kaelig 2018-01-09 14:27:06 UTC
Created attachment 273499 [details]
Gigabyte - GA-MA770T-UD3P - acpidump
Comment 30 Erik Kaneda 2018-01-09 21:14:20 UTC
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..
Comment 31 Martin Sand 2018-01-09 22:37:37 UTC
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?
Comment 32 Erik Kaneda 2018-01-10 15:55:55 UTC
It's missing in the firmware. The best thing to do is to contact firmware vendors and proceed from there.
Comment 33 Marcin Kurek 2018-01-10 17:28:36 UTC
(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 ;(
Comment 34 Hans de Goede 2018-01-11 19:37:36 UTC
(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.
Comment 35 westerj 2018-01-12 05:28:08 UTC
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.
Comment 36 Hans de Goede 2018-01-12 09:37:41 UTC
(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 ?
Comment 37 Hans de Goede 2018-01-12 11:40:40 UTC
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.
Comment 38 Hans de Goede 2018-01-12 11:41:07 UTC
Created attachment 273559 [details]
[PATCH 2/2] ACPICA: Log failing to find symbols in the tables as warnings
Comment 39 westerj 2018-01-12 12:32:39 UTC
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.
Comment 40 Erik Kaneda 2018-01-23 18:36:10 UTC
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.
Comment 41 Hans de Goede 2018-01-23 19:23:59 UTC
(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.
Comment 42 westerj 2018-01-24 04:24:09 UTC
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.
>
Comment 43 Klaus Mueller 2018-01-24 07:53:43 UTC
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
Comment 44 Klaus Mueller 2018-01-24 07:56:51 UTC
Created attachment 273841 [details]
acpidump for GA-990XA-UD3
Comment 45 Gerardo Exequiel Pozzi 2018-01-24 17:36:18 UTC
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)
Comment 46 Erik Kaneda 2018-01-24 19:14:12 UTC
(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.
Comment 47 Erik Kaneda 2018-01-26 21:13:22 UTC
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).
Comment 48 Hans de Goede 2018-01-27 14:11:09 UTC
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
Comment 49 Hans de Goede 2018-01-27 14:12:19 UTC
Created attachment 273891 [details]
DSDT of asrock-B150M-Pro4S-D3 which has similar problems
Comment 50 Erik Kaneda 2018-01-29 17:10:16 UTC
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
Comment 51 Hans de Goede 2018-01-29 17:16:50 UTC
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
Comment 52 Erik Kaneda 2018-01-29 18:24:52 UTC
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
Comment 53 Erik Kaneda 2018-01-29 22:00:12 UTC
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...
Comment 54 Jorge Martínez López 2018-01-29 22:28:48 UTC
(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
Comment 55 Marcin Kurek 2018-01-30 09:45:35 UTC
(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
Comment 56 Jorge Martínez López 2018-01-30 20:22:44 UTC
Created attachment 273935 [details]
dmesg for release 4.13.16
Comment 57 Jorge Martínez López 2018-01-30 20:24:07 UTC
(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.
Comment 58 Hans de Goede 2018-02-01 12:40:41 UTC
Created attachment 273955 [details]
asrock-B150M-Pro4S-D3 acpidump
Comment 59 Hans de Goede 2018-02-01 12:41:21 UTC
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.
Comment 60 Erik Kaneda 2018-02-05 21:21:36 UTC
(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.
Comment 61 Len Brown 2018-02-05 23:20:22 UTC
*** Bug 198561 has been marked as a duplicate of this bug. ***
Comment 62 Erik Kaneda 2018-02-07 23:33:50 UTC
Just an update, I am in the process of bisecting this between 4.13 and 4.14...
Comment 63 Erik Kaneda 2018-02-15 22:06:24 UTC
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...
Comment 64 Erik Kaneda 2018-02-15 22:07:21 UTC
Created attachment 274193 [details]
patch 1/3
Comment 65 Erik Kaneda 2018-02-15 22:07:40 UTC
Created attachment 274195 [details]
patch 2/3
Comment 66 Erik Kaneda 2018-02-15 22:07:57 UTC
Created attachment 274197 [details]
patch 3/3
Comment 67 Erik Kaneda 2018-03-01 18:33:26 UTC
I believe this issue can be resolved by the above patches. Closing
Comment 68 infove 2018-05-19 17:27:27 UTC
This is NOT resolved as of today and continues with up to 4.16.7 kernel
Comment 69 infove 2018-05-19 17:34:58 UTC
Created attachment 276069 [details]
acpi dump
Comment 70 vikb 2018-09-08 09:27:29 UTC
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 :(
Comment 71 karpo518 2018-09-30 22:20:38 UTC
Problem is not solved!
Comment 72 karpo518 2018-10-01 09:53:24 UTC
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?
Comment 73 Hans de Goede 2018-10-01 10:46:13 UTC
(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.
Comment 74 karpo518 2018-10-01 10:54:51 UTC
> 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.
Comment 75 karpo518 2018-10-02 08:31:12 UTC
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.
Comment 76 Yury Martynov 2018-10-02 15:26:15 UTC
"Problem is not solved!" — me too (GA-780T-D3L)
Comment 77 Erik Kaneda 2018-10-02 23:16:59 UTC
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.
Comment 78 Marco Kluth 2019-09-07 09:33:38 UTC
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.
Comment 79 Marco Kluth 2019-09-07 11:53:40 UTC
Because of this EASYLY _ignorable_ *problemo*,
I'm still using Debian 9 as primary operating system
and not Debian 10 for my desktop (tasks).
Comment 80 Angelo SdR 2019-10-22 16:20:19 UTC
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.
Comment 81 Angelo SdR 2019-10-28 00:17:59 UTC
(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.
Comment 82 infove 2019-10-28 00:22:27 UTC
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?
Comment 83 westerj 2019-10-28 02:13:56 UTC
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.
Comment 84 Angelo SdR 2019-10-28 16:28:41 UTC
(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).

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