I get the following BUG every time when trying to start xend after booting the current xen-unstable tip (20088:4e2ffbd99aeb). Yesterday''s tip was fine for me. Only happens on x86_32. (XEN) Xen BUG at msi.c:391 (XEN) ----[ Xen-3.5-unstable x86_32p debug=y Not tainted ]---- (XEN) CPU: 1 (XEN) EIP: e008:[<ff152aff>] msi_set_mask_bit+0x45/0x104 (XEN) EFLAGS: 00210046 CONTEXT: hypervisor (XEN) eax: 00000001 ebx: 00000000 ecx: ffb201a0 edx: 00000001 (XEN) esi: 00000001 edi: 00000402 ebp: ffbcbdbc esp: ffbcbd74 (XEN) cr0: 8005003b cr4: 000026f0 cr3: 002d0ca0 cr2: b7ff1ea0 (XEN) ds: e010 es: e010 fs: 00d8 gs: 0033 ss: e010 cs: e008 (XEN) Xen stack trace from esp=ffbcbd74: (XEN) ffb2019c 00200282 00000020 00000000 80090000 00200082 ffbcbd9c ff1186ac (XEN) 00000002 00200282 ffbcbdcc ff16309d ff204694 00200282 ffbcbdcc 00000402 (XEN) ffb2019c 00000402 ffbcbdcc ff152d72 00000058 ffb20180 ffbcbdec ff14f583 (XEN) 00000402 00200086 ffbcbdec ff1186ac ffb20180 ffb2019c ffbcbe2c ff15445c (XEN) 00000402 00000000 00000000 0000005a 00000086 00200282 00000000 00200286 (XEN) 80090000 00000058 0000005a 00000402 000007fd ff2f2000 ffbcbe4c ff15669f (XEN) 00000402 00000009 ffbcbe8c ff1529db 00000009 ff2ce510 ffbcbe8c ff1535b7 (XEN) 00000402 00020100 ffbcbe8c ff152665 ffb2019c 00000001 00001ff4 00000000 (XEN) 00000018 00200086 ffbcbe8c 000007fd 000007fd ff2f2000 ffbcbeec ff155a2a (XEN) ff2ce510 00200286 00000000 ff116642 ff2d0024 d397995d 0000001c ffbf5988 (XEN) 00200286 00000402 ffb2019c 0000001c 00001ff4 00000402 ffb20180 ff2ce510 (XEN) ffbcbf34 df365b20 00200202 fffffffd ff2f2000 ff2f2074 ffbcbf8c ff1639cd (XEN) ff2f2000 000007fd 00000008 ff10701e ffbcbf64 df365b20 00000004 00000000 (XEN) ff2d0024 ffffffff 7fffffff 0000001c d3985cad 0000001c ffbcbf7c ff11a338 (XEN) df367ff0 000007fd c0454f02 c0454efc ff2d0000 ff224100 d397995d 0000001c (XEN) ffbf5ad0 ffbf5ad0 ff2d0034 ff224100 00000018 aaaaaaaa aaaaaaaa ff274b80 (XEN) 0000007b ffbcbfb4 ffbcbfac ff2d0000 00000021 ffbcbfac 00434037 ff1cc038 (XEN) 0000000e df365b20 deadbeef deadbeef deadbeef deadbeef c0201427 00000021 (XEN) 0000000e df365b20 00000000 df7734a0 00001003 df365b34 00000021 00f90000 (XEN) c0201427 00000061 00200202 df365b00 00000069 0000007b 0000007b 000000d8 (XEN) Xen call trace: (XEN) [<ff152aff>] msi_set_mask_bit+0x45/0x104 (XEN) [<ff152d72>] mask_msi_irq+0x16/0x23 (XEN) [<ff14f583>] shutdown_msi_irq+0x11/0x13 (XEN) [<ff15445c>] dynamic_irq_cleanup+0x31/0x8b (XEN) [<ff15669f>] destroy_irq+0x2c/0x3d (XEN) [<ff1535b7>] msi_free_irq+0x158/0x172 (XEN) [<ff155a2a>] unmap_domain_pirq+0x28c/0x30b (XEN) [<ff1639cd>] do_physdev_op+0x84e/0xf31 (XEN) [<ff1cc038>] hypercall+0xb8/0xd8 (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 1: (XEN) Xen BUG at msi.c:391 (XEN) **************************************** -- Stephen Smalley National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Could you apply the following patch to see whether it works or not ?
Xiantao
diff -r a3ae60f8b546 xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c Wed Aug 19 17:00:26 2009 +0100
+++ b/xen/arch/x86/io_apic.c Thu Aug 20 12:36:33 2009 +0800
@@ -2393,7 +2393,7 @@ void __init init_ioapic_mappings(void)
}
}
- nr_irqs_gsi = max(nr_irqs, highest_gsi());
+ nr_irqs_gsi = highest_gsi();
if ( !smp_found_config || skip_ioapic_setup || nr_irqs_gsi < 16 )
nr_irqs_gsi = 16;
Stephen Smalley wrote:> I get the following BUG every time when trying to start xend after
> booting the current xen-unstable tip (20088:4e2ffbd99aeb).
> Yesterday''s
> tip was fine for me. Only happens on x86_32.
>
> (XEN) Xen BUG at msi.c:391
> (XEN) ----[ Xen-3.5-unstable x86_32p debug=y Not tainted ]----
> (XEN) CPU: 1
> (XEN) EIP: e008:[<ff152aff>] msi_set_mask_bit+0x45/0x104
> (XEN) EFLAGS: 00210046 CONTEXT: hypervisor
> (XEN) eax: 00000001 ebx: 00000000 ecx: ffb201a0 edx: 00000001
> (XEN) esi: 00000001 edi: 00000402 ebp: ffbcbdbc esp: ffbcbd74
> (XEN) cr0: 8005003b cr4: 000026f0 cr3: 002d0ca0 cr2: b7ff1ea0
> (XEN) ds: e010 es: e010 fs: 00d8 gs: 0033 ss: e010 cs: e008
> (XEN) Xen stack trace from esp=ffbcbd74:
> (XEN) ffb2019c 00200282 00000020 00000000 80090000 00200082
> ffbcbd9c ff1186ac (XEN) 00000002 00200282 ffbcbdcc ff16309d
> ff204694 00200282 ffbcbdcc 00000402 (XEN) ffb2019c 00000402
> ffbcbdcc ff152d72 00000058 ffb20180 ffbcbdec ff14f583 (XEN)
> 00000402 00200086 ffbcbdec ff1186ac ffb20180 ffb2019c ffbcbe2c
> ff15445c (XEN) 00000402 00000000 00000000 0000005a 00000086
> 00200282 00000000 00200286 (XEN) 80090000 00000058 0000005a
> 00000402 000007fd ff2f2000 ffbcbe4c ff15669f (XEN) 00000402
> 00000009 ffbcbe8c ff1529db 00000009 ff2ce510 ffbcbe8c ff1535b7 (XEN)
> 00000402 00020100 ffbcbe8c ff152665 ffb2019c 00000001 00001ff4
> 00000000 (XEN) 00000018 00200086 ffbcbe8c 000007fd 000007fd
> ff2f2000 ffbcbeec ff155a2a (XEN) ff2ce510 00200286 00000000
> ff116642 ff2d0024 d397995d 0000001c ffbf5988 (XEN) 00200286
> 00000402 ffb2019c 0000001c 00001ff4 00000402 ffb20180 ff2ce510 (XEN)
> ffbcbf34 df365b20 00200202 fffffffd ff2f2000 ff2f2074 ffbcbf8c
> ff1639cd (XEN) ff2f2000 000007fd 00000008 ff10701e ffbcbf64
> df365b20 00000004 00000000 (XEN) ff2d0024 ffffffff 7fffffff
> 0000001c d3985cad 0000001c ffbcbf7c ff11a338 (XEN) df367ff0
> 000007fd c0454f02 c0454efc ff2d0000 ff224100 d397995d 0000001c (XEN)
> ffbf5ad0 ffbf5ad0 ff2d0034 ff224100 00000018 aaaaaaaa aaaaaaaa
> ff274b80 (XEN) 0000007b ffbcbfb4 ffbcbfac ff2d0000 00000021
> ffbcbfac 00434037 ff1cc038 (XEN) 0000000e df365b20 deadbeef
> deadbeef deadbeef deadbeef c0201427 00000021 (XEN) 0000000e
> df365b20 00000000 df7734a0 00001003 df365b34 00000021 00f90000 (XEN)
> c0201427 00000061 00200202 df365b00 00000069 0000007b 0000007b
> 000000d8 (XEN) Xen call trace: (XEN) [<ff152aff>]
> msi_set_mask_bit+0x45/0x104 (XEN) [<ff152d72>]
> mask_msi_irq+0x16/0x23 (XEN) [<ff14f583>]
> shutdown_msi_irq+0x11/0x13 (XEN) [<ff15445c>]
> dynamic_irq_cleanup+0x31/0x8b (XEN) [<ff15669f>]
> destroy_irq+0x2c/0x3d (XEN) [<ff1535b7>] msi_free_irq+0x158/0x172
> (XEN) [<ff155a2a>] unmap_domain_pirq+0x28c/0x30b (XEN)
> [<ff1639cd>] do_physdev_op+0x84e/0xf31 (XEN) [<ff1cc038>]
> hypercall+0xb8/0xd8 (XEN) (XEN) (XEN)
> **************************************** (XEN) Panic on CPU 1: (XEN)
> Xen BUG at msi.c:391 (XEN) ****************************************
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Hi, Your two patches fixed the problem on x86_32, but we now see the following BUG on booting changeset 20093:e83bb28d48fe on a Dell Optiplex 960 Core 2 Quad. (XEN) Initializing CPU#0 (XEN) Detected 2992.543 MHz processor. (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K (XEN) CPU: L2 cache: 6144K (XEN) CPU: Physical Processor ID: 0 (XEN) CPU: Processor Core ID: 0 (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) HVM: VMX enabled (XEN) Intel machine check reporting enabled on CPU#0. (XEN) CPU0: Thermal monitoring enabled (TM2) (XEN) CMCI: CPU0 has no CMCI support (XEN) CPU0: Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz stepping 0a (XEN) Booting processor 1/1 eip 8c000 (XEN) Initializing CPU#1 (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K (XEN) CPU: L2 cache: 6144K (XEN) CPU: Physical Processor ID: 0 (XEN) CPU: Processor Core ID: 1 (XEN) Intel machine check reporting enabled on CPU#1. (XEN) CPU1: Thermal monitoring enabled (TM2) (XEN) CMCI: CPU1 has no CMCI support (XEN) CPU1: Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz stepping 0a (XEN) Booting processor 2/2 eip 8c000 (XEN) Initializing CPU#2 (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K (XEN) CPU: L2 cache: 6144K (XEN) CPU: Physical Processor ID: 0 (XEN) CPU: Processor Core ID: 2 (XEN) Intel machine check reporting enabled on CPU#2. (XEN) CPU2: Thermal monitoring enabled (TM2) (XEN) CMCI: CPU2 has no CMCI support (XEN) CPU2: Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz stepping 0a (XEN) Booting processor 3/3 eip 8c000 (XEN) Initializing CPU#3 (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K (XEN) CPU: L2 cache: 6144K (XEN) CPU: Physical Processor ID: 0 (XEN) CPU: Processor Core ID: 3 (XEN) Intel machine check reporting enabled on CPU#3. (XEN) CPU3: Thermal monitoring enabled (TM2) (XEN) CMCI: CPU3 has no CMCI support (XEN) CPU3: Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz stepping 0a (XEN) Total of 4 processors activated. (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) checking TSC synchronization across 4 CPUs: passed. (XEN) Platform timer is 14.318MHz HPET (XEN) microcode.c:73:d32767 microcode: CPU1 resumed (XEN) Brought up 4 CPUs (XEN) microcode.c:73:d32767 microcode: CPU2 resumed (XEN) microcode.c:73:d32767 microcode: CPU3 resumed (XEN) I/O virtualisation disabled (XEN) Xen BUG at spinlock.c:24 (XEN) ----[ Xen-3.5-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<ffff828c8011ba81>] check_lock+0x39/0x45 (XEN) RFLAGS: 0000000000010246 CONTEXT: hypervisor (XEN) rax: 0000000000000001 rbx: ffff828c802302fc rcx: 0000000000000000 (XEN) rdx: 0000000000000001 rsi: 0000000000000001 rdi: ffff828c80230300 (XEN) rbp: ffff828c8029fd40 rsp: ffff828c8029fd40 r8: ffff830237ef0004 (XEN) r9: 000000000000000c r10: 0000000000000000 r11: 0000000000000040 (XEN) r12: ffff830237e80c80 r13: ffff830237ed0310 r14: 0000000000000018 (XEN) r15: 0000000000000008 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 00000000bfaa4000 cr2: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen stack trace from rsp=ffff828c8029fd40: (XEN) ffff828c8029fd58 ffff828c8011be43 0000000000000001 ffff828c8029fd68 (XEN) ffff828c8015fe26 ffff828c8029fd98 ffff828c8015b6ec 0000000000000018 (XEN) 0000000000000018 ffff830237ed0310 0000000000000000 ffff828c8029fdd8 (XEN) ffff828c8018f57b 0000000000000000 0000000000000000 ffff828c8029fdd8 (XEN) 0000000000000000 0000000000000100 ffff828c802d2080 ffff828c8029fe58 (XEN) ffff828c8018f8a4 ffff828c8029fe18 0000000000000060 0000001880255a48 (XEN) 0000000000da7a63 ffff828c80258a88 0000001800000000 00000000fee0f00c (XEN) ffff828c00004198 00000000ffffffed ffff828c80257dd8 ffff828c80257ea8 (XEN) ffff83000008bfc0 ffff83000008bf60 ffff828c80236ea0 ffff828c8029fe68 (XEN) ffff828c80175307 ffff828c8029ff18 ffff828c8024aea4 0000000000000000 (XEN) 0000000000000000 0000000000000000 00000000011d0fe4 ffff83000008bf60 (XEN) 0000000000000000 00000000ffffffff ffff830000000003 0000000800000000 (XEN) 000000010000006e 0000000000000003 00000000000002f8 0000000000000000 (XEN) 0000000100000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000067ddc (XEN) ffff828c801000b5 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<ffff828c8011ba81>] check_lock+0x39/0x45 (XEN) [<ffff828c8011be43>] _spin_lock+0x11/0x3f (XEN) [<ffff828c8015fe26>] lock_vector_lock+0x10/0x12 (XEN) [<ffff828c8015b6ec>] set_desc_affinity+0x37/0x84 (XEN) [<ffff828c8018f57b>] hpet_msi_set_affinity+0x30/0xd4 (XEN) [<ffff828c8018f8a4>] hpet_broadcast_init+0x237/0x537 (XEN) [<ffff828c80175307>] disable_pit_irq+0x34/0x8a (XEN) [<ffff828c8024aea4>] __start_xen+0x233a/0x2616 (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) Xen BUG at spinlock.c:24 (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... -- Stephen Smalley National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Looks like a lock normally taken with irqs disabled may be being taken with irqs enabled. Which wouldn''t be allowed but could be easy to fix. -- Keir On 20/08/2009 16:18, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:> Hi, > > Your two patches fixed the problem on x86_32, but we now see the > following BUG on booting changeset 20093:e83bb28d48fe on a Dell Optiplex > 960 Core 2 Quad. > > (XEN) Initializing CPU#0 > (XEN) Detected 2992.543 MHz processor. > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > (XEN) CPU: L2 cache: 6144K > (XEN) CPU: Physical Processor ID: 0 > (XEN) CPU: Processor Core ID: 0 > (XEN) VMX: Supported advanced features: > (XEN) - APIC MMIO access virtualisation > (XEN) - APIC TPR shadow > (XEN) - Virtual NMI > (XEN) - MSR direct-access bitmap > (XEN) HVM: VMX enabled > (XEN) Intel machine check reporting enabled on CPU#0. > (XEN) CPU0: Thermal monitoring enabled (TM2) > (XEN) CMCI: CPU0 has no CMCI support > (XEN) CPU0: Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz stepping 0a > (XEN) Booting processor 1/1 eip 8c000 > (XEN) Initializing CPU#1 > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > (XEN) CPU: L2 cache: 6144K > (XEN) CPU: Physical Processor ID: 0 > (XEN) CPU: Processor Core ID: 1 > (XEN) Intel machine check reporting enabled on CPU#1. > (XEN) CPU1: Thermal monitoring enabled (TM2) > (XEN) CMCI: CPU1 has no CMCI support > (XEN) CPU1: Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz stepping 0a > (XEN) Booting processor 2/2 eip 8c000 > (XEN) Initializing CPU#2 > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > (XEN) CPU: L2 cache: 6144K > (XEN) CPU: Physical Processor ID: 0 > (XEN) CPU: Processor Core ID: 2 > (XEN) Intel machine check reporting enabled on CPU#2. > (XEN) CPU2: Thermal monitoring enabled (TM2) > (XEN) CMCI: CPU2 has no CMCI support > (XEN) CPU2: Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz stepping 0a > (XEN) Booting processor 3/3 eip 8c000 > (XEN) Initializing CPU#3 > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > (XEN) CPU: L2 cache: 6144K > (XEN) CPU: Physical Processor ID: 0 > (XEN) CPU: Processor Core ID: 3 > (XEN) Intel machine check reporting enabled on CPU#3. > (XEN) CPU3: Thermal monitoring enabled (TM2) > (XEN) CMCI: CPU3 has no CMCI support > (XEN) CPU3: Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz stepping 0a > (XEN) Total of 4 processors activated. > (XEN) ENABLING IO-APIC IRQs > (XEN) -> Using new ACK method > (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 > (XEN) checking TSC synchronization across 4 CPUs: passed. > (XEN) Platform timer is 14.318MHz HPET > (XEN) microcode.c:73:d32767 microcode: CPU1 resumed > (XEN) Brought up 4 CPUs > (XEN) microcode.c:73:d32767 microcode: CPU2 resumed > (XEN) microcode.c:73:d32767 microcode: CPU3 resumed > (XEN) I/O virtualisation disabled > (XEN) Xen BUG at spinlock.c:24 > (XEN) ----[ Xen-3.5-unstable x86_64 debug=y Not tainted ]---- > (XEN) CPU: 0 > (XEN) RIP: e008:[<ffff828c8011ba81>] check_lock+0x39/0x45 > (XEN) RFLAGS: 0000000000010246 CONTEXT: hypervisor > (XEN) rax: 0000000000000001 rbx: ffff828c802302fc rcx: 0000000000000000 > (XEN) rdx: 0000000000000001 rsi: 0000000000000001 rdi: ffff828c80230300 > (XEN) rbp: ffff828c8029fd40 rsp: ffff828c8029fd40 r8: ffff830237ef0004 > (XEN) r9: 000000000000000c r10: 0000000000000000 r11: 0000000000000040 > (XEN) r12: ffff830237e80c80 r13: ffff830237ed0310 r14: 0000000000000018 > (XEN) r15: 0000000000000008 cr0: 000000008005003b cr4: 00000000000026f0 > (XEN) cr3: 00000000bfaa4000 cr2: 0000000000000000 > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 > (XEN) Xen stack trace from rsp=ffff828c8029fd40: > (XEN) ffff828c8029fd58 ffff828c8011be43 0000000000000001 ffff828c8029fd68 > (XEN) ffff828c8015fe26 ffff828c8029fd98 ffff828c8015b6ec 0000000000000018 > (XEN) 0000000000000018 ffff830237ed0310 0000000000000000 ffff828c8029fdd8 > (XEN) ffff828c8018f57b 0000000000000000 0000000000000000 ffff828c8029fdd8 > (XEN) 0000000000000000 0000000000000100 ffff828c802d2080 ffff828c8029fe58 > (XEN) ffff828c8018f8a4 ffff828c8029fe18 0000000000000060 0000001880255a48 > (XEN) 0000000000da7a63 ffff828c80258a88 0000001800000000 00000000fee0f00c > (XEN) ffff828c00004198 00000000ffffffed ffff828c80257dd8 ffff828c80257ea8 > (XEN) ffff83000008bfc0 ffff83000008bf60 ffff828c80236ea0 ffff828c8029fe68 > (XEN) ffff828c80175307 ffff828c8029ff18 ffff828c8024aea4 0000000000000000 > (XEN) 0000000000000000 0000000000000000 00000000011d0fe4 ffff83000008bf60 > (XEN) 0000000000000000 00000000ffffffff ffff830000000003 0000000800000000 > (XEN) 000000010000006e 0000000000000003 00000000000002f8 0000000000000000 > (XEN) 0000000100000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000067ddc > (XEN) ffff828c801000b5 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) Xen call trace: > (XEN) [<ffff828c8011ba81>] check_lock+0x39/0x45 > (XEN) [<ffff828c8011be43>] _spin_lock+0x11/0x3f > (XEN) [<ffff828c8015fe26>] lock_vector_lock+0x10/0x12 > (XEN) [<ffff828c8015b6ec>] set_desc_affinity+0x37/0x84 > (XEN) [<ffff828c8018f57b>] hpet_msi_set_affinity+0x30/0xd4 > (XEN) [<ffff828c8018f8a4>] hpet_broadcast_init+0x237/0x537 > (XEN) [<ffff828c80175307>] disable_pit_irq+0x34/0x8a > (XEN) [<ffff828c8024aea4>] __start_xen+0x233a/0x2616 > (XEN) > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 0: > (XEN) Xen BUG at spinlock.c:24 > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds..._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2009-08-20 at 17:02 +0100, Keir Fraser wrote:> Looks like a lock normally taken with irqs disabled may be being taken with > irqs enabled. Which wouldn''t be allowed but could be easy to fix.This appears to have been introduced by CS 20073, x86: Implement per-cpu vector for xen hypervisor. It introduces mixed usage of spin_lock() and spin_lock_irqsave() on the vector_lock, whereas previously it was always spin_lock_irqsave(). -- Stephen Smalley National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 21/08/2009 13:03, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:> On Thu, 2009-08-20 at 17:02 +0100, Keir Fraser wrote: >> Looks like a lock normally taken with irqs disabled may be being taken with >> irqs enabled. Which wouldn''t be allowed but could be easy to fix. > > This appears to have been introduced by CS 20073, x86: Implement > per-cpu vector for xen hypervisor. It introduces mixed usage of > spin_lock() and spin_lock_irqsave() on the vector_lock, whereas > previously it was always spin_lock_irqsave().Xiantao, Can you make a patch for this? Any acquisition of the lock where irqs may not already be disabled must do spin_lock_irq or spin_lock_irqsave. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 21/08/2009 13:03, "Stephen Smalley" <sds@tycho.nsa.gov> wrote: > >> On Thu, 2009-08-20 at 17:02 +0100, Keir Fraser wrote: >>> Looks like a lock normally taken with irqs disabled may be being >>> taken with irqs enabled. Which wouldn''t be allowed but could be >>> easy to fix. >> >> This appears to have been introduced by CS 20073, x86: Implement >> per-cpu vector for xen hypervisor. It introduces mixed usage of >> spin_lock() and spin_lock_irqsave() on the vector_lock, whereas >> previously it was always spin_lock_irqsave(). > > Xiantao, Can you make a patch for this? Any acquisition of the lock > where irqs may not already be disabled must do spin_lock_irq or > spin_lock_irqsave.Yes, I will work out a fix for that. :) Xiantao _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel