* [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it
@ 2009-03-08 5:31 Jeremy Fitzhardinge
2009-03-08 8:52 ` Boris Derzhavets
` (3 more replies)
0 siblings, 4 replies; 46+ messages in thread
From: Jeremy Fitzhardinge @ 2009-03-08 5:31 UTC (permalink / raw)
To: Keir Fraser
Cc: Boris Derzhavets, Xen-devel,
Marc - A. Dahlhaus [ Administration | Westermann GmbH ]
Mask X86_FEATURE_XSAVE in cpuid leaf 1, ecx, as we don't allow guests to
use it (by setting cr4.OSXSAVE).
This prevents crashes in pvops dom0 kernels, as new versions of Linux try
to use this feature.
(This patch deals with dom0 cpuid; I'm not sure where the right place to
set up the default mask for domU is.)
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
diff -r 7f573cb76db4 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c Tue Mar 03 13:22:28 2009 +0000
+++ b/xen/arch/x86/traps.c Sat Mar 07 17:02:03 2009 -0800
@@ -757,6 +757,7 @@
__clear_bit(X86_FEATURE_XTPR % 32, &c);
__clear_bit(X86_FEATURE_PDCM % 32, &c);
__clear_bit(X86_FEATURE_DCA % 32, &c);
+ __clear_bit(X86_FEATURE_XSAVE % 32, &c);
if ( !cpu_has_apic )
__clear_bit(X86_FEATURE_X2APIC % 32, &c);
__set_bit(X86_FEATURE_HYPERVISOR % 32, &c);
diff -r 7f573cb76db4 xen/include/asm-x86/cpufeature.h
--- a/xen/include/asm-x86/cpufeature.h Tue Mar 03 13:22:28 2009 +0000
+++ b/xen/include/asm-x86/cpufeature.h Sat Mar 07 17:02:03 2009 -0800
@@ -95,6 +95,7 @@
#define X86_FEATURE_SSE4_2 (4*32+20) /* Streaming SIMD Extensions 4.2 */
#define X86_FEATURE_X2APIC (4*32+21) /* Extended xAPIC */
#define X86_FEATURE_POPCNT (4*32+23) /* POPCNT instruction */
+#define X86_FEATURE_XSAVE (4*32+26) /* XSAVE/XRSTOR/XSETBV/XGETBV */
#define X86_FEATURE_HYPERVISOR (4*32+31) /* Running under some hypervisor */
/* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC0000001, word 5 */
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-08 5:31 [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Jeremy Fitzhardinge @ 2009-03-08 8:52 ` Boris Derzhavets 2009-03-08 9:13 ` Keir Fraser ` (2 subsequent siblings) 3 siblings, 0 replies; 46+ messages in thread From: Boris Derzhavets @ 2009-03-08 8:52 UTC (permalink / raw) To: Keir Fraser, Jeremy Fitzhardinge Cc: Xen-devel, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] [-- Attachment #1.1: Type: text/plain, Size: 2272 bytes --] Performed:- cd /usr/src/linux-2.6-xen git pull make make modules_install install mkinitramfs -o /boot/initrd-2.6.29-rc7-tip.img 2.6.29-rc7-tip Now kernel boots on Q9550 The most recent serial console boot log attached Boris. P.S. --- On Sun, 3/8/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: "Keir Fraser" <keir.fraser@eu.citrix.com> Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Marc - A. Dahlhaus [ Administration | Westermann GmbH ]" <mad@wol.de>, "Boris Derzhavets" <bderzhavets@yahoo.com> Date: Sunday, March 8, 2009, 12:31 AM Mask X86_FEATURE_XSAVE in cpuid leaf 1, ecx, as we don't allow guests to use it (by setting cr4.OSXSAVE). This prevents crashes in pvops dom0 kernels, as new versions of Linux try to use this feature. (This patch deals with dom0 cpuid; I'm not sure where the right place to set up the default mask for domU is.) Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> diff -r 7f573cb76db4 xen/arch/x86/traps.c --- a/xen/arch/x86/traps.c Tue Mar 03 13:22:28 2009 +0000 +++ b/xen/arch/x86/traps.c Sat Mar 07 17:02:03 2009 -0800 @@ -757,6 +757,7 @@ __clear_bit(X86_FEATURE_XTPR % 32, &c); __clear_bit(X86_FEATURE_PDCM % 32, &c); __clear_bit(X86_FEATURE_DCA % 32, &c); + __clear_bit(X86_FEATURE_XSAVE % 32, &c); if ( !cpu_has_apic ) __clear_bit(X86_FEATURE_X2APIC % 32, &c); __set_bit(X86_FEATURE_HYPERVISOR % 32, &c); diff -r 7f573cb76db4 xen/include/asm-x86/cpufeature.h --- a/xen/include/asm-x86/cpufeature.h Tue Mar 03 13:22:28 2009 +0000 +++ b/xen/include/asm-x86/cpufeature.h Sat Mar 07 17:02:03 2009 -0800 @@ -95,6 +95,7 @@ #define X86_FEATURE_SSE4_2 (4*32+20) /* Streaming SIMD Extensions 4.2 */ #define X86_FEATURE_X2APIC (4*32+21) /* Extended xAPIC */ #define X86_FEATURE_POPCNT (4*32+23) /* POPCNT instruction */ +#define X86_FEATURE_XSAVE (4*32+26) /* XSAVE/XRSTOR/XSETBV/XGETBV */ #define X86_FEATURE_HYPERVISOR (4*32+31) /* Running under some hypervisor */ /* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC0000001, word 5 */ [-- Attachment #1.2: Type: text/html, Size: 2716 bytes --] [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Q9550S0.log --] [-- Type: text/x-log; name="Q9550S0.log", Size: 78417 bytes --] __ __ _____ _ _ _ _ _ \ \/ /___ _ __ |___ /| || | _ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \ |_ \| || |_ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | ___) |__ _|__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |____(_) |_| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| (XEN) Xen version 3.4-unstable (root@) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) ) Fri Feb 27 06:14:29 EST 2009 (XEN) Latest ChangeSet: Fri Feb 20 17:02:36 2009 +0000 19238:f8187a343ad2 (XEN) Command line: dom0_mem=1024M loglvl=all guest_loglvl=all com1=9600,8n1 console=com1 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 2 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009cc00 (usable) (XEN) 000000000009cc00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cff70000 (usable) (XEN) 00000000cff70000 - 00000000cff7e000 (ACPI data) (XEN) 00000000cff7e000 - 00000000cffd0000 (ACPI NVS) (XEN) 00000000cffd0000 - 00000000d0000000 (reserved) (XEN) 00000000fee00000 - 00000000fee01000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) System RAM: 8191MB (8387632kB) (XEN) ACPI: RSDP 000FB030, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFF70100, 0054 (r1 A_M_I_ OEMXSDT 7000809 MSFT 97) (XEN) ACPI: FACP CFF70290, 00F4 (r3 A_M_I_ OEMFACP 7000809 MSFT 97) (XEN) ACPI: DSDT CFF70440, 963E (r1 A0986 A0986000 0 INTL 20060113) (XEN) ACPI: FACS CFF7E000, 0040 (XEN) ACPI: APIC CFF70390, 006C (r1 A_M_I_ OEMAPIC 7000809 MSFT 97) (XEN) ACPI: MCFG CFF70400, 003C (r1 A_M_I_ OEMMCFG 7000809 MSFT 97) (XEN) ACPI: OEMB CFF7E040, 0081 (r1 A_M_I_ AMI_OEM 7000809 MSFT 97) (XEN) ACPI: HPET CFF79A80, 0038 (r1 A_M_I_ OEMHPET 7000809 MSFT 97) (XEN) ACPI: OSFR CFF79AC0, 00B0 (r1 A_M_I_ OEMOSFR 7000809 MSFT 97) (XEN) NUMA turned off (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cff7e00c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) Processor #0 7:7 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) (XEN) Processor #1 7:7 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) (XEN) Processor #2 7:7 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) (XEN) Processor #3 7:7 APIC version 20 (XEN) ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000 (XEN) Using ACPI (MADT) for SMP configuration information (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Initializing CPU#0 (XEN) Detected 2833.074 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) MCE: Intel newly family MC Init (XEN) Intel machine check reporting enabled on CPU#0. (XEN) CPU0: Thermal monitoring enaCMCI: CPU0 has no CMCI support (XEN) CPU0: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz 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) MCE: Intel newly family MC Init (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 Q9550 @ 2.83GHz 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) MCE: Intel newly family MC Init (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 Q9550 @ 2.83GHz 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) MCE: Intel newly family MC Init (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 Q9550 @ 2.83GHz 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) microcode.c:73:d32767 microcode: CPU2 resumed (XEN) Brought up 4 CPUs (XEN) microcode.c:73:d32767 microcode: CPU3 resumed (XEN) I/O virtualisation disabled (XEN) ACPI sleep modes: S3 (XEN) mcheck_poll: Init_mcheck_timer (XEN) mcheck_poll: Machine check polling timer started. (XEN) *** LOADING DOMAIN 0 *** (XEN) 'H' pressed -> dumping heap info (now-0x0:170E26DF) (XEN) heap[node=0][zone=0] -> 0 pages (XEN) heap[node=0][zone=1] -> 0 pages (XEN) heap[node=0][zone=2] -> 0 pages (XEN) heap[node=0][zone=3] -> 0 pages (XEN) heap[node=0][zone=4] -> 0 pages (XEN) heap[node=0][zone=5] -> 0 pages (XEN) heap[node=0][zone=6] -> 0 pages (XEN) heap[node=0][zone=7] -> 0 pages (XEN) heap[node=0][zone=8] -> 256 pages (XEN) heap[node=0][zone=9] -> 512 pages (XEN) heap[node=0][zone=10] -> 1024 pages (XEN) heap[node=0][zone=11] -> 2048 pages (XEN) heap[node=0][zone=12] -> 4096 pages (XEN) heap[node=0][zone=13] -> 8192 pages (XEN) heap[node=0][zone=14] -> 16384 pages (XEN) heap[node=0][zone=15] -> 32768 pages (XEN) heap[node=0][zone=16] -> 65536 pages (XEN) heap[node=0][zone=17] -> 131072 pages (XEN) heap[node=0][zone=18] -> 262144 pages (XEN) heap[node=0][zone=19] -> 277883 pages (XEN) heap[node=0][zone=20] -> 1048576 pages (XEN) heap[node=0][zone=21] -> 171413 pages (XEN) heap[node=0][zone=22] -> 0 pages (XEN) heap[node=0][zone=23] -> 0 pages (XEN) heap[node=0][zone=24] -> 0 pages (XEN) heap[node=0][zone=25] -> 0 pages (XEN) heap[node=0][zone=26] -> 0 pages (XEN) heap[node=0][zone=27] -> 0 pages (XEN) heap[node=0][zone=28] -> 0 pages (XEN) heap[node=0][zone=29] -> 0 pages (XEN) heap[node=0][zone=30] -> 0 pages (XEN) heap[node=0][zone=31] -> 0 pages (XEN) heap[node=0][zone=32] -> 0 pages (XEN) heap[node=0][zone=33] -> 0 pages (XEN) heap[node=0][zone=34] -> 0 pages (XEN) heap[node=0][zone=35] -> 0 pages (XEN) heap[node=0][zone=36] -> 0 pages (XEN) heap[node=0][zone=37] -> 0 pages (XEN) heap[node=0][zone=38] -> 0 pages (XEN) heap[node=0][zone=39] -> 0 pages (XEN) number of MP IRQ sources: 15. (XEN) number of IO-APIC #4 registers: 24. (XEN) testing the IO APIC....................... (XEN) IO APIC #4...... (XEN) .... register #00: 04000000 (XEN) ....... : physical APIC id: 04 (XEN) ....... : Delivery Type: 0 (XEN) ....... : LTS : 0 (XEN) .... register #01: 00170020 (XEN) ....... : max redirection entries: 0017 (XEN) ....... : PRQ implemented: 0 (XEN) ....... : IO APIC version: 0020 (XEN) .... IRQ redirection table: (XEN) NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: (XEN) 00 000 00 1 0 0 0 0 0 0 00 (XEN) 01 00F 0F 0 0 0 0 0 1 1 20 (XEN) 02 00F 0F 0 0 0 0 0 1 1 F0 (XEN) 03 00F 0F 0 0 0 0 0 1 1 28 (XEN) 04 00F 0F 0 0 0 0 0 1 1 F1 (XEN) 05 00F 0F 0 0 0 0 0 1 1 30 (XEN) 06 00F 0F 0 0 0 0 0 1 1 38 (XEN) 07 00F 0F 0 0 0 0 0 1 1 40 (XEN) 08 00F 0F 0 0 0 0 0 1 1 48 (XEN) 09 00F 0F 1 1 0 0 0 1 1 50 (XEN) 0a 00F 0F 0 0 0 0 0 1 1 58 (XEN) 0b 00F 0F 0 0 0 0 0 1 1 60 (XEN) 0c 00F 0F 0 0 0 0 0 1 1 68 (XEN) 0d 00F 0F 0 0 0 0 0 1 1 70 (XEN) 0e 00F 0F 0 0 0 0 0 1 1 78 (XEN) 0f 00F 0F 0 0 0 0 0 1 1 88 (XEN) 10 000 00 1 0 0 0 0 0 0 00 (XEN) 11 000 00 1 0 0 0 0 0 0 00 (XEN) 12 000 00 1 0 0 0 0 0 0 00 (XEN) 13 000 00 1 0 0 0 0 0 0 00 (XEN) 14 000 00 1 0 0 0 0 0 0 00 (XEN) 15 000 00 1 0 0 0 0 0 0 00 (XEN) 16 000 00 1 0 0 0 0 0 0 00 (XEN) 17 000 00 1 0 0 0 0 0 0 00 (XEN) Using vector-based indexing (XEN) IRQ to pin mappings: (XEN) IRQ240 -> 0:2 (XEN) IRQ32 -> 0:1 (XEN) IRQ40 -> 0:3 (XEN) IRQ241 -> 0:4 (XEN) IRQ48 -> 0:5 (XEN) IRQ56 -> 0:6 (XEN) IRQ64 -> 0:7 (XEN) IRQ72 -> 0:8 (XEN) IRQ80 -> 0:9 (XEN) IRQ88 -> 0:10 (XEN) IRQ96 -> 0:11 (XEN) IRQ104 -> 0:12 (XEN) IRQ112 -> 0:13 (XEN) IRQ120 -> 0:14 (XEN) IRQ136 -> 0:15 (XEN) .................................... done. (XEN) CPU NMI (XEN) 0 0 (XEN) 1 0 (XEN) 2 0 (XEN) 3 0 (XEN) dom0 vcpu0: NMI neither pending nor masked (XEN) Physical memory information: (XEN) Xen heap: 0kB free (XEN) heap[08]: 1024kB free (XEN) heap[09]: 2048kB free (XEN) heap[10]: 4096kB free (XEN) heap[11]: 8192kB free (XEN) heap[12]: 16384kB free (XEN) heap[13]: 32768kB free (XEN) heap[14]: 65536kB free (XEN) heap[15]: 131072kB free (XEN) heap[16]: 262144kB free (XEN) heap[17]: 524288kB free (XEN) heap[18]: 1048576kB free (XEN) heap[19]: 1111532kB free (XEN) heap[20]: 4194304kB free (XEN) heap[21]: 685652kB free (XEN) Dom heap: 8087616kB free (XEN) Guest interrupt information: (XEN) IO-APIC interrupt information: (XEN) IRQ 0 Vec240: (XEN) Apic 0x00, Pin 2: vector=240, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) IRQ 1 Vec 32: (XEN) Apic 0x00, Pin 1: vector=32, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) IRQ 3 Vec 40: (XEN) Apic 0x00, Pin 3: vector=40, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) IRQ 4 Vec241: (XEN) Apic 0x00, Pin 4: vector=241, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) IRQ 5 Vec 48: (XEN) Apic 0x00, Pin 5: vector=48, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) IRQ 6 Vec 56: (XEN) Apic 0x00, Pin 6: vector=56, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) IRQ 7 Vec 64: (XEN) Apic 0x00, Pin 7: vector=64, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) IRQ 8 Vec 72: (XEN) Apic 0x00, Pin 8: vector=72, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) IRQ 9 Vec 80: (XEN) Apic 0x00, Pin 9: vector=80, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=level, mask=1 (XEN) IRQ 10 Vec 88: (XEN) Apic 0x00, Pin 10: vector=88, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) IRQ 11 Vec 96: (XEN) Apic 0x00, Pin 11: vector=96, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) IRQ 12 Vec104: (XEN) Apic 0x00, Pin 12: vector=104, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) IRQ 13 Vec112: (XEN) Apic 0x00, Pin 13: vector=112, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) IRQ 14 Vec120: (XEN) Apic 0x00, Pin 14: vector=120, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) IRQ 15 Vec136: (XEN) Apic 0x00, Pin 15: vector=136, delivery_mode=1, dest_mode=logical, delivery_status=0, polarity=0, irr=0, trigger=edge, mask=0 (XEN) Scheduler: SMP Credit Scheduler (credit) (XEN) info: (XEN) ncpus = 4 (XEN) master = 0 (XEN) credit = 1200 (XEN) credit balance = 0 (XEN) weight = 0 (XEN) runq_sort = 0 (XEN) default-weight = 256 (XEN) msecs per tick = 10ms (XEN) credits per tick = 100 (XEN) ticks per tslice = 3 (XEN) ticks per acct = 3 (XEN) idlers: 0000000f (XEN) stats: (XEN) vcpu_check = 5 (XEN) schedule = 0 (XEN) acct_run = 0 (XEN) acct_no_work = 0 (XEN) acct_balance = 0 (XEN) acct_reorder = 0 (XEN) acct_min_credit = 0 (XEN) acct_vcpu_active = 0 (XEN) acct_vcpu_idle = 0 (XEN) vcpu_sleep = 0 (XEN) vcpu_wake_running = 0 (XEN) vcpu_wake_onrunq = 0 (XEN) vcpu_wake_runnable = 0 (XEN) vcpu_wake_not_runnable = 0 (XEN) vcpu_park = 0 (XEN) vcpu_unpark = 0 (XEN) tickle_local_idler = 0 (XEN) tickle_local_over = 0 (XEN) tickle_local_under = 0 (XEN) tickle_local_other = 0 (XEN) tickle_idlers_none = 0 (XEN) tickle_idlers_some = 0 (XEN) load_balance_idle = 0 (XEN) load_balance_over = 0 (XEN) load_balance_other = 0 (XEN) steal_trylock_failed = 0 (XEN) steal_peer_idle = 0 (XEN) migrate_queued = 0 (XEN) migrate_running = 0 (XEN) dom_init = 2 (XEN) dom_destroy = 0 (XEN) vcpu_init = 5 (XEN) vcpu_destroy = 0 (XEN) active vcpus: (XEN) NOW=0x00000000184B6C0A (XEN) CPU[00] sort=0, sibling=00000001, core=0000000f (XEN) run: [32767.0] pri=-64 flags=0 cpu=0 (XEN) CPU[01] sort=0, sibling=00000002, core=0000000f (XEN) run: [32767.1] pri=-64 flags=0 cpu=1 (XEN) CPU[02] sort=0, sibling=00000004, core=0000000f (XEN) run: [32767.2] pri=-64 flags=0 cpu=2 (XEN) CPU[03] sort=0, sibling=00000008, core=0000000f (XEN) run: [32767.3] pri=-64 flags=0 cpu=3 (XEN) elf_parse_binary: phdr: paddr=0x200000 memsz=0x488000 (XEN) 'd' pressed -> dumping registers (XEN) (XEN) *** Dumping CPU1 host state: *** (XEN) elf_parse_binary: phdr: paddr=0x688000 memsz=0x93c94 (XEN) ----[ Xen-3.4-unstable x86_64 debug=y Not tainted ]---- (XEN) elf_parse_binary: phdr: paddr=0x71c000 memsz=0x8c8 (XEN) CPU: 1 (XEN) elf_parse_binary: phdr: paddr=0x71e000 memsz=0x64200 (XEN) RIP: e008:[<ffff828c8010e354>]elf_parse_binary: phdr: paddr=0x783000 memsz=0x124a0 (XEN) __dump_execstate+0x9/0x78elf_parse_binary: phdr: paddr=0x796000 memsz=0xc8160 (XEN) (XEN) RFLAGS: 0000000000010296 elf_parse_binary: memory: 0x200000 -> 0x85e160 (XEN) CONTEXT: hypervisor (XEN) elf_xen_parse_note: GUEST_OS = "linux" (XEN) rax: 000000000000ffff rbx: 0000000000000064 rcx: 0000000000000000 (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) rdx: 0000000000000000 rsi: 000000000000000a rdi: 0000000000000000 (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) rbp: ffff83022ffdfc98 rsp: ffff83022ffdfc88 r8: 0000000000000004 (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) r9: ffff828c801d95a0 r10: 00000000fffffffc r11: 0000000000000001 (XEN) elf_xen_parse_note: ENTRY = 0xffffffff80727200 (XEN) r12: ffff83022ffdfe38 r13: 0000000000000064 r14: 0000000000000286 (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff80209000 (XEN) r15: ffff83022ffdfe38 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb" (XEN) cr3: 00000000cfc7c000 cr2: 0000000000000000 (XEN) elf_xen_parse_note: PAE_MODE = "yes" (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) elf_xen_parse_note: LOADER = "generic" (XEN) Xen stack trace from rsp=ffff83022ffdfc88: (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) 0000000000000064elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) 0000000000000064elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) ffff83022ffdfcd8elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) ffff828c8010e420elf_xen_addr_calc_check: addresses: (XEN) (XEN) virt_base = 0xffffffff80000000 (XEN) ffff83022ffdfcc8 elf_paddr_offset = 0x0 (XEN) 0000000000000064 virt_offset = 0xffffffff80000000 (XEN) ffff83022ffdfe38 virt_kstart = 0xffffffff80200000 (XEN) 0000000000000064 virt_kend = 0xffffffff8085e160 (XEN) virt_entry = 0xffffffff80727200 (XEN) (XEN) p2m_base = 0xffffffffffffffff (XEN) 0000000000000286 Xen kernel: 64-bit, lsb, compat32 (XEN) ffff83022ffdfe38 Dom0 kernel: 64-bit, PAE, lsb, paddr 0x200000 -> 0x85e160 (XEN) ffff83022ffdfcf8PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000210000000->0000000220000000 ffff828c8010e5af (196608 pages to be allocated) (XEN) (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff80200000->ffffffff8085e160 (XEN) Init. ramdisk: ffffffff8085f000->ffffffff8bbc0e00 (XEN) Phys-Mach map: ffffffff8bbc1000->ffffffff8bdc1000 (XEN) Start info: ffffffff8bdc1000->ffffffff8bdc14b4 (XEN) Page tables: ffffffff8bdc2000->ffffffff8be25000 (XEN) Boot stack: ffffffff8be25000->ffffffff8be26000 (XEN) TOTAL: ffffffff80000000->ffffffff8c000000 (XEN) ffff83022ffdfe38 ENTRY ADDRESS: ffffffff80727200 (XEN) ffff828c801f7f28Dom0 has maximum 4 VCPUs (XEN) ffff83022ffdfd08elf_load_binary: phdr 0 at 0xffffffff80200000 -> 0xffffffff80688000 (XEN) ffff828c8012859eelf_load_binary: phdr 1 at 0xffffffff80688000 -> 0xffffffff8071bc94 (XEN) (XEN) elf_load_binary: phdr 2 at 0xffffffff8071c000 -> 0xffffffff8071c8c8 (XEN) ffff83022ffdfd38elf_load_binary: phdr 3 at 0xffffffff8071e000 -> 0xffffffff80782200 (XEN) ffff828c80128678elf_load_binary: phdr 4 at 0xffffffff80783000 -> 0xffffffff807954a0 (XEN) ffff83022ffdfd38elf_load_binary: phdr 5 at 0xffffffff80796000 -> 0xffffffff80796000 (XEN) ffff828c801f8000 (XEN) ffff828c801285e2 ffff828c801f8078 ffff83022ffdfd88 ffff828c8012989c (XEN) Scrubbing Free RAM: 0000000000006000 ffff83022fff19e0 6400000000006000 0000000000000001. (XEN) ffff828c80294360 ffff828c801f8000. ffff83022ffdfe38 ffff828c80294388. (XEN) ffff83022ffdfdb8 ffff828c80128f8c ffff828c802a4d00. ffff83022ffdfe38 (XEN) ffff83022ffdff28. ffff828c8028e900 ffff83022ffdfe28. ffff828c80147fdd (XEN) 00000000000000f1. ffff828c8011b446 0000000000000010. ffff828c802a4d24 (XEN) 000000f18012051b. ffff828c802b1f08 0000000000000003. ffff83022ffdff28 (XEN) ffff83022ffdff28. ffff828c8028e900 ffff828c8020dd60. ffff828c8028ad60 (XEN) 00007cfdd00201a7. ffff828c801414e6 ffff828c8028ad60. ffff828c8020dd60 (XEN) ffff828c8028e900. ffff83022ffdff28 ffff83022ffdfee0. ffff83022ffdff28 (XEN) 0000000000000001. 00000000fffffffc ffff828c801d95a0. 00000000fffffffe (XEN) 0000000000000080. 0000000000000001 ffff828c8028e900. 0000000000000282 (XEN) 0000000000002000. 000000f100000000 ffff828c8013b4fe. 000000000000e008 (XEN) 0000000000000246. ffff83022ffdfee0 0000000000000000. ffff83022ffdff20 (XEN) ffff828c8013d742. ffff8300cfafa000 0000000000000020. 0000000000000008 (XEN) Xen call trace: (XEN) .[<ffff828c8010e354>] __dump_execstate+0x9/0x78 (XEN) .[<ffff828c8010e420>] dump_registers+0x5d/0x135 (XEN) .[<ffff828c8010e5af>] handle_keypress+0x76/0xa7 (XEN) .[<ffff828c8012859e>] __serial_rx+0x16/0x5a (XEN) .[<ffff828c80128678>] serial_rx+0x96/0xa1 (XEN) .[<ffff828c8012989c>] serial_rx_interrupt+0xb3/0xc9 (XEN) .[<ffff828c80128f8c>]. ns16550_interrupt+0x47/0x61 (XEN) .[<ffff828c80147fdd>] do_IRQ+0x40f/0x456 (XEN) .[<ffff828c801414e6>] common_interrupt+0x26/0x30 (XEN) .[<ffff828c8013b4fe>] default_idle+0x2f/0x34 (XEN) .[<ffff828c8013d742>] idle_loop+0xc8/0xe2 (XEN) . (XEN) *** Dumping CPU1 guest state: *** (XEN) .No guest context (CPU is idle). (XEN) . (XEN) *** Dumping CPU0 host state: *** (XEN) .----[ Xen-3.4-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<ffff828c8010e354>] __dump_execstate+0x9/0x78 (XEN) RFLAGS: 0000000000010096 CONTEXT: hypervisor (XEN) rax: ffff83022ffdfc48 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) rdx: ffff828c8028e900 rsi: ffff83022ffdfc48 rdi: 0000000000000000 (XEN) rbp: ffff828c80277c58 rsp: ffff828c80277c48 r8: ffff828c8010e34b (XEN) r9: 0000000000000002 r10: ffff828c802bdb00 r11: 000000756ffb8000 (XEN) r12: ffff828c801e815f r13: ffff828c80277d30 r14: 0000000000000286 (XEN) r15: ffff828c801f7d34 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 00000000cfc7c000 cr2: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen stack trace from rsp=ffff828c80277c48: (XEN) ffff828c801e815f 0000000000000000 ffff828c80277c68 ffff828c8015809c (XEN) 00007d737fd88367 ffff828c801425a0 ffff828c801f7d34 0000000000000286 (XEN) ffff828c80277d30 ffff828c801e815f ffff828c80277e28 0000000000000000 (XEN) 000000756ffb8000 ffff828c802bdb00 0000000000000002 0000000000000004 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000082 (XEN) ffff828c801f7f6c 000000fb00000000 ffff828c801282f8 000000000000e008 (XEN) 0000000000000286 ffff828c80277d28 0000000000000000 0000000000000286 (XEN) 0000000000000000 ffff828c8028fe80 0000003000000008 ffff828c80277e38 (XEN) ffff828c80277d58 0000000000000282 ffff828c8015b758 ffff828c8022e5c0 (XEN) 0000000000132400 0000000000000000 0000000000000001 0000000000000002 (XEN) ffff828c8011b48b ffff828c8022e180 ffff828c80277dc8 ffff828c8011d0b3 (XEN) ffff828c80277dc8 ffff828c80138cd1 ffff828c8011cd9d ffff828c802bdb00 (XEN) ffff828c80277e18 ffff828c8011d3fd c2c2c2c2c2c2c2c2 ffff828c8022e180 (XEN) ffff83022fff1aa0 0000000000130494 0000000000000013 0000000000026090 (XEN) 0000000000132400 0000000000000000 0000000000026480 0000000002648000 (XEN) ffff828c80277e68 ffff828c8021246a ffff828c80277e68 ffff828c802b1aa0 (XEN) 000000000b361e00 00000000c469e000 ffff828c8020dd60 ffff828c8020dc60 (XEN) ffff828c80277f18 ffff828c80221da8 ffff828c802b1aa0 0000000000000000 (XEN) 0000000000000000 000000000008bf40 0000000000000000 ffff83000008bfc0 (XEN) ffff83000008bf40 000000000b5c0e00 0000000000a1c000 ffffffff00000000 (XEN) Xen call trace: (XEN) [<ffff828c8010e354>] __dump_execstate+0x9/0x78 (XEN) [<ffff828c8015809c>] smp_call_function_interrupt+0x99/0xe8 (XEN) [<ffff828c801425a0>] call_function_interrupt+0x30/0x40 (XEN) [<ffff828c801282f8>] printk+0x1b9/0x1c9 (XEN) [<ffff828c8021246a>] scrub_heap_pages+0xbb/0x1ad (XEN) [<ffff828c80221da8>] __start_xen+0x2239/0x2281 (XEN) (XEN) *** Dumping CPU0 guest state: *** (XEN) No guest context (CPU is idle). (XEN) (XEN) *** Dumping CPU2 host state: *** (XEN) .----[ Xen-3.4-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 2 (XEN) RIP: e008:[<ffff828c8010e354>]. __dump_execstate+0x9/0x78 (XEN) RFLAGS: 0000000000010092 .CONTEXT: hypervisor (XEN) rax: ffff83022ffdfc48 rbx: ffff83022ffcff28 rcx: 0000000000000001 (XEN) .rdx: ffff828c8028e900 rsi: ffff83022ffdfc48 rdi: 0000000000000000 (XEN) .rbp: ffff83022ffcfe18 rsp: ffff83022ffcfe08 r8: ffff828c8010e34b (XEN) .r9: ffff83022fff1998 r10: 00000000fffffff6 r11: 0000000000000007 (XEN) .r12: ffff83022ffcff28 r13: ffff828c8028e900 r14: ffff828c8020dd60 (XEN) .r15: ffff828c8028ad60 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) .cr3: 00000000cfc7c000 cr2: 0000000000000000 (XEN) .ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen stack trace from rsp=ffff83022ffcfe08: (XEN) . ffff83022ffcfe20 ffff83022ffcff28. ffff83022ffcfe28 ffff828c8015809c. (XEN) 00007cfdd00301a7 ffff828c801425a0. ffff828c8028ad60 ffff828c8020dd60. (XEN) ffff828c8028e900 ffff83022ffcff28. ffff83022ffcfee0 ffff83022ffcff28. (XEN) 0000000000000007 00000000fffffff6. ffff83022fff1998 0000000000000004. (XEN) 0000000000000100 0000000000000001. ffff828c8028e900 ffff828c802325c0. (XEN) 0000000000004000 000000fb00000000. ffff828c8013b4fe 000000000000e008. (XEN) 0000000000000246 ffff83022ffcfee0. 0000000000000000 ffff83022ffcff20. (XEN) ffff828c8013d742 ffff8801f1498100. 0000000000000020 0000000000000010. (XEN) 0000000000000002 0000000000000002 0000000000000002. ffff83022ffcfeb0 (XEN) 0000000000000000. ffffffff80637000done. (XEN) ffff8801f1498100Xen trace buffers: disabled (XEN) ffffffffffffffb8Std. Loglevel: All (XEN) (XEN) Guest Loglevel: All 0000000001d41038 0000000001d41010 (XEN) 0000000000000246*** Serial input -> DOM0 8101010101010100 (type 'CTRL-a' three times to switch input to Xen) (XEN) (XEN) 7efefefefefefeff 0000000001d41038 000000000000004e ffffffff8020732a (XEN) 0000000000000000 00000000deadbeef 00000000deadbeef 0000010000000000 (XEN) ffffffff8020732a 000000000000e033 0000000000000246 ffff8801ea123990 (XEN) 000000000000e02b ffffffffffffffff ffffffffffffffff fffffffffdffffff (XEN) ffffffffffffffff ffffffff00000002 ffff8300cff68000 (XEN) Xen call trace: (XEN) [<ffff828c8010e354>] __dump_execstate+0x9/0x78 (XEN) [<ffff828c8015809c>] smp_call_function_interrupt+0x99/0xe8 (XEN) [<ffff828c801425a0>] call_function_interrupt+0x30/0x40 (XEN) [<ffff828c8013b4fe>] default_idle+0x2f/0x34 (XEN) [<ffff828c8013d742>] idle_loop+0xc8/0xe2 (XEN) (XEN) *** Dumping CPU2 guest state: *** (XEN) No guest context (CPU is idle). (XEN) (XEN) *** Dumping CPU3 host state: *** (XEN) ----[ Xen-3.4-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 3 (XEN) RIP: e008:[<ffff828c8010e354>] __dump_execstate+0x9/0x78 (XEN) RFLAGS: 0000000000010092 CONTEXT: hypervisor (XEN) rax: ffff83022ffdfc48 rbx: ffff83022ffc7f28 rcx: 0000000000000001 (XEN) rdx: ffff828c8028e900 rsi: ffff83022ffdfc48 rdi: 0000000000000000 (XEN) rbp: ffff83022ffc7e18 rsp: ffff83022ffc7e08 r8: ffff828c8010e34b (XEN) r9: ffff83022fff1a58 r10: 00000000fffffffc r11: 0000000000000001 (XEN) r12: ffff83022ffc7f28 r13: ffff828c8028e900 r14: ffff828c8020dd60 (XEN) r15: ffff828c8028ad60 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 00000000cfc7c000 cr2: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen stack trace from rsp=ffff83022ffc7e08: (XEN) ffff828c8020dd60 ffff83022ffc7f28 ffff83022ffc7e28 ffff828c8015809c (XEN) 00007cfdd00381a7 ffff828c801425a0 ffff828c8028ad60 ffff828c8020dd60 (XEN) ffff828c8028e900 ffff83022ffc7f28 ffff83022ffc7ee0 ffff83022ffc7f28 (XEN) 0000000000000001 00000000fffffffc ffff83022fff1a58 00000000fffffffe (XEN) 0000000000000180 0000000000000001 ffff828c8028e900 ffff828c802345c0 (XEN) 0000000000006000 000000fb00000000 ffff828c8013b4fe 000000000000e008 (XEN) 0000000000000246 ffff83022ffc7ee0 0000000000000000 ffff83022ffc7f20 (XEN) ffff828c8013d742 ffff8300cfaf6000 0000000000000020 0000000000000018 (XEN) 0000000000000003 0000000000000003 0000000000000003 ffff83022ffc7eb0 (XEN) ffff8801e40b5578 0000000000000000 ffff8801e40b5400 0000000000000000 (XEN) ffff8801f149ff20 0000000000000003 0000000000000246 0000000000000000 (XEN) 0000000000000003 0000000000000000 0000000000000000 0000000000005dab (XEN) ffffffffff5fc000 ffff8801ea9fd080 ffff8801f1428cc0 000000f900000000 (XEN) ffffffff80282737 000000000000e033 0000000000000297 ffff8801f0c85b78 (XEN) 000000000000e02b ffffffffffffffff ffffffffffdfffff ffffffffffffffff (XEN) ffffffffffffffff ffffffff00000003 ffff8300cfafa000 (XEN) Xen call trace: (XEN) [<ffff828c8010e354>] __dump_execstate+0x9/0x78 (XEN) [<ffff828c8015809c>] smp_call_function_interrupt+0x99/0xe8 (XEN) [<ffff828c801425a0>] call_function_interrupt+0x30/0x40 (XEN) [<ffff828c8013b4fe>] default_idle+0x2f/0x34 (XEN) [<ffff828c8013d742>] idle_loop+0xc8/0xe2 (XEN) (XEN) *** Dumping CPU3 guest state: *** (XEN) No guest context (CPU is idle). (XEN) (XEN) Freed 124kB init memory. (XEN) domain.c:525:d0 Attempt to change CR4 flags 00002660 -> 00042660 mapping kernel into physical memory Xen: setup ISA identity maps about to get started... [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.29-rc7-tip (root@ServerINTR) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) ) #4 SMP Sun Mar 8 03:23:45 EDT 2009 [ 0.000000] Command line: root=/dev/sdb1 ro console=hvc0 earlyprintk=xen [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 000000000009cc00 (usable) [ 0.000000] Xen: 000000000009cc00 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 000000000bbc1000 (usable) [ 0.000000] Xen: 000000000bbc1000 - 000000000bdc2000 (reserved) [ 0.000000] Xen: 000000000bdc2000 - 0000000040000000 (usable) [ 0.000000] Xen: 00000000cff70000 - 00000000cff7e000 (ACPI data) [ 0.000000] Xen: 00000000cff7e000 - 00000000cffd0000 (ACPI NVS) [ 0.000000] Xen: 00000000cffd0000 - 00000000d0000000 (reserved) [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) [ 0.000000] console [xenboot0] enabled [ 0.000000] DMI present. [ 0.000000] AMI BIOS detected: BIOS may corrupt low RAM, working around it. [ 0.000000] last_pfn = 0x40000 max_arch_pfn = 0x100000000 [ 0.000000] init_memory_mapping: 0000000000000000-0000000040000000 [ 0.000000] RAMDISK: 0085f000 - 0bbc0e00 [ 0.000000] ACPI: RSDP 000FB030, 0024 (r2 ACPIAM) [ 0.000000] ACPI: XSDT CFF70100, 0054 (r1 A_M_I_ OEMXSDT 7000809 MSFT 97) [ 0.000000] ACPI: FACP CFF70290, 00F4 (r3 A_M_I_ OEMFACP 7000809 MSFT 97) [ 0.000000] FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4) [ 0.000000] ACPI: DSDT CFF70440, 963E (r1 A0986 A0986000 0 INTL 20060113) [ 0.000000] ACPI: FACS CFF7E000, 0040 [ 0.000000] ACPI: APIC CFF70390, 006C (r1 A_M_I_ OEMAPIC 7000809 MSFT 97) [ 0.000000] ACPI: MCFG CFF70400, 003C (r1 A_M_I_ OEMMCFG 7000809 MSFT 97) [ 0.000000] ACPI: OEMB CFF7E040, 0081 (r1 A_M_I_ AMI_OEM 7000809 MSFT 97) [ 0.000000] ACPI: HPET CFF79A80, 0038 (r1 A_M_I_ OEMHPET 7000809 MSFT 97) [ 0.000000] ACPI: OSFR CFF79AC0, 00B0 (r1 A_M_I_ OEMOSFR 7000809 MSFT 97) [ 0.000000] (7 early reservations) ==> bootmem [0000000000 - 0040000000] [ 0.000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] [ 0.000000] #1 [000bdc2000 - 000be25000] XEN PAGETABLES ==> [000bdc2000 - 000be25000] [ 0.000000] #2 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000] [ 0.000000] #3 [0000200000 - 000085e160] TEXT DATA BSS ==> [0000200000 - 000085e160] [ 0.000000] #4 [000085f000 - 000bbc0e00] RAMDISK ==> [000085f000 - 000bbc0e00] [ 0.000000] #5 [000be25000 - 000be68280] BRK ==> [000be25000 - 000be68280] [ 0.000000] #6 [000be69000 - 000c009000] PGTABLE ==> [000be69000 - 000c009000] [ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780 [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x00100000 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x0000009c [ 0.000000] 0: 0x00000100 -> 0x0000bbc1 [ 0.000000] 0: 0x0000bdc2 -> 0x00040000 [ 0.000000] ACPI: PM-Timer IO Port: 0x808 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) [ 0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 4, version 0, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000 [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs (XEN) io_apic.c:2147: (XEN) ioapic_guest_write: apic=0, pin=2, old_irq=0, new_irq=-1 (XEN) ioapic_guest_write: old_entry=000009f0, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to remove IO-APIC pin of in-use IRQ! (XEN) io_apic.c:2147: (XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=-1 (XEN) ioapic_guest_write: old_entry=000009f1, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to remove IO-APIC pin of in-use IRQ! [ 0.000000] Allocating PCI resources starting at 50000000 (gap: 40000000:8ff70000) [ 0.000000] NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:4 nr_node_ids:1 [ 0.000000] PERCPU: Allocated 19 4k pages, static data 74912 bytes [ 0.000000] Xen: using vcpu_info placement [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 256298 [ 0.000000] Kernel command line: root=/dev/sdb1 ro console=hvc0 earlyprintk=xen [ 0.000000] Initializing CPU#0 [ 0.000000] NR_IRQS:1280 [ 0.000000] xen_set_ioapic_routing: irq 0 gsi 0 vector 240 ioapic 0 pin 0 triggering 0 polarity 0 (XEN) io_apic.c:2160: (XEN) ioapic_guest_write: apic=0, pin=0, old_irq=-1, new_irq=0 (XEN) ioapic_guest_write: old_entry=00010900, new_entry=000009f0 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! [ 0.000000] xen_set_ioapic_routing: irq 1 gsi 1 vector 32 ioapic 0 pin 1 triggering 0 polarity 0 [ 0.000000] xen_set_ioapic_routing: irq 3 gsi 3 vector 40 ioapic 0 pin 3 triggering 0 polarity 0 [ 0.000000] xen_set_ioapic_routing: irq 4 gsi 4 vector 241 ioapic 0 pin 4 triggering 0 polarity 0 [ 0.000000] xen_set_ioapic_routing: irq 5 gsi 5 vector 48 ioapic 0 pin 5 triggering 0 polarity 0 [ 0.000000] xen_set_ioapic_routing: irq 6 gsi 6 vector 56 ioapic 0 pin 6 triggering 0 polarity 0 [ 0.000000] xen_set_ioapic_routing: irq 7 gsi 7 vector 64 ioapic 0 pin 7 triggering 0 polarity 0 [ 0.000000] xen_set_ioapic_routing: irq 8 gsi 8 vector 72 ioapic 0 pin 8 triggering 0 polarity 0 [ 0.000000] xen_set_ioapic_routing: irq 9 gsi 9 vector 80 ioapic 0 pin 9 triggering 1 polarity 0 [ 0.000000] xen_set_ioapic_routing: irq 10 gsi 10 vector 88 ioapic 0 pin 10 triggering 0 polarity 0 [ 0.000000] xen_set_ioapic_routing: irq 11 gsi 11 vector 96 ioapic 0 pin 11 triggering 0 polarity 0 [ 0.000000] xen_set_ioapic_routing: irq 12 gsi 12 vector 104 ioapic 0 pin 12 triggering 0 polarity 0 [ 0.000000] xen_set_ioapic_routing: irq 13 gsi 13 vector 112 ioapic 0 pin 13 triggering 0 polarity 0 [ 0.000000] xen_set_ioapic_routing: irq 14 gsi 14 vector 120 ioapic 0 pin 14 triggering 0 polarity 0 [ 0.000000] xen_set_ioapic_routing: irq 15 gsi 15 vector 136 ioapic 0 pin 15 triggering 0 polarity 0 [ 0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes) [ 0.000000] Detected 2833.074 MHz processor. [ 0.010000] Console: colour VGA+ 80x25 [ 0.010000] console handover: boot [xenboot0] -> real [hvc0] [ 0.010000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.010000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) [ 0.010000] allocated 10485760 bytes of page_cgroup [ 0.010000] please try cgroup_disable=memory option if you don't want [ 0.010000] Checking aperture... [ 0.010000] No AGP bridge found [ 0.010000] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 0.010000] Placing 64MB software IO TLB between ffff88000da94000 - ffff880011a94000 [ 0.010000] software IO TLB at phys 0xda94000 - 0x11a94000 [ 0.010000] Memory: 760608k/1048576k available (3217k kernel code, 2516k absent, 285076k reserved, 1754k data, 444k init) [ 0.010000] installing Xen timer for CPU 0 [ 0.010000] Calibrating delay loop (skipped), value calculated using timer frequency.. 5666.14 BogoMIPS (lpj=28330740) [ 0.010062] Security Framework initialized [ 0.020000] SELinux: Disabled at boot. [ 0.020024] Mount-cache hash table entries: 256 [ 0.030175] Initializing cgroup subsys ns [ 0.040000] Initializing cgroup subsys cpuacct [ 0.040000] Initializing cgroup subsys memory [ 0.040032] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.050000] CPU: L2 cache: 6144K [ 0.050005] CPU: Physical Processor ID: 0 [ 0.060000] CPU: Processor Core ID: 0 [ 0.060011] SMP alternatives: switching to UP code [ 0.094117] ACPI: Core revision 20081204 [ 0.120069] cpu 0 spinlock event irq 25 [ 0.130295] installing Xen timer for CPU 1 [ 0.140303] cpu 1 spinlock event irq 31 [ 0.150046] SMP alternatives: switching to SMP code [ 0.000005] Initializing CPU#1 [ 0.000040] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.000043] CPU: L2 cache: 6144K [ 0.000046] CPU: Physical Processor ID: 0 [ 0.000048] CPU: Processor Core ID: 0 [ 0.190272] installing Xen timer for CPU 2 [ 0.200031] cpu 2 spinlock event irq 37 [ 0.000015] Initializing CPU#2 [ 0.000065] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.000068] CPU: L2 cache: 6144K [ 0.000071] CPU: Physical Processor ID: 0 [ 0.000073] CPU: Processor Core ID: 0 [ 0.210874] installing Xen timer for CPU 3 [ 0.220011] cpu 3 spinlock event irq 43 [ 0.000006] Initializing CPU#3 [ 0.000038] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.000042] CPU: L2 cache: 6144K [ 0.000045] CPU: Physical Processor ID: 0 [ 0.000047] CPU: Processor Core ID: 0 [ 0.230119] Brought up 4 CPUs [ 0.240995] net_namespace: 1840 bytes [ 0.250004] Booting paravirtualized kernel on Xen [ 0.260000] Xen version: 3.4-unstable (preserve-AD) (dom0) [ 0.260044] Grant table initialized [ 0.270000] Time: 3:37:51 Date: 03/08/09 [ 0.270101] NET: Registered protocol family 16 [ 0.280619] xenbus_probe_init ok [ 0.290443] ACPI: bus type pci registered [ 0.300657] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255 [ 0.310000] PCI: Not using MMCONFIG. [ 0.310000] PCI: Using configuration type 1 for base access [ 0.315465] bio: create slab <bio-0> at 0 [ 0.344867] ACPI: Interpreter enabled [ 0.350000] ACPI: (supports S0 S1 S3 S5) [ 0.350032] ACPI: Using IOAPIC for interrupt routing [ 0.360083] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255 [ 0.373334] PCI: MCFG area at e0000000 reserved in ACPI motherboard resources [ 0.440783] PCI: Using MMCONFIG at e0000000 - efffffff [ 0.458191] ACPI: No dock devices found. [ 0.460000] ACPI: PCI Root Bridge [PCI0] (0000:00) [ 0.460335] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold [ 0.470000] pci 0000:00:01.0: PME# disabled [ 0.470668] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold [ 0.480000] pci 0000:00:1a.7: PME# disabled [ 0.480156] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold [ 0.490000] pci 0000:00:1b.0: PME# disabled [ 0.490103] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold [ 0.500000] pci 0000:00:1c.0: PME# disabled [ 0.500112] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold [ 0.510000] pci 0000:00:1c.4: PME# disabled [ 0.510121] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold [ 0.520000] pci 0000:00:1c.5: PME# disabled [ 0.520623] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold [ 0.530000] pci 0000:00:1d.7: PME# disabled [ 0.530215] pci 0000:00:1f.0: quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO [ 0.540000] pci 0000:00:1f.0: quirk: region 0500-053f claimed by ICH6 GPIO [ 0.540000] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0294 (mask 0003) [ 0.540000] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 4700 (mask 001f) [ 0.540211] pci 0000:00:1f.2: PME# supported from D3hot [ 0.550000] pci 0000:00:1f.2: PME# disabled [ 0.550683] pci 0000:03:00.0: PME# supported from D0 D1 D3hot [ 0.560000] pci 0000:03:00.0: PME# disabled [ 0.560320] pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.570000] pci 0000:02:00.0: PME# disabled [ 0.570283] pci 0000:05:02.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.580000] pci 0000:05:02.0: PME# disabled [ 0.580148] pci 0000:05:03.0: PME# supported from D0 D1 D2 D3hot [ 0.590000] pci 0000:05:03.0: PME# disabled [ 0.590069] pci 0000:00:1e.0: transparent bridge [ 0.626020] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15) [ 0.630000] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 *11 12 14 15) [ 0.630094] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 14 *15) [ 0.640000] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 10 11 12 14 15) [ 0.640000] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.640000] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 *14 15) [ 0.640000] ACPI: PCI Interrupt Link [LNKG] (IRQs *3 4 5 6 7 10 11 12 14 15) [ 0.640000] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 *7 10 11 12 14 15) [ 0.640256] ACPI Warning (tbutils-0242): Incorrect checksum in table [OEMB] - D6, should be D5 [20081204] [ 0.650169] xenbus_probe_backend_init bus registered ok [ 0.660079] xenbus_probe_frontend_init bus registered ok [ 0.670000] xen_balloon: Initialising balloon driver. [ 0.670808] SCSI subsystem initialized [ 0.680749] PCI: Using ACPI for IRQ routing [ 0.830020] NET: Registered protocol family 8 [ 0.830025] NET: Registered protocol family 20 [ 0.830135] NetLabel: Initializing [ 0.840000] NetLabel: domain hash size = 128 [ 0.840000] NetLabel: protocols = UNLABELED CIPSOv4 [ 0.840000] NetLabel: unlabeled traffic allowed by default [ 0.840114] Xen: Initializing Xen DMA ops [ 0.850000] Xen: Enabling DMA fallback to swiotlb [ 0.930034] pnp: PnP ACPI init [ 0.930051] ACPI: bus type pnp registered [ 0.933805] xen_allocate_pirq: returning irq 8 for gsi 8 [ 0.940010] xen_set_ioapic_routing: irq 8 gsi 8 vector 72 ioapic 0 pin 8 triggering 0 polarity 0 [ 1.116516] xen_allocate_pirq: returning irq 13 for gsi 13 [ 1.126260] xen_set_ioapic_routing: irq 13 gsi 13 vector 112 ioapic 0 pin 13 triggering 0 polarity 0 [ 1.285153] xen_allocate_pirq: returning irq 4 for gsi 4 [ 1.292669] xen_set_ioapic_routing: irq 4 gsi 4 vector 241 ioapic 0 pin 4 triggering 0 polarity 0 [ 1.449583] xen_allocate_pirq: returning irq 1 for gsi 1 [ 1.459114] xen_set_ioapic_routing: irq 1 gsi 1 vector 32 ioapic 0 pin 1 triggering 0 polarity 0 [ 1.633498] pnp: PnP ACPI: found 16 devices [ 1.665340] ACPI: ACPI bus type pnp unregistered [ 1.675336] system 00:01: iomem range 0xfed14000-0xfed19fff has been reserved [ 1.675336] system 00:06: ioport range 0x290-0x29f has been reserved [ 1.675336] system 00:07: ioport range 0x4d0-0x4d1 has been reserved [ 1.675336] system 00:07: ioport range 0x800-0x87f has been reserved [ 1.675336] system 00:07: ioport range 0x500-0x57f could not be reserved [ 1.675336] system 00:07: iomem range 0xfed08000-0xfed08fff has been reserved [ 1.675336] system 00:07: iomem range 0xfed1c000-0xfed1ffff has been reserved [ 1.675336] system 00:07: iomem range 0xfed20000-0xfed3ffff has been reserved [ 1.675336] system 00:07: iomem range 0xfed50000-0xfed8ffff has been reserved [ 1.675336] system 00:0a: iomem range 0xffc00000-0xffdfffff has been reserved [ 1.675336] system 00:0c: iomem range 0xfec00000-0xfec00fff has been reserved [ 1.675336] system 00:0c: iomem range 0xfee00000-0xfee00fff has been reserved [ 1.675336] system 00:0e: iomem range 0xe0000000-0xefffffff has been reserved [ 1.675336] system 00:0f: iomem range 0x0-0x9ffff could not be reserved [ 1.675336] system 00:0f: iomem range 0xc0000-0xcffff could not be reserved [ 1.675336] system 00:0f: iomem range 0xe0000-0xfffff could not be reserved [ 1.675336] system 00:0f: iomem range 0x100000-0xcfffffff could not be reserved [ 3.169123] pci 0000:00:01.0: PCI bridge, secondary bus 0000:01 [ 3.173514] pci 0000:00:01.0: IO window: 0xb000-0xbfff [ 3.173514] pci 0000:00:01.0: MEM window: 0xfa000000-0xfe8fffff [ 3.173514] pci 0000:00:01.0: PREFETCH window: 0x000000d0000000-0x000000dfffffff [ 3.173514] pci 0000:00:1c.0: PCI bridge, secondary bus 0000:04 [ 3.173514] pci 0000:00:1c.0: IO window: disabled [ 3.173514] pci 0000:00:1c.0: MEM window: disabled [ 3.173514] pci 0000:00:1c.0: PREFETCH window: 0x000000f8f00000-0x000000f8ffffff [ 3.173514] pci 0000:00:1c.4: PCI bridge, secondary bus 0000:03 [ 3.173514] pci 0000:00:1c.4: IO window: 0xd000-0xdfff [ 3.173514] pci 0000:00:1c.4: MEM window: 0xfea00000-0xfeafffff [ 3.173514] pci 0000:00:1c.4: PREFETCH window: disabled [ 3.173514] pci 0000:00:1c.5: PCI bridge, secondary bus 0000:02 [ 3.173514] pci 0000:00:1c.5: IO window: 0xc000-0xcfff [ 3.173514] pci 0000:00:1c.5: MEM window: 0xfe900000-0xfe9fffff [ 3.173514] pci 0000:00:1c.5: PREFETCH window: disabled [ 3.173514] pci 0000:00:1e.0: PCI bridge, secondary bus 0000:05 [ 3.173514] pci 0000:00:1e.0: IO window: 0xe000-0xefff [ 3.173514] pci 0000:00:1e.0: MEM window: 0xfeb00000-0xfebfffff [ 3.173514] pci 0000:00:1e.0: PREFETCH window: 0x00000050000000-0x000000500fffff [ 4.593823] xen_set_ioapic_routing: irq 16 gsi 16 vector 144 ioapic 0 pin 16 triggering 1 polarity 1 [ 4.603812] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 4.776695] xen_set_ioapic_routing: irq 17 gsi 17 vector 152 ioapic 0 pin 17 triggering 1 polarity 1 [ 4.786688] pci 0000:00:1c.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 4.786688] xen_allocate_pirq: returning irq 17 for gsi 17 [ 4.786688] xen_set_ioapic_routing: irq 17 gsi 17 vector 152 ioapic 0 pin 17 triggering 1 polarity 1 [ 4.786688] pci 0000:00:1c.4: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 4.786688] xen_allocate_pirq: returning irq 16 for gsi 16 [ 4.786688] xen_set_ioapic_routing: irq 16 gsi 16 vector 144 ioapic 0 pin 16 triggering 1 polarity 1 [ 4.786688] pci 0000:00:1c.5: PCI INT B -> GSI 16 (level, low) -> IRQ 16 [ 5.493035] NET: Registered protocol family 2 [ 5.670171] IP route cache hash table entries: 32768 (order: 6, 262144 bytes) [ 5.670700] TCP established hash table entries: 131072 (order: 9, 2097152 bytes) [ 5.680008] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 5.680008] TCP: Hash tables configured (established 131072 bind 65536) [ 5.680008] TCP reno registered [ 5.960196] NET: Registered protocol family 1 [ 5.975139] checking if image is initramfs... it is [ 6.222600] Freeing initrd memory: 183687k freed [ 6.288023] audit: initializing netlink socket (disabled) [ 6.288045] type=2000 audit(1236483475.893:1): initialized [ 6.293133] VFS: Disk quotas dquot_6.5.2 [ 6.293218] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 6.341269] msgmni has been set to 2406 [ 6.391367] alg: No test for stdrng (krng) [ 6.441057] io scheduler noop registered [ 6.450013] io scheduler anticipatory registered [ 6.450013] io scheduler deadline registered (default) [ 6.607524] io scheduler cfq registered [ 6.660281] Event-channel device installed. [ 6.707369] ***blkif_init [ 6.742701] *** netif_init [ 6.774576] registering netback [ 6.888986] Linux agpgart interface v0.103 [ 6.892628] brd: module loaded [ 6.907157] input: Macintosh mouse button emulation as /devices/virtual/input/input0 [ 6.990251] xen_set_ioapic_routing: irq 19 gsi 19 vector 160 ioapic 0 pin 19 triggering 1 polarity 1 [ 7.000242] ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19 [ 7.173310] ahci: SSS flag set, parallel bus scan disabled [ 7.183244] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode [ 7.183244] ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pmp pio slum part ems [ 7.440116] scsi0 : ahci [ 7.473038] scsi1 : ahci [ 7.506246] scsi2 : ahci [ 7.539525] scsi3 : ahci [ 7.572806] scsi4 : ahci [ 7.606079] scsi5 : ahci [ 7.639519] ata1: SATA max UDMA/133 irq_stat 0x00000040, connection status changed [ 7.649113] ata2: SATA max UDMA/133 irq_stat 0x00000040, connection status changed [ 7.649113] ata3: SATA max UDMA/133 irq_stat 0x00000040, connection status changed [ 7.649113] ata4: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffea80 irq 19 [ 7.649113] ata5: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffeb00 irq 19 [ 7.649113] ata6: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffeb80 irq 19 [ 9.100031] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 9.103114] ata1.00: ATAPI: TSSTcorpCD/DVDW SH-S183A, SB01, max UDMA/33, ATAPI AN [ 9.103129] ata1.00: applying bridge limits [ 9.106657] ata1.00: configured for UDMA/33 [ 9.120859] scsi 0:0:0:0: CD-ROM TSSTcorp CD/DVDW SH-S183A SB01 PQ: 0 ANSI: 5 [ 10.050030] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 10.098681] ata2.00: ATA-7: ST3160811AS, 3.AAE, max UDMA/133 [ 10.098689] ata2.00: 312581808 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 10.156988] ata2.00: configured for UDMA/133 [ 10.170130] scsi 1:0:0:0: Direct-Access ATA ST3160811AS 3.AA PQ: 0 ANSI: 5 [ 11.110031] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 11.160971] ata3.00: ATA-7: ST3160811AS, 3.AAE, max UDMA/133 [ 11.160979] ata3.00: 312581808 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 11.219281] ata3.00: configured for UDMA/133 [ 11.230140] scsi 2:0:0:0: Direct-Access ATA ST3160811AS 3.AA PQ: 0 ANSI: 5 [ 11.580035] ata4: SATA link down (SStatus 0 SControl 300) [ 11.950036] ata5: SATA link down (SStatus 0 SControl 300) [ 12.320032] ata6: SATA link down (SStatus 0 SControl 300) [ 12.340315] xen_allocate_pirq: returning irq 16 for gsi 16 [ 12.340323] xen_set_ioapic_routing: irq 16 gsi 16 vector 144 ioapic 0 pin 16 triggering 1 polarity 1 [ 12.340331] pata_marvell 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 12.340482] scsi6 : pata_marvell [ 12.340731] scsi7 : pata_marvell [ 12.340933] ata7: PATA max UDMA/100 cmd 0xdc00 ctl 0xd880 bmdma 0xd400 irq 16 [ 12.340939] ata8: PATA max UDMA/133 cmd 0xd800 ctl 0xd480 bmdma 0xd408 irq 16 [ 12.520460] ata7.00: ATAPI: Optiarc DVD RW AD-7200A, 1.06, max UDMA/66 [ 12.560475] ata7.00: configured for UDMA/66 [ 12.562499] scsi 6:0:0:0: CD-ROM Optiarc DVD RW AD-7200A 1.06 PQ: 0 ANSI: 5 [ 12.732036] PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 [ 12.732041] PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp [ 12.732593] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 12.770265] mice: PS/2 mouse device common for all mice [ 12.770397] rtc_cmos 00:03: RTC can wake from S4 [ 12.770529] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 [ 12.770561] rtc0: alarms up to one month, y3k, 114 bytes nvram [ 12.770657] cpuidle: using governor ladder [ 12.771209] TCP cubic registered [ 12.771282] Bridge firewalling registered [ 12.771338] IO APIC resources could be not be allocated. [ 12.771678] registered taskstats version 1 [ 12.771832] Magic number: 1:477:613 [ 12.771859] tty ptye3: hash matches [ 12.771933] rtc_cmos 00:03: setting system clock to 2009-03-08 03:38:07 UTC (1236483487) [ 12.771939] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 12.771944] EDD information not available. [ 12.772062] Freeing unused kernel memory: 444k freed [ 12.772196] Write protecting the kernel read-only data: 4604k Loading, please wait... e.c:73:d32767 miXEN) ffff8801f149ff20 0000000000000003 0000000000000246 0000000000000000 (XEN) 0000000000000003 0000000 reser[ 12.789172] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1 ved [ 1.675336] system 00:0c: iomem range 0xfee000Couldnt get a file descriptor referring to the console 00-0xfee0Begin: Loading essential drivers... ... 0fff has b[ 12.866237] fuse init (API version 7.11) een reserved [ 1.675336] syste[ 12.900445] device-mapper: uevent: version 1.0.3 [ 12.900721] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com m 00:0e: iomem rangeDone. Begin: Running /scripts/init-premount ... 0xe0000000-0xefffffff has been reserved [ 1.675336] system 00:0f: iomem range 0x0-0x9ffff could not be resDone. Begin: Mounting root file system... ... erved Begin: Running /scripts/local-top ... Done. [ 1.6Begin: Waiting for root file system... ... 75336] system 00:0f: iomem range 0xc0000-0xcffff[ 13.116519] usbcore: registered new interface driver usbfs [ 13.116551] usbcore: registered new interface driver hub [ 13.116626] usbcore: registered new device driver usb [ 13.119756] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 13.119815] xen_set_ioapic_routing: irq 18 gsi 18 vector 168 ioapic 0 pin 18 triggering 1 polarity 1 [ 13.119826] ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18 [ 13.119873] ehci_hcd 0000:00:1a.7: EHCI Host Controller [ 13.147069] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1 [ 13.250796] ehci_hcd 0000:00:1a.7: debug port 1 [ 13.260005] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xf9fffc00 could not be reserved [ 1.675336] system 00:0f: iomem range 0xe0000-0xfffff could not be reserved [ 1.675336] system 00:0f: iomem range 0x100000-0xcfffff[ 13.570037] efhci_hcd 0000:00:f1a.7: USB 2.0 st arted, EHCI 1.00c ould not [ 13.646346] ubsb usb1: configueration #1 chosen from 1 choice r[ 13.712780] hub 1-0:1.0: USB eshub found e[ 13.762660] hub 1-0:1.0: 6 porvrts detected e[ 13.812807] xden_set_ioapic_ro uting: irq 23 gs i 23 vector 176 ioapic 0 pin 23 triggering 1 pol arity 1 [ 13.822551] e [hci_hcd 0000:00: 1d.7: PCI INT A -> GSI 23 (level , low) -> IRQ 23 3.169[ 13.822551] e1hci_hcd 0000:00:21d.7: EHCI Host 3Controller [ 14.112173] e] hci_hcd 0000:00:p1d.7: new USB bucs registered, asisigned bus numbe r 2 000[ 14.215885] e0:hci_hcd 0000:00:01d.7: debug port0 1 :01.0: P[ 14.221931] ehci_hcd 0000:00:CI1d.7: irq 23, io mem 0xf9fff800 b ridge, secondary bus 0000:01 [ 3.173514] pci 0000:00:01.0: IO window: 0xb000-0xbfff [ 3.173514] pci 0000:00:01.0: MEM window: 0xfa000000-0xfe8fffff [ 3.173514] pci 0000:00:01.0: PREFET[ 14.620099] ehci_hcd 0000:00:CH1d.7: USB 2.0 started, EHCI 1.00 w indow: 0[ 14.694595] usb usb2: configuration #1 chosen from 1 choice [ 14.761063] hub 2-0:1.0: USB hub found x00[ 14.810943] hub 2-0:1.0: 6 ports detected 0000d0000000-0x000000dfffffff [ 3.173514] pci 0000:00:1c.0: PCI bridge, secondary bus 0000[ 14.977530] uhci_hcd: USB Universal Host Controller Interface driver IO window: 0xe000-0xefff [ 3.173514] pci 0000:00:1e.0: MEM window: 0xfeb00000-0xfebfffff [ 3.173514] pci 000G[ 15.210385] xen_allocate_pirq: returning irq 16 for gsi 16 [ 15.220025] xen_set_ioapic_routing: irq 16 gsi 16 vector 144 ioapic 0 pin 16 triggering 1 polarity 1 S(XEN) io_apic.c:2160: (XEN) ioapic_guest_write: apic=0, pin=16, old_irq=16, new_irq=16 (XEN) ioapic_guest_write: old_entry=0000a990, new_entry=0001a990 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! I[ 15.220025] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 16 (level, [ 15.220025] uhci_hcd 0000:00:1a.0: UHCI Host Controller low[ 15.793012] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3 ) -> IRQ 1[ 15.892699] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000a800 6 [ 15.976118] usb usb3: configuration #1 chosen from 1 choice [ 16.042539] hub 3-0:1.0: USB hub found [ 16.092376] hub 3-0:1.0: 2 ports detected [ 16.142531] xen_set_ioapic_routing: irq 21 gsi 21 vector 184 ioapic 0 pin 21 triggering 1 polarity 1 [ [ 16.152218] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21 [ 16.152218] uhci_hcd 0000:00:1a.1: UHCI Host Controller [ 16.408613] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4 4.776695][ 16.508412] uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000a880 xen_set_ioap[ 16.591696] usb usb4: configuration #1 chosen from 1 choice [ 16.658161] hub 4-0:1.0: USB hub found ic_[ 16.708075] hub 4-0:1.0: 2 ports detected r[ 16.758103] xen_allocate_pirq: returning irq 18 for gsi 18 [ 16.767977] xen_set_ioapic_routing: irq 18 gsi 18 vector 168 ioapic 0 pin 18 triggering 1 polarity 1 (XEN) io_apic.c:2160: (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=18, new_irq=18 (XEN) ioapic_guest_write: old_entry=0000a9a8, new_entry=0001a9a8 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! o[ 16.767977] uhci_hcd 0000:00:1a.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18 uting: irq 17[ 16.767977] uhci_hcd 0000:00:1a.2: UHCI Host Controller gs[ 17.340583] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5 i 17 vecto[ 17.440345] uhci_hcd 0000:00:1a.2: irq 18, io base 0x0000ac00 r 15[ 17.523661] usb usb5: configuration #1 chosen from 1 choice [ 17.573480] hub 5-0:1.0: USB hub found [ 17.623294] hub 5-0:1.0: 2 ports detected [ 17.673279] xen_allocate_pirq: returning irq 23 for gsi 23 [ 17.683151] xen_set_ioapic_routing: irq 23 gsi 23 vector 176 ioapic 0 pin 23 triggering 1 polarity 1 (XEN) io_apic.c:2160: (XEN) ioapic_guest_write: apic=0, pin=23, old_irq=23, new_irq=23 (XEN) ioapic_guest_write: old_entry=0000a9b0, new_entry=0001a9b0 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! 2[ 17.683151] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23 ioapic 0 [ 17.683151] uhci_hcd 0000:00:1d.0: UHCI Host Controller pin[ 18.255246] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6 17 trigge[ 18.354923] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000a080 ring 1 p [ [ 18.438149] usb usb6: configuration #1 chosen from 1 choice [ 18.504580] hub 6-0:1.0: USB hub found [ 18.554427] hub 6-0:1.0: 2 ports detected 4[ 18.604412] xen_allocate_pirq: returning irq 19 for gsi 19 [ 18.614286] xen_set_ioapic_routing: irq 19 gsi 19 vector 160 ioapic 0 pin 19 triggering 1 polarity 1 (XEN) io_apic.c:2160: (XEN) ioapic_guest_write: apic=0, pin=19, old_irq=19, new_irq=19 (XEN) ioapic_guest_write: old_entry=0000a9a0, new_entry=0001a9a0 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! .[ 18.614286] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19 786688] xen_a[ 18.614286] uhci_hcd 0000:00:1d.1: UHCI Host Controller llo[ 19.186369] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7 cate_pirq:[ 19.286060] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000a400 returning ir[ 19.369285] usb usb7: configuration #1 chosen from 1 choice [ 19.435696] hub 7-0:1.0: USB hub found q 1[ 19.485568] hub 7-0:1.0: 2 ports detected 7[ 19.535545] xen_allocate_pirq: returning irq 18 for gsi 18 [ 19.545421] xen_set_ioapic_routing: irq 18 gsi 18 vector 168 ioapic 0 pin 18 triggering 1 polarity 1 (XEN) io_apic.c:2160: (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=18, new_irq=18 (XEN) ioapic_guest_write: old_entry=0000a9a8, new_entry=0001a9a8 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! [ 19.545421] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18 for gsi 17 [ 19.545421] uhci_hcd 0000:00:1d.2: UHCI Host Controller [ 20.117496] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8 [ 20.217168] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000a480 [ 4.7866[ 20.300421] usb usb8: configuration #1 chosen from 1 choice [ 20.366829] hub 8-0:1.0: USB hub found 88][ 20.416696] hub 8-0:1.0: 2 ports detected xen_set_ioapic_routing: irq 17 gsi 17 vector 152 ioap [ 7.173310] ahci: SSS flag set, parallel bus scan disabled [ 7.183244] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 20460] ata7.00: ATAPI: Optiarc DVD RW AD-7200A, 1.06, max UDMA/66 [ 12.560475] ata7.00: configured for UDMA/66 [ 1[ 20.833344] xen_allocate_pirq: returning irq 18 for gsi 18 [ 20.840023] xen_set_ioapic_routing: irq 18 gsi 18 vector 168 ioapic 0 pin 18 triggering 1 polarity 1 (XEN) io_apic.c:2160: (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=18, new_irq=18 (XEN) ioapic_guest_write: old_entry=0000a9a8, new_entry=0001a9a8 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! [ 20.840023] skge 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [ 20.840023] skge 1.13 addr 0xfebfc000 irq 18 chip Yukon-Lite rev 9 [ 21.400118] skge eth0: addr 00:22:15:63:f9:9f 0A 1.06 PQ: 0 ANSI: 5 [ 12.732036] PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 [ 12.732041] PNP: PS/2 AUX p[ 21.636141] xen_allocate_pirqo: returning irq rt19 for gsi 19 [ 21.640108] u sb 8-1: new low dspeed USB devicei using uhci_hcd saand address 2 [ 21.640021] xben_set_ioapic_roluting: irq 19 gsei 19 vector 160 d,ioapic 0 pin 19 triggering 1 pol iarity 1 f (XEN) io_apic.c:2160: (XEN) ioapic_guest_write: apic=0, pin=19, old_irq=19, new_irq=19 (XEN) ioapic_guest_write: old_entry=0000a9a0, new_entry=0001a9a0 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! [ 21.640021] othci1394 0000:05:hi03.0: PCI INT A -> GSI 19 (levels, low) -> IRQ 19 is incorrect please boot with i8042.nopnp [ 12.732593] serio: i8042 KBD port at 0x60,0x64 irq 1 cmos 0[ 22.382590] sky2 driver version 1.22 [ 22.392071] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[febfb000-febfb7ff] Max Packet=[2048] IR/IT contexts=[8/8] [ 22.399918] xen_allocate_pirq: returning irq 17 for gsi 17 [ 22.399918] xen_set_ioapic_routing: irq 17 gsi 17 vector 152 ioapic 0 pin 17 triggering 1 polarity 1 0[ 22.399918] s:ky2 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 22.399918] sky2 0000:02:00.0: Yukon-2 EC Ultra chip revision 3 03: setting sys[ 22.913432] sky2 0000:02:00.0: Marvell Yukon 88E8056 Gigabit Ethernet Controller tem clock [ 22.998158] sky2 eth1: addr 00:22:15:63:e4:e2 to 2009-03-08 03:38:07 UTC (1236483487) [ 12.771939] BIOS EDD facility v0.16 2004-Jun-25, 0 de file [ 23.181195] scsi 0:0:0:0: Attached scsi generic sg0 type 5 [ 23.230781] scsi 1:0:0:0: Attached scsi generic sg1 type 0 [ 23.297355] scsi 2:0:0:0: Attached scsi generic sg2 type 0 [ 23.363922] scsi 6:0:0:0: Attached scsi generic sg3 type 5 descriptor referring to the console 00-0xfee0Begin: Loading essential drivers... ... 0fff has b[ 12.866237] fuse iniBegin: W[ 23.618993] Driver 'sr' needs updating - please use bus_type methods aiting for root file system... ... 75336] system 00:0f: iomem range 0xc0000-0xcffff[ 13.116519] usbcore: registered new isi 18[ 23.846740] D vectriver 'sd' needsor 168 ioapi updating - pleac 0 pinse use bus_type 18 triggmethods ering 1 polarity 1 [ 13.119826] ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) 9][ 24.062896] sr0: scsi3-mmc dr ive: 48x/48x wrieter dvd-ram cd/rhw xa/form2 cdda citray _hcd [ 24.070008] Uniform CD-ROM dr0iver Revision: 300.20 0:00:1a.7: new [ 24.231197] sUSB bud 1:0:0:0: [sda]s register 312581808 512-bed, assyte hardware secigned bustors: (160 GB/14 number9 GiB) 1 [[ 24.362580] s 13.25079d 1:0:0:0: [sda]6] ehci Write Protect i_hcd 0000s off :00:1a.7[ 24.478813] s: debugd 1:0:0:0: [sda] port 1 Write cache: en not babled, read cache: enabled, doesn't support DPO or FUA e re[ 24.628667] sd 1:0:0:0: [sda] 312581808 512-byte hardware sectors: (160 GB/149 GiB) served [ 24.728421] sd 1:0:0:0: [sda] Write Protect is off [ 24.795017] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 24.911501] sda: [ 1.675336] system 00:0f: iomem range 0xe0000-0xfffff could not be reserved sda1 sda2 xden sda3_set_ioa sda4pi <c_ro uting: irq 23 gs i 23 vector 176 ioapic 0 pin 23 triggering 1 pol arity 1 sda5sr1: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray b ridge, secondary bus 0000:01 [ 3.173514] pci 0000:00:01.0: IO window: 0xb000-0xbfffxfe8ffff[ 25.677011] fsda6 > [ 3.173514] pci 0000:00:01.0: PREFET[ 14.620099] ehci_hcd 0000:00:CH1d.7: USB 2.0 st 2[ 25.909985] sda2: <solaris: [s0] sda7 [s1] sda8 [s2]- sda9 [s7] sda10 [s8] sda11 > 0:1.0: 6 ports detected 0000d0000000-0x000000dfffffff [ 3.173514] pci 0000:00:1c.0: [ 26.226234] usb 8-1: configur dation #1 chosen rfrom 1 choice i[ 26.229619] sd 1:0:0:0: [sda]v Attached SCSI derisk [ 26.230997] s d 2:0:0:0: [sdb] 312581808 512-b yte hardware sec tors: (160 GB/149 GiB) [ 26.231028] s d 2:0:0:0: [sdb] Write Protect i s off [ 26.231080] s d 2:0:0:0: [sdb] Write cache: enIOabled, read cach e: enabled, doeswn't support DPO ior FUA [ 26.231178] sndd 2:0:0:0: [sdb]o 312581808 512-bwyte hardware sectors: (160 GB/14: 9 GiB) [ 26.231206] s0d 2:0:0:0: [sdb]xe Write Protect i0s off 0[ 26.231261] s0d 2:0:0:0: [sdb]- Write cache: enabled, read cach0e: enabled, doesxn't support DPO efor FUA [ 26.231264] ffsdb: [ 3.173514] pci 0000:00:1e.0: MEM window: 0xfeb0ng: sdb1 sdb2 irq 1 sdb36 sdb4gsi 16 <vector 144 ioapic 0 pin 16 triggering 1 polarity 1 S(XEN) io_apic.c:2160: (XEN) ioapic_guest_write: apic sdb5<6>usbcore: registered new interface driver hiddev 16.142531] xen_set_ioapic_routing: irq 21 gsi 21 vector 184 ioapic 0 pin 21 triggering 1 polarity 1 [ [ 16.152218] ul, low) [ 27.507414] -sdb6> >IR Q 21 [ 16.152218] uhci_hcd 0000:00:1a.1: UHCI Host Controller [ 16.408613] uhci_hcd 0000:00:1a.1: new USB bucd[ 27.690691] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/input/input2 [ 27.690758] sd 2:0:0:0: [sdb] Attached SCSI disk 0000:00:1a.1: irq 21, io base 0x0000a880 xen_set_ioap[ 16.591696] usb usb4: configuration #1 chosen from 1 choice ic_[ 16.708075] hub 4-0:1.0: 2 ports detected r[ 16.758103] xen_allocate_pirq: returning irq 18 for gsi 18 [ 16.767977][ 28.220275] generic-usb 0003:046D:C018.0001: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1d.2-1/input0 [ 28.339342] usbcore: registered new interface driver usbhid [ 28.400010] usbhid: v2.6:USB HID core driver Done. Begin: Running /scripts/local-premount ... 19+0 records in 19+0 records out kinit: name_to_dev_t(/dev/sdb2) = dev(8,18) Cannot write /sys/power/resume (no software suspend kernel support?) kinit: No resume image, doing normal boot... Done. [ 29.878337] kjournald starting. Commit interval 5 seconds [ 29.878361] EXT3-fs: mounted filesystem with ordered data mode. Begin: Running /scripts/local-bottom ... Done. Done. Begin: Running /scripts/init-bottom ... Done. , assigned bus number 7 cate_pirq:[ 19.286060] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000a400 returning ir[ 19.369285] usb usb7: configuration #1 chosen from 1 choice [ 19.435696] hub 7-0:1.0: USB hub found q 1[ 19.485568] hub 7-0:1.0: 2 ports detected 7[ 19.535545] xen_allocate_pirq: returning irq 18 for gsi 18 [ 19.545421] xen_set_ioapic_routing: irq 18 gsi 18 vector 168 ioapic 0 pin 18 triggering 1 polarity 1 (XEN) io_apic.c:2160: (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=18, new_irq=18 (XEN) ioapic_guest_write: old_entry=0000a9a8, new_entry=0001a9a8 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! [ 19.545421] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18 for gsi 17 [ 19.545421] uhci_hcd 0000:00:1d.2: UHCI Host Controller [ 20.117496] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8 [ 20.217168] uhci_hcd 0000:00:1d.2: irq 18, * Reading files needed to boot... ^[[80G io base 0x0000a480 [ 4.7866[ 20.300421] usb usb8: configuration #1 chosen from 1 choice [ 20.366829] hub 8-0:1.0: USB hub found 88][ 20.416696] hub 8-0:1.0: 2 ports detected xen_set_ioapic_routing: irq 17 gsi 17 vector 152 ioap [ 7.173310] ahci: SSS flag set, parallel bus scan disabled [ 7.183244] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 20460] ata7.00: ATAPI: Optiarc DVD RW AD-7200A, 1.06, max UDMA/66 [ 12.560475] ata7.00: configured for UDMA/66 [ 1[ 20.833344] xen_allocate_pirq: returning irq 18 for gsi 18 [ 20.840023] xen_set_ioapic_routing: irq 18 gsi 18 vector 168 ioapic 0 pin 18 triggering 1 polarity 1 (XEN) io_apic.c:2160: (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=18, new_irq=18 (XEN) ioapic_guest_write: old_entry=0000a9a8, new_entry=0001a9a8 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! [ 20.840023] skge 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [ 20.840023] skge 1.13 addr 0xfebfc000 irq 18 chip Yukon-Lite rev 9 [ 21.400118] skge eth0: addr 00:22:15:63:f9:9f 0A 1.06 PQ: 0 ANSI: 5 [ 12.732036] PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 [ 12.732041] PNP: PS/2 AUX p[ 21.636141] xen_allocate_pirqo: returning irq rt19 for gsi 19 [ 21.640108] u sb 8-1: new low dspeed USB devicei using uhci_hcd saand address 2 [ 21.640021] xben_set_ioapic_roluting: irq 19 gsei 19 vector 160 d,ioapic 0 pin 19 triggering 1 pol iarity 1 f (XEN) io_apic.c:2160: (XEN) ioapic_guest_write: apic=0, pin=19, old_irq=19, new_irq=19 (XEN) ioapic_guest_write: old_entry=0000a9a0, new_entry=0001a9a0 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! [ 21.640021] othci1394 0000:05:hi03.0: PCI INT A -> GSI 19 (levels, low) -> IRQ 19 is incorrect please boot with i8042.nopnp [ 12.732593] serio: i8042 KBD port at 0x60,0x64 irq 1 cmos 0[ 22.382590] sky2 driver version 1.22 [ 22.392071] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[febfb000-febfb7ff] Max Packet=[2048] IR/IT contexts=[8/8] [ 22.399918] xen_allocate_pirq: returning irq 17 for gsi 17 [ 22.399918] xen_set_ioapic_routing: irq 17 gsi 17 vector 152 ioapic 0 pin 17 triggering 1 polarity 1 0[ 22.399918] s:ky2 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 22.399918] sky2 0000:02:00.0: Yukon-2 EC Ultra chip revision 3 03: setting sys[ 22.913432] sky2 0000:02:00.0: Marvell Yukon 88E8056 Gigabit Ethernet Controller tem clock [ 22.998158] sky2 eth1: addr 00:22:15:63:e4:e2 to 2009-03-08 03:38:07 UTC (1236483487) ^[[74G[ OK ] * Setting preliminary keymap... ^[[80G ^[[74G[ OK ] * Setting the system clock * Starting basic networking... ^[[80G ^[[74G[ OK ] * Starting kernel event manager... ^[[80G [ 36.390384] udevd version 124 started ^[[74G[ OK ] * Loading hardware drivers... ^[[80G [ 37.119029] input: Power Button (FF) as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 [ 37.160076] ACPI: Power Button (FF) [PWRF] [ 37.160286] input: Power Button (CM) as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input4 [ 37.200045] ACPI: Power Button (CM) [PWRB] [ 37.202716] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 37.257243] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 37.283300] udev: renamed network interface eth0 to eth3 [ 37.284084] input: PC Speaker as /devices/platform/pcspkr/input/input5 [ 37.496081] iTCO_vendor_support: vendor-support=0 [ 37.520746] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.05 [ 37.520886] iTCO_wdt: Found a ICH10R TCO device (Version=2, TCOBASE=0x0860) [ 37.520992] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 37.546513] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 37.611264] udev: renamed network interface eth1 to eth4 [ 41.449517] xen_set_ioapic_routing: irq 22 gsi 22 vector 192 ioapic 0 pin 22 triggering 1 polarity 1 [ 41.449530] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 ^[[74G[ OK ] * Setting the system clock * Loading kernel modules... ^[[80G * Loading manual drivers... ^[[80G [ 43.285573] loop: module loaded [ 43.499253] lp: driver loaded but no devices found ^[[74G[ OK ] * Setting kernel variables (/etc/sysctl.conf)... ^[[80G ^[[74G[ OK ] * Setting kernel variables (/etc/sysctl.d/10-console-messages.conf)... ^[[80G ^[[74G[ OK ] * Setting kernel variables (/etc/sysctl.d/10-network-security.conf)... ^[[80G ^[[74G[ OK ] * Setting kernel variables (/etc/sysctl.d/10-process-security.conf)... ^[[80G error: "kernel.maps_protect" is an unknown key ^[[74G[^[[31mfail^[[39;49m] * Setting kernel variables (/etc/sysctl.d/10-tcp-timestamps-workaround.conf)... ^[[80G ^[[74G[ OK ] * Setting kernel variables (/etc/sysctl.d/30-tracker.conf)... ^[[80G ^[[74G[ OK ] * Activating swap... ^[[80G ^[[74G[ OK ] * Checking root file system... ^[[80G fsck 1.41.3 (12-Oct-2008) /dev/sdb1: clean, 344128/1831424 files, 6238812/7323624 blocks ^[[74G[ OK ] * Checking file systems... ^[[80G fsck 1.41.3 (12-Oct-2008) ^[[74G[ OK ] * Mounting local filesystems... ^[[80G ^[[74G[ OK ] * Activating swapfile swap... ^[[80G ^[[74G[ OK ] $Mounting securityfs on /sys/kernel/security: done. $Loading AppArmor module: Failed. * Skipping firewall: ufw (not enabled)... ^[[80G ^[[74G[ OK ] * Configuring network interfaces... ^[[80G ^[[74G[ OK ] * Setting up console font and keymap... ^[[80G ^[[74G[ OK ] * Loading ACPI modules... ^[[80G ^[[74G[ OK ] * Starting ACPI services... ^[[80G ^[[74G[ OK ] * Starting system log daemon... ^[[80G ^[[74G[ OK ] * Doing Wacom setup... ^[[80G ^[[74G[ OK ] * Starting kernel log daemon... ^[[80G ^[[74G[ OK ] * Starting system message bus dbus ^[[80G ^[[74G[ OK ] * Starting Avahi mDNS/DNS-SD Daemon avahi-daemon ^[[80G ^[[74G[ OK ] * Starting OpenBSD Secure Shell server sshd ^[[80G ^[[74G[ OK ] * Starting Common Unix Printing System: cupsd ^[[80G ^[[74G[ OK ] * Starting powernowd... ^[[80G * CPU frequency scaling not supported... ^[[80G ^[[74G[ OK ] * Starting internet superserver xinetd ^[[80G ^[[74G[ OK ] * Starting Hardware abstraction layer hald ^[[80G ^[[74G[ OK ] * Starting bluetooth ^[[80G ^[[74G[ OK ] * Starting NetworkManager... ^[[80G ^[[74G[ OK ] * Starting GNOME Display Manager... ^[[80G ^[[74G[ OK ] * Starting System Tools Backends system-tools-backends ^[[80G ^[[74G[ OK ] * Starting anac(h)ronistic cron anacron ^[[80G ^[[74G[ OK ] * Starting deferred execution scheduler atd ^[[80G ^[[74G[ OK ] * Starting periodic command scheduler crond ^[[80G ^[[74G[ OK ] * Enabling additional executable binary formats binfmt-support ^[[80G ^[[74G[ OK ] * Checking battery state... ^[[80G ^[[74G[ OK ] There is already a pid file /var/run/dhclient.eth4.pid with pid 4868 killed old client process, removed PID file Internet Systems Consortium DHCP Client V3.1.1 Copyright 2004-2008 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/eth4/00:22:15:63:e4:e2 Sending on LPF/eth4/00:22:15:63:e4:e2 Sending on Socket/fallback DHCPRELEASE on eth4 to 192.168.1.1 port 67 Nothing to flush. Waiting for peth4 to negotiate link... Internet Systems Consortium DHCP Client V3.1.1 Copyright 2004-2008 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/eth4/00:22:15:63:e4:e2 Sending on LPF/eth4/00:22:15:63:e4:e2 Sending on Socket/fallback DHCPDISCOVER on eth4 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on eth4 to 255.255.255.255 port 67 interval 13 DHCPOFFER of 192.168.1.39 from 192.168.1.1 DHCPREQUEST of 192.168.1.39 on eth4 to 255.255.255.255 port 67 DHCPACK of 192.168.1.39 from 192.168.1.1 bound to 192.168.1.39 -- renewal in 124171 seconds. [ 91.714581] xenbus_probe wake_waiting [ 91.714606] xenbus_probe wake_waiting [ 91.725278] xenbus_probe_devices backend [ 91.726294] xenbus_probe_devices failed xenbus_directory [ 91.726300] backend_probe_and_watch devices probed ok [ 91.726411] backend_probe_and_watch watch add ok ok [ 91.726417] backend_probe_and_watch all done [ 91.726421] xenbus_probe_devices device [ 91.726538] xenbus_probe_devices failed xenbus_directory [ 91.726543] frontend_probe_and_watch devices probed ok [ 91.726652] frontend_probe_and_watch watch add ok ok [ 91.726657] frontend_probe_and_watch all done Ubuntu 8.10 ServerINTR hvc0 ServerINTR login: Ubuntu 8.10 ServerINTR hvc0 ServerINTR login: Ubuntu 8.10 ServerINTR hvc0 ServerINTR login: [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-08 5:31 [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Jeremy Fitzhardinge 2009-03-08 8:52 ` Boris Derzhavets @ 2009-03-08 9:13 ` Keir Fraser 2009-03-09 11:31 ` [PATCH] xen: mask XSAVE in cpuid since we don'tallow " Jan Beulich 2009-03-09 11:18 ` [PATCH] xen: mask XSAVE in cpuid since we don't allow " Boris Derzhavets 2009-03-09 11:26 ` [PATCH] xen: mask XSAVE in cpuid since we don't allowguests " Jan Beulich 3 siblings, 1 reply; 46+ messages in thread From: Keir Fraser @ 2009-03-08 9:13 UTC (permalink / raw) To: Jeremy Fitzhardinge Cc: Boris Derzhavets, Xen-devel, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] On 08/03/2009 05:31, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote: > Mask X86_FEATURE_XSAVE in cpuid leaf 1, ecx, as we don't allow guests to > use it (by setting cr4.OSXSAVE). > > This prevents crashes in pvops dom0 kernels, as new versions of Linux try > to use this feature. > > (This patch deals with dom0 cpuid; I'm not sure where the right place to > set up the default mask for domU is.) Thanks, the whole problem stems from blacklisting rather than whitelisting feature bits. I might try and do a more comprehensive job for xen-unstable at least. This is good for 3.3. -- Keir ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH] xen: mask XSAVE in cpuid since we don'tallow guests to use it 2009-03-08 9:13 ` Keir Fraser @ 2009-03-09 11:31 ` Jan Beulich 2009-03-09 11:45 ` Keir Fraser 0 siblings, 1 reply; 46+ messages in thread From: Jan Beulich @ 2009-03-09 11:31 UTC (permalink / raw) To: Keir Fraser, Jeremy Fitzhardinge Cc: Boris Derzhavets, Xen-devel, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] >>> Keir Fraser <keir.fraser@eu.citrix.com> 08.03.09 10:13 >>> >On 08/03/2009 05:31, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote: > >> Mask X86_FEATURE_XSAVE in cpuid leaf 1, ecx, as we don't allow guests to >> use it (by setting cr4.OSXSAVE). >> >> This prevents crashes in pvops dom0 kernels, as new versions of Linux try >> to use this feature. >> >> (This patch deals with dom0 cpuid; I'm not sure where the right place to >> set up the default mask for domU is.) > >Thanks, the whole problem stems from blacklisting rather than whitelisting >feature bits. I might try and do a more comprehensive job for xen-unstable >at least. This is good for 3.3. I'm not sure whitelisting will be much better than blacklisting - while now any feature requiring not-yet-implemented support in Xen must be turned off explicitly, this would just turn over to requiring explicitly un-hiding any new feature not requiring Xen's intervention. A real solution to this issue would require some assistance from the hardware vendors I'd think. Jan ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don'tallow guests to use it 2009-03-09 11:31 ` [PATCH] xen: mask XSAVE in cpuid since we don'tallow " Jan Beulich @ 2009-03-09 11:45 ` Keir Fraser 0 siblings, 0 replies; 46+ messages in thread From: Keir Fraser @ 2009-03-09 11:45 UTC (permalink / raw) To: Jan Beulich, Jeremy Fitzhardinge Cc: Boris Derzhavets, Xen-devel, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] On 09/03/2009 11:31, "Jan Beulich" <jbeulich@novell.com> wrote: >> Thanks, the whole problem stems from blacklisting rather than whitelisting >> feature bits. I might try and do a more comprehensive job for xen-unstable >> at least. This is good for 3.3. > > I'm not sure whitelisting will be much better than blacklisting - while now > any feature requiring not-yet-implemented support in Xen must be turned > off explicitly, this would just turn over to requiring explicitly un-hiding > any > new feature not requiring Xen's intervention. A real solution to this issue > would require some assistance from the hardware vendors I'd think. Well, it makes the difference between working but without the new feature, versus quite possibly simply not working at all (and failing in rare and subtle ways, perhaps). Isn't one obviously better than the other? -- Keir ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-08 5:31 [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Jeremy Fitzhardinge 2009-03-08 8:52 ` Boris Derzhavets 2009-03-08 9:13 ` Keir Fraser @ 2009-03-09 11:18 ` Boris Derzhavets 2009-03-09 11:26 ` Keir Fraser 2009-03-09 11:26 ` [PATCH] xen: mask XSAVE in cpuid since we don't allowguests " Jan Beulich 3 siblings, 1 reply; 46+ messages in thread From: Boris Derzhavets @ 2009-03-09 11:18 UTC (permalink / raw) To: Keir Fraser, Jeremy Fitzhardinge Cc: Xen-devel, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] [-- Attachment #1.1: Type: text/plain, Size: 5878 bytes --] I was able to go through creating PV DomUs images via corresponding pygrub's profiles for F10,CentOS 5.2,SNV_106 (64-bit all). However, only Solaris Nevada PV DomU gets loaded via standard pygrub profile. Attempt to load F10 PV:- [2009-03-09 05:33:38 6351] DEBUG (XendDomainInfo:92) XendDomainInfo.create(['vm', ['name', 'F10PV'], ['memory', 2048], ['on_reboot', 'restart'], ['on_crash', 'restart'], ['vcpus', 1], ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'], ['bootloader', '/usr/bin/pygrub'], ['bootloader_args', '-q'], ['image', ['linux', ['videoram', 4]]], ['device', ['vbd', ['uname', 'phy:/dev/sdb5'], ['dev', 'xvda'], ['mode', 'w']]], ['device', ['vif', ['bridge', 'eth0']]], ['device', ['vkbd']], ['device', ['vfb', ['vncunused', '1'], ['type', 'vnc'], ['xauthority', '/root/.Xauthority']]]]) [2009-03-09 05:33:38 6351] DEBUG (XendDomainInfo:2183) XendDomainInfo.constructDomain [2009-03-09 05:33:38 6351] DEBUG (balloon:166) Balloon: 7239368 KiB free; need 2048; done. [2009-03-09 05:33:38 6351] DEBUG (XendDomain:452) Adding Domain: 8 [2009-03-09 05:33:38 6351] DEBUG (XendDomainInfo:2362) XendDomainInfo.initDomain: 8 256 [2009-03-09 05:33:38 12975] DEBUG (XendBootloader:113) Launching bootloader as ['/usr/bin/pygrub', '--output=/var/run/xend/boot/xenbl.29001', '-q', '/dev/sdb5']. [2009-03-09 05:33:39 6351] ERROR (XendBootloader:213) Boot loader didn't return any data! [2009-03-09 05:33:39 6351] ERROR (XendDomainInfo:472) VM start failed Traceback (most recent call last): File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 452, in start XendTask.log_progress(31, 60, self._initDomain) File "//usr/lib64/python/xen/xend/XendTask.py", line 209, in log_progress retval = func(*args, **kwds) File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2364, in _initDomain self._configureBootloader() File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2765, in _configureBootloader bootloader_args, kernel, ramdisk, args) File "//usr/lib64/python/xen/xend/XendBootloader.py", line 214, in bootloader raise VmError, msg Attempt to load CentOS 5.2 PV:- [2009-03-09 06:45:39 6351] DEBUG (XendDomainInfo:92) XendDomainInfo.create(['vm', ['name', 'RHEL52PV'], ['memory', 2048], ['vcpus', 1], ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'], ['image', ['linux', ['videoram', 4]]], ['device', ['vbd', ['uname', 'phy:/dev/sdb5'], ['dev', 'xvda'], ['mode', 'w']]], ['device', ['vif', ['bridge', 'eth0']]]]) [2009-03-09 06:45:39 6351] DEBUG (XendDomainInfo:2183) XendDomainInfo.constructDomain [2009-03-09 06:45:39 6351] DEBUG (balloon:166) Balloon: 7239368 KiB free; need 2048; done. [2009-03-09 06:45:39 6351] DEBUG (XendDomain:452) Adding Domain: 12 [2009-03-09 06:45:39 6351] DEBUG (XendDomainInfo:2362) XendDomainInfo.initDomain: 12 256 [2009-03-09 06:45:39 16739] DEBUG (XendBootloader:113) Launching bootloader as ['/usr/bin/pygrub', '--output=/var/run/xend/boot/xenbl.15023', '/dev/sdb5']. [2009-03-09 06:45:44 6351] ERROR (XendBootloader:213) Boot loader didn't return any data! [2009-03-09 06:45:44 6351] ERROR (XendDomainInfo:472) VM start failed Traceback (most recent call last): File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 452, in start XendTask.log_progress(31, 60, self._initDomain) File "//usr/lib64/python/xen/xend/XendTask.py", line 209, in log_progress retval = func(*args, **kwds) File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2364, in _initDomain self._configureBootloader() File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2765, in _configureBootloader bootloader_args, kernel, ramdisk, args) File "//usr/lib64/python/xen/xend/XendBootloader.py", line 214, in bootloader raise VmError, msg VmError: Boot loader didn't return any data! --- On Sun, 3/8/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: "Keir Fraser" <keir.fraser@eu.citrix.com> Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Marc - A. Dahlhaus [ Administration | Westermann GmbH ]" <mad@wol.de>, "Boris Derzhavets" <bderzhavets@yahoo.com> Date: Sunday, March 8, 2009, 12:31 AM Mask X86_FEATURE_XSAVE in cpuid leaf 1, ecx, as we don't allow guests to use it (by setting cr4.OSXSAVE). This prevents crashes in pvops dom0 kernels, as new versions of Linux try to use this feature. (This patch deals with dom0 cpuid; I'm not sure where the right place to set up the default mask for domU is.) Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> diff -r 7f573cb76db4 xen/arch/x86/traps.c --- a/xen/arch/x86/traps.c Tue Mar 03 13:22:28 2009 +0000 +++ b/xen/arch/x86/traps.c Sat Mar 07 17:02:03 2009 -0800 @@ -757,6 +757,7 @@ __clear_bit(X86_FEATURE_XTPR % 32, &c); __clear_bit(X86_FEATURE_PDCM % 32, &c); __clear_bit(X86_FEATURE_DCA % 32, &c); + __clear_bit(X86_FEATURE_XSAVE % 32, &c); if ( !cpu_has_apic ) __clear_bit(X86_FEATURE_X2APIC % 32, &c); __set_bit(X86_FEATURE_HYPERVISOR % 32, &c); diff -r 7f573cb76db4 xen/include/asm-x86/cpufeature.h --- a/xen/include/asm-x86/cpufeature.h Tue Mar 03 13:22:28 2009 +0000 +++ b/xen/include/asm-x86/cpufeature.h Sat Mar 07 17:02:03 2009 -0800 @@ -95,6 +95,7 @@ #define X86_FEATURE_SSE4_2 (4*32+20) /* Streaming SIMD Extensions 4.2 */ #define X86_FEATURE_X2APIC (4*32+21) /* Extended xAPIC */ #define X86_FEATURE_POPCNT (4*32+23) /* POPCNT instruction */ +#define X86_FEATURE_XSAVE (4*32+26) /* XSAVE/XRSTOR/XSETBV/XGETBV */ #define X86_FEATURE_HYPERVISOR (4*32+31) /* Running under some hypervisor */ /* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC0000001, word 5 */ [-- Attachment #1.2: Type: text/html, Size: 6609 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-09 11:18 ` [PATCH] xen: mask XSAVE in cpuid since we don't allow " Boris Derzhavets @ 2009-03-09 11:26 ` Keir Fraser 2009-03-09 14:31 ` Boris Derzhavets 0 siblings, 1 reply; 46+ messages in thread From: Keir Fraser @ 2009-03-09 11:26 UTC (permalink / raw) To: bderzhavets@yahoo.com; +Cc: Xen-devel If you¹re using a recent xen-unstable then you might try again with the current tip. A couple of changes went in recently (including one fix today). -- Keir On 09/03/2009 11:18, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote: > I was able to go through creating PV DomUs images via corresponding pygrub's > profiles for F10,CentOS 5.2,SNV_106 (64-bit all). > However, only Solaris Nevada PV DomU gets loaded via standard > pygrub profile. > > Attempt to load F10 PV:- > > [2009-03-09 05:33:38 6351] DEBUG (XendDomainInfo:92) > XendDomainInfo.create(['vm', ['name', 'F10PV'], ['memory', 2048], > ['on_reboot', 'restart'], ['on_crash', 'restart'], ['vcpus', 1], > ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'], ['bootloader', > '/usr/bin/pygrub'], ['bootloader_args', '-q'], ['image', ['linux', > ['videoram', 4]]], ['device', ['vbd', ['uname', 'phy:/dev/sdb5'], ['dev', > 'xvda'], ['mode', 'w']]], ['device', ['vif', ['bridge', 'eth0']]], ['device', > ['vkbd']], ['device', ['vfb', ['vncunused', '1'], ['type', 'vnc'], > ['xauthority', '/root/.Xauthority']]]]) > [2009-03-09 05:33:38 6351] DEBUG (XendDomainInfo:2183) > XendDomainInfo.constructDomain > [2009-03-09 05:33:38 6351] DEBUG (balloon:166) Balloon: 7239368 KiB free; need > 2048; done. > [2009-03-09 05:33:38 6351] DEBUG (XendDomain:452) Adding Domain: 8 > [2009-03-09 05:33:38 6351] DEBUG (XendDomainInfo:2362) > XendDomainInfo.initDomain: 8 256 > [2009-03-09 05:33:38 12975] DEBUG (XendBootloader:113) Launching bootloader as > ['/usr/bin/pygrub', '--output=/var/run/xend/boot/xenbl.29001', '-q', > '/dev/sdb5']. > [2009-03-09 05:33:39 6351] ERROR (XendBootloader:213) Boot loader didn't > return any data! > [2009-03-09 05:33:39 6351] ERROR (XendDomainInfo:472) VM start failed > Traceback (most recent call last): > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 452, in start > XendTask.log_progress(31, 60, self._initDomain) > File "//usr/lib64/python/xen/xend/XendTask.py", line 209, in log_progress > retval = func(*args, **kwds) > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2364, in > _initDomain > self._configureBootloader() > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2765, in > _configureBootloader > bootloader_args, kernel, ramdisk, args) > File "//usr/lib64/python/xen/xend/XendBootloader.py", line 214, in > bootloader > raise VmError, msg > > Attempt to load CentOS 5.2 PV:- > > [2009-03-09 06:45:39 6351] DEBUG (XendDomainInfo:92) > XendDomainInfo.create(['vm', ['name', 'RHEL52PV'], ['memory', 2048], ['vcpus', > 1], ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'], ['image', > ['linux', ['videoram', 4]]], ['device', ['vbd', ['uname', 'phy:/dev/sdb5'], > ['dev', 'xvda'], ['mode', 'w']]], ['device', ['vif', ['bridge', 'eth0']]]]) > [2009-03-09 06:45:39 6351] DEBUG (XendDomainInfo:2183) > XendDomainInfo.constructDomain > [2009-03-09 06:45:39 6351] DEBUG (balloon:166) Balloon: 7239368 KiB free; need > 2048; done. > [2009-03-09 06:45:39 6351] DEBUG (XendDomain:452) Adding Domain: 12 > [2009-03-09 06:45:39 6351] DEBUG (XendDomainInfo:2362) > XendDomainInfo.initDomain: 12 256 > [2009-03-09 06:45:39 16739] DEBUG (XendBootloader:113) Launching bootloader as > ['/usr/bin/pygrub', '--output=/var/run/xend/boot/xenbl.15023', '/dev/sdb5']. > [2009-03-09 06:45:44 6351] ERROR (XendBootloader:213) Boot loader didn't > return any data! > [2009-03-09 06:45:44 6351] ERROR (XendDomainInfo:472) VM start failed > Traceback (most recent call last): > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 452, in start > XendTask.log_progress(31, 60, self._initDomain) > File "//usr/lib64/python/xen/xend/XendTask.py", line 209, in log_progress > retval = func(*args, **kwds) > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2364, in > _initDomain > self._configureBootloader() > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2765, in > _configureBootloader > bootloader_args, kernel, ramdisk, args) > File "//usr/lib64/python/xen/xend/XendBootloader.py", line 214, in > bootloader > raise VmError, msg > VmError: Boot loader didn't return any data! > > > > > > > > > > --- On Sun, 3/8/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> From: Jeremy Fitzhardinge <jeremy@goop.org> >> Subject: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use >> it >> To: "Keir Fraser" <keir.fraser@eu.citrix.com> >> Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Marc - A. Dahlhaus [ >> Administration | Westermann GmbH ]" <mad@wol.de>, "Boris Derzhavets" >> <bderzhavets@yahoo.com> >> Date: Sunday, March 8, 2009, 12:31 AM >> >> Mask X86_FEATURE_XSAVE in cpuid leaf 1, ecx, as we don't allow guests to >> use it (by setting cr4.OSXSAVE). >> >> This prevents crashes in pvops dom0 kernels, as new versions of Linux try >> to use this feature. >> >> (This patch deals with dom0 cpuid; I'm not sure where the right place to >> set up the default mask for domU is.) >> >> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >> >> diff -r 7f573cb76db4 xen/arch/x86/traps.c >> --- a/xen/arch/x86/traps.c Tue Mar 03 13:22:28 2009 +0000 >> +++ b/xen/arch/x86/traps.c Sat Mar 07 17:02:03 2009 -0800 >> @@ -757,6 +757,7 @@ >> __clear_bit(X86_FEATURE_XTPR % 32, &c); >> __clear_bit(X86_FEATURE_PDCM % 32, &c); >> __clear_bit(X86_FEATURE_DCA % 32, &c); >> + __clear_bit(X86_FEATURE_XSAVE % 32, &c); >> if ( !cpu_has_apic ) >> >> __clear_bit(X86_FEATURE_X2APIC % 32, &c); >> __set_bit(X86_FEATURE_HYPERVISOR % 32, &c); >> diff -r 7f573cb76db4 xen/include/asm-x86/cpufeature.h >> --- a/xen/include/asm-x86/cpufeature.h Tue Mar 03 13:22:28 2009 +0000 >> +++ b/xen/include/asm-x86/cpufeature.h Sat Mar 07 17:02:03 2009 -0800 >> @@ -95,6 +95,7 @@ >> #define X86_FEATURE_SSE4_2 (4*32+20) /* Streaming SIMD Extensions 4.2 */ >> #define X86_FEATURE_X2APIC (4*32+21) /* Extended xAPIC */ >> #define X86_FEATURE_POPCNT (4*32+23) /* POPCNT instruction */ >> +#define X86_FEATURE_XSAVE (4*32+26) /* XSAVE/XRSTOR/XSETBV/XGETBV */ >> #define X86_FEATURE_HYPERVISOR (4*32+31) /* Running under some hypervisor */ >> >> /* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC0000001, word 5 */ >> >> > > ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-09 11:26 ` Keir Fraser @ 2009-03-09 14:31 ` Boris Derzhavets 2009-03-10 22:24 ` Boris Derzhavets 0 siblings, 1 reply; 46+ messages in thread From: Boris Derzhavets @ 2009-03-09 14:31 UTC (permalink / raw) To: Keir Fraser; +Cc: Xen-devel [-- Attachment #1.1: Type: text/plain, Size: 12089 bytes --] Just cloned,built and installed the most recent xen-unstable. Seems like "make tools" reports some errors , but still finishes with no error message. CentOS 5.2 PV DomU may be loaded OK only the very first time. The next attempt after DomU shutdown brings it to paused state. After "xm unpause DomainName":- i8042.c: No controller found. in 1 seconds Red Hat nash version 5.1.19.6 starting Reading all physical volumes. This may take a while... No volume groups found Volume group "VolGroup00" not found mount: could not find filesystem '/dev/root' setuproot: moving /dev failed: No such file or directory setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory switchroot: mount failed: No such file or directory Kernel panic - not syncing: Attempted to kill init! root@ServerUbuntu810:/home/boris/vm# Error: Device 51712 (vbd) could not be connected. Hotplug scripts not working. /var/log/xen/xend.log:- [2009-03-09 10:18:33 6335] DEBUG (XendDomainInfo:2131) No device model [2009-03-09 10:18:33 6335] DEBUG (XendDomainInfo:2133) Releasing devices [2009-03-09 10:19:29 6335] DEBUG (DevController:629) hotplugStatusCallback /local/domain/0/backend/vbd/2/51712/hotplug-status. [2009-03-09 10:19:29 6335] DEBUG (DevController:643) hotplugStatusCallback 1. [2009-03-09 10:19:42 6335] ERROR (XendDomainInfo:1983) Failed to restart domain 2. Traceback (most recent call last): File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 1969, in _restart new_dom.waitForDevices() File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 1020, in waitForDevices self.getDeviceController(devclass).waitForDevices() File "//usr/lib64/python/xen/xend/server/DevController.py", line 140, in waitForDevices return map(self.waitForDevice, self.deviceIDs()) File "//usr/lib64/python/xen/xend/server/DevController.py", line 152, in waitForDevice self.destroyDevice(devid, False) File "//usr/lib64/python/xen/xend/server/blkif.py", line 200, in destroyDevice DevController.destroyDevice(self, devid, force) File "//usr/lib64/python/xen/xend/server/DevController.py", line 228, in destroyDevice self.writeBackend(dev, 'online', "0") File "//usr/lib64/python/xen/xend/server/DevController.py", line 474, in writeBackend raise VmError("Device %s not connected" % devid) VmError: Device 51712 not connected [2009-03-09 10:21:06 6335] DEBUG (DevController:629) hotplugStatusCallback /local/domain/0/backend/vbd/3/51712/hotplug-status. [2009-03-09 10:21:06 6335] DEBUG (DevController:643) hotplugStatusCallback 2. Start F10 PV DomU:- root@ServerUbuntu810:/home/boris/vm# xm create -c f10.pyrun Using config file "./f10.pyrun". PCI: Fatal: No config space access function found IO APIC resources could be not be allocated. Loading /lib/kbd/keymaps/i386/qwerty/us.map BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: [<ffffffffa00010e5>] backend_changed+0x2d5/0x3af [xen_blkfront] PGD 7d1f6067 PUD 7d143067 PMD 7d116067 PTE 0 Oops: 0000 [1] SMP CPU 1 Modules linked in: xen_blkfront Pid: 19, comm: xenwatch Not tainted 2.6.27.5-117.fc10.x86_64 #1 RIP: e030:[<ffffffffa00010e5>] [<ffffffffa00010e5>] backend_changed+0x2d5/0x3af [xen_blkfront] RSP: e02b:ffff88007f40fdf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88007d02d840 RCX: 0000000000000000 RDX: ffff88007f40fe28 RSI: 0000000000000005 RDI: ffff88007ff5f400 RBP: ffff88007f40fe80 R08: ffff88007f40fdd0 R09: ffff88007f40fcc0 R10: 0000000000000001 R11: ffff880000000018 R12: ffff88007ff5f400 R13: ffff88007d042000 R14: 000000000000000a R15: ffffffff817e2f44 FS: 00007fb68f67e6f0(0000) GS:ffff88007fc04880(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000007d105000 CR4: 0000000000002660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process xenwatch (pid: 19, threadinfo ffff88007f40e000, task ffff88007ffd5c40) Stack: ffff88007f40fe00 ffff88007f40fe40 ffffffff816de500 ffffffff816de500 ffffffff81455f53 ffffffff81462b99 ffff88007f40fe7c 0000000000000000 000000000000000a ffff88007d02d840 ffff88007ff5f400 ffffffffa0002ac0 Call Trace: [<ffffffff811c91e6>] otherend_changed+0x81/0x8a [<ffffffff811c7e14>] xenwatch_thread+0x101/0x134 [<ffffffff81055199>] ? autoremove_wake_function+0x0/0x38 [<ffffffff811c7d13>] ? xenwatch_thread+0x0/0x134 [<ffffffff81054e53>] kthread+0x49/0x76 [<ffffffff810116e9>] child_rip+0xa/0x11 [<ffffffff81010a07>] ? restore_args+0x0/0x30 [<ffffffff810116df>] ? child_rip+0x0/0x11 Code: 58 08 e9 97 00 00 00 49 8b 7d 00 48 c7 c2 b9 15 00 a0 be ed ff ff ff 48 8b 4f 10 31 c0 e8 da 5f 1c e1 e9 cf 00 00 00 49 8b 45 08 <8b> 38 c1 e7 14 0b 78 04 e8 26 55 0e e1 48 85 c0 48 89 c3 75 16 RIP [<ffffffffa00010e5>] backend_changed+0x2d5/0x3af [xen_blkfront] RSP <ffff88007f40fdf0> CR2: 0000000000000000 ---[ end trace bf88f6e1c7a703d2 ]--- root@ServerUbuntu810:/home/boris/vm# Error: Device 51712 (vbd) could not be connected. Hotplug scripts not working. --- On Mon, 3/9/09, Keir Fraser <keir.fraser@eu.citrix.com> wrote: From: Keir Fraser <keir.fraser@eu.citrix.com> Subject: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: "bderzhavets@yahoo.com" <bderzhavets@yahoo.com> Cc: "Xen-devel" <xen-devel@lists.xensource.com> Date: Monday, March 9, 2009, 7:26 AM If you¹re using a recent xen-unstable then you might try again with the current tip. A couple of changes went in recently (including one fix today). -- Keir On 09/03/2009 11:18, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote: > I was able to go through creating PV DomUs images via corresponding pygrub's > profiles for F10,CentOS 5.2,SNV_106 (64-bit all). > However, only Solaris Nevada PV DomU gets loaded via standard > pygrub profile. > > Attempt to load F10 PV:- > > [2009-03-09 05:33:38 6351] DEBUG (XendDomainInfo:92) > XendDomainInfo.create(['vm', ['name', 'F10PV'], ['memory', 2048], > ['on_reboot', 'restart'], ['on_crash', 'restart'], ['vcpus', 1], > ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'], ['bootloader', > '/usr/bin/pygrub'], ['bootloader_args', '-q'], ['image', ['linux', > ['videoram', 4]]], ['device', ['vbd', ['uname', 'phy:/dev/sdb5'], ['dev', > 'xvda'], ['mode', 'w']]], ['device', ['vif', ['bridge', 'eth0']]], ['device', > ['vkbd']], ['device', ['vfb', ['vncunused', '1'], ['type', 'vnc'], > ['xauthority', '/root/.Xauthority']]]]) > [2009-03-09 05:33:38 6351] DEBUG (XendDomainInfo:2183) > XendDomainInfo.constructDomain > [2009-03-09 05:33:38 6351] DEBUG (balloon:166) Balloon: 7239368 KiB free; need > 2048; done. > [2009-03-09 05:33:38 6351] DEBUG (XendDomain:452) Adding Domain: 8 > [2009-03-09 05:33:38 6351] DEBUG (XendDomainInfo:2362) > XendDomainInfo.initDomain: 8 256 > [2009-03-09 05:33:38 12975] DEBUG (XendBootloader:113) Launching bootloader as > ['/usr/bin/pygrub', '--output=/var/run/xend/boot/xenbl.29001', '-q', > '/dev/sdb5']. > [2009-03-09 05:33:39 6351] ERROR (XendBootloader:213) Boot loader didn't > return any data! > [2009-03-09 05:33:39 6351] ERROR (XendDomainInfo:472) VM start failed > Traceback (most recent call last): > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 452, in start > XendTask.log_progress(31, 60, self._initDomain) > File "//usr/lib64/python/xen/xend/XendTask.py", line 209, in log_progress > retval = func(*args, **kwds) > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2364, in > _initDomain > self._configureBootloader() > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2765, in > _configureBootloader > bootloader_args, kernel, ramdisk, args) > File "//usr/lib64/python/xen/xend/XendBootloader.py", line 214, in > bootloader > raise VmError, msg > > Attempt to load CentOS 5.2 PV:- > > [2009-03-09 06:45:39 6351] DEBUG (XendDomainInfo:92) > XendDomainInfo.create(['vm', ['name', 'RHEL52PV'], ['memory', 2048], ['vcpus', > 1], ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'], ['image', > ['linux', ['videoram', 4]]], ['device', ['vbd', ['uname', 'phy:/dev/sdb5'], > ['dev', 'xvda'], ['mode', 'w']]], ['device', ['vif', ['bridge', 'eth0']]]]) > [2009-03-09 06:45:39 6351] DEBUG (XendDomainInfo:2183) > XendDomainInfo.constructDomain > [2009-03-09 06:45:39 6351] DEBUG (balloon:166) Balloon: 7239368 KiB free; need > 2048; done. > [2009-03-09 06:45:39 6351] DEBUG (XendDomain:452) Adding Domain: 12 > [2009-03-09 06:45:39 6351] DEBUG (XendDomainInfo:2362) > XendDomainInfo.initDomain: 12 256 > [2009-03-09 06:45:39 16739] DEBUG (XendBootloader:113) Launching bootloader as > ['/usr/bin/pygrub', '--output=/var/run/xend/boot/xenbl.15023', '/dev/sdb5']. > [2009-03-09 06:45:44 6351] ERROR (XendBootloader:213) Boot loader didn't > return any data! > [2009-03-09 06:45:44 6351] ERROR (XendDomainInfo:472) VM start failed > Traceback (most recent call last): > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 452, in start > XendTask.log_progress(31, 60, self._initDomain) > File "//usr/lib64/python/xen/xend/XendTask.py", line 209, in log_progress > retval = func(*args, **kwds) > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2364, in > _initDomain > self._configureBootloader() > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2765, in > _configureBootloader > bootloader_args, kernel, ramdisk, args) > File "//usr/lib64/python/xen/xend/XendBootloader.py", line 214, in > bootloader > raise VmError, msg > VmError: Boot loader didn't return any data! > > > > > > > > > > --- On Sun, 3/8/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> From: Jeremy Fitzhardinge <jeremy@goop.org> >> Subject: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use >> it >> To: "Keir Fraser" <keir.fraser@eu.citrix.com> >> Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Marc - A. Dahlhaus [ >> Administration | Westermann GmbH ]" <mad@wol.de>, "Boris Derzhavets" >> <bderzhavets@yahoo.com> >> Date: Sunday, March 8, 2009, 12:31 AM >> >> Mask X86_FEATURE_XSAVE in cpuid leaf 1, ecx, as we don't allow guests to >> use it (by setting cr4.OSXSAVE). >> >> This prevents crashes in pvops dom0 kernels, as new versions of Linux try >> to use this feature. >> >> (This patch deals with dom0 cpuid; I'm not sure where the right place to >> set up the default mask for domU is.) >> >> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >> >> diff -r 7f573cb76db4 xen/arch/x86/traps.c >> --- a/xen/arch/x86/traps.c Tue Mar 03 13:22:28 2009 +0000 >> +++ b/xen/arch/x86/traps.c Sat Mar 07 17:02:03 2009 -0800 >> @@ -757,6 +757,7 @@ >> __clear_bit(X86_FEATURE_XTPR % 32, &c); >> __clear_bit(X86_FEATURE_PDCM % 32, &c); >> __clear_bit(X86_FEATURE_DCA % 32, &c); >> + __clear_bit(X86_FEATURE_XSAVE % 32, &c); >> if ( !cpu_has_apic ) >> >> __clear_bit(X86_FEATURE_X2APIC % 32, &c); >> __set_bit(X86_FEATURE_HYPERVISOR % 32, &c); >> diff -r 7f573cb76db4 xen/include/asm-x86/cpufeature.h >> --- a/xen/include/asm-x86/cpufeature.h Tue Mar 03 13:22:28 2009 +0000 >> +++ b/xen/include/asm-x86/cpufeature.h Sat Mar 07 17:02:03 2009 -0800 >> @@ -95,6 +95,7 @@ >> #define X86_FEATURE_SSE4_2 (4*32+20) /* Streaming SIMD Extensions 4.2 */ >> #define X86_FEATURE_X2APIC (4*32+21) /* Extended xAPIC */ >> #define X86_FEATURE_POPCNT (4*32+23) /* POPCNT instruction */ >> +#define X86_FEATURE_XSAVE (4*32+26) /* XSAVE/XRSTOR/XSETBV/XGETBV */ >> #define X86_FEATURE_HYPERVISOR (4*32+31) /* Running under some hypervisor */ >> >> /* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC0000001, word 5 */ >> >> > > [-- Attachment #1.2: Type: text/html, Size: 13935 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-09 14:31 ` Boris Derzhavets @ 2009-03-10 22:24 ` Boris Derzhavets 2009-03-11 0:29 ` Jeremy Fitzhardinge 0 siblings, 1 reply; 46+ messages in thread From: Boris Derzhavets @ 2009-03-10 22:24 UTC (permalink / raw) To: Keir Fraser; +Cc: Xen-devel [-- Attachment #1.1: Type: text/plain, Size: 13221 bytes --] Seems like new kernel brought up back some old issues with ubuntu 8.10 devices. It never happened before patching 2.6.29-rc7 kernel on C2D boxes with the same ubuntu 8.10 server release and 2.6.29-rc5. In particular, CentOS 5.2 PV DomU's xen-hotplug.log looks like:- xenstore-read: couldn't read path /local/domain/2/vm xenstore-read: couldn't read path /local/domain/9/vm xenstore-read: couldn't read path /local/domain/3/vm xenstore-read: couldn't read path /local/domain/4/vm Either xen-tools (or whatever else in xen unstable) requires correlation with patched kernel. --- On Mon, 3/9/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris Derzhavets <bderzhavets@yahoo.com> Subject: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: "Keir Fraser" <keir.fraser@eu.citrix.com> Cc: "Xen-devel" <xen-devel@lists.xensource.com> Date: Monday, March 9, 2009, 10:31 AM Just cloned,built and installed the most recent xen-unstable. Seems like "make tools" reports some errors , but still finishes with no error message. CentOS 5.2 PV DomU may be loaded OK only the very first time. The next attempt after DomU shutdown brings it to paused state. After "xm unpause DomainName":- i8042.c: No controller found. in 1 seconds Red Hat nash version 5.1.19.6 starting Reading all physical volumes. This may take a while... No volume groups found Volume group "VolGroup00" not found mount: could not find filesystem '/dev/root' setuproot: moving /dev failed: No such file or directory setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory switchroot: mount failed: No such file or directory Kernel panic - not syncing: Attempted to kill init! root@ServerUbuntu810:/home/boris/vm# Error: Device 51712 (vbd) could not be connected. Hotplug scripts not working. /var/log/xen/xend.log:- [2009-03-09 10:18:33 6335] DEBUG (XendDomainInfo:2131) No device model [2009-03-09 10:18:33 6335] DEBUG (XendDomainInfo:2133) Releasing devices [2009-03-09 10:19:29 6335] DEBUG (DevController:629) hotplugStatusCallback /local/domain/0/backend/vbd/2/51712/hotplug-status. [2009-03-09 10:19:29 6335] DEBUG (DevController:643) hotplugStatusCallback 1. [2009-03-09 10:19:42 6335] ERROR (XendDomainInfo:1983) Failed to restart domain 2. Traceback (most recent call last): File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 1969, in _restart new_dom.waitForDevices() File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 1020, in waitForDevices self.getDeviceController(devclass).waitForDevices() File "//usr/lib64/python/xen/xend/server/DevController.py", line 140, in waitForDevices return map(self.waitForDevice, self.deviceIDs()) File "//usr/lib64/python/xen/xend/server/DevController.py", line 152, in waitForDevice self.destroyDevice(devid, False) File "//usr/lib64/python/xen/xend/server/blkif.py", line 200, in destroyDevice DevController.destroyDevice(self, devid, force) File "//usr/lib64/python/xen/xend/server/DevController.py", line 228, in destroyDevice self.writeBackend(dev, 'online', "0") File "//usr/lib64/python/xen/xend/server/DevController.py", line 474, in writeBackend raise VmError("Device %s not connected" % devid) VmError: Device 51712 not connected [2009-03-09 10:21:06 6335] DEBUG (DevController:629) hotplugStatusCallback /local/domain/0/backend/vbd/3/51712/hotplug-status. [2009-03-09 10:21:06 6335] DEBUG (DevController:643) hotplugStatusCallback 2. Start F10 PV DomU:- root@ServerUbuntu810:/home/boris/vm# xm create -c f10.pyrun Using config file "./f10.pyrun". PCI: Fatal: No config space access function found IO APIC resources could be not be allocated. Loading /lib/kbd/keymaps/i386/qwerty/us.map BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: [<ffffffffa00010e5>] backend_changed+0x2d5/0x3af [xen_blkfront] PGD 7d1f6067 PUD 7d143067 PMD 7d116067 PTE 0 Oops: 0000 [1] SMP CPU 1 Modules linked in: xen_blkfront Pid: 19, comm: xenwatch Not tainted 2.6.27.5-117.fc10.x86_64 #1 RIP: e030:[<ffffffffa00010e5>] [<ffffffffa00010e5>] backend_changed+0x2d5/0x3af [xen_blkfront] RSP: e02b:ffff88007f40fdf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88007d02d840 RCX: 0000000000000000 RDX: ffff88007f40fe28 RSI: 0000000000000005 RDI: ffff88007ff5f400 RBP: ffff88007f40fe80 R08: ffff88007f40fdd0 R09: ffff88007f40fcc0 R10: 0000000000000001 R11: ffff880000000018 R12: ffff88007ff5f400 R13: ffff88007d042000 R14: 000000000000000a R15: ffffffff817e2f44 FS: 00007fb68f67e6f0(0000) GS:ffff88007fc04880(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000007d105000 CR4: 0000000000002660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process xenwatch (pid: 19, threadinfo ffff88007f40e000, task ffff88007ffd5c40) Stack: ffff88007f40fe00 ffff88007f40fe40 ffffffff816de500 ffffffff816de500 ffffffff81455f53 ffffffff81462b99 ffff88007f40fe7c 0000000000000000 000000000000000a ffff88007d02d840 ffff88007ff5f400 ffffffffa0002ac0 Call Trace: [<ffffffff811c91e6>] otherend_changed+0x81/0x8a [<ffffffff811c7e14>] xenwatch_thread+0x101/0x134 [<ffffffff81055199>] ? autoremove_wake_function+0x0/0x38 [<ffffffff811c7d13>] ? xenwatch_thread+0x0/0x134 [<ffffffff81054e53>] kthread+0x49/0x76 [<ffffffff810116e9>] child_rip+0xa/0x11 [<ffffffff81010a07>] ? restore_args+0x0/0x30 [<ffffffff810116df>] ? child_rip+0x0/0x11 Code: 58 08 e9 97 00 00 00 49 8b 7d 00 48 c7 c2 b9 15 00 a0 be ed ff ff ff 48 8b 4f 10 31 c0 e8 da 5f 1c e1 e9 cf 00 00 00 49 8b 45 08 <8b> 38 c1 e7 14 0b 78 04 e8 26 55 0e e1 48 85 c0 48 89 c3 75 16 RIP [<ffffffffa00010e5>] backend_changed+0x2d5/0x3af [xen_blkfront] RSP <ffff88007f40fdf0> CR2: 0000000000000000 ---[ end trace bf88f6e1c7a703d2 ]--- root@ServerUbuntu810:/home/boris/vm# Error: Device 51712 (vbd) could not be connected. Hotplug scripts not working. --- On Mon, 3/9/09, Keir Fraser <keir.fraser@eu.citrix.com> wrote: From: Keir Fraser <keir.fraser@eu.citrix.com> Subject: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: "bderzhavets@yahoo.com" <bderzhavets@yahoo.com> Cc: "Xen-devel" <xen-devel@lists.xensource.com> Date: Monday, March 9, 2009, 7:26 AM If you¹re using a recent xen-unstable then you might try again with the current tip. A couple of changes went in recently (including one fix today). -- Keir On 09/03/2009 11:18, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote: > I was able to go through creating PV DomUs images via corresponding pygrub's > profiles for F10,CentOS 5.2,SNV_106 (64-bit all). > However, only Solaris Nevada PV DomU gets loaded via standard > pygrub profile. > > Attempt to load F10 PV:- > > [2009-03-09 05:33:38 6351] DEBUG (XendDomainInfo:92) > XendDomainInfo.create(['vm', ['name', 'F10PV'], ['memory', 2048], > ['on_reboot', 'restart'], ['on_crash', 'restart'], ['vcpus', 1], > ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'], ['bootloader', > '/usr/bin/pygrub'], ['bootloader_args', '-q'], ['image', ['linux', > ['videoram', 4]]], ['device', ['vbd', ['uname', 'phy:/dev/sdb5'], ['dev', > 'xvda'], ['mode', 'w']]], ['device', ['vif', ['bridge', 'eth0']]], ['device', > ['vkbd']], ['device', ['vfb', ['vncunused', '1'], ['type', 'vnc'], > ['xauthority', '/root/.Xauthority']]]]) > [2009-03-09 05:33:38 6351] DEBUG (XendDomainInfo:2183) > XendDomainInfo.constructDomain > [2009-03-09 05:33:38 6351] DEBUG (balloon:166) Balloon: 7239368 KiB free; need > 2048; done. > [2009-03-09 05:33:38 6351] DEBUG (XendDomain:452) Adding Domain: 8 > [2009-03-09 05:33:38 6351] DEBUG (XendDomainInfo:2362) > XendDomainInfo.initDomain: 8 256 > [2009-03-09 05:33:38 12975] DEBUG (XendBootloader:113) Launching bootloader as > ['/usr/bin/pygrub', '--output=/var/run/xend/boot/xenbl.29001', '-q', > '/dev/sdb5']. > [2009-03-09 05:33:39 6351] ERROR (XendBootloader:213) Boot loader didn't > return any data! > [2009-03-09 05:33:39 6351] ERROR (XendDomainInfo:472) VM start failed > Traceback (most recent call last): > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 452, in start > XendTask.log_progress(31, 60, self._initDomain) > File "//usr/lib64/python/xen/xend/XendTask.py", line 209, in log_progress > retval = func(*args, **kwds) > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2364, in > _initDomain > self._configureBootloader() > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2765, in > _configureBootloader > bootloader_args, kernel, ramdisk, args) > File "//usr/lib64/python/xen/xend/XendBootloader.py", line 214, in > bootloader > raise VmError, msg > > Attempt to load CentOS 5.2 PV:- > > [2009-03-09 06:45:39 6351] DEBUG (XendDomainInfo:92) > XendDomainInfo.create(['vm', ['name', 'RHEL52PV'], ['memory', 2048], ['vcpus', > 1], ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'], ['image', > ['linux', ['videoram', 4]]], ['device', ['vbd', ['uname', 'phy:/dev/sdb5'], > ['dev', 'xvda'], ['mode', 'w']]], ['device', ['vif', ['bridge', 'eth0']]]]) > [2009-03-09 06:45:39 6351] DEBUG (XendDomainInfo:2183) > XendDomainInfo.constructDomain > [2009-03-09 06:45:39 6351] DEBUG (balloon:166) Balloon: 7239368 KiB free; need > 2048; done. > [2009-03-09 06:45:39 6351] DEBUG (XendDomain:452) Adding Domain: 12 > [2009-03-09 06:45:39 6351] DEBUG (XendDomainInfo:2362) > XendDomainInfo.initDomain: 12 256 > [2009-03-09 06:45:39 16739] DEBUG (XendBootloader:113) Launching bootloader as > ['/usr/bin/pygrub', '--output=/var/run/xend/boot/xenbl.15023', '/dev/sdb5']. > [2009-03-09 06:45:44 6351] ERROR (XendBootloader:213) Boot loader didn't > return any data! > [2009-03-09 06:45:44 6351] ERROR (XendDomainInfo:472) VM start failed > Traceback (most recent call last): > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 452, in start > XendTask.log_progress(31, 60, self._initDomain) > File "//usr/lib64/python/xen/xend/XendTask.py", line 209, in log_progress > retval = func(*args, **kwds) > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2364, in > _initDomain > self._configureBootloader() > File "//usr/lib64/python/xen/xend/XendDomainInfo.py", line 2765, in > _configureBootloader > bootloader_args, kernel, ramdisk, args) > File "//usr/lib64/python/xen/xend/XendBootloader.py", line 214, in > bootloader > raise VmError, msg > VmError: Boot loader didn't return any data! > > > > > > > > > > --- On Sun, 3/8/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> From: Jeremy Fitzhardinge <jeremy@goop.org> >> Subject: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use >> it >> To: "Keir Fraser" <keir.fraser@eu.citrix.com> >> Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Marc - A. Dahlhaus [ >> Administration | Westermann GmbH ]" <mad@wol.de>, "Boris Derzhavets" >> <bderzhavets@yahoo.com> >> Date: Sunday, March 8, 2009, 12:31 AM >> >> Mask X86_FEATURE_XSAVE in cpuid leaf 1, ecx, as we don't allow guests to >> use it (by setting cr4.OSXSAVE). >> >> This prevents crashes in pvops dom0 kernels, as new versions of Linux try >> to use this feature. >> >> (This patch deals with dom0 cpuid; I'm not sure where the right place to >> set up the default mask for domU is.) >> >> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >> >> diff -r 7f573cb76db4 xen/arch/x86/traps.c >> --- a/xen/arch/x86/traps.c Tue Mar 03 13:22:28 2009 +0000 >> +++ b/xen/arch/x86/traps.c Sat Mar 07 17:02:03 2009 -0800 >> @@ -757,6 +757,7 @@ >> __clear_bit(X86_FEATURE_XTPR % 32, &c); >> __clear_bit(X86_FEATURE_PDCM % 32, &c); >> __clear_bit(X86_FEATURE_DCA % 32, &c); >> + __clear_bit(X86_FEATURE_XSAVE % 32, &c); >> if ( !cpu_has_apic ) >> >> __clear_bit(X86_FEATURE_X2APIC % 32, &c); >> __set_bit(X86_FEATURE_HYPERVISOR % 32, &c); >> diff -r 7f573cb76db4 xen/include/asm-x86/cpufeature.h >> --- a/xen/include/asm-x86/cpufeature.h Tue Mar 03 13:22:28 2009 +0000 >> +++ b/xen/include/asm-x86/cpufeature.h Sat Mar 07 17:02:03 2009 -0800 >> @@ -95,6 +95,7 @@ >> #define X86_FEATURE_SSE4_2 (4*32+20) /* Streaming SIMD Extensions 4.2 */ >> #define X86_FEATURE_X2APIC (4*32+21) /* Extended xAPIC */ >> #define X86_FEATURE_POPCNT (4*32+23) /* POPCNT instruction */ >> +#define X86_FEATURE_XSAVE (4*32+26) /* XSAVE/XRSTOR/XSETBV/XGETBV */ >> #define X86_FEATURE_HYPERVISOR (4*32+31) /* Running under some hypervisor */ >> >> /* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC0000001, word 5 */ >> >> > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel [-- Attachment #1.2: Type: text/html, Size: 15650 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-10 22:24 ` Boris Derzhavets @ 2009-03-11 0:29 ` Jeremy Fitzhardinge 2009-03-11 7:26 ` Boris Derzhavets 0 siblings, 1 reply; 46+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-11 0:29 UTC (permalink / raw) To: bderzhavets; +Cc: Xen-devel, Keir Fraser Boris Derzhavets wrote: > > Seems like new kernel brought up back some old issues with ubuntu 8.10 > devices. It never happened before patching 2.6.29-rc7 kernel on C2D > boxes with the same ubuntu 8.10 server release and 2.6.29-rc5. > In particular, CentOS 5.2 PV DomU's xen-hotplug.log looks like:- > > xenstore-read: couldn't read path /local/domain/2/vm > xenstore-read: couldn't read path /local/domain/9/vm > xenstore-read: couldn't read path /local/domain/3/vm > xenstore-read: couldn't read path /local/domain/4/vm > > Either xen-tools (or whatever else in xen unstable) requires correlation > with patched kernel. > Ah, I noticed that too, but I don't see any obvious changes which might have caused this. Time to pull out "git bisect" I think. J ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 0:29 ` Jeremy Fitzhardinge @ 2009-03-11 7:26 ` Boris Derzhavets 2009-03-11 8:40 ` Boris Derzhavets 0 siblings, 1 reply; 46+ messages in thread From: Boris Derzhavets @ 2009-03-11 7:26 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Xen-devel, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 1345 bytes --] disk= [ phy:/dev/sdb5] seems not to be released after PV DomU shutdown. Hence , second attempt to load DomU gets paused waiting for particular device. When i reboot xen host, DomU can be loaded again. --- On Tue, 3/10/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: bderzhavets@yahoo.com Cc: "Keir Fraser" <keir.fraser@eu.citrix.com>, "Xen-devel" <xen-devel@lists.xensource.com> Date: Tuesday, March 10, 2009, 8:29 PM Boris Derzhavets wrote: > > Seems like new kernel brought up back some old issues with ubuntu 8.10 > devices. It never happened before patching 2.6.29-rc7 kernel on C2D boxes with the same ubuntu 8.10 server release and 2.6.29-rc5. > In particular, CentOS 5.2 PV DomU's xen-hotplug.log looks like:- > > xenstore-read: couldn't read path /local/domain/2/vm > xenstore-read: couldn't read path /local/domain/9/vm > xenstore-read: couldn't read path /local/domain/3/vm > xenstore-read: couldn't read path /local/domain/4/vm > Either xen-tools (or whatever else in xen unstable) requires correlation > with patched kernel. > Ah, I noticed that too, but I don't see any obvious changes which might have caused this. Time to pull out "git bisect" I think. J [-- Attachment #1.2: Type: text/html, Size: 1750 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 7:26 ` Boris Derzhavets @ 2009-03-11 8:40 ` Boris Derzhavets 2009-03-11 9:09 ` Attempt to install SNV_106 under Suse's 2.6.27 xen-ified kernel & Xen Unstable Boris Derzhavets 2009-03-11 11:36 ` Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Boris Derzhavets 0 siblings, 2 replies; 46+ messages in thread From: Boris Derzhavets @ 2009-03-11 8:40 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Xen-devel, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 4139 bytes --] I've got the same issue with CentOS 5.2 PV DomU (same /dev/sdb5) under Suse's 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). I believe Xen is broken in some way. It's not about the kernel. Boris. --- On Wed, 3/11/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris Derzhavets <bderzhavets@yahoo.com> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: "Jeremy Fitzhardinge" <jeremy@goop.org> Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" <keir.fraser@eu.citrix.com> Date: Wednesday, March 11, 2009, 3:26 AM disk= [ phy:/dev/sdb5] seems not to be released after PV DomU shutdown. Hence , second attempt to load DomU gets paused waiting for particular device. When i reboot xen host, DomU can be loaded again. --- On Tue, 3/10/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: bderzhavets@yahoo.com Cc: "Keir Fraser" <keir.fraser@eu.citrix.com>, "Xen-devel" <xen-devel@lists.xensource.com> Date: Tuesday, March 10, 2009, 8:29 PM Boris Derzhavets wrote: > > Seems like new kernel brought up back some old issues with ubuntu 8.10 > devices. It never happened before patching 2.6.29-rc7 kernel on C2D boxes with the same ubuntu 8.10 server release and 2.6.29-rc5. > In particular, CentOS 5.2 PV DomU's xen-hotplug.log looks like:- > > xenstore-read: couldn't read path /local/domain/2/vm > xenstore-read: couldn't read path /local/domain/9/vm > xenstore-read: couldn't read path /local/domain/3/vm > xenstore-read: couldn't read path /local/domain/4/vm > Either xen-tools (or whatever else in xen unstable) requires correlation > with patched kernel. > Ah, I noticed that too, but I don't see any obvious changes which might have caused this. Time to pull out "git bisect" I think. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel second boot up under Novell's 2.6.27 & Xen Unstable ( the most recent). I believe it's not about kernel, it's about Xen Unstable. It's broken in some way. Boris. --- On Wed, 3/11/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris Derzhavets <bderzhavets@yahoo.com> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: "Jeremy Fitzhardinge" <jeremy@goop.org> Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" <keir.fraser@eu.citrix.com> Date: Wednesday, March 11, 2009, 3:26 AM disk= [ phy:/dev/sdb5] seems not to be released after PV DomU shutdown. Hence , second attempt to load DomU gets paused waiting for particular device. When i reboot xen host, DomU can be loaded again. --- On Tue, 3/10/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: bderzhavets@yahoo.com Cc: "Keir Fraser" <keir.fraser@eu.citrix.com>, "Xen-devel" <xen-devel@lists.xensource.com> Date: Tuesday, March 10, 2009, 8:29 PM Boris Derzhavets wrote: > > Seems like new kernel brought up back some old issues with ubuntu 8.10 > devices. It never happened before patching 2.6.29-rc7 kernel on C2D boxes with the same ubuntu 8.10 server release and 2.6.29-rc5. > In particular, CentOS 5.2 PV DomU's xen-hotplug.log looks like:- > > xenstore-read: couldn't read path /local/domain/2/vm > xenstore-read: couldn't read path /local/domain/9/vm > xenstore-read: couldn't read path /local/domain/3/vm > xenstore-read: couldn't read path /local/domain/4/vm > Either xen-tools (or whatever else in xen unstable) requires correlation > with patched kernel. > Ah, I noticed that too, but I don't see any obvious changes which might have caused this. Time to pull out "git bisect" I think. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel [-- Attachment #1.2: Type: text/html, Size: 5970 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Attempt to install SNV_106 under Suse's 2.6.27 xen-ified kernel & Xen Unstable 2009-03-11 8:40 ` Boris Derzhavets @ 2009-03-11 9:09 ` Boris Derzhavets 2009-03-11 11:36 ` Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Boris Derzhavets 1 sibling, 0 replies; 46+ messages in thread From: Boris Derzhavets @ 2009-03-11 9:09 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Xen-devel, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 2087 bytes --] root@ServerUbuntu810:/home/boris/vm# xm info host : ServerUbuntu810 release : 2.6.27.5 version : #1 SMP Sun Mar 1 02:27:38 EST 2009 machine : x86_64 nr_cpus : 4 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 1 cpu_mhz : 2833 hw_caps : bfebfbff:20100800:00000000:00000140:0408e3fd:00000000:00000001:00000000 virt_caps : hvm total_memory : 8191 free_memory : 2074 node_to_cpu : node0:0-3 node_to_memory : node0:2074 xen_major : 3 xen_minor : 4 xen_extra : -unstable xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : Mon Mar 09 10:32:24 2009 +0000 19297:b249f3e979a5 cc_compiler : gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) cc_compile_by : root cc_compile_domain : cc_compile_date : Tue Mar 10 16:03:22 EDT 2009 xend_config_format : 4 root@ServerUbuntu810:/home/boris/vm# xm create -c snv106.py Using config file "./snv106.py". WARNING: Cannot extract revision on this hypervisor version: v-unstable, unexpected version format v3.4-unstable chgset 'Mon Mar 09 10:32:24 2009 +0000 19297:b249f3e979a5' SunOS Release 5.11 Version snv_106 64-bit Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Configuring /dev 1. Solaris Interactive Text (Console session) (default) 2. Apply driver updates 3. Single user shell Enter the number of your choice. Selected: 1 Solaris Interactive Text (Console session) WARNING: g.e. still in use! root@ServerUbuntu810:/home/boris/vm# Error: Device 6 (vbd) could not be connected. Hotplug scripts not working. [-- Attachment #1.2: Type: text/html, Size: 4182 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 8:40 ` Boris Derzhavets 2009-03-11 9:09 ` Attempt to install SNV_106 under Suse's 2.6.27 xen-ified kernel & Xen Unstable Boris Derzhavets @ 2009-03-11 11:36 ` Boris Derzhavets 2009-03-11 16:09 ` Jeremy Fitzhardinge 1 sibling, 1 reply; 46+ messages in thread From: Boris Derzhavets @ 2009-03-11 11:36 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Xen-devel, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 5005 bytes --] Blktap helps out for multiple CentOS PV DomU restarts (with image on FS) under Suse's 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). But it seems not implemented yet for 2.6.29-rc7 --- On Wed, 3/11/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris Derzhavets <bderzhavets@yahoo.com> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: "Jeremy Fitzhardinge" <jeremy@goop.org> Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" <keir.fraser@eu.citrix.com> Date: Wednesday, March 11, 2009, 4:40 AM I've got the same issue with CentOS 5.2 PV DomU (same /dev/sdb5) under Suse's 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). I believe Xen is broken in some way. It's not about the kernel. Boris. --- On Wed, 3/11/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris Derzhavets <bderzhavets@yahoo.com> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: "Jeremy Fitzhardinge" <jeremy@goop.org> Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" <keir.fraser@eu.citrix.com> Date: Wednesday, March 11, 2009, 3:26 AM disk= [ phy:/dev/sdb5] seems not to be released after PV DomU shutdown. Hence , second attempt to load DomU gets paused waiting for particular device. When i reboot xen host, DomU can be loaded again. --- On Tue, 3/10/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: bderzhavets@yahoo.com Cc: "Keir Fraser" <keir.fraser@eu.citrix.com>, "Xen-devel" <xen-devel@lists.xensource.com> Date: Tuesday, March 10, 2009, 8:29 PM Boris Derzhavets wrote: > > Seems like new kernel brought up back some old issues with ubuntu 8.10 > devices. It never happened before patching 2.6.29-rc7 kernel on C2D boxes with the same ubuntu 8.10 server release and 2.6.29-rc5. > In particular, CentOS 5.2 PV DomU's xen-hotplug.log looks like:- > > xenstore-read: couldn't read path /local/domain/2/vm > xenstore-read: couldn't read path /local/domain/9/vm > xenstore-read: couldn't read path /local/domain/3/vm > xenstore-read: couldn't read path /local/domain/4/vm > Either xen-tools (or whatever else in xen unstable) requires correlation > with patched kernel. > Ah, I noticed that too, but I don't see any obvious changes which might have caused this. Time to pull out "git bisect" I think. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel second boot up under Novell's 2.6.27 & Xen Unstable ( the most recent). I believe it's not about kernel, it's about Xen Unstable. It's broken in some way. Boris. --- On Wed, 3/11/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris Derzhavets <bderzhavets@yahoo.com> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: "Jeremy Fitzhardinge" <jeremy@goop.org> Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" <keir.fraser@eu.citrix.com> Date: Wednesday, March 11, 2009, 3:26 AM disk= [ phy:/dev/sdb5] seems not to be released after PV DomU shutdown. Hence , second attempt to load DomU gets paused waiting for particular device. When i reboot xen host, DomU can be loaded again. --- On Tue, 3/10/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: bderzhavets@yahoo.com Cc: "Keir Fraser" <keir.fraser@eu.citrix.com>, "Xen-devel" <xen-devel@lists.xensource.com> Date: Tuesday, March 10, 2009, 8:29 PM Boris Derzhavets wrote: > > Seems like new kernel brought up back some old issues with ubuntu 8.10 > devices. It never happened before patching 2.6.29-rc7 kernel on C2D boxes with the same ubuntu 8.10 server release and 2.6.29-rc5. > In particular, CentOS 5.2 PV DomU's xen-hotplug.log looks like:- > > xenstore-read: couldn't read path /local/domain/2/vm > xenstore-read: couldn't read path /local/domain/9/vm > xenstore-read: couldn't read path /local/domain/3/vm > xenstore-read: couldn't read path /local/domain/4/vm > Either xen-tools (or whatever else in xen unstable) requires correlation > with patched kernel. > Ah, I noticed that too, but I don't see any obvious changes which might have caused this. Time to pull out "git bisect" I think. 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 [-- Attachment #1.2: Type: text/html, Size: 7257 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 11:36 ` Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Boris Derzhavets @ 2009-03-11 16:09 ` Jeremy Fitzhardinge 2009-03-11 16:27 ` Boris Derzhavets 0 siblings, 1 reply; 46+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-11 16:09 UTC (permalink / raw) To: bderzhavets; +Cc: Xen-devel, Keir Fraser Boris Derzhavets wrote: > Blktap helps out for multiple CentOS PV DomU restarts (with image on > FS) under Suse's 2.6.27 xen-ified kernel & Xen Unstable ( the most > recent). > But it seems not implemented yet for 2.6.29-rc7 > So your conclusion is that there's a regression in the tools stack when using blkback rather than blktab? J ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 16:09 ` Jeremy Fitzhardinge @ 2009-03-11 16:27 ` Boris Derzhavets 2009-03-11 16:50 ` Jeremy Fitzhardinge 2009-03-11 19:13 ` Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Andrew Lyon 0 siblings, 2 replies; 46+ messages in thread From: Boris Derzhavets @ 2009-03-11 16:27 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Xen-devel, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 1178 bytes --] It's not so important for me. The important thing is:- CentOS 5.2 PV DomU may be loaded only the very first time under Suse's 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). Attempt to shutdown and start it again gives VBD cannot be connected . Hotplug scripts not working. That's a core issue, same behavior as under 2.6.29-rc7 (with XSAVE patch ). Kernel doesn't seem to be a root cause. I believe Xen unstable is broken in some way. Boris. --- On Wed, 3/11/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: bderzhavets@yahoo.com Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" <keir.fraser@eu.citrix.com> Date: Wednesday, March 11, 2009, 12:09 PM Boris Derzhavets wrote: > Blktap helps out for multiple CentOS PV DomU restarts (with image on FS) under Suse's 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). > But it seems not implemented yet for 2.6.29-rc7 > So your conclusion is that there's a regression in the tools stack when using blkback rather than blktab? J [-- Attachment #1.2: Type: text/html, Size: 1552 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 16:27 ` Boris Derzhavets @ 2009-03-11 16:50 ` Jeremy Fitzhardinge 2009-03-11 16:57 ` Boris Derzhavets 2009-03-11 19:13 ` Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Andrew Lyon 1 sibling, 1 reply; 46+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-11 16:50 UTC (permalink / raw) To: bderzhavets; +Cc: Xen-devel, Keir Fraser Boris Derzhavets wrote: > It's not so important for me. The important thing is:- > > CentOS 5.2 PV DomU may be loaded only the very first time under Suse's > 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). Attempt to > shutdown and start it again gives VBD cannot be connected . Hotplug > scripts not working. That's a core issue, same behavior as under > 2.6.29-rc7 (with XSAVE patch ). Kernel doesn't seem to be a root cause. > I believe Xen unstable is broken in some way. > Could you try bisecting xen-unstable to see which change started failing for you? There were some recent changes to the hotplug scripts which could have introduced a problem. However, I'm pretty sure I started seeing this problem without updating my usermode tools, so there could also be a kernel problem. But its not obvious what it might be. Thanks, J ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 16:50 ` Jeremy Fitzhardinge @ 2009-03-11 16:57 ` Boris Derzhavets 2009-03-11 17:04 ` Jeremy Fitzhardinge 0 siblings, 1 reply; 46+ messages in thread From: Boris Derzhavets @ 2009-03-11 16:57 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Xen-devel, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 1565 bytes --] >Could you try bisecting xen-unstable to see which change started failing for >you? There were some recent changes to the hotplug scripts which could have > introduced a problem. No. It's above me. --- On Wed, 3/11/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: bderzhavets@yahoo.com Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" <keir.fraser@eu.citrix.com> Date: Wednesday, March 11, 2009, 12:50 PM Boris Derzhavets wrote: > It's not so important for me. The important thing is:- > > CentOS 5.2 PV DomU may be loaded only the very first time under Suse's 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). Attempt to shutdown and start it again gives VBD cannot be connected . Hotplug scripts not working. That's a core issue, same behavior as under 2.6.29-rc7 (with XSAVE patch ). Kernel doesn't seem to be a root cause. > I believe Xen unstable is broken in some way. > Could you try bisecting xen-unstable to see which change started failing for you? There were some recent changes to the hotplug scripts which could have introduced a problem. However, I'm pretty sure I started seeing this problem without updating my usermode tools, so there could also be a kernel problem. But its not obvious what it might be. Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel [-- Attachment #1.2: Type: text/html, Size: 2005 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 16:57 ` Boris Derzhavets @ 2009-03-11 17:04 ` Jeremy Fitzhardinge 2009-03-11 17:21 ` Boris Derzhavets ` (2 more replies) 0 siblings, 3 replies; 46+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-11 17:04 UTC (permalink / raw) To: bderzhavets; +Cc: Xen-devel, Keir Fraser Boris Derzhavets wrote: > >Could you try bisecting xen-unstable to see which change started failing for > >you? There were some recent changes to the hotplug scripts which could have > > introduced a problem. > No. It's above me. > > If you're fetching xen-unstable with "hg" and building it, then you have everything you need to do bisection: 1. hg bisect -r 2. hg bisect -g <known good version> 3. hg bisect -b <known bad version> 4. build as usual and test 1. if works: hg bisect -g 2. if not: hg bisect -b 5. repeat 4 until first bad version has been isolated Thanks, J ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 17:04 ` Jeremy Fitzhardinge @ 2009-03-11 17:21 ` Boris Derzhavets 2009-03-11 17:43 ` Boris Derzhavets 2009-03-13 14:39 ` Boris Derzhavets 2 siblings, 0 replies; 46+ messages in thread From: Boris Derzhavets @ 2009-03-11 17:21 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Xen-devel, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 1789 bytes --] I didn't get a chance to notice the last good version , because pygrub stopped working (return no data ) right after XSAVE patch (for myself, of course) . ***************** Then i followed ****************** Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Monday, March 9, 2009 7:26 AM From: "Keir Fraser" <keir.fraser@eu.citrix.com> Add sender to Contacts To: "bderzhavets@yahoo.com" <bderzhavets@yahoo.com> Cc: "Xen-devel" <xen-devel@lists.xensource.com> If you¹re using a recent xen-unstable then you might try again with the current tip. A couple of changes went in recently (including one fix today). -- Keir ******************************** and turned into current issues ******************************** --- On Wed, 3/11/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: bderzhavets@yahoo.com Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" <keir.fraser@eu.citrix.com> Date: Wednesday, March 11, 2009, 1:04 PM Boris Derzhavets wrote: > >Could you try bisecting xen-unstable to see which change started failing for > >you? There were some recent changes to the hotplug scripts which could have > > introduced a problem. > No. It's above me. > If you're fetching xen-unstable with "hg" and building it, then you have everything you need to do bisection: 1. hg bisect -r 2. hg bisect -g <known good version> 3. hg bisect -b <known bad version> 4. build as usual and test 1. if works: hg bisect -g 2. if not: hg bisect -b 5. repeat 4 until first bad version has been isolated Thanks, J [-- Attachment #1.2: Type: text/html, Size: 2226 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 17:04 ` Jeremy Fitzhardinge 2009-03-11 17:21 ` Boris Derzhavets @ 2009-03-11 17:43 ` Boris Derzhavets 2009-03-11 17:47 ` Jeremy Fitzhardinge 2009-03-13 14:39 ` Boris Derzhavets 2 siblings, 1 reply; 46+ messages in thread From: Boris Derzhavets @ 2009-03-11 17:43 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Xen-devel, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 1063 bytes --] Sorry, i may try. Just one question Is version a changeset number ? --- On Wed, 3/11/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: bderzhavets@yahoo.com Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" <keir.fraser@eu.citrix.com> Date: Wednesday, March 11, 2009, 1:04 PM Boris Derzhavets wrote: > >Could you try bisecting xen-unstable to see which change started failing for > >you? There were some recent changes to the hotplug scripts which could have > > introduced a problem. > No. It's above me. > If you're fetching xen-unstable with "hg" and building it, then you have everything you need to do bisection: 1. hg bisect -r 2. hg bisect -g <known good version> 3. hg bisect -b <known bad version> 4. build as usual and test 1. if works: hg bisect -g 2. if not: hg bisect -b 5. repeat 4 until first bad version has been isolated Thanks, J [-- Attachment #1.2: Type: text/html, Size: 1482 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 17:43 ` Boris Derzhavets @ 2009-03-11 17:47 ` Jeremy Fitzhardinge 2009-03-11 19:49 ` Boris Derzhavets 0 siblings, 1 reply; 46+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-11 17:47 UTC (permalink / raw) To: bderzhavets; +Cc: Xen-devel, Keir Fraser Boris Derzhavets wrote: > Sorry, i may try. Just one question > > Is version a changeset number ? > Yes. J ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 17:47 ` Jeremy Fitzhardinge @ 2009-03-11 19:49 ` Boris Derzhavets 2009-03-12 0:41 ` Jeremy Fitzhardinge 0 siblings, 1 reply; 46+ messages in thread From: Boris Derzhavets @ 2009-03-11 19:49 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Xen-devel, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 1920 bytes --] What i am doing wrong ? hg bisect -r hg bisect -g 19282 hg bisect -b 19297 make install-xen OK make install-tools make[5]: *** [block-qcow2.o] Error 1 make[5]: Leaving directory `/usr/src/xen-unstable.hg/tools/blktap/drivers' make[4]: *** [subdir-install-drivers] Error 2 make[4]: Leaving directory `/usr/src/xen-unstable.hg/tools/blktap' make[3]: *** [subdirs-install] Error 2 make[3]: Leaving directory `/usr/src/xen-unstable.hg/tools/blktap' make[2]: *** [subdir-install-blktap] Error 2 make[2]: Leaving directory `/usr/src/xen-unstable.hg/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/usr/src/xen-unstable.hg/tools' make: *** [install-tools] Error 2 hg bisect -r hg bisect -g 19232 hg bisect -b 19297 make install-xen make[4]: Leaving directory `/usr/src/xen-unstable.hg/xen/arch/x86' make[3]: *** [/usr/src/xen-unstable.hg/xen/arch/x86/built_in.o] Error 2 make[3]: Leaving directory `/usr/src/xen-unstable.hg/xen/arch/x86' make[2]: *** [/usr/src/xen-unstable.hg/xen/xen] Error 2 make[2]: Leaving directory `/usr/src/xen-unstable.hg/xen' make[1]: *** [install] Error 2 make[1]: Leaving directory `/usr/src/xen-unstable.hg/xen' make: *** [install-xen] Error 2 make install-tools OK --- On Wed, 3/11/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: bderzhavets@yahoo.com Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" <keir.fraser@eu.citrix.com> Date: Wednesday, March 11, 2009, 1:47 PM Boris Derzhavets wrote: > Sorry, i may try. Just one question > > Is version a changeset number ? > Yes. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel [-- Attachment #1.2: Type: text/html, Size: 2351 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 19:49 ` Boris Derzhavets @ 2009-03-12 0:41 ` Jeremy Fitzhardinge 0 siblings, 0 replies; 46+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-12 0:41 UTC (permalink / raw) To: bderzhavets; +Cc: Xen-devel, Keir Fraser Boris Derzhavets wrote: > What i am doing wrong ? > Not sure. You should only need to install tools though; Xen and the other trees should be irrelevant. > > hg bisect -r > hg bisect -g 19282 > hg bisect -b 19297 > make install-xen OK > make install-tools > > make[5]: *** [block-qcow2.o] Error 1 > What happens before this line? > make[5]: Leaving directory `/usr/src/xen-unstable.hg/tools/blktap/drivers' > make[4]: *** [subdir-install-drivers] Error 2 > make[4]: Leaving directory `/usr/src/xen-unstable.hg/tools/blktap' > make[3]: *** [subdirs-install] Error 2 > make[3]: Leaving directory `/usr/src/xen-unstable.hg/tools/blktap' > make[2]: *** [subdir-install-blktap] Error 2 > make[2]: Leaving directory `/usr/src/xen-unstable.hg/tools' > make[1]: *** [subdirs-install] Error 2 > make[1]: Leaving directory `/usr/src/xen-unstable.hg/tools' > make: *** [install-tools] Error 2 > > hg bisect -r > hg bisect -g 19232 > hg bisect -b 19297 > > make install-xen > make[4]: Leaving directory `/usr/src/xen-unstable.hg/xen/arch/x86' > make[3]: *** [/usr/src/xen-unstable.hg/xen/arch/x86/built_in.o] Error 2 > make[3]: Leaving directory `/usr/src/xen-unstable.hg/xen/arch/x86' > make[2]: *** [/usr/src/xen-unstable.hg/xen/xen] Error 2 > make[2]: Leaving directory `/usr/src/xen-unstable.hg/xen' > make[1]: *** [install] Error 2 > make[1]: Leaving directory `/usr/src/xen-unstable.hg/xen' > make: *** [install-xen] Error 2 > > make install-tools OK > J ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 17:04 ` Jeremy Fitzhardinge 2009-03-11 17:21 ` Boris Derzhavets 2009-03-11 17:43 ` Boris Derzhavets @ 2009-03-13 14:39 ` Boris Derzhavets 2009-03-13 15:20 ` Jeremy Fitzhardinge 2 siblings, 1 reply; 46+ messages in thread From: Boris Derzhavets @ 2009-03-13 14:39 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: Xen-devel, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 515 bytes --] Yesterday 2.6.29-rc7 ( built on 03/08/09) kernel worked fine under Xen Unstable (rel 19317). Today a new fresh kernel 2.6.29-rc7 has been built. The most recent rc7 kernel under Xen Unstable (rel 19317) generates an error (vif) cannot be connected, hotplug scripts not working when i attempted to start f10 PV DomU or SNV_106 PV DomU. Status of Xen seems to be OK due to same DomUs functionality under Suse's 2.6.27-5 & Xen Unstable (rel 19317), it is absolutely normal. Boris [-- Attachment #1.2: Type: text/html, Size: 700 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-13 14:39 ` Boris Derzhavets @ 2009-03-13 15:20 ` Jeremy Fitzhardinge 2009-03-13 15:46 ` Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) Dan Magenheimer 0 siblings, 1 reply; 46+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-13 15:20 UTC (permalink / raw) To: bderzhavets; +Cc: Xen-devel, Keir Fraser Boris Derzhavets wrote: > Yesterday 2.6.29-rc7 ( built on 03/08/09) kernel worked fine > under Xen Unstable (rel 19317). > Today a new fresh kernel 2.6.29-rc7 has been built. The most recent rc7 > kernel under Xen Unstable (rel 19317) generates an error (vif) cannot > be connected, hotplug scripts not working when i attempted to start > f10 PV DomU > or SNV_106 PV DomU. > Status of Xen seems to be OK due to same DomUs functionality under > Suse's 2.6.27-5 & Xen Unstable (rel 19317), it is absolutely normal. > Yes, I think there's a second problem in dom0, which has similar symptoms as the other hotplug scripts bug. The scripts bug confused efforts in tracking down the dom0 problem. I'll have another go at the kernel side today. J ^ permalink raw reply [flat|nested] 46+ messages in thread
* Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) 2009-03-13 15:20 ` Jeremy Fitzhardinge @ 2009-03-13 15:46 ` Dan Magenheimer 2009-03-13 16:05 ` Hot plug scripts not working c/s 19355 Jeremy Fitzhardinge 2009-03-13 16:59 ` Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) Keir Fraser 0 siblings, 2 replies; 46+ messages in thread From: Dan Magenheimer @ 2009-03-13 15:46 UTC (permalink / raw) To: Xen-devel, Jeremy Fitzhardinge, bderzhavets; +Cc: Keir Fraser A heads-up that I just got a "(tap)...Hotplug scripts not working" completely unrelated to pvops. I updated hypervisor and tools (but notably NOT dom0 kernel) to xen-unstable c/s 19355. Launching a domain now fails with the above error. Rolling tools (only) back to 19187 makes the problem go away. Is there maybe a new dependency between tools and dom0 kernel? > -----Original Message----- > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] > Sent: Friday, March 13, 2009 9:20 AM > To: bderzhavets@yahoo.com > Cc: Xen-devel; Keir Fraser > Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we > don't allow guests to use it > > > Boris Derzhavets wrote: > > Yesterday 2.6.29-rc7 ( built on 03/08/09) kernel worked fine > > under Xen Unstable (rel 19317). > > Today a new fresh kernel 2.6.29-rc7 has been built. The > most recent rc7 > > kernel under Xen Unstable (rel 19317) generates an error > (vif) cannot > > be connected, hotplug scripts not working when i attempted > to start > > f10 PV DomU > > or SNV_106 PV DomU. > > Status of Xen seems to be OK due to same DomUs functionality under > > Suse's 2.6.27-5 & Xen Unstable (rel 19317), it is > absolutely normal. > > > > Yes, I think there's a second problem in dom0, which has similar > symptoms as the other hotplug scripts bug. The scripts bug confused > efforts in tracking down the dom0 problem. I'll have another > go at the > kernel side today. > > J > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Hot plug scripts not working c/s 19355 2009-03-13 15:46 ` Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) Dan Magenheimer @ 2009-03-13 16:05 ` Jeremy Fitzhardinge 2009-03-13 16:59 ` Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) Keir Fraser 1 sibling, 0 replies; 46+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-13 16:05 UTC (permalink / raw) To: Dan Magenheimer; +Cc: bderzhavets, Xen-devel, Keir Fraser, Gerd Hoffmann Dan Magenheimer wrote: > A heads-up that I just got a "(tap)...Hotplug scripts not working" > completely unrelated to pvops. > > I updated hypervisor and tools (but notably NOT dom0 kernel) to > xen-unstable c/s 19355. Launching a domain now fails with the > above error. Rolling tools (only) back to 19187 makes the > problem go away. > Any chance you could try to pinpoint the failing version? > Is there maybe a new dependency between tools and dom0 kernel? > There's certainly nothing explicit. Bisecting the kernel seemed to point to some cleanups I did around /dev/privcmd, but that's not really used for hotplug/xenbus stuff (I mean, it is at a low level, but surely xenbus would break entirely if it were broken). And those changes work with older tools. (And the bisection was probably lead astray by the other hotplug bug.) Maybe some timing/ordering thing? Unfortunately I know very little about how things are supposed to work at that level. IanC said that he thought that xenbus watches were failing to fire, which makes me wonder if Gerd's xenstore fixes might be worth looking at more closely. J ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) 2009-03-13 15:46 ` Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) Dan Magenheimer 2009-03-13 16:05 ` Hot plug scripts not working c/s 19355 Jeremy Fitzhardinge @ 2009-03-13 16:59 ` Keir Fraser 2009-03-13 17:09 ` Jeremy Fitzhardinge 1 sibling, 1 reply; 46+ messages in thread From: Keir Fraser @ 2009-03-13 16:59 UTC (permalink / raw) To: Dan Magenheimer, Xen-devel, Jeremy Fitzhardinge, bderzhavets@yahoo.com On 13/03/2009 15:46, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote: > A heads-up that I just got a "(tap)...Hotplug scripts not working" > completely unrelated to pvops. > > I updated hypervisor and tools (but notably NOT dom0 kernel) to > xen-unstable c/s 19355. Launching a domain now fails with the > above error. Rolling tools (only) back to 19187 makes the > problem go away. > > Is there maybe a new dependency between tools and dom0 kernel? You could try reverting changeset 19342, as most likely culprit. -- Keir ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) 2009-03-13 16:59 ` Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) Keir Fraser @ 2009-03-13 17:09 ` Jeremy Fitzhardinge 2009-03-13 18:15 ` Boris Derzhavets ` (2 more replies) 0 siblings, 3 replies; 46+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-13 17:09 UTC (permalink / raw) To: Keir Fraser; +Cc: Dan Magenheimer, Xen-devel, bderzhavets@yahoo.com Keir Fraser wrote: > On 13/03/2009 15:46, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote: > > >> A heads-up that I just got a "(tap)...Hotplug scripts not working" >> completely unrelated to pvops. >> >> I updated hypervisor and tools (but notably NOT dom0 kernel) to >> xen-unstable c/s 19355. Launching a domain now fails with the >> above error. Rolling tools (only) back to 19187 makes the >> problem go away. >> >> Is there maybe a new dependency between tools and dom0 kernel? >> > > You could try reverting changeset 19342, as most likely culprit. > Is that the fixed xen-hotplug-cleanup change? The symptoms aren't quite the same; with the broken cleanup, there were lockfiles left lying about, so all the "block add" scripts were blocked waiting for the lock to be released. In this case, everything is just sitting there; the hotplug never seems to get started. J ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) 2009-03-13 17:09 ` Jeremy Fitzhardinge @ 2009-03-13 18:15 ` Boris Derzhavets 2009-03-13 18:49 ` Andrew Lyon 2009-03-16 17:17 ` Dan Magenheimer 2 siblings, 0 replies; 46+ messages in thread From: Boris Derzhavets @ 2009-03-13 18:15 UTC (permalink / raw) To: Keir Fraser, Jeremy Fitzhardinge; +Cc: Dan Magenheimer, Xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1837 bytes --] The most recent 2.6.29-rc7 under Xen (release19317) shows up hotplug issue at the very first start up. When i revers back to rc7 built on 03/08/09 under same Xen, hotplug issue gets gone. I gonna test Xen(19355) with Suse 2.6.27-5 kernel Boris. --- On Fri, 3/13/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: [Xen-devel] Re: Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) To: "Keir Fraser" <keir.fraser@eu.citrix.com> Cc: "Dan Magenheimer" <dan.magenheimer@oracle.com>, "Xen-devel" <xen-devel@lists.xensource.com>, "bderzhavets@yahoo.com" <bderzhavets@yahoo.com> Date: Friday, March 13, 2009, 1:09 PM Keir Fraser wrote: > On 13/03/2009 15:46, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote: > > >> A heads-up that I just got a "(tap)...Hotplug scripts not working" >> completely unrelated to pvops. >> >> I updated hypervisor and tools (but notably NOT dom0 kernel) to >> xen-unstable c/s 19355. Launching a domain now fails with the >> above error. Rolling tools (only) back to 19187 makes the >> problem go away. >> >> Is there maybe a new dependency between tools and dom0 kernel? >> > > You could try reverting changeset 19342, as most likely culprit. > Is that the fixed xen-hotplug-cleanup change? The symptoms aren't quite the same; with the broken cleanup, there were lockfiles left lying about, so all the "block add" scripts were blocked waiting for the lock to be released. In this case, everything is just sitting there; the hotplug never seems to get started. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel [-- Attachment #1.2: Type: text/html, Size: 2320 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) 2009-03-13 17:09 ` Jeremy Fitzhardinge 2009-03-13 18:15 ` Boris Derzhavets @ 2009-03-13 18:49 ` Andrew Lyon 2009-03-13 19:08 ` Boris Derzhavets 2009-03-16 17:17 ` Dan Magenheimer 2 siblings, 1 reply; 46+ messages in thread From: Andrew Lyon @ 2009-03-13 18:49 UTC (permalink / raw) To: Jeremy Fitzhardinge Cc: bderzhavets@yahoo.com, Dan Magenheimer, Xen-devel, Keir Fraser On Fri, Mar 13, 2009 at 5:09 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > Keir Fraser wrote: >> >> On 13/03/2009 15:46, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote: >> >> >>> >>> A heads-up that I just got a "(tap)...Hotplug scripts not working" >>> completely unrelated to pvops. >>> >>> I updated hypervisor and tools (but notably NOT dom0 kernel) to >>> xen-unstable c/s 19355. Launching a domain now fails with the >>> above error. Rolling tools (only) back to 19187 makes the >>> problem go away. >>> >>> Is there maybe a new dependency between tools and dom0 kernel? >>> >> >> You could try reverting changeset 19342, as most likely culprit. >> > > Is that the fixed xen-hotplug-cleanup change? The symptoms aren't quite the > same; with the broken cleanup, there were lockfiles left lying about, so all > the "block add" scripts were blocked waiting for the lock to be released. > In this case, everything is just sitting there; the hotplug never seems to > get started. > > J > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > I think the hotplug problem where the lockfile was left lying about is fixed, I updated to c/s 19354 today and since then no problems with hotplug scripts, I can start and stop domains cleanly or by destroying them and nothing is left behind, I've verified this by running the xen-hotplug-cleanup script manually and it completes and removes the lock as it should. Like boris I am using a opensuse kernel, so if he is still having problems I think he has another issue or there is a remaining problem with hotplug which for some reason doesnt trigger on my test system. There is a separate issue where Xen crashes with (XEN) ** page_alloc.c:534 -- 0/1 ffffffffffffffff which started around the same time the hotplug scripts were fixed, it happens regardless of which kernel is used and has been discussed in thead with subject "xen unstable crash". Andy ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) 2009-03-13 18:49 ` Andrew Lyon @ 2009-03-13 19:08 ` Boris Derzhavets 0 siblings, 0 replies; 46+ messages in thread From: Boris Derzhavets @ 2009-03-13 19:08 UTC (permalink / raw) To: Jeremy Fitzhardinge, Andrew Lyon; +Cc: Dan Magenheimer, Xen-devel, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 2921 bytes --] Suse's 2.6.27 xen-ified kernel & Xen Unstable (19355) don't have any problems with hotplug sripts. I've restarted F10 PV DomU several times. Boris --- On Fri, 3/13/09, Andrew Lyon <andrew.lyon@gmail.com> wrote: From: Andrew Lyon <andrew.lyon@gmail.com> Subject: Re: [Xen-devel] Re: Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) To: "Jeremy Fitzhardinge" <jeremy@goop.org> Cc: "bderzhavets@yahoo.com" <bderzhavets@yahoo.com>, "Dan Magenheimer" <dan.magenheimer@oracle.com>, "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" <keir.fraser@eu.citrix.com> Date: Friday, March 13, 2009, 2:49 PM On Fri, Mar 13, 2009 at 5:09 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > Keir Fraser wrote: >> >> On 13/03/2009 15:46, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote: >> >> >>> >>> A heads-up that I just got a "(tap)...Hotplug scripts not working" >>> completely unrelated to pvops. >>> >>> I updated hypervisor and tools (but notably NOT dom0 kernel) to >>> xen-unstable c/s 19355. Launching a domain now fails with the >>> above error. Rolling tools (only) back to 19187 makes the >>> problem go away. >>> >>> Is there maybe a new dependency between tools and dom0 kernel? >>> >> >> You could try reverting changeset 19342, as most likely culprit. >> > > Is that the fixed xen-hotplug-cleanup change? The symptoms aren't quite the > same; with the broken cleanup, there were lockfiles left lying about, so all > the "block add" scripts were blocked waiting for the lock to be released. > In this case, everything is just sitting there; the hotplug never seems to > get started. > > J > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > I think the hotplug problem where the lockfile was left lying about is fixed, I updated to c/s 19354 today and since then no problems with hotplug scripts, I can start and stop domains cleanly or by destroying them and nothing is left behind, I've verified this by running the xen-hotplug-cleanup script manually and it completes and removes the lock as it should. Like boris I am using a opensuse kernel, so if he is still having problems I think he has another issue or there is a remaining problem with hotplug which for some reason doesnt trigger on my test system. There is a separate issue where Xen crashes with (XEN) ** page_alloc.c:534 -- 0/1 ffffffffffffffff which started around the same time the hotplug scripts were fixed, it happens regardless of which kernel is used and has been discussed in thead with subject "xen unstable crash". Andy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel [-- Attachment #1.2: Type: text/html, Size: 3612 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* RE: Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) 2009-03-13 17:09 ` Jeremy Fitzhardinge 2009-03-13 18:15 ` Boris Derzhavets 2009-03-13 18:49 ` Andrew Lyon @ 2009-03-16 17:17 ` Dan Magenheimer 2009-03-16 18:00 ` Hot plug scripts not working c/s 19355 Jeremy Fitzhardinge 2 siblings, 1 reply; 46+ messages in thread From: Dan Magenheimer @ 2009-03-16 17:17 UTC (permalink / raw) To: Jeremy Fitzhardinge, Keir Fraser; +Cc: bderzhavets, Xen-devel > Any chance you could try to pinpoint the failing version? > > You could try reverting changeset 19342, as most likely culprit. Well I've been struggling with this on and off since Friday and am having major problems because there are now many parts that I'm no longer sure how to synchronize. The tools now seem to be dependent on ioemu but I don't know how (or if its possible) to synchronize versions of the ioemu git tree with a specific xen hg changeset. Rolling xen tools back to 19187 worked fine, but I couldn't roll the tools back to tip due to a compile error ioemu-dir/hw/pt-msi.c:95: error: too few arguments to xc_domain_update_msi_irq I did a git pull in ioemu-dir and no longer got the compile error but it didn't help (same hotplug problem) and now I can't rollback xen tools to 19187 because I get the opposite compile error. So my test machine, which HAD been working at least with tools 19187 is now useless unless I solve the problem. (BTW, I tried reverting 19342 and it didn't solve the problem.) I was able to do a fresh tip build and install on a new test machine (that previously had no xen on it at all), so I suspect my problem was due to a mismatch between dom0 and "something else" so am now in the process of rebuilding dom0 from latest. Argh! I thought bisecting was supposed to be easy! With so many interdependent parts (and two different change-tracking tools needed), perhaps its time to start being more careful about describing version interdependencies between them? Or maybe if I were sufficiently knowledgeable about both mercurial and git, this wouldn't be a problem? > -----Original Message----- > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] > Sent: Friday, March 13, 2009 11:09 AM > To: Keir Fraser > Cc: Dan Magenheimer; Xen-devel; bderzhavets@yahoo.com > Subject: Re: Hot plug scripts not working c/s 19355 (was: Re: [PATCH] > xen: mask XSAVE in cpuid since we don't allow guests to use it) > > > Keir Fraser wrote: > > On 13/03/2009 15:46, "Dan Magenheimer" > <dan.magenheimer@oracle.com> wrote: > > > > > >> A heads-up that I just got a "(tap)...Hotplug scripts not working" > >> completely unrelated to pvops. > >> > >> I updated hypervisor and tools (but notably NOT dom0 kernel) to > >> xen-unstable c/s 19355. Launching a domain now fails with the > >> above error. Rolling tools (only) back to 19187 makes the > >> problem go away. > >> > >> Is there maybe a new dependency between tools and dom0 kernel? > >> > > > > You could try reverting changeset 19342, as most likely culprit. > > > > Is that the fixed xen-hotplug-cleanup change? The symptoms > aren't quite > the same; with the broken cleanup, there were lockfiles left lying > about, so all the "block add" scripts were blocked waiting > for the lock > to be released. In this case, everything is just sitting there; the > hotplug never seems to get started. > > J > ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Hot plug scripts not working c/s 19355 2009-03-16 17:17 ` Dan Magenheimer @ 2009-03-16 18:00 ` Jeremy Fitzhardinge 0 siblings, 0 replies; 46+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-16 18:00 UTC (permalink / raw) To: Dan Magenheimer; +Cc: bderzhavets, Xen-devel, Keir Fraser Dan Magenheimer wrote: > Well I've been struggling with this on and off since Friday and > am having major problems because there are now many parts that > I'm no longer sure how to synchronize. The tools now seem to > be dependent on ioemu but I don't know how (or if its possible) > to synchronize versions of the ioemu git tree with a specific > xen hg changeset. Rolling xen tools back to 19187 worked fine, > but I couldn't roll the tools back to tip due to a compile error > > ioemu-dir/hw/pt-msi.c:95: error: too few arguments to xc_domain_update_msi_irq > > I did a git pull in ioemu-dir and no longer got the compile error > but it didn't help (same hotplug problem) and now I can't rollback > xen tools to 19187 because I get the opposite compile error. > So my test machine, which HAD been working at least with tools 19187 > is now useless unless I solve the problem. > Yeah, having xen-unstable in two different source systems is extremely brittle; I don't think its sustainable for much longer. > (BTW, I tried reverting 19342 and it didn't solve the problem.) > > I was able to do a fresh tip build and install on a new test machine > (that previously had no xen on it at all), so I suspect my problem was > due to a mismatch between dom0 and "something else" so am now in the > process of rebuilding dom0 from latest. > > Argh! I thought bisecting was supposed to be easy! > > With so many interdependent parts (and two different change-tracking > tools needed), perhaps its time to start being more careful about > describing version interdependencies between them? > > Or maybe if I were sufficiently knowledgeable about both mercurial > and git, this wouldn't be a problem? No, its all a big pain, especially since there are multiple bugs with similar symptoms. There was the original hotplug script bug in xen-unstable, which now appears to be fixed. There was also a pvops dom0 bug, which turned out to be an upstream bug in vsprintf()'s handling of "%.*s", which is also now fixed. And there may well be some other bugs... J ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 16:27 ` Boris Derzhavets 2009-03-11 16:50 ` Jeremy Fitzhardinge @ 2009-03-11 19:13 ` Andrew Lyon 2009-03-12 1:21 ` Jeremy Fitzhardinge 2009-03-12 8:55 ` Andrew Lyon 1 sibling, 2 replies; 46+ messages in thread From: Andrew Lyon @ 2009-03-11 19:13 UTC (permalink / raw) To: bderzhavets; +Cc: Jeremy Fitzhardinge, Xen-devel, Keir Fraser On Wed, Mar 11, 2009 at 4:27 PM, Boris Derzhavets <bderzhavets@yahoo.com> wrote: > It's not so important for me. The important thing is:- > > CentOS 5.2 PV DomU may be loaded only the very first time under Suse's > 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). Attempt to > shutdown and start it again gives VBD cannot be connected . Hotplug scripts > not working. That's a core issue, same behavior as under 2.6.29-rc7 (with > XSAVE patch ). Kernel doesn't seem to be a root cause. > I believe Xen unstable is broken in some way. > > Boris. This sounds very much like the problem I described in thread subject "domain id number on xen unstable", I maintain my own 2.6.27 dom0 kernel using opensuse Xen patches which I rebase to apply to vanilla without the many other patches opensuse usually applies to the kernel tree, so from a Xen point of view I am using a very similar kernel to yours, I found that I could start a hvm but after shutting it down attempting to restart it would fail or hang, sometimes I got hotplug error that vbd could not be connected. The script that has problems on my system is xen-hotplug-cleanup , the first time it is run it puts a lock in /var/run/xen-hotplug and never removes it, so the next time the script runs it blocks waiting for the lock and eventually times out. The offending line in the script is: vm=$(xenstore-read "/local/domain/${path_array[2]}/vm") putting a echo immediately after that line shows that nothing after it is executed, which is why the lock is not released. replacing xen-hotplug-cleanup and xen-hotplug-common with the ones from 3.3.1 seems to help, but after starting and stopping a few vm's the entire system reboots, so I think some objects are not being cleaned up, not surprising really, can hardly expect scripts to work with the wrong version of Xen. This problem has got me stuck into a nasty corner, only Xen unstable can fit our virtualization requirements (need viridian for stable windows smp), but the Xensource kernel is too old for our hardware. I am going to put some serious effort into debugging this in the next few days. Andy > > > > --- On Wed, 3/11/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > > From: Jeremy Fitzhardinge <jeremy@goop.org> > Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't > allow guests to use it > To: bderzhavets@yahoo.com > Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" > <keir.fraser@eu.citrix.com> > Date: Wednesday, March 11, 2009, 12:09 PM > > Boris Derzhavets wrote: >> Blktap helps out for multiple CentOS PV DomU restarts (with image on FS) > under Suse's 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). >> But it seems not implemented yet for 2.6.29-rc7 >> > > So your conclusion is that there's a regression in the tools stack when > using blkback rather than blktab? > > J > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 19:13 ` Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Andrew Lyon @ 2009-03-12 1:21 ` Jeremy Fitzhardinge 2009-03-12 1:54 ` Jeremy Fitzhardinge 2009-03-12 8:55 ` Andrew Lyon 1 sibling, 1 reply; 46+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-12 1:21 UTC (permalink / raw) To: Andrew Lyon; +Cc: bderzhavets, Xen-devel, Keir Fraser Andrew Lyon wrote: > On Wed, Mar 11, 2009 at 4:27 PM, Boris Derzhavets <bderzhavets@yahoo.com> wrote: > >> It's not so important for me. The important thing is:- >> >> CentOS 5.2 PV DomU may be loaded only the very first time under Suse's >> 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). Attempt to >> shutdown and start it again gives VBD cannot be connected . Hotplug scripts >> not working. That's a core issue, same behavior as under 2.6.29-rc7 (with >> XSAVE patch ). Kernel doesn't seem to be a root cause. >> I believe Xen unstable is broken in some way. >> >> Boris. >> > > This sounds very much like the problem I described in thread subject > "domain id number on xen unstable", I maintain my own 2.6.27 dom0 > kernel using opensuse Xen patches which I rebase to apply to vanilla > without the many other patches opensuse usually applies to the kernel > tree, so from a Xen point of view I am using a very similar kernel to > yours, I found that I could start a hvm but after shutting it down > attempting to restart it would fail or hang, sometimes I got hotplug > error that vbd could not be connected. > > The script that has problems on my system is xen-hotplug-cleanup , the > first time it is run it puts a lock in /var/run/xen-hotplug and never > removes it, so the next time the script runs it blocks waiting for the > lock and eventually times out. > > The offending line in the script is: > > vm=$(xenstore-read "/local/domain/${path_array[2]}/vm") > > putting a echo immediately after that line shows that nothing after it > is executed, which is why the lock is not released. > > replacing xen-hotplug-cleanup and xen-hotplug-common with the ones > from 3.3.1 seems to help, but after starting and stopping a few vm's > the entire system reboots, so I think some objects are not being > cleaned up, not surprising really, can hardly expect scripts to work > with the wrong version of Xen. > > This problem has got me stuck into a nasty corner, only Xen unstable > can fit our virtualization requirements (need viridian for stable > windows smp), but the Xensource kernel is too old for our hardware. > > I am going to put some serious effort into debugging this in the next few days. > Change 19242:226031d62fc5 is the last one which works for me. I haven't managed to bisect which specific change the problem starts occuring in, but 19250:b3774712e654 seems like a good starting point. J > Andy > > >> >> --- On Wed, 3/11/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> >> From: Jeremy Fitzhardinge <jeremy@goop.org> >> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't >> allow guests to use it >> To: bderzhavets@yahoo.com >> Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" >> <keir.fraser@eu.citrix.com> >> Date: Wednesday, March 11, 2009, 12:09 PM >> >> Boris Derzhavets wrote: >> >>> Blktap helps out for multiple CentOS PV DomU restarts (with image on FS) >>> >> under Suse's 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). >> >>> But it seems not implemented yet for 2.6.29-rc7 >>> >>> >> So your conclusion is that there's a regression in the tools stack when >> using blkback rather than blktab? >> >> 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 > ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-12 1:21 ` Jeremy Fitzhardinge @ 2009-03-12 1:54 ` Jeremy Fitzhardinge 2009-03-12 8:48 ` Boris Derzhavets 0 siblings, 1 reply; 46+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-12 1:54 UTC (permalink / raw) To: Andrew Lyon; +Cc: bderzhavets, Xen-devel, Keir Fraser Jeremy Fitzhardinge wrote: > Change 19242:226031d62fc5 is the last one which works for me. I > haven't managed to bisect which specific change the problem starts > occuring in, but 19250:b3774712e654 seems like a good starting point. Hm, perhaps not; it doesn't work for me now after a reboot. I realize now that I wasn't restarting xenstored between tests. J ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-12 1:54 ` Jeremy Fitzhardinge @ 2009-03-12 8:48 ` Boris Derzhavets 0 siblings, 0 replies; 46+ messages in thread From: Boris Derzhavets @ 2009-03-12 8:48 UTC (permalink / raw) To: Andrew Lyon, Jeremy Fitzhardinge; +Cc: Xen-devel, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 3132 bytes --] Trying to get 19242 on fresh clone :- root@ServerXen331:/usr/src/xen-unstable.hg# hg bisect -r root@ServerXen331:/usr/src/xen-unstable.hg# hg bisect -g 19242 root@ServerXen331:/usr/src/xen-unstable.hg# hg bisect -b 19297 Testing changeset 19269:3673926b2375 (55 changesets remaining, ~5 tests) 63 files updated, 0 files merged, 0 files removed, 0 files unresolved root@ServerXen331:/usr/src/xen-unstable.hg# make tools gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .block-qcow2.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror -Wno-unused -I../lib -I../../../tools/libxc -I../../../tools/include -I../../../tools/xenstore -I../../../tools/include -I ../../libaio/src -D_GNU_SOURCE -c -o block-qcow2.o block-qcow2.c cc1: warnings being treated as errors block-qcow2.c: In function ‘qcow2_create’: block-qcow2.c:2045: error: ignoring return value of ‘write’, declared with attribute warn_unused_result block-qcow2.c:2047: error: ignoring return value of ‘write’, declared with attribute warn_unused_result block-qcow2.c:2052: error: ignoring return value of ‘write’, declared with attribute warn_unused_result block-qcow2.c:2055: error: ignoring return value of ‘write’, declared with attribute warn_unused_result block-qcow2.c:2058: error: ignoring return value of ‘write’, declared with attribute warn_unused_result make[5]: *** [block-qcow2.o] Error 1 make[5]: Leaving directory `/usr/src/xen-unstable.hg/tools/blktap/drivers' make[4]: *** [subdir-install-drivers] Error 2 make[4]: Leaving directory `/usr/src/xen-unstable.hg/tools/blktap' make[3]: *** [subdirs-install] Error 2 make[3]: Leaving directory `/usr/src/xen-unstable.hg/tools/blktap' make[2]: *** [subdir-install-blktap] Error 2 make[2]: Leaving directory `/usr/src/xen-unstable.hg/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/usr/src/xen-unstable.hg/tools' make: *** [install-tools] Error 2 I can build tools only for 19232, but pygrub return no data for this release --- On Wed, 3/11/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: From: Jeremy Fitzhardinge <jeremy@goop.org> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: "Andrew Lyon" <andrew.lyon@gmail.com> Cc: bderzhavets@yahoo.com, "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" <keir.fraser@eu.citrix.com> Date: Wednesday, March 11, 2009, 9:54 PM Jeremy Fitzhardinge wrote: > Change 19242:226031d62fc5 is the last one which works for me. I haven't managed to bisect which specific change the problem starts occuring in, but 19250:b3774712e654 seems like a good starting point. Hm, perhaps not; it doesn't work for me now after a reboot. I realize now that I wasn't restarting xenstored between tests. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel [-- Attachment #1.2: Type: text/html, Size: 3542 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-11 19:13 ` Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Andrew Lyon 2009-03-12 1:21 ` Jeremy Fitzhardinge @ 2009-03-12 8:55 ` Andrew Lyon 2009-03-12 9:34 ` Keir Fraser 1 sibling, 1 reply; 46+ messages in thread From: Andrew Lyon @ 2009-03-12 8:55 UTC (permalink / raw) To: bderzhavets; +Cc: Jeremy Fitzhardinge, Xen-devel, Keir Fraser On Wed, Mar 11, 2009 at 7:13 PM, Andrew Lyon <andrew.lyon@gmail.com> wrote: > On Wed, Mar 11, 2009 at 4:27 PM, Boris Derzhavets <bderzhavets@yahoo.com> wrote: >> It's not so important for me. The important thing is:- >> >> CentOS 5.2 PV DomU may be loaded only the very first time under Suse's >> 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). Attempt to >> shutdown and start it again gives VBD cannot be connected . Hotplug scripts >> not working. That's a core issue, same behavior as under 2.6.29-rc7 (with >> XSAVE patch ). Kernel doesn't seem to be a root cause. >> I believe Xen unstable is broken in some way. >> >> Boris. > > This sounds very much like the problem I described in thread subject > "domain id number on xen unstable", I maintain my own 2.6.27 dom0 > kernel using opensuse Xen patches which I rebase to apply to vanilla > without the many other patches opensuse usually applies to the kernel > tree, so from a Xen point of view I am using a very similar kernel to > yours, I found that I could start a hvm but after shutting it down > attempting to restart it would fail or hang, sometimes I got hotplug > error that vbd could not be connected. > > The script that has problems on my system is xen-hotplug-cleanup , the > first time it is run it puts a lock in /var/run/xen-hotplug and never > removes it, so the next time the script runs it blocks waiting for the > lock and eventually times out. > > The offending line in the script is: > > vm=$(xenstore-read "/local/domain/${path_array[2]}/vm") > > putting a echo immediately after that line shows that nothing after it > is executed, which is why the lock is not released. > > replacing xen-hotplug-cleanup and xen-hotplug-common with the ones > from 3.3.1 seems to help, but after starting and stopping a few vm's > the entire system reboots, so I think some objects are not being > cleaned up, not surprising really, can hardly expect scripts to work > with the wrong version of Xen. > > This problem has got me stuck into a nasty corner, only Xen unstable > can fit our virtualization requirements (need viridian for stable > windows smp), but the Xensource kernel is too old for our hardware. > > I am going to put some serious effort into debugging this in the next few days. > > Andy I have just managed to get the Xensource 2.6.18.8 kernel working on one of my test systems and this problem still happens, I updated Xen unstable to latest hg as well, so this is definitely not a kernel version problem, after starting and stopping one hvm I cannot start any more, and xenstore-ls shows that objects are not being cleaned up properly: tool = "" xenstored = "" local = "" domain = "" 0 = "" vm = "/vm/00000000-0000-0000-0000-000000000000" device = "" control = "" platform-feature-multiprocessor-suspend = "1" error = "" memory = "" target = "3453952" cpu = "" 1 = "" availability = "online" 0 = "" availability = "online" name = "Domain-0" console = "" limit = "1048576" type = "xenconsoled" domid = "0" backend = "" vfb = "" 1 = "" 0 = "" hotplug-error = "/etc/xen/scripts/xen-hotplug-cleanup failed; error detected." hotplug-status = "error" vbd = "" 1 = "" 768 = "" domain = "xptest" frontend = "/local/domain/1/device/vbd/768" uuid = "7f03ff88-17ca-5442-2684-fee0e2d43e98" bootable = "1" dev = "hda" state = "6" params = "/root/xp" mode = "w" online = "0" frontend-id = "1" type = "file" node = "/dev/loop0" physical-device = "7:0" hotplug-status = "connected" vif = "" 1 = "" 0 = "" domain = "xptest" handle = "0" uuid = "258a56f7-721d-647b-98c3-b030eb9572de" script = "/etc/xen/scripts/vif-bridge" state = "6" frontend = "/local/domain/1/device/vif/0" mac = "00:16:3e:4c:c2:43" online = "0" frontend-id = "1" feature-sg = "1" feature-gso-tcpv4 = "1" feature-rx-copy = "1" feature-rx-flip = "0" hotplug-status = "connected" console = "" 1 = "" device-model = "" vm = "" 00000000-0000-0000-0000-000000000000 = "" on_xend_stop = "ignore" shadow_memory = "0" uuid = "00000000-0000-0000-0000-000000000000" on_reboot = "restart" image = "(linux (kernel ))" ostype = "linux" kernel = "" cmdline = "" ramdisk = "" on_poweroff = "destroy" bootloader_args = "" on_xend_start = "ignore" on_crash = "restart" xend = "" restart_count = "0" vcpus = "2" vcpu_avail = "3" bootloader = "" name = "Domain-0" memory = "3373" Andy > >> >> >> >> --- On Wed, 3/11/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> >> From: Jeremy Fitzhardinge <jeremy@goop.org> >> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't >> allow guests to use it >> To: bderzhavets@yahoo.com >> Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" >> <keir.fraser@eu.citrix.com> >> Date: Wednesday, March 11, 2009, 12:09 PM >> >> Boris Derzhavets wrote: >>> Blktap helps out for multiple CentOS PV DomU restarts (with image on FS) >> under Suse's 2.6.27 xen-ified kernel & Xen Unstable ( the most recent). >>> But it seems not implemented yet for 2.6.29-rc7 >>> >> >> So your conclusion is that there's a regression in the tools stack when >> using blkback rather than blktab? >> >> J >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >> > ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-12 8:55 ` Andrew Lyon @ 2009-03-12 9:34 ` Keir Fraser 2009-03-12 12:36 ` Boris Derzhavets 0 siblings, 1 reply; 46+ messages in thread From: Keir Fraser @ 2009-03-12 9:34 UTC (permalink / raw) To: Andrew Lyon, bderzhavets@yahoo.com; +Cc: Jeremy Fitzhardinge, Xen-devel On 12/03/2009 08:55, "Andrew Lyon" <andrew.lyon@gmail.com> wrote: > I have just managed to get the Xensource 2.6.18.8 kernel working on > one of my test systems and this problem still happens, I updated Xen > unstable to latest hg as well, so this is definitely not a kernel > version problem, after starting and stopping one hvm I cannot start > any more, and xenstore-ls shows that objects are not being cleaned up > properly: Changeset 19314 reverts a problematic changeset. You might upgrade and try with that. -- Keir ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it 2009-03-12 9:34 ` Keir Fraser @ 2009-03-12 12:36 ` Boris Derzhavets 0 siblings, 0 replies; 46+ messages in thread From: Boris Derzhavets @ 2009-03-12 12:36 UTC (permalink / raw) To: Andrew Lyon, Keir Fraser; +Cc: Jeremy Fitzhardinge, Xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1160 bytes --] Thank you. PV DomUs are restartable now. Boris --- On Thu, 3/12/09, Keir Fraser <keir.fraser@eu.citrix.com> wrote: From: Keir Fraser <keir.fraser@eu.citrix.com> Subject: Re: [Xen-devel] Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it To: "Andrew Lyon" <andrew.lyon@gmail.com>, "bderzhavets@yahoo.com" <bderzhavets@yahoo.com> Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>, "Xen-devel" <xen-devel@lists.xensource.com> Date: Thursday, March 12, 2009, 5:34 AM On 12/03/2009 08:55, "Andrew Lyon" <andrew.lyon@gmail.com> wrote: > I have just managed to get the Xensource 2.6.18.8 kernel working on > one of my test systems and this problem still happens, I updated Xen > unstable to latest hg as well, so this is definitely not a kernel > version problem, after starting and stopping one hvm I cannot start > any more, and xenstore-ls shows that objects are not being cleaned up > properly: Changeset 19314 reverts a problematic changeset. You might upgrade and try with that. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel [-- Attachment #1.2: Type: text/html, Size: 1568 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH] xen: mask XSAVE in cpuid since we don't allowguests to use it 2009-03-08 5:31 [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Jeremy Fitzhardinge ` (2 preceding siblings ...) 2009-03-09 11:18 ` [PATCH] xen: mask XSAVE in cpuid since we don't allow " Boris Derzhavets @ 2009-03-09 11:26 ` Jan Beulich 2009-03-09 11:29 ` Keir Fraser 3 siblings, 1 reply; 46+ messages in thread From: Jan Beulich @ 2009-03-09 11:26 UTC (permalink / raw) To: Keir Fraser, Jeremy Fitzhardinge Cc: Boris Derzhavets, Xen-devel, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] >>> Jeremy Fitzhardinge <jeremy@goop.org> 08.03.09 06:31 >>> >Mask X86_FEATURE_XSAVE in cpuid leaf 1, ecx, as we don't allow guests to >use it (by setting cr4.OSXSAVE). I actually disagree to this. The kernel should be dealing with the situation by inspecting the OSXSAVE bit in CPUID when running under Xen, since it's really Xen that's the 'OS' for that particular feature. Then, once Keir gets willing to take Intel xsave patch(es), no further change is going to be needed here. And the same kernel will work (assuming it has no other dependencies) on older Xen not having this bit masked. Jan ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH] xen: mask XSAVE in cpuid since we don't allowguests to use it 2009-03-09 11:26 ` [PATCH] xen: mask XSAVE in cpuid since we don't allowguests " Jan Beulich @ 2009-03-09 11:29 ` Keir Fraser 2009-03-09 16:40 ` Jeremy Fitzhardinge 0 siblings, 1 reply; 46+ messages in thread From: Keir Fraser @ 2009-03-09 11:29 UTC (permalink / raw) To: Jan Beulich, Jeremy Fitzhardinge Cc: Boris Derzhavets, Xen-devel, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] On 09/03/2009 11:26, "Jan Beulich" <jbeulich@novell.com> wrote: >>>> Jeremy Fitzhardinge <jeremy@goop.org> 08.03.09 06:31 >>> >> Mask X86_FEATURE_XSAVE in cpuid leaf 1, ecx, as we don't allow guests to >> use it (by setting cr4.OSXSAVE). > > I actually disagree to this. The kernel should be dealing with the situation > by inspecting the OSXSAVE bit in CPUID when running under Xen, since it's > really Xen that's the 'OS' for that particular feature. > > Then, once Keir gets willing to take Intel xsave patch(es), no further change > is going to be needed here. And the same kernel will work (assuming it has > no other dependencies) on older Xen not having this bit masked. It seems reasonable to mask XSAVE for now though. I don't think it can usefully be used without some Xen support. -- Keir ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH] xen: mask XSAVE in cpuid since we don't allowguests to use it 2009-03-09 11:29 ` Keir Fraser @ 2009-03-09 16:40 ` Jeremy Fitzhardinge 2009-03-09 17:54 ` Keir Fraser 0 siblings, 1 reply; 46+ messages in thread From: Jeremy Fitzhardinge @ 2009-03-09 16:40 UTC (permalink / raw) To: Keir Fraser Cc: Boris Derzhavets, Xen-devel, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] Keir Fraser wrote: > It seems reasonable to mask XSAVE for now though. I don't think it can > usefully be used without some Xen support. > You mean Xen support to deal with a new CPU context structure, or something requiring specific guest code, like what's needed to support sysenter/syscall? J ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH] xen: mask XSAVE in cpuid since we don't allowguests to use it 2009-03-09 16:40 ` Jeremy Fitzhardinge @ 2009-03-09 17:54 ` Keir Fraser 0 siblings, 0 replies; 46+ messages in thread From: Keir Fraser @ 2009-03-09 17:54 UTC (permalink / raw) To: Jeremy Fitzhardinge Cc: Boris Derzhavets, Xen-devel, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] On 09/03/2009 16:40, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote: > Keir Fraser wrote: >> It seems reasonable to mask XSAVE for now though. I don't think it can >> usefully be used without some Xen support. >> > > You mean Xen support to deal with a new CPU context structure, or > something requiring specific guest code, like what's needed to support > sysenter/syscall? I mean it indicates new CPU context requiring context switching. But, fully generally, who knows? :-) -- Keir ^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2009-03-16 18:00 UTC | newest] Thread overview: 46+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-03-08 5:31 [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Jeremy Fitzhardinge 2009-03-08 8:52 ` Boris Derzhavets 2009-03-08 9:13 ` Keir Fraser 2009-03-09 11:31 ` [PATCH] xen: mask XSAVE in cpuid since we don'tallow " Jan Beulich 2009-03-09 11:45 ` Keir Fraser 2009-03-09 11:18 ` [PATCH] xen: mask XSAVE in cpuid since we don't allow " Boris Derzhavets 2009-03-09 11:26 ` Keir Fraser 2009-03-09 14:31 ` Boris Derzhavets 2009-03-10 22:24 ` Boris Derzhavets 2009-03-11 0:29 ` Jeremy Fitzhardinge 2009-03-11 7:26 ` Boris Derzhavets 2009-03-11 8:40 ` Boris Derzhavets 2009-03-11 9:09 ` Attempt to install SNV_106 under Suse's 2.6.27 xen-ified kernel & Xen Unstable Boris Derzhavets 2009-03-11 11:36 ` Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Boris Derzhavets 2009-03-11 16:09 ` Jeremy Fitzhardinge 2009-03-11 16:27 ` Boris Derzhavets 2009-03-11 16:50 ` Jeremy Fitzhardinge 2009-03-11 16:57 ` Boris Derzhavets 2009-03-11 17:04 ` Jeremy Fitzhardinge 2009-03-11 17:21 ` Boris Derzhavets 2009-03-11 17:43 ` Boris Derzhavets 2009-03-11 17:47 ` Jeremy Fitzhardinge 2009-03-11 19:49 ` Boris Derzhavets 2009-03-12 0:41 ` Jeremy Fitzhardinge 2009-03-13 14:39 ` Boris Derzhavets 2009-03-13 15:20 ` Jeremy Fitzhardinge 2009-03-13 15:46 ` Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) Dan Magenheimer 2009-03-13 16:05 ` Hot plug scripts not working c/s 19355 Jeremy Fitzhardinge 2009-03-13 16:59 ` Hot plug scripts not working c/s 19355 (was: Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it) Keir Fraser 2009-03-13 17:09 ` Jeremy Fitzhardinge 2009-03-13 18:15 ` Boris Derzhavets 2009-03-13 18:49 ` Andrew Lyon 2009-03-13 19:08 ` Boris Derzhavets 2009-03-16 17:17 ` Dan Magenheimer 2009-03-16 18:00 ` Hot plug scripts not working c/s 19355 Jeremy Fitzhardinge 2009-03-11 19:13 ` Re: [PATCH] xen: mask XSAVE in cpuid since we don't allow guests to use it Andrew Lyon 2009-03-12 1:21 ` Jeremy Fitzhardinge 2009-03-12 1:54 ` Jeremy Fitzhardinge 2009-03-12 8:48 ` Boris Derzhavets 2009-03-12 8:55 ` Andrew Lyon 2009-03-12 9:34 ` Keir Fraser 2009-03-12 12:36 ` Boris Derzhavets 2009-03-09 11:26 ` [PATCH] xen: mask XSAVE in cpuid since we don't allowguests " Jan Beulich 2009-03-09 11:29 ` Keir Fraser 2009-03-09 16:40 ` Jeremy Fitzhardinge 2009-03-09 17:54 ` Keir Fraser
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.