From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: "Schmauss, Erik" <erik.schmauss@intel.com>
Cc: "Andy Shevchenko" <andy.shevchenko@gmail.com>,
"Toralf Förster" <toralf.foerster@gmx.de>,
"Moore, Robert" <robert.moore@intel.com>,
"ACPI Devel Maling List" <linux-acpi@vger.kernel.org>,
"Linux Kernel" <linux-kernel@vger.kernel.org>,
"Guenter Roeck" <linux@roeck-us.net>
Subject: Re: small dmesg regression in kernel 4.17.3
Date: Fri, 29 Jun 2018 11:31:59 +0200 [thread overview]
Message-ID: <3440214.eqW5gfvlOh@aspire.rjw.lan> (raw)
In-Reply-To: <CF6A88132359CE47947DB4C6E1709ED53BB35DC6@ORSMSX110.amr.corp.intel.com>
On Friday, June 29, 2018 12:13:54 AM CEST Schmauss, Erik wrote:
>
> > -----Original Message-----
> > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > Sent: Wednesday, June 27, 2018 10:29 AM
> > To: Toralf Förster <toralf.foerster@gmx.de>; Schmauss, Erik
> > <erik.schmauss@intel.com>
> > Cc: ACPI Devel Maling List <linux-acpi@vger.kernel.org>; Linux Kernel <linux-
> > kernel@vger.kernel.org>
> > Subject: Re: small dmesg regression in kernel 4.17.3
> >
> > +Cc: Erik
> >
> > On Tue, Jun 26, 2018 at 8:57 PM, Toralf Förster <toralf.foerster@gmx.de>
> > wrote:
> > > The attached dmesg contains non printable chars 0x01 33 around "ACPI
> > > BIOS Error (bug): Could not resolve" which is a new issue compared to
> > > the dmesg of 4.17.2
> > >
> > > System is a stable hardened Gentoo Linux at a ThinkPad T440s.
> >
> > I bet the below commit makes this.
> >
> > commit 2e78935d1e27d31955ad2dad4abe6c453cf669fd
> > Author: Erik Schmauss <erik.schmauss@intel.com>
> > Date: Fri Jun 1 12:06:43 2018 -0700
> >
> > ACPICA: AML parser: attempt to continue loading table after error
> >
> >
> Hi Andy,
>
> > So, it does add leading '\n' which flushes buffers followed by printing the
> > message you see. But, I'm guessing now, kernel adds a default level since it's
> > going to dmesg which you can see as unprintable symbols.
>
> What do you mean by a default level?
>
> > Personally I'm not a fan of leading '\n':s since it brings more pain than fixing
> > something. It has special meaning (flushing buffers) and many developers forget
> > this.
>
> This leading '\n' made it in Linux kernel unintentionally. It was originally intended as a change for acpiexec and it makes the dmesg look strange. I'll send out a fix.
Which would be something like the patch below I suppose?
---
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Subject: [PATCH] ACPICA: Drop leading newlines from error messages
Commit 5088814a6e93 (ACPICA: AML parser: attempt to continue loading
table after error) unintentionally added leading newlines to error
messages emitted by ACPICA which caused unexpected things to be
printed to the kernel log. Drop these newlines (which effectively
reverts the part of commit 5088814a6e93 adding them).
Fixes: 5088814a6e93 (ACPICA: AML parser: attempt to continue loading table after error)
Reported-by: Toralf Förster <toralf.foerster@gmx.de>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/acpi/acpica/uterror.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-pm/drivers/acpi/acpica/uterror.c
===================================================================
--- linux-pm.orig/drivers/acpi/acpica/uterror.c
+++ linux-pm/drivers/acpi/acpica/uterror.c
@@ -182,19 +182,19 @@ acpi_ut_prefixed_namespace_error(const c
switch (lookup_status) {
case AE_ALREADY_EXISTS:
- acpi_os_printf("\n" ACPI_MSG_BIOS_ERROR);
+ acpi_os_printf(ACPI_MSG_BIOS_ERROR);
message = "Failure creating";
break;
case AE_NOT_FOUND:
- acpi_os_printf("\n" ACPI_MSG_BIOS_ERROR);
+ acpi_os_printf(ACPI_MSG_BIOS_ERROR);
message = "Could not resolve";
break;
default:
- acpi_os_printf("\n" ACPI_MSG_ERROR);
+ acpi_os_printf(ACPI_MSG_ERROR);
message = "Failure resolving";
break;
}
next prev parent reply other threads:[~2018-06-29 9:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-26 17:57 Toralf Förster
2018-06-27 17:28 ` Andy Shevchenko
2018-06-28 22:13 ` Schmauss, Erik
2018-06-29 9:31 ` Rafael J. Wysocki [this message]
2018-06-29 17:40 ` Schmauss, Erik
2018-06-29 10:43 ` Andy Shevchenko
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=3440214.eqW5gfvlOh@aspire.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=andy.shevchenko@gmail.com \
--cc=erik.schmauss@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=robert.moore@intel.com \
--cc=toralf.foerster@gmx.de \
/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
all inboxes | Powered by JetHome®