Bug#1041142: ACPI Warning: SystemIO range … conflicts with OpRegion … . lpc_ich: Resource conflict(s) found affecting gpio_ich

[AlMa]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.37-1
Severity: wishlist

In the journal we find the following warnings (the texts "ACPI Warning:
… (20220331/utaddress-204)" and “lpc_ich: … gpio_ich” are orange, and
everything else is white as usual):

…
Jul 15 03:35:14 AnonymizedMachneName kernel: input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input5
Jul 15 03:35:14 AnonymizedMachneName kernel: ACPI: button: Power Button
[PWRF]
Jul 15 03:35:14 AnonymizedMachneName kernel: ACPI Warning: SystemIO
range 0x0000000000000428-0x000000000000042F conflicts with OpRegion
0x0000000000000400-0x000000000000047F (\PMIO) (20220331/utaddress-204)
Jul 15 03:35:14 AnonymizedMachneName kernel: ACPI: OSL: Resource
conflict; ACPI support missing from driver?
Jul 15 03:35:14 AnonymizedMachneName kernel: ACPI: battery: Slot [BAT0]
(battery present)
Jul 15 03:35:14 AnonymizedMachneName kernel: ACPI Warning: SystemIO
range 0x0000000000000540-0x000000000000054F conflicts with OpRegion
0x0000000000000500-0x0000000000000563 (\GPIO) (20220331/utaddress-204)
Jul 15 03:35:14 AnonymizedMachneName kernel: ACPI: OSL: Resource
conflict; ACPI support missing from driver?
Jul 15 03:35:14 AnonymizedMachneName kernel: ACPI: battery: Slot [BAT1]
(battery absent)
Jul 15 03:35:14 AnonymizedMachneName kernel: ACPI Warning: SystemIO
range 0x0000000000000530-0x000000000000053F conflicts with OpRegion
0x0000000000000500-0x0000000000000563 (\GPIO) (20220331/utaddress-204)
Jul 15 03:35:14 AnonymizedMachneName kernel: ACPI: OSL: Resource
conflict; ACPI support missing from driver?
Jul 15 03:35:14 AnonymizedMachneName kernel: ACPI Warning: SystemIO
range 0x0000000000000500-0x000000000000052F conflicts with OpRegion
0x0000000000000500-0x0000000000000563 (\GPIO) (20220331/utaddress-204)
Jul 15 03:35:14 AnonymizedMachneName kernel: ACPI: OSL: Resource
conflict; ACPI support missing from driver?
Jul 15 03:35:14 AnonymizedMachneName kernel: lpc_ich: Resource
conflict(s) found affecting gpio_ich
…

The machine is a Dell Mobile Precision M6700 with the processor Intel
Core i7-3720QM, 32 GB RAM, and AMD FirePro M6000 Mobility Pro graphic
chip with 2GB GDDR5. BIOS is at its latest available version A20. As
the machine experiences high-level issues later at boot (e.g., some
services can't start), we wish to be sure about the contribution of the
issues warned about here. If we believe Jean Delvare from
https://bugzilla.kernel.org/show_bug.cgi?id=48811 , these warnings might
be just informative; the user probably needn't be warned. If this is
really so (myself, I have no idea), there's no need for the orange color.

Gratefully,
AlMa

[AlMa]

On 01.08.23 01:12, Debian Bug Tracking System wrote:
> You filed *8* different 'bugs' which (almost?) all are about a Dell Mobile
> Precision M6700 ... and not once did you say what actual problem you
> experienced?!?

That's wrong.
Before I posted some (not all) of the bug reports, the Dell laptop
stopped booting properly rather early; the root cause is still unknown
(though an intermediate cause is finally resolved now, the bug report is
already closed). It took me a bit to get a working console, a mouse and
network going so as to simply be able to start debugging. Some other
machines I manage had (and still have) other, less severe symptoms,
e.g., Wayland and programs depending on Wayland (e.g., “foot”) failing
to start after Debian upgrade.

If your computer doesn't boot properly, you go one by one through every
suspicious message you find. The fact that some messages are shown as
warnings and others as errors is clearly meant to warn whoever reads
them (i.e., the admin) and make him/her concerned. By the definition of
the terms “warning” and “error”! If these messages shouldn't make the
admin concerned, well, then the journalctl shouldn't show these messages
as warnings (AFAIK, yellow) and errors (red according to `man
journalctl`). Please don't try to unload on me because of this mess;
I'm just an admin, and not even a developer.

Therefore, please restore the bug reports you closed.

Gratefully,

Alma

[AlMa]

[AlMa]

> You filed *8* different 'bugs' which (almost?) all are about a Dell Mobile
> Precision M6700 ... and not once did you say what actual problem you
> experienced?!?

That's wrong (at least if you put it this straight).

Before I posted some (not all) of the bug reports, the Dell laptop
stopped booting properly rather early; the root cause is still unknown

(though an intermediate cause is finally resolved now, and the
corresponding bug report is already closed). It took me a bit to get a

[Ben Hutchings]

On Tue, 2023-08-01 at 02:49 +0200, AlMa wrote:
> On 01.08.23 01:12, Debian Bug Tracking System wrote:
> > You filed *8* different 'bugs' which (almost?) all are about a Dell Mobile
> > Precision M6700 ... and not once did you say what actual problem you
> > experienced?!?
>
> That's wrong.
> Before I posted some (not all) of the bug reports, the Dell laptop
> stopped booting properly rather early; the root cause is still unknown
> (though an intermediate cause is finally resolved now, the bug report is
> already closed). It took me a bit to get a working console, a mouse and
> network going so as to simply be able to start debugging. Some other
> machines I manage had (and still have) other, less severe symptoms,
> e.g., Wayland and programs depending on Wayland (e.g., “foot”) failing
> to start after Debian upgrade.
>
> If your computer doesn't boot properly, you go one by one through every
> suspicious message you find. The fact that some messages are shown as
> warnings and others as errors is clearly meant to warn whoever reads
> them (i.e., the admin) and make him/her concerned. By the definition of
> the terms “warning” and “error”!

This is a rather naive understanding of how logging is done in
practice. The reality is that developers often don't know (and maybe
can't know) just how severe an odd condition may be in practice.

> If these messages shouldn't make the
> admin concerned, well, then the journalctl shouldn't show these messages
> as warnings (AFAIK, yellow) and errors (red according to `man
> journalctl`). Please don't try to unload on me because of this mess;
> I'm just an admin, and not even a developer.
>
> Therefore, please restore the bug reports you closed.

I agree with Diederik's closing these bug reports. We as kernel
maintainers have limited time and resources for investigating bugs, and
we are certainly not able to provide individual support for users and
administrators. Investigating warning messages one by one is not a
priority at all.

If there is still an actual problem on this machine (not just warning
messages), please open *1* bug report that describes the actual problem
and the log messages.

Ben.

--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.

[AlMa]

> This is a rather naive understanding of how logging is done in
> practice. The reality is that developers often don't know (and maybe
> can't know) just how severe an odd condition may be in practice.

Unfortunately, neither do I. Though seemingly unrelated journal-visible
issues are quite often indeed independent, sometimes unexpected
interactions or common root causes occur.

> If there is still an actual problem on this machine (not just warning
> messages), please open *1* bug report that describes the actual problem
> and the log messages.

If under *actual* you mean *user-disturbing* (“error, flaw or fault in
the design, development, or operation of computer software that causes
it to produce an incorrect or unexpected result, or to behave in
unintended ways”, a definition from Wikipedia), I've got none for the
kernel because the kernel is not visible (nor should it be visible) to
users directly. The only (sometimes reproducible) full lock-up (SysRq
doesn't seem to work) I saw myself, which might concern the kernel,
happened when epiphany-browser loads Google maps directly or embedded
into a different Web site; I plan to submit a bug report.

As for other high-level problems which are already posted, there are at
least two (and more are likely to come).

One of them, already resolved recently (though the root cause is still
unknown, the intermediate problem is gone) is #1041014. If I had to
state the *actual* problem there, it would have been „the machine
doesn't boot properly, the screen is black, the keyboard doesn't seem to
respond“; such a description would've probably been considered *actual*
but pretty useless to the maintainers. Even if it would have been
useful to you, then only in the sense that a failure to start a
graphical user interface should not prevent text logins from visibly
showing up on Ctrl + Alt + F1 … Ctrl + Alt + F6 and that error codes
(instead of "ERRNO" and "exit-code") from failed spawns by systemd
should be printed.

As another big problem on another machine, cf. #1040497. A next step in
debugging this could be looking at how /run/gdm3/custom.conf is created,
whether the logic in /lib/udev/rules.d/61-gdm.rules is correct, and
whether using X.Org (in Debian 12) instead of Wayland (in Debian 11) is
really justified on the particular machine
(https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/171#note_1403697
doesn't apply in my use case because the onboard graphics chip is
usually not connected to a monitor in my setup, except if the monitor
connected to the PCIe NVIDIA card happens to fail, which has not yet
happened). If this issue involves the kernel at all, then probably the
nouveau driver. The details of this issue are beyond my level of
expertise, so I'm unsure how much I can really do myself.

Gratefully,
Alma

[AlMa]

On 01.08.23 21:08, AlMa wrote:
>> This is a rather naive understanding of how logging is done in
>> practice.  The reality is that developers often don't know (and maybe
>> can't know) just how severe an odd condition may be in practice.
>
> Unfortunately, neither do I.  Though seemingly unrelated journal-visible
> issues are quite often indeed independent, sometimes unexpected
> interactions or common root causes occur.

Perhaps, there should be a category for tentative errors and/or
tentative warnings (i.e., with an unknown (or yet unknown) severity in
practice). E.g., dereferencing a zero pointer, or division by zero, or
garbled screen output, or the inability to read '/' as the root user,
etc. are almost always errors (except when you test error-handling
routes themselves; then a division by zero is not a bug but a must). If
you say that it is unknown how severe a message such as “ACPI Warning:
SystemIO range … conflicts with OpRegion … . lpc_ich: Resource
conflict(s) found affecting gpio_ich” really is, it should not be a
warning (especially, it should not warn the reader) but be a tentative
warning (i.e., it might warn the reader in the future or under
particular circumstances). The (new?) colors of the tentative errors
and warnings should be clearly stated in the manpages of journalctl.