Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp580538imm; Fri, 29 Jun 2018 02:59:24 -0700 (PDT) X-Google-Smtp-Source: AAOMgpf3t2l5byBsKSOIuZfkZrMkUUKOKmtDAn6CMO3jvTelrzGJv+0jF/sXKf2pSxPSzvLKauim X-Received: by 2002:a65:5245:: with SMTP id q5-v6mr1238207pgp.67.1530266364724; Fri, 29 Jun 2018 02:59:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530266364; cv=none; d=google.com; s=arc-20160816; b=eVza15LD85F74r0lJxs5RSFXSCd3trAhnT4JDEkXMos0U7pK6+xOpztCnsP+BHuHH0 FxKwLsOOv6CnYl9+Sz8a9DdNWVIGcOfMMU0a9psNFln/6CBbnKsAO196Q/0ZVpHPIPO2 il14yWeMM8dISKmpcMUjcCNjKDaL2CPbeDaVMB3wC46eRTjsD3hxpk3AJE0vZRDr/SeG kK7EMGB8xqqHkzx3vAxvK9dZ5iSV3206YthyH2sQLnt8fBom45d+bSyoEg0NALBdF0bG A3l+5b2fhl8yl+jWbsXZDiyPnvRZj4aJGdNfxVxbJrKhbF8d5Oj9OunvW+hb0obL5xWd yT4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=D3EnZySYzZyxfeAQRMpTv00LkFftKZcb3hLWQwQuljM=; b=JsW8cPFBA+BVMsk9LESGPKdPTTzayUuwEa8JQ1NyUFZuInknuPnNDg2ca4EHH6hk7X 5tUJPutt3AqZR3Oa1vi88Xj0Ks68tDNyDO/xr+OUXK+OBQ8d4UsJMIUP58F21GB6W1sq Wp3HFRtrNmCuyJG1EujphxZYE5DzMp54EBlCDBFfzQaif/vORHd5USD2p9zuy4csJb8I UhXDspIZcIjIsvnDGe7HO+n1eek1R0wnfK2tnzGZgGpRxYC07fqkAJiY2nHdMdgret0g jQm/qoQsTZIujqb61Lzm7ZgJqihRTr5uSsooWQSOIbf2sEdwJGY5sdE6i8jO1KZ9EdME L/Kw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si2703637pfv.135.2018.06.29.02.59.10; Fri, 29 Jun 2018 02:59:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935637AbeF2JdV convert rfc822-to-8bit (ORCPT + 99 others); Fri, 29 Jun 2018 05:33:21 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:54520 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935602AbeF2JdU (ORCPT ); Fri, 29 Jun 2018 05:33:20 -0400 Received: from 79.184.253.185.ipv4.supernova.orange.pl (79.184.253.185) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83) id 7f30c14fcd3324ef; Fri, 29 Jun 2018 11:33:18 +0200 From: "Rafael J. Wysocki" To: "Schmauss, Erik" Cc: Andy Shevchenko , Toralf =?ISO-8859-1?Q?F=F6rster?= , "Moore, Robert" , ACPI Devel Maling List , Linux Kernel , Guenter Roeck Subject: Re: small dmesg regression in kernel 4.17.3 Date: Fri, 29 Jun 2018 11:31:59 +0200 Message-ID: <3440214.eqW5gfvlOh@aspire.rjw.lan> In-Reply-To: References: <8837a9e2-e614-e2bf-ed32-6d49de4dd4ed@gmx.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 ; Schmauss, Erik > > > > Cc: ACPI Devel Maling List ; Linux Kernel > 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 > > 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 > > 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 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 Reported-by: Guenter Roeck Signed-off-by: Rafael J. Wysocki --- 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; }