Xen /dev/mcelog registration in Linux

Xen /dev/mcelog registration in Linux

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 623 bytes --]

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...

How is that supposed to work?

-- 
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

Re: Xen /dev/mcelog registration in Linux

[Konrad Rzeszutek Wilk]

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?
> 
> -- 
> 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?



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

Re: Xen /dev/mcelog registration in Linux

[Marek Marczykowski-Górecki]

[-- 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