From: Takashi Iwai <tiwai@suse.de>
To: "Artem S. Tashkinov" <aros@gmx.com>
Cc: Takashi Iwai <tiwai@suse.de>,
Thorsten Leemhuis <linux@leemhuis.info>,
Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
workflows@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Greg KH <gregkh@linuxfoundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"regressions@lists.linux.dev" <regressions@lists.linux.dev>,
ksummit@lists.linux.dev
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla blues"
Date: Sun, 02 Oct 2022 11:14:22 +0200 [thread overview]
Message-ID: <87h70mvb81.wl-tiwai@suse.de> (raw)
In-Reply-To: <56a04cae-7240-9005-4931-5b3e9f598ffb@gmx.com>
On Sun, 02 Oct 2022 10:23:07 +0200,
Artem S. Tashkinov wrote:
>
>
>
> On 10/2/22 07:37, Takashi Iwai wrote:
> > On Sat, 01 Oct 2022 12:30:22 +0200,
> > Artem S. Tashkinov wrote:
> >> - 2 -
> >>
> >> Here's another one which is outright puzzling:
> >>
> >> You run: dmesg -t --level=emerg,crit,err
> >>
> >> And you see some non-descript errors of some kernel subsystems seemingly
> >> failing or being unhappy about your hardware. Errors are as cryptic as
> >> humanly possible, you don't even know what part of kernel has produced them.
> >>
> >> OK, as a "power" user I download the kernel source, run `grep -R message
> >> /tmp/linux-5.19` and there are _multiple_ different modules and places
> >> which contain this message.
> >>
> >> I'm lost. Send this to LKML? Did that in the long past, no one cared, I
> >> stopped.
> >>
> >> Here's what I'm getting with Linux 5.19.12:
> >>
> >> platform wdat_wdt: failed to claim resource 5: [mem
> >> 0x00000000-0xffffffff7fffffff]
> >> ACPI: watchdog: Device creation failed: -16
> >> ACPI BIOS Error (bug): Could not resolve symbol
> >> [\_SB.PCI0.XHC.RHUB.TPLD], AE_NOT_FOUND (20220331/psargs-330)
> >> ACPI Error: Aborting method \_SB.UBTC.CR01._PLD due to previous error
> >> (AE_NOT_FOUND) (20220331/psparse-529)
> >> platform MSFT0101:00: failed to claim resource 1: [mem
> >> 0xfed40000-0xfed40fff]
> >> acpi MSFT0101:00: platform device creation failed: -16
> >> lis3lv02d: unknown sensor type 0x0
> >>
> >> Are they serious? Should they be reported or not? Is my laptop properly
> >> working? I have no clue at all.
> >
> > That's a dilemma. The kernel can't know whether it's "properly"
> > working, either -- that is, whether the lack of some functions matters
> > for you or not. In your case above, it's about a watchdog, something
> > related with USB, TPM, and acceleration sensor, all of which likely
> > come from a buggy BIOS. Would you mind if those features are missing?
> > Or even whether your device has a correct hardware implementation?
> > Kernel doesn't know, hence it complains as an error.
> >
> > In many drivers, there are mechanisms to shut off superfluous error
> > messages for known devices. So it's case-by-case solutions.
> >
> > Or you can completely hide those errors at boot by a boot option
> > (e.g. loglevel=2).
>
> The problem is some of such messages are indeed indicative of certain
> real issues which result in HW not working properly, including:
>
> 1) missing/incorrect firmware
> 2) most importantly: not enabled power saving modes
> 3) not enabled high performance modes
> 4) not enabled devices
> 5) not enabled devices' functions
> 6) drivers conflicts (i.e. the wrong module gets loaded for the device)
> 7) physically failing hardware
>
> I'm quite sure you don't really know what half of those messages
> actually mean.
Of course: not because those messages are hardly understandable but
because those messages indicate only the cause, and the exact end
result can't be always known from the kernel at that point. A lack of
physical failing hardware? Not enabled devices? Who knows. There
might be some alternative, even a user-space driver.
> Speaking of 7. Various kernel subsystems/drivers deal with e.g. mass
> storage which is known to fail quite often. There's not a single driver
> in the kernel which is actually brave enough to spew something like this:
>
> "/dev/xxxx might be failing, please RMA or seek help online"
>
> instead you get a dmesg choke full of "unable to read sector XXX" or
> something like that.
Oh you suggest that we should put "please RMA or seek help online" to
each printk of KERN_ERR level, if it saves the world? ;)
IMO, what matters for users is whether the system works or not. It's
not how the kernel message appears. A kernel message may help for
diagnose, but the message itself is no solution; that is, the most
importance of a kernel message is that it indicates a real error that
can be diagnosed by developers.
If the end effect is pretty sure, a message may be more chatty. OTOH,
people are annoyed by such too verbosity, too. So it needs a sensible
choice.
> To return to the previous errors: it's impossible for the user to assess
> their severity and that sucks.
Right, that's why I wrote it's a dilemma.
> What is "platform device creation
> failed"? What is "unknown sensor type"? What am I missing? Who's
> responsible? The kernel? My HW vendor? Are those errors actionable?
All those depend on the driver implementation and the hardware
implementation. There is no general answer at all, unfortunately.
> In
> my understanding a properly working computer must not produce
> "emerg,crit,err" errors. I'm not even talking about "warn,info" and such.
Yes, some errors can be downgraded to warn or even to info.
I myself find ACPI is way too chatty, too.
So I believe something we can improve is to define some more clear
guideline for KERN_ERR level errors.
Takashi
next prev parent reply other threads:[~2022-10-02 9:14 UTC|newest]
Thread overview: 165+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-29 11:19 Planned changes for bugzilla.kernel.org to reduce the "Bugzilla blues" Thorsten Leemhuis
2022-09-29 11:33 ` Thorsten Leemhuis
2022-09-29 12:22 ` Artem S. Tashkinov
2022-09-29 12:52 ` Greg KH
2022-09-29 13:09 ` Artem S. Tashkinov
2022-09-29 13:21 ` Greg KH
2022-09-29 13:23 ` Konstantin Ryabitsev
2022-09-29 13:04 ` Konstantin Ryabitsev
2022-09-29 13:31 ` Artem S. Tashkinov
2022-09-29 13:43 ` Greg KH
2022-09-29 13:53 ` Konstantin Ryabitsev
2022-09-29 14:22 ` Artem S. Tashkinov
2022-09-29 14:54 ` Slade Watkins
2022-09-29 16:42 ` Laurent Pinchart
2022-09-29 19:00 ` Slade Watkins
2022-09-30 9:35 ` Thorsten Leemhuis
2022-09-30 13:23 ` Laurent Pinchart
2022-09-30 16:19 ` Bird, Tim
2022-09-30 16:34 ` Artem S. Tashkinov
2022-09-30 16:47 ` Laurent Pinchart
2022-10-01 1:18 ` Theodore Ts'o
2022-10-01 2:47 ` Slade Watkins
2022-10-01 7:57 ` Bagas Sanjaya
2022-10-01 13:01 ` Theodore Ts'o
2022-10-03 6:55 ` Christoph Hellwig
2022-09-30 17:36 ` Slade Watkins
2022-09-30 16:36 ` Laurent Pinchart
2022-09-30 17:28 ` Luck, Tony
2022-09-30 17:49 ` Slade Watkins
2022-09-30 20:04 ` Randy Dunlap
2022-09-30 20:29 ` Thorsten Leemhuis
2022-09-29 15:31 ` Konstantin Ryabitsev
2022-09-29 15:39 ` Slade Watkins
2022-09-29 16:06 ` Artem S. Tashkinov
2022-09-29 20:26 ` Slade Watkins
2022-09-30 8:47 ` Thorsten Leemhuis
2022-09-30 9:03 ` Artem S. Tashkinov
2022-09-30 10:37 ` Slade Watkins
2022-09-30 15:32 ` Laurent Pinchart
2022-10-03 11:44 ` Jani Nikula
2022-09-29 15:26 ` James Bottomley
2022-09-30 8:52 ` Artem S. Tashkinov
2022-09-29 13:47 ` Steven Rostedt
2022-09-29 14:02 ` Thorsten Leemhuis
2022-09-29 14:12 ` Steven Rostedt
2022-10-01 10:30 ` Artem S. Tashkinov
2022-10-01 10:39 ` Greg KH
2022-10-01 10:47 ` Artem S. Tashkinov
2022-10-01 10:57 ` Thorsten Leemhuis
2022-10-01 11:21 ` Artem S. Tashkinov
2022-10-01 11:34 ` Thorsten Leemhuis
2022-10-01 13:07 ` Theodore Ts'o
2022-10-01 14:58 ` Artem S. Tashkinov
2022-10-02 12:18 ` Theodore Ts'o
2022-10-02 12:49 ` Artem S. Tashkinov
2022-10-02 14:35 ` Greg KH
2022-10-02 19:27 ` Artem S. Tashkinov
2022-10-02 20:46 ` Linus Torvalds
2022-10-02 20:56 ` Artem S. Tashkinov
2022-10-02 21:07 ` Linus Torvalds
2022-10-02 21:27 ` Artem S. Tashkinov
2022-10-02 21:40 ` Willy Tarreau
2022-10-02 21:57 ` Artem S. Tashkinov
2022-10-02 14:48 ` Slade Watkins
2022-10-02 19:37 ` Artem S. Tashkinov
2022-10-02 21:11 ` Laurent Pinchart
2022-10-02 21:38 ` Artem S. Tashkinov
2022-10-02 15:05 ` Konstantin Ryabitsev
2022-10-02 19:43 ` Artem S. Tashkinov
2022-10-02 20:54 ` Willy Tarreau
2022-10-02 21:07 ` Artem S. Tashkinov
2022-10-02 21:32 ` Willy Tarreau
2022-10-02 21:53 ` Artem S. Tashkinov
2022-10-03 6:37 ` Geert Uytterhoeven
2022-10-03 7:49 ` Artem S. Tashkinov
2022-10-03 10:04 ` Willy Tarreau
2022-10-02 15:56 ` Al Viro
2022-10-02 17:22 ` Slade Watkins
2022-10-02 16:08 ` Geert Uytterhoeven
2022-10-02 16:10 ` Geert Uytterhoeven
2022-10-02 16:32 ` Joe Perches
2022-10-02 18:56 ` Joe Perches
2022-10-02 19:46 ` Artem S. Tashkinov
2022-10-02 17:57 ` Willy Tarreau
2022-10-02 19:55 ` Artem S. Tashkinov
2022-10-02 20:40 ` Willy Tarreau
2022-10-02 18:13 ` Steven Rostedt
2022-10-02 20:14 ` Artem S. Tashkinov
2022-10-02 22:08 ` Steven Rostedt
2022-10-02 22:20 ` Artem S. Tashkinov
2022-10-02 22:28 ` Steven Rostedt
2022-10-02 23:04 ` Al Viro
2022-10-02 23:21 ` Steven Rostedt
2022-10-03 7:41 ` Artem S. Tashkinov
2022-10-03 8:55 ` Mike Rapoport
2022-10-03 9:15 ` David Laight
2022-10-03 9:16 ` Artem S. Tashkinov
2022-10-03 9:26 ` Geert Uytterhoeven
2022-10-03 9:40 ` Artem S. Tashkinov
2022-10-03 10:26 ` Mike Rapoport
2022-10-03 14:20 ` Steven Rostedt
2022-10-03 18:24 ` Al Viro
2022-10-03 19:07 ` Steven Rostedt
2022-10-03 20:28 ` Slade Watkins
2022-10-04 12:16 ` Artem S. Tashkinov
2022-10-04 12:32 ` Geert Uytterhoeven
2022-10-04 22:45 ` Steven Rostedt
2022-10-03 14:22 ` Konstantin Ryabitsev
2022-10-04 12:21 ` Artem S. Tashkinov
2022-10-04 14:20 ` Konstantin Ryabitsev
2022-10-06 10:46 ` Artem S. Tashkinov
2022-10-06 19:29 ` Greg KH
2022-10-03 15:37 ` Konstantin Ryabitsev
2022-10-04 7:37 ` Thorsten Leemhuis
2022-10-04 7:56 ` Conor Dooley
2022-10-04 12:24 ` Artem S. Tashkinov
2022-10-04 14:48 ` Konstantin Ryabitsev
2022-10-02 20:41 ` Slade Watkins
2022-10-02 20:52 ` Slade Watkins
2022-10-02 21:06 ` Laurent Pinchart
2022-10-02 22:18 ` Steven Rostedt
2022-10-02 22:41 ` Laurent Pinchart
2022-10-02 23:59 ` Slade Watkins
2022-10-02 18:17 ` Geert Uytterhoeven
2022-10-02 20:17 ` Artem S. Tashkinov
2022-10-02 20:48 ` Willy Tarreau
2022-10-02 19:59 ` Laurent Pinchart
2022-10-02 20:19 ` Artem S. Tashkinov
2022-10-02 20:26 ` Laurent Pinchart
2022-10-02 13:25 ` Slade Watkins
2022-10-02 9:03 ` Geert Uytterhoeven
2022-10-02 9:06 ` Artem S. Tashkinov
2022-10-02 9:25 ` Geert Uytterhoeven
2022-10-02 7:37 ` Takashi Iwai
2022-10-02 8:23 ` Artem S. Tashkinov
2022-10-02 8:53 ` Geert Uytterhoeven
2022-10-02 9:14 ` Takashi Iwai [this message]
2022-10-03 10:10 ` Thorsten Leemhuis
2022-10-03 11:18 ` Slade Watkins
2022-10-03 12:59 ` Thorsten Leemhuis
2022-10-03 15:26 ` Steven Rostedt
2022-10-03 15:44 ` Laurent Pinchart
2022-10-03 15:51 ` Steven Rostedt
2022-10-03 15:59 ` Laurent Pinchart
2022-10-03 16:03 ` Steven Rostedt
2022-10-04 8:41 ` Thorsten Leemhuis
2022-10-04 9:20 ` Geert Uytterhoeven
2022-10-04 10:16 ` Thorsten Leemhuis
2022-10-04 10:45 ` Geert Uytterhoeven
2022-10-04 17:53 ` Konstantin Ryabitsev
2022-10-04 18:02 ` Greg KH
2022-10-04 18:13 ` Konstantin Ryabitsev
2022-10-04 18:03 ` Linus Torvalds
2022-10-04 18:11 ` Konstantin Ryabitsev
2022-10-04 19:21 ` Jani Nikula
2022-10-04 19:24 ` Konstantin Ryabitsev
2022-10-04 20:06 ` Thorsten Leemhuis
2022-10-04 20:25 ` Konstantin Ryabitsev
2022-10-05 9:00 ` Thorsten Leemhuis
2022-10-05 9:57 ` Hans de Goede
2022-10-12 16:12 ` Thorsten Leemhuis
2022-10-06 7:56 ` Artem S. Tashkinov
2022-10-17 13:57 ` Thorsten Leemhuis
2022-10-17 20:47 ` Konstantin Ryabitsev
2022-10-18 16:24 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h70mvb81.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=aros@gmx.com \
--cc=gregkh@linuxfoundation.org \
--cc=konstantin@linuxfoundation.org \
--cc=ksummit@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=regressions@lists.linux.dev \
--cc=torvalds@linux-foundation.org \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).