[PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

Yu Zhiguo

author

2010-04-16 02:07 UTC #0 lore raw

PATCH 1/1 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 <[email protected]>

---
 arch/x86/kernel/acpi/boot.c    |    2 ++
 arch/x86/kernel/apic/io_apic.c |    4 ++++
 2 files changed, 6 insertions(+), 0 deletions(-)

arch/x86/kernel/acpi/boot.c +2 -0

index 144b7d7..e2cd426 100644
@@ -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
 	/*

arch/x86/kernel/apic/io_apic.c +4 -0

index eb263ec..123e554 100644
@@ -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;

Signature · 1 line

1.5.4.2

Konrad Rzeszutek Wilk

2010-04-16 14:56 UTC #1 lore raw

Quoted 3 lines · Yu Zhiguo

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?

Yu Zhiguo

author

2010-04-18 03:56 UTC #2 lore raw

Quoted 9 lines · Konrad Rzeszutek Wilk

Quoted 2 lines · Yu Zhiguo
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

Jeremy Fitzhardinge

2010-04-18 04:46 UTC #3 lore raw

Quoted 27 lines · Yu Zhiguo

Quoted 11 lines · Konrad Rzeszutek Wilk
Quoted 3 lines · Yu Zhiguo
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)

Quoted 5 lines

{
        return -1;
}

...

This is a good way of handling it.

J

Boris Derzhavets

2010-04-19 11:23 UTC #16 lore raw

Failure to load the most recent kernel 2.6.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

In reply to Konrad Rzeszutek Wilk

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
[email protected]
http://lists.xensource.com/xen-devel

Konrad Rzeszutek Wilk

2010-04-19 13:30 UTC #4 lore raw

In reply to Jeremy Fitzhardinge

Quoted 20 lines · Jeremy Fitzhardinge

Quoted 19 lines · Yu Zhiguo
Quoted 11 lines · Konrad Rzeszutek Wilk
Quoted 3 lines · Yu Zhiguo
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?

Quoted 7 lines

Quoted 7 lines
-----------------------asm/xen/pci.h---------------------- #ifdef CONFIG_XEN
...
#ifdef CONFIG_XEN_DOM0_PCI
int xen_register_gsi(u32 gsi, int triggering, int polarity);
...
#else

So this #else is for the CONFIG_XEN_DOM0_PCI..

Quoted 4 lines

Quoted 4 lines
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

Quoted 4 lines

Quoted 2 lines
...
This is a good way of handling it.

The header file change or the #ifdef in the acpi/boot.c file?

Quoted 7 lines

J
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Jeremy Fitzhardinge

2010-04-19 16:22 UTC #5 lore raw

Quoted 7 lines · Konrad Rzeszutek Wilk

Quoted 5 lines
Quoted 3 lines
...
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

Yu Zhiguo

author

2010-04-20 05:31 UTC #6 lore raw

In reply to Konrad Rzeszutek Wilk

Hi, Konrad

Quoted 18 lines · Konrad Rzeszutek Wilk

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

Quoted 8 lines

#endif
Quoted 3 lines
Quoted 2 lines
...
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.

Signature · 2 lines

Regards
Yu Zhiguo

Boris Derzhavets

2010-04-20 10:44 UTC #17 lore raw

Re: Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

In reply to Boris Derzhavets

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 <[email protected]> wrote:

From: Boris Derzhavets <[email protected]>
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" <[email protected]>, "Jeremy Fitzhardinge" <[email protected]>
Cc: "[email protected]" <[email protected]>
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
[email protected]
http://lists.xensource.com/xen-devel

Boris Derzhavets

2010-04-20 12:46 UTC #18 lore raw

Re: 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 <[email protected]> wrote:

From: Boris Derzhavets <[email protected]>
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" <[email protected]>, "Jeremy Fitzhardinge" <[email protected]>
Cc: "[email protected]" <[email protected]>
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 <[email protected]> wrote:

From: Boris Derzhavets <[email protected]>
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"
<[email protected]>, "Jeremy Fitzhardinge" <[email protected]>
Cc: "[email protected]" <[email protected]>
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
[email protected]
http://lists.xensource.com/xen-devel

-----Inline Attachment Follows-----

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Jeremy Fitzhardinge

2010-04-20 18:21 UTC #19 lore raw

Re: Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

In reply to Boris Derzhavets

Quoted 10 lines · Boris Derzhavets

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

Konrad Rzeszutek Wilk

2010-04-20 18:33 UTC #7 lore raw

In reply to Yu Zhiguo

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
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.

Boris Derzhavets

2010-04-20 21:25 UTC #20 lore raw

Re: Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

In reply to Jeremy Fitzhardinge

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 <[email protected]> wrote:

From: Jeremy Fitzhardinge <[email protected]>
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" <[email protected]>
Cc: "Konrad Rzeszutek Wilk" <[email protected]>, "[email protected]" <[email protected]>, "Yu, Ke" <[email protected]>
Date: Tuesday, April 20, 2010, 2:21 PM

Quoted 10 lines · Boris Derzhavets

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
[email protected]
http://lists.xensource.com/xen-devel

Yu Zhiguo

author

2010-04-21 03:29 UTC #8 lore raw

In reply to Konrad Rzeszutek Wilk

Quoted 10 lines · Konrad Rzeszutek Wilk

Quoted 4 lines
Quoted 2 lines
Quoted 1 line
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)

Quoted 10 lines

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)

Quoted 8 lines

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.

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?

Signature · 2 lines

Regards
Yu Zhiguo

Yu, Ke

2010-04-21 08:05 UTC #21 lore raw

RE: Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

In reply to Boris Derzhavets

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:[email protected]]
Sent: Wednesday, April 21, 2010 5:26 AM
To: Yu, Ke
Cc: Konrad Rzeszutek Wilk; [email protected]; 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 <[email protected]> wrote:

From: Jeremy Fitzhardinge <[email protected]>
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" <[email protected]>
Cc: "Konrad Rzeszutek Wilk" <[email protected]>, "[email protected]" <[email protected]>, "Yu, Ke" <[email protected]>
Date: Tuesday, April 20, 2010, 2:21 PM

Quoted 10 lines · Boris Derzhavets

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

Boris Derzhavets

2010-04-21 12:19 UTC #22 lore raw

RE: 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 <[email protected]> wrote:

From: Yu, Ke <[email protected]>
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" <[email protected]>
Cc: "Konrad Rzeszutek Wilk" <[email protected]>, "[email protected]" <[email protected]>, "Jeremy Fitzhardinge" <[email protected]>
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:[email protected]]
Sent: Wednesday, April 21, 2010 5:26 AM
To: Yu, Ke
Cc: Konrad Rzeszutek Wilk; [email protected]; 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 <[email protected]> wrote:

From: Jeremy Fitzhardinge <[email protected]>
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" <[email protected]>
Cc: "Konrad Rzeszutek Wilk" <[email protected]>, "[email protected]" <[email protected]>, "Yu, Ke" <[email protected]>
Date: Tuesday, April 20, 2010, 2:21 PM

Quoted 10 lines · Boris Derzhavets

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
[email protected]
http://lists.xensource.com/xen-devel

Konrad Rzeszutek Wilk

2010-04-21 13:00 UTC #9 lore raw

In reply to Yu Zhiguo

Quoted 5 lines

method-3)
Quoted 4 lines
Or maybe better take out the xen_register_gsi out of this double #ifdef and move it to its own. Say:

Quoted 7 lines

Quoted 4 lines
#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.

Yu Zhiguo

author

2010-04-21 13:53 UTC #10 lore raw

Quoted 8 lines · Konrad Rzeszutek Wilk

Quoted 8 lines
method-3)
Quoted 7 lines
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(..)

Quoted 9 lines

Quoted 3 lines
Quoted 1 line
#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 <[email protected]>

---
 arch/x86/include/asm/xen/pci.h |   55 +++++++++++++++++++++------------------
 1 files changed, 30 insertions(+), 25 deletions(-)

arch/x86/include/asm/xen/pci.h +30 ~~-25~~

index 650645d..27e0667 100644
@@ -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 */

Signature · 1 line

1.5.4.2

Jeremy Fitzhardinge

2010-04-21 16:31 UTC #15 lore raw

In reply to Yu Zhiguo

Quoted 2 lines · Yu Zhiguo

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.

Quoted 3 lines

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

Jeremy Fitzhardinge

2010-04-21 16:33 UTC #11 lore raw

In reply to Yu Zhiguo

Quoted 78 lines · Yu Zhiguo

Quoted 9 lines · Konrad Rzeszutek Wilk
Quoted 9 lines
method-3)
Quoted 7 lines
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(..)
Quoted 11 lines
Quoted 5 lines
Quoted 2 lines
#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 <[email protected]>
---
 arch/x86/include/asm/xen/pci.h |   55 +++++++++++++++++++++------------------
 1 files changed, 30 insertions(+), 25 deletions(-)
arch/x86/include/asm/xen/pci.h +1 ~~-25~~
index 650645d..27e0667 100644
@@ -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

arch/x86/include/asm/xen/pci.h static inline int xen_create_msi_irq(struct pci_dev *dev, · line 78

Quoted 6 lines

arch/x86/include/asm/xen/pci.h +2 -0

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

Quoted 13 lines

arch/x86/include/asm/xen/pci.h +12 -0

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

arch/x86/include/asm/xen/pci.h static inline int xen_create_msi_irq(struct pci_dev *dev, · line 99

Quoted 10 lines

arch/x86/include/asm/xen/pci.h +10 -0

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

Yu Zhiguo

author

2010-04-22 04:05 UTC #12 lore raw

Hi jeremy,

Quoted 7 lines · Jeremy Fitzhardinge

Review
Quoted 4 lines
#endif
(quoted diff) +2 -0
+
+#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 <[email protected]>

---
 arch/x86/include/asm/xen/pci.h |   54 +++++++++++++++++++++------------------
 1 files changed, 29 insertions(+), 25 deletions(-)

arch/x86/include/asm/xen/pci.h +29 ~~-25~~

index 650645d..56b15d1 100644
@@ -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 */

Signature · 1 line

1.5.4.2

Jeremy Fitzhardinge

2010-04-22 16:27 UTC #13 lore raw

Quoted 12 lines · Yu Zhiguo

Hi jeremy,
Quoted 8 lines · Jeremy Fitzhardinge
Review
Quoted 5 lines
#endif
(quoted diff) +2 -0
+
+#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.

Quoted 3 lines

Indeed, thanks for your hint.
Correct now, please refer to the following.

Better, but:

Review

Quoted 3 lines

(quoted diff) +1 -1

-
+#if (!defined(CONFIG_PCI_MSI) || !defined(CONFIG_XEN_DOM0_PCI))

Isn't there already a XEN MSI CONFIG variable?

J

Yu Zhiguo

author

2010-04-25 04:24 UTC #14 lore raw

Hi, jeremy

Quoted 10 lines · Jeremy Fitzhardinge

Quoted 1 line
Better, but:
Review
Quoted 3 lines
(quoted diff) +1 -1
-
+#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.

Signature · 2 lines

Regards
Yu Zhiguo