Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1560129 > unrolled thread

Re: [PATCH] x86/mce: Fix initialization error warning

Started byBorislav Petkov <bp@alien8.de>
First post2017-01-16 23:00 +0100
Last post2017-01-17 10:20 +0100
Articles 9 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH] x86/mce: Fix initialization error warning Borislav Petkov <bp@alien8.de> - 2017-01-16 23:00 +0100
    Re: [PATCH] x86/mce: Fix initialization error warning Prarit Bhargava <prarit@redhat.com> - 2017-01-16 23:10 +0100
      Re: [PATCH] x86/mce: Fix initialization error warning Borislav Petkov <bp@alien8.de> - 2017-01-16 23:50 +0100
        Re: [PATCH] x86/mce: Fix initialization error warning Prarit Bhargava <prarit@redhat.com> - 2017-01-17 00:20 +0100
          Re: [PATCH] x86/mce: Fix initialization error warning Borislav Petkov <bp@alien8.de> - 2017-01-17 00:40 +0100
            Re: [PATCH] x86/mce: Fix initialization error warning Prarit Bhargava <prarit@redhat.com> - 2017-01-17 01:20 +0100
            Re: [PATCH] x86/mce: Fix initialization error warning Thomas Gleixner <tglx@linutronix.de> - 2017-01-17 09:40 +0100
              Re: [PATCH] x86/mce: Fix initialization error warning Thomas Gleixner <tglx@linutronix.de> - 2017-01-17 10:20 +0100
              Re: [PATCH] x86/mce: Fix initialization error warning Borislav Petkov <bp@alien8.de> - 2017-01-17 10:20 +0100

#1560129 — Re: [PATCH] x86/mce: Fix initialization error warning

FromBorislav Petkov <bp@alien8.de>
Date2017-01-16 23:00 +0100
SubjectRe: [PATCH] x86/mce: Fix initialization error warning
Message-ID<t0ntM-6uv-25@gated-at.bofh.it>
On Mon, Jan 16, 2017 at 04:49:41PM -0500, Prarit Bhargava wrote:
> When booting kernel with mce=off a loud warning from the mce code
> is displayed.  This causes confusion for end users.

Is this what you call a loud warning?

[    1.885648] mce: Unable to init device /dev/mcelog (rc: -5)

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [next] | [standalone]


#1560133

FromPrarit Bhargava <prarit@redhat.com>
Date2017-01-16 23:10 +0100
Message-ID<t0nDs-6Nj-7@gated-at.bofh.it>
In reply to#1560129

On 01/16/2017 04:56 PM, Borislav Petkov wrote:
> On Mon, Jan 16, 2017 at 04:49:41PM -0500, Prarit Bhargava wrote:
>> When booting kernel with mce=off a loud warning from the mce code
>> is displayed.  This causes confusion for end users.
> 
> Is this what you call a loud warning?
> 
> [    1.885648] mce: Unable to init device /dev/mcelog (rc: -5)

Yes, it was loud enough to generate a bug report from a user.

FWIW, I just found this from last year calling the same message "scary".  It
doesn't look like there was a follow up though.

https://lkml.org/lkml/2016/2/9/354

P.

> 

[toc] | [prev] | [next] | [standalone]


#1560143

FromBorislav Petkov <bp@alien8.de>
Date2017-01-16 23:50 +0100
Message-ID<t0oga-725-7@gated-at.bofh.it>
In reply to#1560133
On Mon, Jan 16, 2017 at 05:06:02PM -0500, Prarit Bhargava wrote:
> Yes, it was loud enough to generate a bug report from a user.

Yeah, because all users are sane and we should do whatever they want -
no questions asked. Especially those who boot with "mce=off".

Did you actually ask that user why she/he is even booting with
"mce=off"?

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [next] | [standalone]


#1560159

FromPrarit Bhargava <prarit@redhat.com>
Date2017-01-17 00:20 +0100
Message-ID<t0oJb-7x8-1@gated-at.bofh.it>
In reply to#1560143

On 01/16/2017 05:43 PM, Borislav Petkov wrote:
> On Mon, Jan 16, 2017 at 05:06:02PM -0500, Prarit Bhargava wrote:
>> Yes, it was loud enough to generate a bug report from a user.
> 
> Yeah, because all users are sane and we should do whatever they want -
> no questions asked. Especially those who boot with "mce=off".
> 
> Did you actually ask that user why she/he is even booting with
> "mce=off"?

Yes, mce=off is the default for kdump:

KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices cgroup_disable=memory
mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail
acpi_no_memhotplug transparent_hugepage=never"

There is a race condition between NMI completing on a CPU and the MCE
synchronization timing out that results in a kernel panic on the kdump kernel,
and a loss of the dump image.  There have been a few attempts to fix it over the
years.  It seems as simple as setting a flag in native_machine_crash_shutdown()
and querying it in do_machine_check() to avoid mce & nmi race.

P.

> 

[toc] | [prev] | [next] | [standalone]


#1560166

FromBorislav Petkov <bp@alien8.de>
Date2017-01-17 00:40 +0100
Message-ID<t0p2y-7EL-19@gated-at.bofh.it>
In reply to#1560159
On Mon, Jan 16, 2017 at 06:13:39PM -0500, Prarit Bhargava wrote:
> Yes, mce=off is the default for kdump:

So fix kdump to disable MCA properly instead of sending me brown paper
bags.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [next] | [standalone]


#1560179

FromPrarit Bhargava <prarit@redhat.com>
Date2017-01-17 01:20 +0100
Message-ID<t0pFg-88P-13@gated-at.bofh.it>
In reply to#1560166

On 01/16/2017 06:32 PM, Borislav Petkov wrote:
> On Mon, Jan 16, 2017 at 06:13:39PM -0500, Prarit Bhargava wrote:
>> Yes, mce=off is the default for kdump:
> 
> So fix kdump to disable MCA properly instead of sending me brown paper
> bags.

Sure, I'll take a shot at it.

Thanks,

P.

> 

[toc] | [prev] | [next] | [standalone]


#1560347

FromThomas Gleixner <tglx@linutronix.de>
Date2017-01-17 09:40 +0100
Message-ID<t0xt7-4GT-5@gated-at.bofh.it>
In reply to#1560166
On Tue, 17 Jan 2017, Borislav Petkov wrote:
> On Mon, Jan 16, 2017 at 06:13:39PM -0500, Prarit Bhargava wrote:
> > Yes, mce=off is the default for kdump:
> 
> So fix kdump to disable MCA properly instead of sending me brown paper
> bags.

That's one thing, but OTOH we really can avoid the KERN_ERR level print out
for the case where mce is not available (for whatever reasons: HW / Virt /
command line ....).

The simple 2 liner I posted earlier in this thread does it nicely.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]


#1560360

FromThomas Gleixner <tglx@linutronix.de>
Date2017-01-17 10:20 +0100
Message-ID<t0y5P-59Z-1@gated-at.bofh.it>
In reply to#1560347
On Tue, 17 Jan 2017, Borislav Petkov wrote:
> On Tue, Jan 17, 2017 at 09:34:18AM +0100, Thomas Gleixner wrote:
> > That's one thing, but OTOH we really can avoid the KERN_ERR level print out
> > for the case where mce is not available (for whatever reasons: HW / Virt /
> > command line ....).
> > 
> > The simple 2 liner I posted earlier in this thread does it nicely.
> 
> Well, I seem to remember at the time of this:
> 
>   9c15a24b038f ("x86/mce: Improve mcheck_init_device() error handling")
> 
> that I requested to have that error message there so that we *know* when
> that function fails instead of trying to decipher "Hey, mcelog doesn't
> start here" and wonder why.
> 
> But we can kill it just as well, especially as there's patch deprecating
> /dev/mcelog floating around. We can reorg error messages in that
> function later, if deemed necessary.

Your decision.

[toc] | [prev] | [next] | [standalone]


#1560365

FromBorislav Petkov <bp@alien8.de>
Date2017-01-17 10:20 +0100
Message-ID<t0y5P-59Z-3@gated-at.bofh.it>
In reply to#1560347
On Tue, Jan 17, 2017 at 09:34:18AM +0100, Thomas Gleixner wrote:
> That's one thing, but OTOH we really can avoid the KERN_ERR level print out
> for the case where mce is not available (for whatever reasons: HW / Virt /
> command line ....).
> 
> The simple 2 liner I posted earlier in this thread does it nicely.

Well, I seem to remember at the time of this:

  9c15a24b038f ("x86/mce: Improve mcheck_init_device() error handling")

that I requested to have that error message there so that we *know* when
that function fails instead of trying to decipher "Hey, mcelog doesn't
start here" and wonder why.

But we can kill it just as well, especially as there's patch deprecating
/dev/mcelog floating around. We can reorg error messages in that
function later, if deemed necessary.

So sure.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web