[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen /dev/mcelog registration in Linux
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@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |