Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1560129 > unrolled thread
| Started by | Borislav Petkov <bp@alien8.de> |
|---|---|
| First post | 2017-01-16 23:00 +0100 |
| Last post | 2017-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.
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
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Date | 2017-01-16 23:00 +0100 |
| Subject | Re: [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]
| From | Prarit Bhargava <prarit@redhat.com> |
|---|---|
| Date | 2017-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]
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Date | 2017-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]
| From | Prarit Bhargava <prarit@redhat.com> |
|---|---|
| Date | 2017-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]
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Date | 2017-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]
| From | Prarit Bhargava <prarit@redhat.com> |
|---|---|
| Date | 2017-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]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-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]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-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]
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Date | 2017-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