From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: Xen /dev/mcelog registration in Linux
Date: Mon, 4 Jan 2016 22:00:38 +0100 [thread overview]
Message-ID: <20160104210038.GD1101@mail-itl> (raw)
In-Reply-To: <20160104204911.GD17427@char.us.oracle.com>
[-- Attachment #1.1: Type: text/plain, Size: 2889 bytes --]
On Mon, Jan 04, 2016 at 03:49:11PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 15, 2015 at 02:54:31PM +0100, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > Booting kernel with both CONFIG_X86_MCE=y and CONFIG_XEN_MCE_LOG=y
> > results in "mce: Unable to init device /dev/mcelog (rc: -16)" error. I
> > think that's because both drivers tries to register that character
> > device (drivers/xen/mcelog.c: xen_late_init_mcelog;
> > arch/x86/kernel/cpu/mcheck/mce.c: mcheck_init_device). So obviously one
> > of them fails. CONFIG_XEN_MCE_LOG depends on CONFIG_X86_MCE...
> >
>
> Right. The baremetal one (mce.c) should fail and then the Xen one
> will pick it up. There is a little comment in threshold_init_device:
>
>
> /*
> * there are 3 funcs which need to be _initcalled in a logic sequence:
> * 1. xen_late_init_mcelog
> * 2. mcheck_init_device
> * 3. threshold_init_device
> *
> * xen_late_init_mcelog must register xen_mce_chrdev_device before
> * native mce_chrdev_device registration if running under xen platform;
> *
> * mcheck_init_device should be inited before threshold_init_device to
> * initialize mce_device, otherwise a NULL ptr dereference will cause panic.
> *
> * so we use following _initcalls
> * 1. device_initcall(xen_late_init_mcelog);
> * 2. device_initcall_sync(mcheck_init_device);
> * 3. late_initcall(threshold_init_device);
> *
> * when running under xen, the initcall order is 1,2,3;
> * on baremetal, we skip 1 and we do only 2 and 3.
> */
>
> > How is that supposed to work?
>
> Hope the above explains it?
Ok, so maybe it would be better to hide that error message somehow? This
is the only dom0 kernel error during boot with "quiet" option. And
scares users a lot (it is blamed for almost all boot problems).
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
[-- Attachment #1.2: Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
prev parent reply other threads:[~2016-01-04 21:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-15 13:54 Xen /dev/mcelog registration in Linux Marek Marczykowski-Górecki
2016-01-04 20:49 ` Konrad Rzeszutek Wilk
2016-01-04 21:00 ` Marek Marczykowski-Górecki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160104210038.GD1101@mail-itl \
--to=marmarek@invisiblethingslab.com \
--cc=konrad.wilk@oracle.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).