Messages in this thread | | | From | "Schmauss, Erik" <> | Subject | RE: small dmesg regression in kernel 4.17.3 | Date | Thu, 28 Jun 2018 22:13:54 +0000 |
| |
> -----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
| |