lkml.org 
[lkml]   [2018]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: small dmesg regression in kernel 4.17.3
Date


> -----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.

Thanks for reporting it,

Erik
>
> --
> With Best Regards,
> Andy Shevchenko
\
 
 \ /
  Last update: 2018-06-29 00:15    [W:0.100 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site