[PATCH 0/4] Drop uninformative messages from bootlog

[PATCH 0/4] Drop uninformative messages from bootlog

[Punit Agrawal]

Hi,

While booting v4.13-rc1 on an arm64 system, I noticed some messages
that clutter the boot log without providing any useful
information. This series trims some of the obvious offenders.

The patches are spread across a few sub-systems - arm64/mm, mailbox,
APEI and xen, and can be independently merged.

Thanks,
Punit


Punit Agrawal (4):
  arm64/numa: Drop duplicate message
  mailbox: pcc: Drop uninformative output during boot
  ACPI / APEI: Drop uninformative messages during boot
  xen: Drop un-informative message during boot

 arch/arm64/mm/numa.c      | 7 +------
 drivers/acpi/apei/ghes.c  | 9 +--------
 drivers/mailbox/pcc.c     | 4 +---
 drivers/xen/xenfs/super.c | 1 -
 4 files changed, 3 insertions(+), 18 deletions(-)

-- 
2.11.0

[PATCH 0/4] Drop uninformative messages from bootlog

[Punit Agrawal]

Hi,

While booting v4.13-rc1 on an arm64 system, I noticed some messages
that clutter the boot log without providing any useful
information. This series trims some of the obvious offenders.

The patches are spread across a few sub-systems - arm64/mm, mailbox,
APEI and xen, and can be independently merged.

Thanks,
Punit


Punit Agrawal (4):
  arm64/numa: Drop duplicate message
  mailbox: pcc: Drop uninformative output during boot
  ACPI / APEI: Drop uninformative messages during boot
  xen: Drop un-informative message during boot

 arch/arm64/mm/numa.c      | 7 +------
 drivers/acpi/apei/ghes.c  | 9 +--------
 drivers/mailbox/pcc.c     | 4 +---
 drivers/xen/xenfs/super.c | 1 -
 4 files changed, 3 insertions(+), 18 deletions(-)

-- 
2.11.0

[PATCH 1/4] arm64/numa: Drop duplicate message

[Punit Agrawal]

When booting linux on a system without CONFIG_NUMA enabled, the
following messages are printed during boot -

NUMA: Faking a node at [mem 0x0000000000000000-0x00000083ffffffff]
NUMA: Adding memblock [0x8000000000 - 0x8000e7ffff] on node 0
NUMA: Adding memblock [0x8000e80000 - 0x83f65cffff] on node 0
NUMA: Adding memblock [0x83f65d0000 - 0x83f665ffff] on node 0
NUMA: Adding memblock [0x83f6660000 - 0x83f676ffff] on node 0
NUMA: Adding memblock [0x83f6770000 - 0x83f678ffff] on node 0
NUMA: Adding memblock [0x83f6790000 - 0x83fb82ffff] on node 0
NUMA: Adding memblock [0x83fb830000 - 0x83fbc0ffff] on node 0
NUMA: Adding memblock [0x83fbc10000 - 0x83fbdfffff] on node 0
NUMA: Adding memblock [0x83fbe00000 - 0x83fbffffff] on node 0
NUMA: Adding memblock [0x83fc000000 - 0x83fffbffff] on node 0
NUMA: Adding memblock [0x83fffc0000 - 0x83fffdffff] on node 0
NUMA: Adding memblock [0x83fffe0000 - 0x83ffffffff] on node 0
NUMA: Initmem setup node 0 [mem 0x8000000000-0x83ffffffff]
NUMA: NODE_DATA [mem 0x83fffec500-0x83fffedfff]

The information is then duplicated by core kernel messages right after
the above output.

Early memory node ranges
  node   0: [mem 0x0000008000000000-0x0000008000e7ffff]
  node   0: [mem 0x0000008000e80000-0x00000083f65cffff]
  node   0: [mem 0x00000083f65d0000-0x00000083f665ffff]
  node   0: [mem 0x00000083f6660000-0x00000083f676ffff]
  node   0: [mem 0x00000083f6770000-0x00000083f678ffff]
  node   0: [mem 0x00000083f6790000-0x00000083fb82ffff]
  node   0: [mem 0x00000083fb830000-0x00000083fbc0ffff]
  node   0: [mem 0x00000083fbc10000-0x00000083fbdfffff]
  node   0: [mem 0x00000083fbe00000-0x00000083fbffffff]
  node   0: [mem 0x00000083fc000000-0x00000083fffbffff]
  node   0: [mem 0x00000083fffc0000-0x00000083fffdffff]
  node   0: [mem 0x00000083fffe0000-0x00000083ffffffff]
Initmem setup node 0 [mem 0x0000008000000000-0x00000083ffffffff]

Remove the duplication of memblock layout information printed during
boot by dropping the messages from arm64 numa initialisation.

Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
 arch/arm64/mm/numa.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index b388a99fea7b..dad128ba98bf 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -208,8 +208,6 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
 	}
 
 	node_set(nid, numa_nodes_parsed);
-	pr_info("Adding memblock [0x%llx - 0x%llx] on node %d\n",
-			start, (end - 1), nid);
 	return ret;
 }
 
@@ -223,10 +221,7 @@ static void __init setup_node_data(int nid, u64 start_pfn, u64 end_pfn)
 	void *nd;
 	int tnid;
 
-	if (start_pfn < end_pfn)
-		pr_info("Initmem setup node %d [mem %#010Lx-%#010Lx]\n", nid,
-			start_pfn << PAGE_SHIFT, (end_pfn << PAGE_SHIFT) - 1);
-	else
+	if (start_pfn >= end_pfn)
 		pr_info("Initmem setup node %d [<memory-less node>]\n", nid);
 
 	nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
-- 
2.11.0

[PATCH 1/4] arm64/numa: Drop duplicate message

[Punit Agrawal]

When booting linux on a system without CONFIG_NUMA enabled, the
following messages are printed during boot -

NUMA: Faking a node at [mem 0x0000000000000000-0x00000083ffffffff]
NUMA: Adding memblock [0x8000000000 - 0x8000e7ffff] on node 0
NUMA: Adding memblock [0x8000e80000 - 0x83f65cffff] on node 0
NUMA: Adding memblock [0x83f65d0000 - 0x83f665ffff] on node 0
NUMA: Adding memblock [0x83f6660000 - 0x83f676ffff] on node 0
NUMA: Adding memblock [0x83f6770000 - 0x83f678ffff] on node 0
NUMA: Adding memblock [0x83f6790000 - 0x83fb82ffff] on node 0
NUMA: Adding memblock [0x83fb830000 - 0x83fbc0ffff] on node 0
NUMA: Adding memblock [0x83fbc10000 - 0x83fbdfffff] on node 0
NUMA: Adding memblock [0x83fbe00000 - 0x83fbffffff] on node 0
NUMA: Adding memblock [0x83fc000000 - 0x83fffbffff] on node 0
NUMA: Adding memblock [0x83fffc0000 - 0x83fffdffff] on node 0
NUMA: Adding memblock [0x83fffe0000 - 0x83ffffffff] on node 0
NUMA: Initmem setup node 0 [mem 0x8000000000-0x83ffffffff]
NUMA: NODE_DATA [mem 0x83fffec500-0x83fffedfff]

The information is then duplicated by core kernel messages right after
the above output.

Early memory node ranges
  node   0: [mem 0x0000008000000000-0x0000008000e7ffff]
  node   0: [mem 0x0000008000e80000-0x00000083f65cffff]
  node   0: [mem 0x00000083f65d0000-0x00000083f665ffff]
  node   0: [mem 0x00000083f6660000-0x00000083f676ffff]
  node   0: [mem 0x00000083f6770000-0x00000083f678ffff]
  node   0: [mem 0x00000083f6790000-0x00000083fb82ffff]
  node   0: [mem 0x00000083fb830000-0x00000083fbc0ffff]
  node   0: [mem 0x00000083fbc10000-0x00000083fbdfffff]
  node   0: [mem 0x00000083fbe00000-0x00000083fbffffff]
  node   0: [mem 0x00000083fc000000-0x00000083fffbffff]
  node   0: [mem 0x00000083fffc0000-0x00000083fffdffff]
  node   0: [mem 0x00000083fffe0000-0x00000083ffffffff]
Initmem setup node 0 [mem 0x0000008000000000-0x00000083ffffffff]

Remove the duplication of memblock layout information printed during
boot by dropping the messages from arm64 numa initialisation.

Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
 arch/arm64/mm/numa.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index b388a99fea7b..dad128ba98bf 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -208,8 +208,6 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
 	}
 
 	node_set(nid, numa_nodes_parsed);
-	pr_info("Adding memblock [0x%llx - 0x%llx] on node %d\n",
-			start, (end - 1), nid);
 	return ret;
 }
 
@@ -223,10 +221,7 @@ static void __init setup_node_data(int nid, u64 start_pfn, u64 end_pfn)
 	void *nd;
 	int tnid;
 
-	if (start_pfn < end_pfn)
-		pr_info("Initmem setup node %d [mem %#010Lx-%#010Lx]\n", nid,
-			start_pfn << PAGE_SHIFT, (end_pfn << PAGE_SHIFT) - 1);
-	else
+	if (start_pfn >= end_pfn)
 		pr_info("Initmem setup node %d [<memory-less node>]\n", nid);
 
 	nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
-- 
2.11.0

[PATCH 2/4] mailbox: pcc: Drop uninformative output during boot

[Punit Agrawal]

When booting on an ACPI enabled system that does not provide the
Platform Communications Channel Table (PCCT), the pcc mailbox driver
prints -

[    0.484261] PCCT header not found.

during probe before returning -ENODEV.

This message clutters the bootlog and doesn't provide any useful
information. Drop this message.

Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
---
 drivers/mailbox/pcc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index ac91fd0d62c6..3d83cdc11ab5 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -457,10 +457,8 @@ static int __init acpi_pcc_probe(void)
 	/* Search for PCCT */
 	status = acpi_get_table(ACPI_SIG_PCCT, 0, &pcct_tbl);
 
-	if (ACPI_FAILURE(status) || !pcct_tbl) {
-		pr_warn("PCCT header not found.\n");
+	if (ACPI_FAILURE(status) || !pcct_tbl)
 		return -ENODEV;
-	}
 
 	count = acpi_table_parse_entries(ACPI_SIG_PCCT,
 			sizeof(struct acpi_table_pcct),
-- 
2.11.0

Re: [PATCH 2/4] mailbox: pcc: Drop uninformative output during boot

[Jassi Brar]

[CC'ing Rafael J. Wysocki, who picks patches for pcc.c]

On Mon, Jul 31, 2017 at 3:22 PM, Punit Agrawal <punit.agrawal@arm.com> wrote:
> Punit Agrawal <punit.agrawal@arm.com> writes:
>
>> When booting on an ACPI enabled system that does not provide the
>> Platform Communications Channel Table (PCCT), the pcc mailbox driver
>> prints -
>>
>> [    0.484261] PCCT header not found.
>>
>> during probe before returning -ENODEV.
>>
>> This message clutters the bootlog and doesn't provide any useful
>> information. Drop this message.
>>
>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>> Cc: Jassi Brar <jassisinghbrar@gmail.com>
>> ---
>>  drivers/mailbox/pcc.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
>> index ac91fd0d62c6..3d83cdc11ab5 100644
>> --- a/drivers/mailbox/pcc.c
>> +++ b/drivers/mailbox/pcc.c
>> @@ -457,10 +457,8 @@ static int __init acpi_pcc_probe(void)
>>       /* Search for PCCT */
>>       status = acpi_get_table(ACPI_SIG_PCCT, 0, &pcct_tbl);
>>
>> -     if (ACPI_FAILURE(status) || !pcct_tbl) {
>> -             pr_warn("PCCT header not found.\n");
>> +     if (ACPI_FAILURE(status) || !pcct_tbl)
>>               return -ENODEV;
>> -     }
>>
>>       count = acpi_table_parse_entries(ACPI_SIG_PCCT,
>>                       sizeof(struct acpi_table_pcct),
>
> Ping! Any comments/concerns with dropping the message?
>
> Thanks.

Re: [PATCH 2/4] mailbox: pcc: Drop uninformative output during boot

[Alexey Klimov]

(keeping Rafael in c/c per Jassi suggestion)

On Thu, Jul 20, 2017 at 12:04 PM, Punit Agrawal <punit.agrawal@arm.com> wrote:
> When booting on an ACPI enabled system that does not provide the
> Platform Communications Channel Table (PCCT), the pcc mailbox driver
> prints -
> 
> [    0.484261] PCCT header not found.

Ah. I thought this was already removed ages ago. Thanks for removing this.
 
> during probe before returning -ENODEV.
> 
> This message clutters the bootlog and doesn't provide any useful
> information. Drop this message.
> 
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>

Acked-by: Alexey Klimov <alexey.klimov@arm.com>

Re: [PATCH 2/4] mailbox: pcc: Drop uninformative output during boot

[Rafael J. Wysocki]

On 7/31/2017 7:47 PM, Alexey Klimov wrote:
> (keeping Rafael in c/c per Jassi suggestion)
>
> On Thu, Jul 20, 2017 at 12:04 PM, Punit Agrawal <punit.agrawal@arm.com> wrote:
>> When booting on an ACPI enabled system that does not provide the
>> Platform Communications Channel Table (PCCT), the pcc mailbox driver
>> prints -
>>
>> [    0.484261] PCCT header not found.
> Ah. I thought this was already removed ages ago. Thanks for removing this.
>   
>> during probe before returning -ENODEV.
>>
>> This message clutters the bootlog and doesn't provide any useful
>> information. Drop this message.
>>
>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Acked-by: Alexey Klimov <alexey.klimov@arm.com>
>
Please resend this, including all applicable tags, with a CC to 
linux-acpi@vger.kernel.org for easier processing.

Thanks,

Rafael

Re: [PATCH 2/4] mailbox: pcc: Drop uninformative output during boot

[Punit Agrawal]

"Rafael J. Wysocki" <rafael.j.wysocki@intel.com> writes:

> On 7/31/2017 7:47 PM, Alexey Klimov wrote:
>> (keeping Rafael in c/c per Jassi suggestion)
>>
>> On Thu, Jul 20, 2017 at 12:04 PM, Punit Agrawal <punit.agrawal@arm.com> wrote:
>>> When booting on an ACPI enabled system that does not provide the
>>> Platform Communications Channel Table (PCCT), the pcc mailbox driver
>>> prints -
>>>
>>> [    0.484261] PCCT header not found.
>> Ah. I thought this was already removed ages ago. Thanks for removing this.
>>   
>>> during probe before returning -ENODEV.
>>>
>>> This message clutters the bootlog and doesn't provide any useful
>>> information. Drop this message.
>>>
>>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>>> Cc: Jassi Brar <jassisinghbrar@gmail.com>
>> Acked-by: Alexey Klimov <alexey.klimov@arm.com>
>>
> Please resend this, including all applicable tags, with a CC to
> linux-acpi@vger.kernel.org for easier processing.

Thanks Jassi for adding the appropriate folks on this
patch. get_maintainer.pl threw me off on this one. ;)

I'll add the tags (Thanks, Alexey) and re-send.

>
> Thanks,
>
> Rafael

[PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

[Punit Agrawal]

When booting an ACPI enabled system that does not provide the hardware
error source table (HEST), the ghes driver prints the following message
in the kernel log -

[    3.460067] GHES: HEST is not enabled!

which is not helpful.

The message is also output when HEST is explicitly disabled using kernel
command line parameter.

Drop this message. While we are touching this code, also drop similar
message when GHES is disabled using the module parameter.

Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Borislav Petkov <bp@suse.de>
---
 drivers/acpi/apei/ghes.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index d661d452b238..3ddd1bd714fc 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -1265,15 +1265,8 @@ static int __init ghes_init(void)
 	if (acpi_disabled)
 		return -ENODEV;
 
-	if (hest_disable) {
-		pr_info(GHES_PFX "HEST is not enabled!\n");
+	if (hest_disable || ghes_disable)
 		return -EINVAL;
-	}
-
-	if (ghes_disable) {
-		pr_info(GHES_PFX "GHES is not enabled!\n");
-		return -EINVAL;
-	}
 
 	ghes_nmi_init_cxt();
 
-- 
2.11.0

Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

[Borislav Petkov]

On Thu, Jul 20, 2017 at 12:04:01PM +0100, Punit Agrawal wrote:
> When booting an ACPI enabled system that does not provide the hardware
> error source table (HEST), the ghes driver prints the following message
> in the kernel log -
> 
> [    3.460067] GHES: HEST is not enabled!
> 
> which is not helpful.
> 
> The message is also output when HEST is explicitly disabled using kernel
> command line parameter.
> 
> Drop this message. While we are touching this code, also drop similar
> message when GHES is disabled using the module parameter.

No.

To the contrary, we want to know *why* GHES/HEST doesn't get enabled when
booting. See

  dba648300e89 ("ACPI / einj: Make error paths more talkative")

for a good example why.

If anything, you should do the total opposite patch and add more
printks to the error paths so that it is obvious why GHES startup fails.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

[Punit Agrawal]

Hi Borislav,

Borislav Petkov <bp@suse.de> writes:

> On Thu, Jul 20, 2017 at 12:04:01PM +0100, Punit Agrawal wrote:
>> When booting an ACPI enabled system that does not provide the hardware
>> error source table (HEST), the ghes driver prints the following message
>> in the kernel log -
>> 
>> [    3.460067] GHES: HEST is not enabled!
>> 
>> which is not helpful.
>> 
>> The message is also output when HEST is explicitly disabled using kernel
>> command line parameter.
>> 
>> Drop this message. While we are touching this code, also drop similar
>> message when GHES is disabled using the module parameter.
>
> No.
>
> To the contrary, we want to know *why* GHES/HEST doesn't get enabled when
> booting. See
>
>   dba648300e89 ("ACPI / einj: Make error paths more talkative")
>
> for a good example why.

einj verbosity can't be used as a model here. einj by it's definition is
for development and testing. It can also be loaded as a module.

>
> If anything, you should do the total opposite patch and add more
>printks to the error paths so that it is obvious why GHES startup
>fails.

As mentioned in the commit log, the platform doesn't provide the HEST
(or any of the APEI tables for that matter). So it's not useful to see a
message complaining that HEST is not enabled. For such platforms, this
message at best adds no value and at worse gives the impression of
something gone wrong during boot.

I agree that where there is a genuine problem, relevant messages can
help to diagnose the problem. But what's printed now doesn't fit the
criteria.

Hope that makes sense.

Thanks,
Punit

>
> -- Regards/Gruss, Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

[Punit Agrawal]

Hi Borislav,

Borislav Petkov <bp@suse.de> writes:

> On Thu, Jul 20, 2017 at 12:04:01PM +0100, Punit Agrawal wrote:
>> When booting an ACPI enabled system that does not provide the hardware
>> error source table (HEST), the ghes driver prints the following message
>> in the kernel log -
>> 
>> [    3.460067] GHES: HEST is not enabled!
>> 
>> which is not helpful.
>> 
>> The message is also output when HEST is explicitly disabled using kernel
>> command line parameter.
>> 
>> Drop this message. While we are touching this code, also drop similar
>> message when GHES is disabled using the module parameter.
>
> No.
>
> To the contrary, we want to know *why* GHES/HEST doesn't get enabled when
> booting. See
>
>   dba648300e89 ("ACPI / einj: Make error paths more talkative")
>
> for a good example why.

einj verbosity can't be used as a model here. einj by it's definition is
for development and testing. It can also be loaded as a module.

>
> If anything, you should do the total opposite patch and add more
>printks to the error paths so that it is obvious why GHES startup
>fails.

As mentioned in the commit log, the platform doesn't provide the HEST
(or any of the APEI tables for that matter). So it's not useful to see a
message complaining that HEST is not enabled. For such platforms, this
message at best adds no value and at worse gives the impression of
something gone wrong during boot.

I agree that where there is a genuine problem, relevant messages can
help to diagnose the problem. But what's printed now doesn't fit the
criteria.

Hope that makes sense.

Thanks,
Punit

>
> -- Regards/Gruss, Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

[Borislav Petkov]

On Thu, Jul 20, 2017 at 01:29:17PM +0100, Punit Agrawal wrote:
> I agree that where there is a genuine problem, relevant messages can
> help to diagnose the problem. But what's printed now doesn't fit the
> criteria.

So make it fit the criteria. Change the code to not issue that message
when the platform doesn't have those tables. But keep it in the
remaining cases, when the tables are there.

You can't be removing useful error messages just because your platform
doesn't have the tables.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

[Punit Agrawal]

Borislav Petkov <bp@suse.de> writes:

> On Thu, Jul 20, 2017 at 01:29:17PM +0100, Punit Agrawal wrote:
>> I agree that where there is a genuine problem, relevant messages can
>> help to diagnose the problem. But what's printed now doesn't fit the
>> criteria.
>
> So make it fit the criteria. Change the code to not issue that message
> when the platform doesn't have those tables. But keep it in the
> remaining cases, when the tables are there.
>
> You can't be removing useful error messages just because your platform
> doesn't have the tables.

Fair point! I'll focus on quiescing the messages when the tables are not
present.

Inspired by your suggestion, I tried the following diff instead of
$SUBJECT.

diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
index 456b488eb1df..f7784d9514e1 100644
--- a/drivers/acpi/apei/hest.c
+++ b/drivers/acpi/apei/hest.c
@@ -233,8 +233,9 @@ void __init acpi_hest_init(void)
        status = acpi_get_table(ACPI_SIG_HEST, 0,
                                (struct acpi_table_header **)&hest_tab);
        if (status == AE_NOT_FOUND)
-           goto err;
-   else if (ACPI_FAILURE(status)) {
+         return;
+
+ if (ACPI_FAILURE(status)) {
                const char *msg = acpi_format_exception(status);
                pr_err(HEST_PFX "Failed to get table, %s\n", msg);
                rc = -EINVAL;

This landed me a new message not seen before -

[    3.232940] GHES: Failed to enable APEI firmware first mode.

On further digging, this message is printed on platforms not supporting
the legacy WHEA stuff, when the APEI Support bit is not set in the
platform wide _OSC capabilities.

To make this message a bit less alarming, I can modify it to something
like -

"Firmware does not support APEI firmware first mode"

Thoughts?

Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

[Punit Agrawal]

Borislav Petkov <bp@suse.de> writes:

> On Thu, Jul 20, 2017 at 01:29:17PM +0100, Punit Agrawal wrote:
>> I agree that where there is a genuine problem, relevant messages can
>> help to diagnose the problem. But what's printed now doesn't fit the
>> criteria.
>
> So make it fit the criteria. Change the code to not issue that message
> when the platform doesn't have those tables. But keep it in the
> remaining cases, when the tables are there.
>
> You can't be removing useful error messages just because your platform
> doesn't have the tables.

Fair point! I'll focus on quiescing the messages when the tables are not
present.

Inspired by your suggestion, I tried the following diff instead of
$SUBJECT.

diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
index 456b488eb1df..f7784d9514e1 100644
--- a/drivers/acpi/apei/hest.c
+++ b/drivers/acpi/apei/hest.c
@@ -233,8 +233,9 @@ void __init acpi_hest_init(void)
        status = acpi_get_table(ACPI_SIG_HEST, 0,
                                (struct acpi_table_header **)&hest_tab);
        if (status == AE_NOT_FOUND)
-           goto err;
-   else if (ACPI_FAILURE(status)) {
+         return;
+
+ if (ACPI_FAILURE(status)) {
                const char *msg = acpi_format_exception(status);
                pr_err(HEST_PFX "Failed to get table, %s\n", msg);
                rc = -EINVAL;

This landed me a new message not seen before -

[    3.232940] GHES: Failed to enable APEI firmware first mode.

On further digging, this message is printed on platforms not supporting
the legacy WHEA stuff, when the APEI Support bit is not set in the
platform wide _OSC capabilities.

To make this message a bit less alarming, I can modify it to something
like -

"Firmware does not support APEI firmware first mode"

Thoughts?

Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

[Borislav Petkov]

On Thu, Jul 20, 2017 at 06:50:51PM +0100, Punit Agrawal wrote:
> "Firmware does not support APEI firmware first mode"
> 
> Thoughts?

I guess the simplest would be to add a third state to that hest_disable
to denote "HEST table not found" and then exit ghes_init() early, based on
checking it.

Otherwise ghes_init() inits a bunch of things which you probably don't
want on a platform which doesn't support APEI.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

[Punit Agrawal]

Hi Boris,

Apologies for the delayed response. I somehow managed to lose updates on
this thread.

Borislav Petkov <bp@suse.de> writes:

> On Thu, Jul 20, 2017 at 06:50:51PM +0100, Punit Agrawal wrote:
>> "Firmware does not support APEI firmware first mode"
>> 
>> Thoughts?
>
> I guess the simplest would be to add a third state to that hest_disable
> to denote "HEST table not found" and then exit ghes_init() early, based on
> checking it.

Although simple, won't it make the already convoluted code flow more
so. Instead in addition to not setting hest_disable when the table is
not found ...

>
> Otherwise ghes_init() inits a bunch of things which you probably don't
> want on a platform which doesn't support APEI.

... would you be open to a patch re-working the ghes driver
initialisation to only do the platform driver registration. The the rest
of the initialisation (including the apei_osc_setup and related
messages) can be performed when the first ghes device gets probed.

Does that sound like a better alternative?

>
> -- 
> Regards/Gruss,
>     Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

[Borislav Petkov]

On Thu, Jul 27, 2017 at 10:35:45AM +0100, Punit Agrawal wrote:
> ... would you be open to a patch re-working the ghes driver
> initialisation to only do the platform driver registration. The the rest
> of the initialisation (including the apei_osc_setup and related
> messages) can be performed when the first ghes device gets probed.
> 
> Does that sound like a better alternative?

If you split it by doing one logical change per patch so that it is
obvious what's going on and you don't break existing usage, I don't see
why not.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

[Punit Agrawal]

Borislav Petkov <bp@suse.de> writes:

> On Thu, Jul 27, 2017 at 10:35:45AM +0100, Punit Agrawal wrote:
>> ... would you be open to a patch re-working the ghes driver
>> initialisation to only do the platform driver registration. The the rest
>> of the initialisation (including the apei_osc_setup and related
>> messages) can be performed when the first ghes device gets probed.
>> 
>> Does that sound like a better alternative?
>
> If you split it by doing one logical change per patch so that it is
> obvious what's going on and you don't break existing usage, I don't see
> why not.

Good! I'll try and get the patches out in the next few days.

Thanks.

>
> -- 
> Regards/Gruss,
>     Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

[PATCH 4/4] xen: Drop un-informative message during boot

[Punit Agrawal]

On systems that are not booted as a Xen domain, the xenfs driver prints
the following message during boot.

[    3.460595] xenfs: not registering filesystem on non-xen platform

As the user chose not to boot a Xen domain, this message does not
provide useful information. Drop this message.

Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
---
 drivers/xen/xenfs/super.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 967f069385d0..71ddfb4cf61c 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -87,7 +87,6 @@ static int __init xenfs_init(void)
 	if (xen_domain())
 		return register_filesystem(&xenfs_type);
 
-	pr_info("not registering filesystem on non-xen platform\n");
 	return 0;
 }
 
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH 4/4] xen: Drop un-informative message during boot

[Punit Agrawal]

On systems that are not booted as a Xen domain, the xenfs driver prints
the following message during boot.

[    3.460595] xenfs: not registering filesystem on non-xen platform

As the user chose not to boot a Xen domain, this message does not
provide useful information. Drop this message.

Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
---
 drivers/xen/xenfs/super.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 967f069385d0..71ddfb4cf61c 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -87,7 +87,6 @@ static int __init xenfs_init(void)
 	if (xen_domain())
 		return register_filesystem(&xenfs_type);
 
-	pr_info("not registering filesystem on non-xen platform\n");
 	return 0;
 }
 
-- 
2.11.0

Re: [PATCH 4/4] xen: Drop un-informative message during boot

[Boris Ostrovsky]

On 07/20/2017 07:04 AM, Punit Agrawal wrote:
> On systems that are not booted as a Xen domain, the xenfs driver prints
> the following message during boot.
>
> [    3.460595] xenfs: not registering filesystem on non-xen platform
>
> As the user chose not to boot a Xen domain, this message does not
> provide useful information. Drop this message.
>
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Re: [PATCH 4/4] xen: Drop un-informative message during boot

[Punit Agrawal]

Boris Ostrovsky <boris.ostrovsky@oracle.com> writes:

> On 07/20/2017 07:04 AM, Punit Agrawal wrote:
>> On systems that are not booted as a Xen domain, the xenfs driver prints
>> the following message during boot.
>>
>> [    3.460595] xenfs: not registering filesystem on non-xen platform
>>
>> As the user chose not to boot a Xen domain, this message does not
>> provide useful information. Drop this message.
>>
>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Cc: Juergen Gross <jgross@suse.com>
>
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Thanks Boris.

Juergen, I assume you'll pick this up for the next round of xen
updates.

>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/4] xen: Drop un-informative message during boot

[Punit Agrawal]

Boris Ostrovsky <boris.ostrovsky@oracle.com> writes:

> On 07/20/2017 07:04 AM, Punit Agrawal wrote:
>> On systems that are not booted as a Xen domain, the xenfs driver prints
>> the following message during boot.
>>
>> [    3.460595] xenfs: not registering filesystem on non-xen platform
>>
>> As the user chose not to boot a Xen domain, this message does not
>> provide useful information. Drop this message.
>>
>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Cc: Juergen Gross <jgross@suse.com>
>
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Thanks Boris.

Juergen, I assume you'll pick this up for the next round of xen
updates.

>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

Re: [PATCH 4/4] xen: Drop un-informative message during boot

[Juergen Gross]

On 21/07/17 12:12, Punit Agrawal wrote:
> Boris Ostrovsky <boris.ostrovsky@oracle.com> writes:
> 
>> On 07/20/2017 07:04 AM, Punit Agrawal wrote:
>>> On systems that are not booted as a Xen domain, the xenfs driver prints
>>> the following message during boot.
>>>
>>> [    3.460595] xenfs: not registering filesystem on non-xen platform
>>>
>>> As the user chose not to boot a Xen domain, this message does not
>>> provide useful information. Drop this message.
>>>
>>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> Cc: Juergen Gross <jgross@suse.com>
>>
>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> 
> Thanks Boris.
> 
> Juergen, I assume you'll pick this up for the next round of xen
> updates.

Yes, probably for rc3 or rc4. For rc2 it was a liitle bit late and
there is no need to hurry.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/4] xen: Drop un-informative message during boot

[Juergen Gross]

On 21/07/17 12:12, Punit Agrawal wrote:
> Boris Ostrovsky <boris.ostrovsky@oracle.com> writes:
> 
>> On 07/20/2017 07:04 AM, Punit Agrawal wrote:
>>> On systems that are not booted as a Xen domain, the xenfs driver prints
>>> the following message during boot.
>>>
>>> [    3.460595] xenfs: not registering filesystem on non-xen platform
>>>
>>> As the user chose not to boot a Xen domain, this message does not
>>> provide useful information. Drop this message.
>>>
>>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> Cc: Juergen Gross <jgross@suse.com>
>>
>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> 
> Thanks Boris.
> 
> Juergen, I assume you'll pick this up for the next round of xen
> updates.

Yes, probably for rc3 or rc4. For rc2 it was a liitle bit late and
there is no need to hurry.


Juergen

Re: [Xen-devel] [PATCH 4/4] xen: Drop un-informative message during boot

[Punit Agrawal]

Juergen Gross <jgross@suse.com> writes:

> On 21/07/17 12:12, Punit Agrawal wrote:
>> Boris Ostrovsky <boris.ostrovsky@oracle.com> writes:
>> 
>>> On 07/20/2017 07:04 AM, Punit Agrawal wrote:
>>>> On systems that are not booted as a Xen domain, the xenfs driver prints
>>>> the following message during boot.
>>>>
>>>> [    3.460595] xenfs: not registering filesystem on non-xen platform
>>>>
>>>> As the user chose not to boot a Xen domain, this message does not
>>>> provide useful information. Drop this message.
>>>>
>>>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>> Cc: Juergen Gross <jgross@suse.com>
>>>
>>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> 
>> Thanks Boris.
>> 
>> Juergen, I assume you'll pick this up for the next round of xen
>> updates.
>
> Yes, probably for rc3 or rc4. For rc2 it was a liitle bit late and
> there is no need to hurry.

Agreed! Thanks for confirming.

Re: [PATCH 4/4] xen: Drop un-informative message during boot

[Punit Agrawal]

Juergen Gross <jgross@suse.com> writes:

> On 21/07/17 12:12, Punit Agrawal wrote:
>> Boris Ostrovsky <boris.ostrovsky@oracle.com> writes:
>> 
>>> On 07/20/2017 07:04 AM, Punit Agrawal wrote:
>>>> On systems that are not booted as a Xen domain, the xenfs driver prints
>>>> the following message during boot.
>>>>
>>>> [    3.460595] xenfs: not registering filesystem on non-xen platform
>>>>
>>>> As the user chose not to boot a Xen domain, this message does not
>>>> provide useful information. Drop this message.
>>>>
>>>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>> Cc: Juergen Gross <jgross@suse.com>
>>>
>>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> 
>> Thanks Boris.
>> 
>> Juergen, I assume you'll pick this up for the next round of xen
>> updates.
>
> Yes, probably for rc3 or rc4. For rc2 it was a liitle bit late and
> there is no need to hurry.

Agreed! Thanks for confirming.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH 4/4] xen: Drop un-informative message during boot

[Boris Ostrovsky]

On 07/20/2017 07:04 AM, Punit Agrawal wrote:
> On systems that are not booted as a Xen domain, the xenfs driver prints
> the following message during boot.
>
> [    3.460595] xenfs: not registering filesystem on non-xen platform
>
> As the user chose not to boot a Xen domain, this message does not
> provide useful information. Drop this message.
>
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH 4/4] xen: Drop un-informative message during boot

[Juergen Gross]

On 20/07/17 13:04, Punit Agrawal wrote:
> On systems that are not booted as a Xen domain, the xenfs driver prints
> the following message during boot.
> 
> [    3.460595] xenfs: not registering filesystem on non-xen platform
> 
> As the user chose not to boot a Xen domain, this message does not
> provide useful information. Drop this message.
> 
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>

Committed to: xen/tip.git for-linus-4.13b


Thanks,

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH 4/4] xen: Drop un-informative message during boot

[Juergen Gross]

On 20/07/17 13:04, Punit Agrawal wrote:
> On systems that are not booted as a Xen domain, the xenfs driver prints
> the following message during boot.
> 
> [    3.460595] xenfs: not registering filesystem on non-xen platform
> 
> As the user chose not to boot a Xen domain, this message does not
> provide useful information. Drop this message.
> 
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>

Committed to: xen/tip.git for-linus-4.13b


Thanks,

Juergen