Yu Zhiguo
2010-Apr-16 02:07 UTC
[Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
routines ''xen_register_gsi'' and ''xen_teardown_msi_dev'' cannot be used unless macro ''CONFIG_XEN'' is defined, otherwise build error occurs. Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com> --- arch/x86/kernel/acpi/boot.c | 2 ++ arch/x86/kernel/apic/io_apic.c | 4 ++++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 144b7d7..e2cd426 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -472,9 +472,11 @@ int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity) int irq; unsigned int plat_gsi = gsi; +#ifdef CONFIG_XEN irq = xen_register_gsi(gsi, trigger, polarity); if (irq >= 0) return irq; +#endif #ifdef CONFIG_PCI /* diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index eb263ec..123e554 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -3564,8 +3564,10 @@ int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) if (type == PCI_CAP_ID_MSI && nvec > 1) return 1; +#ifdef CONFIG_XEN if (xen_domain()) return xen_setup_msi_irqs(dev, nvec, type); +#endif node = dev_to_node(&dev->dev); irq_want = nr_irqs_gsi; @@ -3626,10 +3628,12 @@ void arch_teardown_msi_irqs(struct pci_dev *dev) { struct msi_desc *entry; +#ifdef CONFIG_XEN /* If we are non-privileged PV domain, we have to * to call xen_teardown_msi_dev first. */ if (xen_domain()) xen_teardown_msi_dev(dev); +#endif list_for_each_entry(entry, &dev->msi_list, list) { int i, nvec; -- 1.5.4.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Apr-16 14:56 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
On Fri, Apr 16, 2010 at 10:07:19AM +0800, Yu Zhiguo wrote:> > routines ''xen_register_gsi'' and ''xen_teardown_msi_dev'' cannot be used > unless macro ''CONFIG_XEN'' is defined, otherwise build error occurs.There has to be a better of doing this. Aren''t the xen_register_gsi defined in the header files? How about making in the header file the #ifdef CONFIG_XEN there? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yu Zhiguo
2010-Apr-18 03:56 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
Konrad Rzeszutek Wilk wrote:> On Fri, Apr 16, 2010 at 10:07:19AM +0800, Yu Zhiguo wrote: >> routines ''xen_register_gsi'' and ''xen_teardown_msi_dev'' cannot be used >> unless macro ''CONFIG_XEN'' is defined, otherwise build error occurs. > > There has to be a better of doing this. Aren''t the > xen_register_gsi defined in the header files? How about making in the > header file the #ifdef CONFIG_XEN there? > >In fact, ''xen_register_gsi'' is declared in header file ''asm/xen/pci.h'' with ''#ifdef CONFIG_XEN'', please refer to the following code. So ''acpi/boot.c'' can use it but should check ''#ifdef CONFIG_XEN''. What''s your opinion? -----------------------asm/xen/pci.h---------------------- #ifdef CONFIG_XEN ... #ifdef CONFIG_XEN_DOM0_PCI int xen_register_gsi(u32 gsi, int triggering, int polarity); ... #else static inline int xen_register_gsi(u32 gsi, int triggering, int polarity) { return -1; } ... #endif Regards Yu Zhiguo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Apr-18 04:46 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
On 04/17/2010 08:56 PM, Yu Zhiguo wrote:> Konrad Rzeszutek Wilk wrote: > >> On Fri, Apr 16, 2010 at 10:07:19AM +0800, Yu Zhiguo wrote: >> >>> routines ''xen_register_gsi'' and ''xen_teardown_msi_dev'' cannot be used >>> unless macro ''CONFIG_XEN'' is defined, otherwise build error occurs. >>> >> There has to be a better of doing this. Aren''t the >> xen_register_gsi defined in the header files? How about making in the >> header file the #ifdef CONFIG_XEN there? >> >> >> > In fact, ''xen_register_gsi'' is declared in header file ''asm/xen/pci.h'' > with ''#ifdef CONFIG_XEN'', please refer to the following code. > > So ''acpi/boot.c'' can use it but should check ''#ifdef CONFIG_XEN''. > What''s your opinion? > > -----------------------asm/xen/pci.h---------------------- > #ifdef CONFIG_XEN > ... > #ifdef CONFIG_XEN_DOM0_PCI > int xen_register_gsi(u32 gsi, int triggering, int polarity); > ... > #else > static inline int xen_register_gsi(u32 gsi, int triggering, int polarity) > { > return -1; > } > ... >This is a good way of handling it. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2010-Apr-19 11:23 UTC
[Xen-devel] Failure to load the most recent kernel 2.6.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
Before child_rip word "acpi" shows pretty often. In particular "acpi_xen_processor" Kernels been built about 2 weeks ago still loads fine. Boris. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Apr-19 13:30 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
On Sat, Apr 17, 2010 at 09:46:18PM -0700, Jeremy Fitzhardinge wrote:> On 04/17/2010 08:56 PM, Yu Zhiguo wrote: > > Konrad Rzeszutek Wilk wrote: > > > >> On Fri, Apr 16, 2010 at 10:07:19AM +0800, Yu Zhiguo wrote: > >> > >>> routines ''xen_register_gsi'' and ''xen_teardown_msi_dev'' cannot be used > >>> unless macro ''CONFIG_XEN'' is defined, otherwise build error occurs. > >>> > >> There has to be a better of doing this. Aren''t the > >> xen_register_gsi defined in the header files? How about making in the > >> header file the #ifdef CONFIG_XEN there? > >> > >> > >> > > In fact, ''xen_register_gsi'' is declared in header file ''asm/xen/pci.h'' > > with ''#ifdef CONFIG_XEN'', please refer to the following code. > > > > So ''acpi/boot.c'' can use it but should check ''#ifdef CONFIG_XEN''. > > What''s your opinion? > > > > -----------------------asm/xen/pci.h---------------------- > > #ifdef CONFIG_XEN > > ... > > #ifdef CONFIG_XEN_DOM0_PCI > > int xen_register_gsi(u32 gsi, int triggering, int polarity); > > ... > > #elseSo this #else is for the CONFIG_XEN_DOM0_PCI..> > static inline int xen_register_gsi(u32 gsi, int triggering, int polarity) > > { > > return -1; > > }perhaps add: #else /* This is for CONFIG_XEN */ static inline int xen_register_gsi(...) { } #endif Or maybe better take out the xen_register_gsi out of this double #ifdef and move it to its own. Say: #if !defined(CONFIG_XEN) static int xen_register_gsi(..) #endif> > ... > > > > This is a good way of handling it.The header file change or the #ifdef in the acpi/boot.c file?> > J > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Apr-19 16:22 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
On 04/19/2010 06:30 AM, Konrad Rzeszutek Wilk wrote:>>> ... >>> >>> >> This is a good way of handling it. >> > The header file change or the #ifdef in the acpi/boot.c file? >Adding stub static inlines is almost always preferable to open-coded #ifdefs in .c files. But we''re growing a bit of an #ifdef thicket in there... J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yu Zhiguo
2010-Apr-20 05:31 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
Hi, Konrad Konrad Rzeszutek Wilk wrote:> > perhaps add: > > #else /* This is for CONFIG_XEN */ > > static inline int xen_register_gsi(...) > { > > } > #endif > > Or maybe better take out the xen_register_gsi out of this double > #ifdef and move it to its own. Say: > > > #if !defined(CONFIG_XEN) > static int xen_register_gsi(..) > > #endif > > >>> ... >>> >> This is a good way of handling it. > > The header file change or the #ifdef in the acpi/boot.c file?Thanks for your explanation, I agree it is also a good idea. But if jeremy think adding #ifdef is ok, I will not fix this patch. -- Regards Yu Zhiguo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2010-Apr-20 10:44 UTC
Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
ASUS P5Q-E 2.6.31.13 under Xen 4.0 loads fine ASUS P5Q-E 2.6.32.9 under Xen 4.0 loads fine ASUS P5Q-E 2.6.32.10 under Xen 4.0 doesn''t load ASUS P5Q3 all kernels work fine I believe that the issue is connected with outdated ( ACPI 2 Enabled) BIOS on first board. This question is mostly addressed to Yu Ke. What BIOS upgrade is required (exact version) , if ever possible. Boris. --- On Mon, 4/19/10, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris Derzhavets <bderzhavets@yahoo.com> Subject: [Xen-devel] Failure to load the most recent kernel 2.6.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10 To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "Jeremy Fitzhardinge" <jeremy@goop.org> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Date: Monday, April 19, 2010, 7:23 AM Before child_rip word "acpi" shows pretty often. In particular "acpi_xen_processor" Kernels been built about 2 weeks ago still loads fine. Boris. -----Inline Attachment Follows----- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2010-Apr-20 12:46 UTC
Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
I also noticed that ../acpi/processor_xen.c gets updated when 2.6.32.9 -> git pull -> 2.6.32.10 (xen/stable) . Just a guess. Boris. --- On Tue, 4/20/10, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris Derzhavets <bderzhavets@yahoo.com> Subject: Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10 To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "Jeremy Fitzhardinge" <jeremy@goop.org> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Date: Tuesday, April 20, 2010, 6:44 AM ASUS P5Q-E 2.6.31.13 under Xen 4.0 loads fine ASUS P5Q-E 2.6.32.9 under Xen 4.0 loads fine ASUS P5Q-E 2.6.32.10 under Xen 4.0 doesn''t load ASUS P5Q3 all kernels work fine I believe that the issue is connected with outdated ( ACPI 2 Enabled) BIOS on first board. This question is mostly addressed to Yu Ke. What BIOS upgrade is required (exact version) , if ever possible. Boris. --- On Mon, 4/19/10, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris Derzhavets <bderzhavets@yahoo.com> Subject: [Xen-devel] Failure to load the most recent kernel 2.6.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10 To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "Jeremy Fitzhardinge" <jeremy@goop.org> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Date: Monday, April 19, 2010, 7:23 AM Before child_rip word "acpi" shows pretty often. In particular "acpi_xen_processor" Kernels been built about 2 weeks ago still loads fine. Boris. -----Inline Attachment Follows----- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel -----Inline Attachment Follows----- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Apr-20 18:21 UTC
Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
On 04/20/2010 03:44 AM, Boris Derzhavets wrote:> ASUS P5Q-E 2.6.31.13 under Xen 4.0 loads fine > ASUS P5Q-E 2.6.32.9 under Xen 4.0 loads fine > ASUS P5Q-E 2.6.32.10 under Xen 4.0 doesn''t load > > ASUS P5Q3 all kernels work fine > > I believe that the issue is connected with outdated ( ACPI 2 Enabled) BIOS > on first board. This question is mostly addressed to Yu Ke. What BIOS > upgrade is required (exact version) , if ever possible. >It would probably help him if you 1. address your mail to him, and 2. provide more specific information about what the failure is, beyond ``Before child_rip word "acpi" shows pretty often. In particular "acpi_xen_processor"''''. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Apr-20 18:33 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
> >> This is a good way of handling it. > > > > The header file change or the #ifdef in the acpi/boot.c file? > > Thanks for your explanation, I agree it is also a good idea. > But if jeremy think adding #ifdef is ok, I will not fix this patch.Huh? I thought that Jeremy mentioned that the #ifdef in the header file is the way to go. I was anticipating a patch from you for this... since I figured it isn''t just as easy as that but there is probably some edge case I hadn''t thought of. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2010-Apr-20 21:25 UTC
Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
If it would not help, i will set up serial console ( a bit painful for me to move boxes ) Tail of sreen output on ASUS P5Q-E +C2D E8400 for 2.6.32.11 kernel :- acpi_processor_set_pdc + 0x3c/0x3e xen_acpi_processor_add + 0x2ef/0x426 acpi_device_probe + 0x4b/0x11d driver_probe_device + 0x86/0x180 __diver_attach + 0x86/0x180 __diver_attach + 0x86/0xa0 bus_for_each_dev 0x64/0x90 driver_attach + 0x71/0x140 bus_add_driver + 0x3e/0x140 driver_register + 0x71/0x140 ?acpi_processor_init 0x3e/0x140 ?acpi_processor_init 0x71/0x140 acpi_bus_register_driver +0x3e/0x12 xen_acpi_processor_init 0xae/0x128 acpi_processor_init + 0x3e/0x12 ? acpi_pci_slot_init 0x0/0x20 ? acpi_pci_slot_init 0x0/0x20 do_one_init_call + 0x37/0x1xa0 kernel_init 0x148/0x196 child_rip + 0xa/0x20 ? init_ret_from_sys_call 0x7/0x16 ? retint_restore_args 0x5/0x5 ? child_rip 0x0/0x20 Screen output stopped. Thanks. Boris. P.S. Nothing similar happens on ASUS P5Q3 + Q9550 Dom0 loads smoothly. Tested on F12 and Ubuntu 9.10. Same picture. --- On Tue, 4/20/10, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10 To: "Boris Derzhavets" <bderzhavets@yahoo.com> Cc: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Yu, Ke" <ke.yu@intel.com> Date: Tuesday, April 20, 2010, 2:21 PM On 04/20/2010 03:44 AM, Boris Derzhavets wrote:> ASUS P5Q-E 2.6.31.13 under Xen 4.0 loads fine > ASUS P5Q-E 2.6.32.9 under Xen 4.0 loads fine > ASUS P5Q-E 2.6.32.10 under Xen 4.0 doesn''t load > > ASUS P5Q3 all kernels work fine > > I believe that the issue is connected with outdated ( ACPI 2 Enabled) BIOS > on first board. This question is mostly addressed to Yu Ke. What BIOS > upgrade is required (exact version) , if ever possible. >It would probably help him if you 1. address your mail to him, and 2. provide more specific information about what the failure is, beyond ``Before child_rip word "acpi" shows pretty often. In particular "acpi_xen_processor"''''. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yu Zhiguo
2010-Apr-21 03:29 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
Konrad Rzeszutek Wilk wrote:>>>> This is a good way of handling it. >>> The header file change or the #ifdef in the acpi/boot.c file? >> Thanks for your explanation, I agree it is also a good idea. >> But if jeremy think adding #ifdef is ok, I will not fix this patch. > > Huh? I thought that Jeremy mentioned that the #ifdef in the header file > is the way to go. I was anticipating a patch from you for this... since > I figured it isn''t just as easy as that but there is probably some edge > case I hadn''t thought of. >But what about #if defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)? method-1) fix it in *.c method-2)> perhaps add: > > #else /* This is for CONFIG_XEN */ > > static inline int xen_register_gsi(...) > { > > } > #endif >Do you mean duplicate codes are ok? It will be more complex if there are more macros. method-3)> Or maybe better take out the xen_register_gsi out of this double > #ifdef and move it to its own. Say: > > > #if !defined(CONFIG_XEN) > static int xen_register_gsi(..) > > #endifWe must use #if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)). It is ugly, especially if there are more macros. method-4) If we perfer to fix it in header file, another method, we can use weak attribute of gcc. So there are four method to fix this bug now, I think the fix *.c is easiest. What''s your opinion? -- Regards Yu Zhiguo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yu, Ke
2010-Apr-21 08:05 UTC
RE: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
Yes, it would be helpful if you can provide more complete serial console log. From the below log, I can see acpi_processor_set_pdc-> acpi_evaluate_object(pr->handle, "_PDC", pdc_in, NULL) cause the system panic. However, it cannot tell why _PDC evaluation cause panic. It may be BIOS issue as you suggested, but we need more log to decide if this is true. And if true, ASUS should be the right place to get updated BIOS. Also, how is the 2.6.32.11 kernel working in bare mental environment? acpi_processor_set_pdc is not xen specific code, so this issue is likely also occurring in bare mental environment. And according to your test result, 2.6.32.9 works while 2.6.32.10 not. This remind me change we made recently made, i.e. "re-enable mwait for xen cpuidle", I am not sure if this cause the panic. So could you please try the grub kernel option "idle=nomwait"? This option will revert the effect of that patch. If "idle=nomwait" works, then we can dig more in this direction. Best Regards Ke ==============================From: Boris Derzhavets [mailto:bderzhavets@yahoo.com] Sent: Wednesday, April 21, 2010 5:26 AM To: Yu, Ke Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com; Yu, Ke; Jeremy Fitzhardinge Subject: Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10 If it would not help, i will set up serial console ( a bit painful for me to move boxes ) Tail of sreen output on ASUS P5Q-E +C2D E8400 for 2.6.32.11 kernel :- acpi_processor_set_pdc + 0x3c/0x3e xen_acpi_processor_add + 0x2ef/0x426 acpi_device_probe + 0x4b/0x11d driver_probe_device + 0x86/0x180 __diver_attach + 0x86/0x180 __diver_attach + 0x86/0xa0 bus_for_each_dev 0x64/0x90 driver_attach + 0x71/0x140 bus_add_driver + 0x3e/0x140 driver_register + 0x71/0x140 ?acpi_processor_init 0x3e/0x140 ?acpi_processor_init 0x71/0x140 acpi_bus_register_driver +0x3e/0x12 xen_acpi_processor_init 0xae/0x128 acpi_processor_init + 0x3e/0x12 ? acpi_pci_slot_init 0x0/0x20 ? acpi_pci_slot_init 0x0/0x20 do_one_init_call + 0x37/0x1xa0 kernel_init 0x148/0x196 child_rip + 0xa/0x20 ? init_ret_from_sys_call 0x7/0x16 ? retint_restore_args 0x5/0x5 ? child_rip 0x0/0x20 Screen output stopped. Thanks. Boris. P.S. Nothing similar happens on ASUS P5Q3 + Q9550 Dom0 loads smoothly. Tested on F12 and Ubuntu 9.10. Same picture. --- On Tue, 4/20/10, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10 To: "Boris Derzhavets" <bderzhavets@yahoo.com> Cc: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Yu, Ke" <ke.yu@intel.com> Date: Tuesday, April 20, 2010, 2:21 PM On 04/20/2010 03:44 AM, Boris Derzhavets wrote:> ASUS P5Q-E 2.6.31.13 under Xen 4.0 loads fine > ASUS P5Q-E 2.6.32.9 under Xen 4.0 loads fine > ASUS P5Q-E 2.6.32.10 under Xen 4.0 doesn''t load > > ASUS P5Q3 all kernels work fine > > I believe that the issue is connected with outdated ( ACPI 2 Enabled) BIOS > on first board. This question is mostly addressed to Yu Ke. What BIOS > upgrade is required (exact version) , if ever possible. >It would probably help him if you 1. address your mail to him, and 2. provide more specific information about what the failure is, beyond ``Before child_rip word "acpi" shows pretty often. In particular "acpi_xen_processor"''''. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2010-Apr-21 12:19 UTC
RE: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
This entry works:- menuentry "Ubuntu, Linux 2.6.32.10" { insmod ext2 set root=(hd1,1) linux /boot/vmlinuz-2.6.32.10 root=/dev/sdb1 ro quiet splash initrd /boot/initrd-2.6.32.10.img } This one still doesn''t :- menuentry "Xen 4 / Ubuntu 9.10 kernel 2.6.32.10" { insmod ext2 set root=(hd1,1) multiboot (hd1,1)/boot/xen.gz module (hd1,1)/boot/vmlinuz-2.6.32.10 dummy=dummy idle=nomwait root=/dev/sdb1 ro console=tty0 module (hd1,1)/boot/initrd-2.6.32.10.img } Issues starts since :- acpi_processor_set_pdc + 0x3c/0x3e again Boris --- On Wed, 4/21/10, Yu, Ke <ke.yu@intel.com> wrote: From: Yu, Ke <ke.yu@intel.com> Subject: RE: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10 To: "Boris Derzhavets" <bderzhavets@yahoo.com> Cc: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Jeremy Fitzhardinge" <jeremy@goop.org> Date: Wednesday, April 21, 2010, 4:05 AM Yes, it would be helpful if you can provide more complete serial console log. From the below log, I can see acpi_processor_set_pdc-> acpi_evaluate_object(pr->handle, "_PDC", pdc_in, NULL) cause the system panic. However, it cannot tell why _PDC evaluation cause panic. It may be BIOS issue as you suggested, but we need more log to decide if this is true. And if true, ASUS should be the right place to get updated BIOS. Also, how is the 2.6.32.11 kernel working in bare mental environment? acpi_processor_set_pdc is not xen specific code, so this issue is likely also occurring in bare mental environment. And according to your test result, 2.6.32.9 works while 2.6.32.10 not. This remind me change we made recently made, i.e. "re-enable mwait for xen cpuidle", I am not sure if this cause the panic. So could you please try the grub kernel option "idle=nomwait"? This option will revert the effect of that patch. If "idle=nomwait" works, then we can dig more in this direction. Best Regards Ke ==============================From: Boris Derzhavets [mailto:bderzhavets@yahoo.com] Sent: Wednesday, April 21, 2010 5:26 AM To: Yu, Ke Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com; Yu, Ke; Jeremy Fitzhardinge Subject: Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10 If it would not help, i will set up serial console ( a bit painful for me to move boxes ) Tail of sreen output on ASUS P5Q-E +C2D E8400 for 2.6.32.11 kernel :- acpi_processor_set_pdc + 0x3c/0x3e xen_acpi_processor_add + 0x2ef/0x426 acpi_device_probe + 0x4b/0x11d driver_probe_device + 0x86/0x180 __diver_attach + 0x86/0x180 __diver_attach + 0x86/0xa0 bus_for_each_dev 0x64/0x90 driver_attach + 0x71/0x140 bus_add_driver + 0x3e/0x140 driver_register + 0x71/0x140 ?acpi_processor_init 0x3e/0x140 ?acpi_processor_init 0x71/0x140 acpi_bus_register_driver +0x3e/0x12 xen_acpi_processor_init 0xae/0x128 acpi_processor_init + 0x3e/0x12 ? acpi_pci_slot_init 0x0/0x20 ? acpi_pci_slot_init 0x0/0x20 do_one_init_call + 0x37/0x1xa0 kernel_init 0x148/0x196 child_rip + 0xa/0x20 ? init_ret_from_sys_call 0x7/0x16 ? retint_restore_args 0x5/0x5 ? child_rip 0x0/0x20 Screen output stopped. Thanks. Boris. P.S. Nothing similar happens on ASUS P5Q3 + Q9550 Dom0 loads smoothly. Tested on F12 and Ubuntu 9.10. Same picture. --- On Tue, 4/20/10, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10 To: "Boris Derzhavets" <bderzhavets@yahoo.com> Cc: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Yu, Ke" <ke.yu@intel.com> Date: Tuesday, April 20, 2010, 2:21 PM On 04/20/2010 03:44 AM, Boris Derzhavets wrote:> ASUS P5Q-E 2.6.31.13 under Xen 4.0 loads fine > ASUS P5Q-E 2.6.32.9 under Xen 4.0 loads fine > ASUS P5Q-E 2.6.32.10 under Xen 4.0 doesn''t load > > ASUS P5Q3 all kernels work fine > > I believe that the issue is connected with outdated ( ACPI 2 Enabled) BIOS > on first board. This question is mostly addressed to Yu Ke. What BIOS > upgrade is required (exact version) , if ever possible. >It would probably help him if you 1. address your mail to him, and 2. provide more specific information about what the failure is, beyond ``Before child_rip word "acpi" shows pretty often. In particular "acpi_xen_processor"''''. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Apr-21 13:00 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
> method-3) > > Or maybe better take out the xen_register_gsi out of this double > > #ifdef and move it to its own. Say: > > > > > > #if !defined(CONFIG_XEN) > > static int xen_register_gsi(..) > > > > #endif > > We must use #if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)). > It is ugly, especially if there are more macros.Lets go with this one. Maybe after this is done there will be a way to unmangle this spaghetti mess. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yu Zhiguo
2010-Apr-21 13:53 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
Konrad Rzeszutek Wilk wrote:>> method-3) >>> Or maybe better take out the xen_register_gsi out of this double >>> #ifdef and move it to its own. Say: >>> >>> >>> #if !defined(CONFIG_XEN) >>> static int xen_register_gsi(..) >>> >>> #endif >> We must use #if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)). >> It is ugly, especially if there are more macros. > > Lets go with this one. Maybe after this is done there will be a way to > unmangle this spaghetti mess. > > >OK, please refer to this new version: ---------------- routines ''xen_register_gsi'' and ''xen_setup_msi_irqs'' cannot be used unless macro ''CONFIG_XEN'' is defined, otherwise build error occurs. So fix them in the header file. Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com> --- arch/x86/include/asm/xen/pci.h | 55 +++++++++++++++++++++------------------ 1 files changed, 30 insertions(+), 25 deletions(-) diff --git a/arch/x86/include/asm/xen/pci.h b/arch/x86/include/asm/xen/pci.h index 650645d..27e0667 100644 --- a/arch/x86/include/asm/xen/pci.h +++ b/arch/x86/include/asm/xen/pci.h @@ -14,36 +14,12 @@ void xen_teardown_msi_dev(struct pci_dev *dev); int xen_find_device_domain_owner(struct pci_dev *dev); int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t domain); int xen_unregister_device_domain_owner(struct pci_dev *dev); - -#else -static inline int xen_register_gsi(u32 gsi, int triggering, int polarity) -{ - return -1; -} -static inline int xen_find_device_domain_owner(struct pci_dev *dev) -{ - return -1; -} -static inline int xen_register_device_domain_owner(struct pci_dev *dev, - uint16_t domain) -{ - return -1; -} -static inline int xen_unregister_device_domain_owner(struct pci_dev *dev) -{ - return -1; -} -static inline void xen_teardown_msi_dev(struct pci_dev *dev) { } #endif #if defined(CONFIG_PCI_MSI) && defined(CONFIG_XEN_DOM0_PCI) int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type); -#else -static inline int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) -{ - return -1; -} #endif + #if defined(CONFIG_PCI_MSI) /* The drivers/pci/xen-pcifront.c sets this structure to @@ -97,4 +73,33 @@ static inline int xen_create_msi_irq(struct pci_dev *dev, return -1; } #endif + +#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)) +static inline int xen_register_gsi(u32 gsi, int triggering, int polarity) +{ + return -1; +} +static inline int xen_find_device_domain_owner(struct pci_dev *dev) +{ + return -1; +} +static inline int xen_register_device_domain_owner(struct pci_dev *dev, + uint16_t domain) +{ + return -1; +} +static inline int xen_unregister_device_domain_owner(struct pci_dev *dev) +{ + return -1; +} +static inline void xen_teardown_msi_dev(struct pci_dev *dev) { } +#endif + +#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && \ + (!defined(CONFIG_PCI_MSI) || !defined(CONFIG_XEN_DOM0_PCI))) +static inline int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) +{ + return -1; +} +#endif #endif /* _ASM_X86_XEN_PCI_H */ -- 1.5.4.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Apr-21 16:31 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
On 04/20/2010 08:29 PM, Yu Zhiguo wrote:> We must use #if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)). >CONFIG_XEN_DOM0_PCI depends on CONFIG_XEN, so there''s no need to test that separately, right? "#ifndef CONFIG_XEN_DOM0_PCI" is enough.> method-4) > If we perfer to fix it in header file, another method, we can use weak attribute of gcc. >"weak" has its place, but I''m not sure its the right answer here. The main problem is that it is a link-time binding, so the generated code still has the calls out to the functions. With static inline functions, the compiler will likely completely remove all the code. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Apr-21 16:33 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
On 04/21/2010 06:53 AM, Yu Zhiguo wrote:> Konrad Rzeszutek Wilk wrote: > >>> method-3) >>> >>>> Or maybe better take out the xen_register_gsi out of this double >>>> #ifdef and move it to its own. Say: >>>> >>>> >>>> #if !defined(CONFIG_XEN) >>>> static int xen_register_gsi(..) >>>> >>>> #endif >>>> >>> We must use #if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)). >>> It is ugly, especially if there are more macros. >>> >> Lets go with this one. Maybe after this is done there will be a way to >> unmangle this spaghetti mess. >> >> >> >> > OK, please refer to this new version: > > ---------------- > > routines ''xen_register_gsi'' and ''xen_setup_msi_irqs'' cannot be used > unless macro ''CONFIG_XEN'' is defined, otherwise build error occurs. > So fix them in the header file. > > Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com> > --- > arch/x86/include/asm/xen/pci.h | 55 +++++++++++++++++++++------------------ > 1 files changed, 30 insertions(+), 25 deletions(-) > > diff --git a/arch/x86/include/asm/xen/pci.h b/arch/x86/include/asm/xen/pci.h > index 650645d..27e0667 100644 > --- a/arch/x86/include/asm/xen/pci.h > +++ b/arch/x86/include/asm/xen/pci.h > @@ -14,36 +14,12 @@ void xen_teardown_msi_dev(struct pci_dev *dev); > int xen_find_device_domain_owner(struct pci_dev *dev); > int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t domain); > int xen_unregister_device_domain_owner(struct pci_dev *dev); > - > -#else > -static inline int xen_register_gsi(u32 gsi, int triggering, int polarity) > -{ > - return -1; > -} > -static inline int xen_find_device_domain_owner(struct pci_dev *dev) > -{ > - return -1; > -} > -static inline int xen_register_device_domain_owner(struct pci_dev *dev, > - uint16_t domain) > -{ > - return -1; > -} > -static inline int xen_unregister_device_domain_owner(struct pci_dev *dev) > -{ > - return -1; > -} > -static inline void xen_teardown_msi_dev(struct pci_dev *dev) { } > #endif > > #if defined(CONFIG_PCI_MSI) && defined(CONFIG_XEN_DOM0_PCI) > int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type); > -#else > -static inline int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) > -{ > - return -1; > -} > #endif > + > #if defined(CONFIG_PCI_MSI) > > /* The drivers/pci/xen-pcifront.c sets this structure to > @@ -97,4 +73,33 @@ static inline int xen_create_msi_irq(struct pci_dev *dev, > return -1; > } > #endif > + > +#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)) >As I mentioned in the other mail, there''s no need to test CONFIG_XEN.> +static inline int xen_register_gsi(u32 gsi, int triggering, int polarity) > +{ > + return -1; > +} > +static inline int xen_find_device_domain_owner(struct pci_dev *dev) > +{ > + return -1; > +} > +static inline int xen_register_device_domain_owner(struct pci_dev *dev, > + uint16_t domain) > +{ > + return -1; > +} > +static inline int xen_unregister_device_domain_owner(struct pci_dev *dev) > +{ > + return -1; > +} > +static inline void xen_teardown_msi_dev(struct pci_dev *dev) { } > +#endif > + > +#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && \ > + (!defined(CONFIG_PCI_MSI) || !defined(CONFIG_XEN_DOM0_PCI))) >Likewise. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yu Zhiguo
2010-Apr-22 04:05 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
Hi jeremy, Jeremy Fitzhardinge wrote:>> #endif >> + >> +#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)) >> > > As I mentioned in the other mail, there''s no need to test CONFIG_XEN. >Indeed, thanks for your hint. Correct now, please refer to the following. ------------------------ routines ''xen_register_gsi'' and ''xen_setup_msi_irqs'' cannot be used unless macro ''CONFIG_XEN'' is defined, otherwise build error occurs. So fix them in the header file. Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com> --- arch/x86/include/asm/xen/pci.h | 54 +++++++++++++++++++++------------------ 1 files changed, 29 insertions(+), 25 deletions(-) diff --git a/arch/x86/include/asm/xen/pci.h b/arch/x86/include/asm/xen/pci.h index 650645d..56b15d1 100644 --- a/arch/x86/include/asm/xen/pci.h +++ b/arch/x86/include/asm/xen/pci.h @@ -14,36 +14,12 @@ void xen_teardown_msi_dev(struct pci_dev *dev); int xen_find_device_domain_owner(struct pci_dev *dev); int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t domain); int xen_unregister_device_domain_owner(struct pci_dev *dev); - -#else -static inline int xen_register_gsi(u32 gsi, int triggering, int polarity) -{ - return -1; -} -static inline int xen_find_device_domain_owner(struct pci_dev *dev) -{ - return -1; -} -static inline int xen_register_device_domain_owner(struct pci_dev *dev, - uint16_t domain) -{ - return -1; -} -static inline int xen_unregister_device_domain_owner(struct pci_dev *dev) -{ - return -1; -} -static inline void xen_teardown_msi_dev(struct pci_dev *dev) { } #endif #if defined(CONFIG_PCI_MSI) && defined(CONFIG_XEN_DOM0_PCI) int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type); -#else -static inline int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) -{ - return -1; -} #endif + #if defined(CONFIG_PCI_MSI) /* The drivers/pci/xen-pcifront.c sets this structure to @@ -97,4 +73,32 @@ static inline int xen_create_msi_irq(struct pci_dev *dev, return -1; } #endif + +#ifndef CONFIG_XEN_DOM0_PCI +static inline int xen_register_gsi(u32 gsi, int triggering, int polarity) +{ + return -1; +} +static inline int xen_find_device_domain_owner(struct pci_dev *dev) +{ + return -1; +} +static inline int xen_register_device_domain_owner(struct pci_dev *dev, + uint16_t domain) +{ + return -1; +} +static inline int xen_unregister_device_domain_owner(struct pci_dev *dev) +{ + return -1; +} +static inline void xen_teardown_msi_dev(struct pci_dev *dev) { } +#endif + +#if (!defined(CONFIG_PCI_MSI) || !defined(CONFIG_XEN_DOM0_PCI)) +static inline int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) +{ + return -1; +} +#endif #endif /* _ASM_X86_XEN_PCI_H */ -- 1.5.4.2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Apr-22 16:27 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
On 04/21/2010 09:05 PM, Yu Zhiguo wrote:> Hi jeremy, > > Jeremy Fitzhardinge wrote: > >>> #endif >>> + >>> +#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)) >>> >>> >> As I mentioned in the other mail, there''s no need to test CONFIG_XEN. >> >> > Indeed, thanks for your hint. > Correct now, please refer to the following. >Better, but:> - > +#if (!defined(CONFIG_PCI_MSI) || !defined(CONFIG_XEN_DOM0_PCI)) >Isn''t there already a XEN MSI CONFIG variable? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yu Zhiguo
2010-Apr-25 04:24 UTC
Re: [Xen-devel] [PATCH] pv-ops: Fix missing ''ifdef CONFIG_XEN'' in acpi
Hi, jeremy Jeremy Fitzhardinge wrote:>> > > Better, but: > >> - >> +#if (!defined(CONFIG_PCI_MSI) || !defined(CONFIG_XEN_DOM0_PCI)) >> > > Isn''t there already a XEN MSI CONFIG variable? >I''m sorry I cannot understand what you mean. I looked up menuconfig, it seems than there is no relation between CONFIG_PCI_MSI and CONFIG_XEN_DOM0_PCI, I don''t know to simplify this line. Please tell me what I missed. -- Regards Yu Zhiguo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel