* Re: [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot [not found] ` <82B3AFF8-B4F1-4347-82F3-04F100002684@rit.edu> @ 2009-09-15 11:39 ` Pasi Kärkkäinen 2009-09-15 11:53 ` Pasi Kärkkäinen ` (3 more replies) [not found] ` <alpine.GSO.2.00.0909151240230.27096@algedi.dur.ac.uk> 1 sibling, 4 replies; 13+ messages in thread From: Pasi Kärkkäinen @ 2009-09-15 11:39 UTC (permalink / raw) To: Charles Gruener; +Cc: Jeremy Fitzhardinge, xen-devel, fedora-xen On Tue, Sep 15, 2009 at 07:29:52AM -0400, Charles Gruener wrote: > Thanks for the help on configuring my boot options. I apologize that > I forgot to mention I'm using the latest kernel from M. Young, > 2.6.31-1.2.65.xendom0.fc12.x86_64. Here's what I get now that I've > done all of what you've said: > Ok. I've CCd Jeremy and xen-devel. Does this crash look familiar to you Jeremy? -- Pasi > __ __ _____ _ _ _ _____ __ _ ____ > \ \/ /___ _ __ |___ /| || | / | |___ / / _| ___/ |___ \ > \ // _ \ '_ \ |_ \| || |_ | |__ |_ \ | |_ / __| | __) | > / \ __/ | | | ___) |__ _|| |__|__) || _| (__| |/ __/ > /_/\_\___|_| |_| |____(_) |_|(_)_| |____(_)_| \___|_|_____| > > (XEN) Xen version 3.4.1 (mockbuild@(none)) (gcc version 4.4.1 20090818 > (Red Hat 4.4.1-6) (GCC) ) Wed Sep 2 08:03:46 EDT 2009 > (XEN) Latest ChangeSet: unavailable > (XEN) Command line: dom0_mem=1024M loglvl=all guest_loglvl=all > console=com1 com1=115200,8n1 > (XEN) Video information: > (XEN) VGA is text mode 80x25, font 8x16 > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > (XEN) EDID info not retrieved because no DDC retrieval method detected > (XEN) Disc information: > (XEN) Found 0 MBR signatures > (XEN) Found 2 EDD information structures > (XEN) Xen-e820 RAM map: > (XEN) 0000000000000000 - 0000000000096800 (usable) > (XEN) 0000000000096800 - 00000000000a0000 (reserved) > (XEN) 00000000000e4000 - 0000000000100000 (reserved) > (XEN) 0000000000100000 - 00000000bfe90000 (usable) > (XEN) 00000000bfe90000 - 00000000bfea0000 (ACPI data) > (XEN) 00000000bfea0000 - 00000000bfed0000 (ACPI NVS) > (XEN) 00000000bfed0000 - 00000000bfee0000 (reserved) > (XEN) 00000000bfeeb800 - 00000000c0000000 (reserved) > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > (XEN) 00000000ffb00000 - 0000000100000000 (reserved) > (XEN) 0000000100000000 - 00000001c0000000 (usable) > (XEN) System RAM: 6142MB (6289560kB) > (XEN) ACPI: RSDP 000FA2B0, 0014 (r0 ACPIAM) > (XEN) ACPI: RSDT BFE90000, 0040 (r1 083109 RSDT2145 20090831 > MSFT 97) > (XEN) ACPI: FACP BFE90200, 0084 (r1 A_M_I OEMFACP 12000601 > MSFT 97) > (XEN) ACPI: DSDT BFE90480, 6425 (r1 AS196 AS196246 246 INTL > 20051117) > (XEN) ACPI: FACS BFEA0000, 0040 > (XEN) ACPI: APIC BFE90390, 00AC (r1 083109 APIC2145 20090831 > MSFT 97) > (XEN) ACPI: MCFG BFE90440, 003C (r1 083109 OEMMCFG 20090831 > MSFT 97) > (XEN) ACPI: OEMB BFEA0040, 0073 (r1 083109 OEMB2145 20090831 > MSFT 97) > (XEN) ACPI: AAFT BFE9A480, 0027 (r1 083109 OEMAAFT 20090831 > MSFT 97) > (XEN) ACPI: DMAR BFEA00C0, 0128 (r1 AMI OEMDMAR 1 > MSFT 97) > (XEN) ACPI: SSDT BFEA1BF0, 0363 (r1 DpgPmm CpuPm 12 INTL > 20051117) > (XEN) NUMA turned off > (XEN) Faking a node at 0000000000000000-00000001c0000000 > (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[bfea000c], vec_size[20] > (XEN) ACPI: Local APIC address 0xfee00000 > (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) > (XEN) Processor #0 7:10 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) > (XEN) Processor #2 7:10 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) > (XEN) Processor #4 7:10 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) > (XEN) Processor #6 7:10 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled) > (XEN) Processor #1 7:10 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled) > (XEN) Processor #3 7:10 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled) > (XEN) Processor #5 7:10 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) > (XEN) Processor #7 7:10 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) > (XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) > (XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) > (XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) > (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) > (XEN) IOAPIC[0]: apic_id 8, 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) Using ACPI (MADT) for SMP configuration information > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Initializing CPU#0 > (XEN) Detected 2666.807 MHz processor. > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > (XEN) CPU: L2 cache: 256K > (XEN) CPU: L3 cache: 8192K > (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) - Extended Page Tables (EPT) > (XEN) - Virtual-Processor Identifiers (VPID) > (XEN) - Virtual NMI > (XEN) - MSR direct-access bitmap > (XEN) VMX: EPT is available. > (XEN) VMX: VPID is available. > (XEN) HVM: VMX enabled > (XEN) HVM: Hardware Assisted Paging detected. > (XEN) Intel machine check reporting enabled on CPU#0. > (XEN) mce_init: init bank1 > (XEN) CPU0: Thermal monitoring enabled (TM1) > (XEN) CMCI: find owner on CPU0 > (XEN) CMCI: CPU0 owner_map[6c], no_cmci_map[93] > (XEN) CPU0: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > (XEN) Booting processor 1/2 eip 8c000 > (XEN) Initializing CPU#1 > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > (XEN) CPU: L2 cache: 256K > (XEN) CPU: L3 cache: 8192K > (XEN) CPU: Physical Processor ID: 0 > (XEN) CPU: Processor Core ID: 1 > (XEN) Intel machine check reporting enabled on CPU#1. > (XEN) mce_init: init bank1 > (XEN) CPU1: Thermal monitoring enabled (TM1) > (XEN) CMCI: find owner on CPU1 > (XEN) CMCI: CPU1 owner_map[2c], no_cmci_map[93] > (XEN) CPU1: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > (XEN) Booting processor 2/4 eip 8c000 > (XEN) Initializing CPU#2 > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > (XEN) CPU: L2 cache: 256K > (XEN) CPU: L3 cache: 8192K > (XEN) CPU: Physical Processor ID: 0 > (XEN) CPU: Processor Core ID: 2 > (XEN) Intel machine check reporting enabled on CPU#2. > (XEN) mce_init: init bank1 > (XEN) CPU2: Thermal monitoring enabled (TM1) > (XEN) CMCI: find owner on CPU2 > (XEN) CMCI: CPU2 owner_map[2c], no_cmci_map[93] > (XEN) CPU2: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > (XEN) Booting processor 3/6 eip 8c000 > (XEN) Initializing CPU#3 > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > (XEN) CPU: L2 cache: 256K > (XEN) CPU: L3 cache: 8192K > (XEN) CPU: Physical Processor ID: 0 > (XEN) CPU: Processor Core ID: 3 > (XEN) Intel machine check reporting enabled on CPU#3. > (XEN) mce_init: init bank1 > (XEN) CPU3: Thermal monitoring enabled (TM1) > (XEN) CMCI: find owner on CPU3 > (XEN) CMCI: CPU3 owner_map[2c], no_cmci_map[93] > (XEN) CPU3: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > (XEN) Booting processor 4/1 eip 8c000 > (XEN) Initializing CPU#4 > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > (XEN) CPU: L2 cache: 256K > (XEN) CPU: L3 cache: 8192K > (XEN) CPU: Physical Processor ID: 0 > (XEN) CPU: Processor Core ID: 0 > (XEN) Intel machine check reporting enabled on CPU#4. > (XEN) mce_init: init bank1 > (XEN) CPU4: Thermal monitoring enabled (TM1) > (XEN) CMCI: find owner on CPU4 > (XEN) CMCI: CPU4 owner_map[0], no_cmci_map[93] > (XEN) CPU4: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > (XEN) Booting processor 5/3 eip 8c000 > (XEN) Initializing CPU#5 > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > (XEN) CPU: L2 cache: 256K > (XEN) CPU: L3 cache: 8192K > (XEN) CPU: Physical Processor ID: 0 > (XEN) CPU: Processor Core ID: 1 > (XEN) Intel machine check reporting enabled on CPU#5. > (XEN) mce_init: init bank1 > (XEN) CPU5: Thermal monitoring enabled (TM1) > (XEN) CMCI: find owner on CPU5 > (XEN) CMCI: CPU5 owner_map[0], no_cmci_map[93] > (XEN) CPU5: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > (XEN) Booting processor 6/5 eip 8c000 > (XEN) Initializing CPU#6 > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > (XEN) CPU: L2 cache: 256K > (XEN) CPU: L3 cache: 8192K > (XEN) CPU: Physical Processor ID: 0 > (XEN) CPU: Processor Core ID: 2 > (XEN) Intel machine check reporting enabled on CPU#6. > (XEN) mce_init: init bank1 > (XEN) CPU6: Thermal monitoring enabled (TM1) > (XEN) CMCI: find owner on CPU6 > (XEN) CMCI: CPU6 owner_map[0], no_cmci_map[93] > (XEN) CPU6: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > (XEN) Booting processor 7/7 eip 8c000 > (XEN) Initializing CPU#7 > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > (XEN) CPU: L2 cache: 256K > (XEN) CPU: L3 cache: 8192K > (XEN) CPU: Physical Processor ID: 0 > (XEN) CPU: Processor Core ID: 3 > (XEN) Intel machine check reporting enabled on CPU#7. > (XEN) mce_init: init bank1 > (XEN) CPU7: Thermal monitoring enabled (TM1) > (XEN) CMCI: find owner on CPU7 > (XEN) CMCI: CPU7 owner_map[0], no_cmci_map[93] > (XEN) CPU7: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > (XEN) Total of 8 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 8 CPUs: passed. > (XEN) Platform timer is 3.579MHz ACPI PM Timer > (XEN) microcode.c:73:d32767 microcode: CPU1 resumed > (XEN) microcode.c:73:d32767 microcode: CPU3 resumed > (XEN) microcode.c:73:d32767 microcode: CPU4 resumed > (XEN) microcode.c:73:d32767 microcode: CPU6 resumed > (XEN) microcode.c:73:d32767 microcode: CPU7 resumed > (XEN) microcode.c:73:d32767 microcode: CPU5 resumed > (XEN) microcode.c:73:d32767 microcode: CPU2 resumed > (XEN) Brought up 8 CPUs > (XEN) I/O virtualisation disabled > (XEN) CPUIDLE: disabled due to no HPET. Force enable with 'cpuidle'. > (XEN) ACPI sleep modes: S3 > (XEN) mcheck_poll: Machine check polling timer started. > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Xen kernel: 64-bit, lsb, compat32 > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2695000 > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 00000001b4000000->00000001b8000000 (245760 pages > to be allocated) > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: ffffffff81000000->ffffffff82695000 > (XEN) Init. ramdisk: ffffffff82695000->ffffffff83006a00 > (XEN) Phys-Mach map: ffffffff83007000->ffffffff83207000 > (XEN) Start info: ffffffff83207000->ffffffff832074b4 > (XEN) Page tables: ffffffff83208000->ffffffff83225000 > (XEN) Boot stack: ffffffff83225000->ffffffff83226000 > (XEN) TOTAL: ffffffff80000000->ffffffff83400000 > (XEN) ENTRY ADDRESS: ffffffff819fd820 > (XEN) Dom0 has maximum 8 VCPUs > (XEN) Scrubbing Free > RAM: ..................................................done. > (XEN) Xen trace buffers: disabled > (XEN) Std. Loglevel: All > (XEN) Guest Loglevel: All > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch > input to Xen) > (XEN) Freed 128kB init memory. > (XEN) mm.c:1697:d0 Bad L1 flags 800000 > (XEN) traps.c:437:d0 Unhandled invalid opcode fault/trap [#6] on VCPU > 0 [ec=0000] > (XEN) domain_crash_sync called from entry.S > (XEN) Domain 0 (vcpu#0) crashed on cpu#0: > (XEN) ----[ Xen-3.4.1 x86_64 debug=n Not tainted ]---- > (XEN) CPU: 0 > (XEN) RIP: e033:[<ffffffff81a017f1>] > (XEN) RFLAGS: 0000000000000282 EM: 1 CONTEXT: pv guest > (XEN) rax: 00000000ffffffea rbx: ffffffff8182b000 rcx: > 00000000001b582b > (XEN) rdx: 0000000000000000 rsi: 80000001b582b061 rdi: > ffffffff8182b000 > (XEN) rbp: ffffffff8174ff98 rsp: ffffffff8174fef8 r8: > 0000000000000000 > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > 0000000000000000 > (XEN) r12: ffffffff8174ffa8 r13: ffffffff8174ff40 r14: > 0000000000000080 > (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: > 00000000000026f0 > (XEN) cr3: 00000001b7208000 cr2: 0000000000000000 > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 > (XEN) Guest stack trace from rsp=ffffffff8174fef8: > (XEN) 00000000001b582b 0000000000000000 ffffffff81a017f1 > 000000010000e030 > (XEN) 0000000000010082 ffffffff8174ff38 000000000000e02b > ffffffff81a017ed > (XEN) 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > (XEN) 000000000000182b 0000008000000000 ffffffff8100cc87 > 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > (XEN) ffffffff8174ffc8 ffffffff81021271 ffff8182b000007f > 000000000000ffff > (XEN) 0000000000000000 0000000000000000 ffffffff8174fff8 > ffffffff81a01b49 > (XEN) 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > (XEN) 0000000000000000 > (XEN) Domain 0 crashed: rebooting machine in 5 seconds. > > Looking through that information, I don't see anything that really > helps me out. Am I missing something? Anything else I should try > BIOS level that could shed some light on the nature of the issue or is > my best bet to try booting a debug version of Xen? > > On Sep 15, 2009, at 3:56 AM, Pasi Kärkkäinen wrote: > > >On Tue, Sep 15, 2009 at 10:17:30AM +0300, Pasi Kärkkäinen wrote: > >>On Mon, Sep 14, 2009 at 09:44:25PM -0400, Charles Gruener wrote: > >>>I have an ASRock X58 SuperComputer motherboard that refuses to boot > >>>the latest xen-3.4.1 in Rawhide. > >>> > >>>This is the motherboard: > >>>http://www.asrock.com/mb/overview.asp?Model=X58%20SuperComputer > >>> > >>>Here is a capture of the boot process: > >>> > >>>(XEN) Bad console= option 'tty' > >> > >>You should remove that unsupported 'tty' option. > >> > >>>(XEN) *** LOADING DOMAIN 0 *** > >>>(XEN) Xen kernel: 64-bit, lsb, compat32 > >>>(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2695000 > >>>(XEN) PHYSICAL MEMORY ARRANGEMENT: > >>>(XEN) Dom0 alloc.: 00000001b4000000->00000001b8000000 (1502490 > >>>pages to be allocated) > >>>(XEN) VIRTUAL MEMORY ARRANGEMENT: > >>>(XEN) Loaded kernel: ffffffff81000000->ffffffff82695000 > >>>(XEN) Init. ramdisk: ffffffff82695000->ffffffff83006a00 > >>>(XEN) Phys-Mach map: ffffffff83007000->ffffffff83b9d8d0 > >>>(XEN) Start info: ffffffff83b9e000->ffffffff83b9e4b4 > >>>(XEN) Page tables: ffffffff83b9f000->ffffffff83bc2000 > >>>(XEN) Boot stack: ffffffff83bc2000->ffffffff83bc3000 > >>>(XEN) TOTAL: ffffffff80000000->ffffffff84000000 > >>>(XEN) ENTRY ADDRESS: ffffffff819fd820 > >>>(XEN) Dom0 has maximum 8 VCPUs > >>>(XEN) Scrubbing Free RAM: .done. > >>>(XEN) Xen trace buffers: disabled > >>>(XEN) Std. Loglevel: Errors and warnings > >>>(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > > > >Oh, and also enable logging.. like this: > > > >kernel /xen-3.4.gz dom0_mem=1024M loglvl=all guest_loglvl=all > >com1=115200,8n1 console=com1 > >module /vmlinuz-2.6.31 ro root=whatever console=hvc0 earlyprintk=xen > >module /initrd.img > > > >-- Pasi > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot 2009-09-15 11:39 ` [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot Pasi Kärkkäinen @ 2009-09-15 11:53 ` Pasi Kärkkäinen 2009-09-15 14:41 ` Nathan Stratton ` (2 subsequent siblings) 3 siblings, 0 replies; 13+ messages in thread From: Pasi Kärkkäinen @ 2009-09-15 11:53 UTC (permalink / raw) To: Charles Gruener; +Cc: Jeremy Fitzhardinge, xen-devel, fedora-xen On Tue, Sep 15, 2009 at 02:39:14PM +0300, Pasi Kärkkäinen wrote: > On Tue, Sep 15, 2009 at 07:29:52AM -0400, Charles Gruener wrote: > > Thanks for the help on configuring my boot options. I apologize that > > I forgot to mention I'm using the latest kernel from M. Young, > > 2.6.31-1.2.65.xendom0.fc12.x86_64. Here's what I get now that I've > > done all of what you've said: > > > > Ok. I've CCd Jeremy and xen-devel. > > Does this crash look familiar to you Jeremy? > Btw might be worth trying to add dom0_vcpus=1 parameter for Xen and see if that makes any difference.. -- Pasi > > > __ __ _____ _ _ _ _____ __ _ ____ > > \ \/ /___ _ __ |___ /| || | / | |___ / / _| ___/ |___ \ > > \ // _ \ '_ \ |_ \| || |_ | |__ |_ \ | |_ / __| | __) | > > / \ __/ | | | ___) |__ _|| |__|__) || _| (__| |/ __/ > > /_/\_\___|_| |_| |____(_) |_|(_)_| |____(_)_| \___|_|_____| > > > > (XEN) Xen version 3.4.1 (mockbuild@(none)) (gcc version 4.4.1 20090818 > > (Red Hat 4.4.1-6) (GCC) ) Wed Sep 2 08:03:46 EDT 2009 > > (XEN) Latest ChangeSet: unavailable > > (XEN) Command line: dom0_mem=1024M loglvl=all guest_loglvl=all > > console=com1 com1=115200,8n1 > > (XEN) Video information: > > (XEN) VGA is text mode 80x25, font 8x16 > > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > > (XEN) EDID info not retrieved because no DDC retrieval method detected > > (XEN) Disc information: > > (XEN) Found 0 MBR signatures > > (XEN) Found 2 EDD information structures > > (XEN) Xen-e820 RAM map: > > (XEN) 0000000000000000 - 0000000000096800 (usable) > > (XEN) 0000000000096800 - 00000000000a0000 (reserved) > > (XEN) 00000000000e4000 - 0000000000100000 (reserved) > > (XEN) 0000000000100000 - 00000000bfe90000 (usable) > > (XEN) 00000000bfe90000 - 00000000bfea0000 (ACPI data) > > (XEN) 00000000bfea0000 - 00000000bfed0000 (ACPI NVS) > > (XEN) 00000000bfed0000 - 00000000bfee0000 (reserved) > > (XEN) 00000000bfeeb800 - 00000000c0000000 (reserved) > > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > > (XEN) 00000000ffb00000 - 0000000100000000 (reserved) > > (XEN) 0000000100000000 - 00000001c0000000 (usable) > > (XEN) System RAM: 6142MB (6289560kB) > > (XEN) ACPI: RSDP 000FA2B0, 0014 (r0 ACPIAM) > > (XEN) ACPI: RSDT BFE90000, 0040 (r1 083109 RSDT2145 20090831 > > MSFT 97) > > (XEN) ACPI: FACP BFE90200, 0084 (r1 A_M_I OEMFACP 12000601 > > MSFT 97) > > (XEN) ACPI: DSDT BFE90480, 6425 (r1 AS196 AS196246 246 INTL > > 20051117) > > (XEN) ACPI: FACS BFEA0000, 0040 > > (XEN) ACPI: APIC BFE90390, 00AC (r1 083109 APIC2145 20090831 > > MSFT 97) > > (XEN) ACPI: MCFG BFE90440, 003C (r1 083109 OEMMCFG 20090831 > > MSFT 97) > > (XEN) ACPI: OEMB BFEA0040, 0073 (r1 083109 OEMB2145 20090831 > > MSFT 97) > > (XEN) ACPI: AAFT BFE9A480, 0027 (r1 083109 OEMAAFT 20090831 > > MSFT 97) > > (XEN) ACPI: DMAR BFEA00C0, 0128 (r1 AMI OEMDMAR 1 > > MSFT 97) > > (XEN) ACPI: SSDT BFEA1BF0, 0363 (r1 DpgPmm CpuPm 12 INTL > > 20051117) > > (XEN) NUMA turned off > > (XEN) Faking a node at 0000000000000000-00000001c0000000 > > (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[bfea000c], vec_size[20] > > (XEN) ACPI: Local APIC address 0xfee00000 > > (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) > > (XEN) Processor #0 7:10 APIC version 21 > > (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) > > (XEN) Processor #2 7:10 APIC version 21 > > (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) > > (XEN) Processor #4 7:10 APIC version 21 > > (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) > > (XEN) Processor #6 7:10 APIC version 21 > > (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled) > > (XEN) Processor #1 7:10 APIC version 21 > > (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled) > > (XEN) Processor #3 7:10 APIC version 21 > > (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled) > > (XEN) Processor #5 7:10 APIC version 21 > > (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) > > (XEN) Processor #7 7:10 APIC version 21 > > (XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) > > (XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) > > (XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) > > (XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) > > (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) > > (XEN) IOAPIC[0]: apic_id 8, 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) Using ACPI (MADT) for SMP configuration information > > (XEN) Using scheduler: SMP Credit Scheduler (credit) > > (XEN) Initializing CPU#0 > > (XEN) Detected 2666.807 MHz processor. > > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > > (XEN) CPU: L2 cache: 256K > > (XEN) CPU: L3 cache: 8192K > > (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) - Extended Page Tables (EPT) > > (XEN) - Virtual-Processor Identifiers (VPID) > > (XEN) - Virtual NMI > > (XEN) - MSR direct-access bitmap > > (XEN) VMX: EPT is available. > > (XEN) VMX: VPID is available. > > (XEN) HVM: VMX enabled > > (XEN) HVM: Hardware Assisted Paging detected. > > (XEN) Intel machine check reporting enabled on CPU#0. > > (XEN) mce_init: init bank1 > > (XEN) CPU0: Thermal monitoring enabled (TM1) > > (XEN) CMCI: find owner on CPU0 > > (XEN) CMCI: CPU0 owner_map[6c], no_cmci_map[93] > > (XEN) CPU0: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > > (XEN) Booting processor 1/2 eip 8c000 > > (XEN) Initializing CPU#1 > > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > > (XEN) CPU: L2 cache: 256K > > (XEN) CPU: L3 cache: 8192K > > (XEN) CPU: Physical Processor ID: 0 > > (XEN) CPU: Processor Core ID: 1 > > (XEN) Intel machine check reporting enabled on CPU#1. > > (XEN) mce_init: init bank1 > > (XEN) CPU1: Thermal monitoring enabled (TM1) > > (XEN) CMCI: find owner on CPU1 > > (XEN) CMCI: CPU1 owner_map[2c], no_cmci_map[93] > > (XEN) CPU1: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > > (XEN) Booting processor 2/4 eip 8c000 > > (XEN) Initializing CPU#2 > > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > > (XEN) CPU: L2 cache: 256K > > (XEN) CPU: L3 cache: 8192K > > (XEN) CPU: Physical Processor ID: 0 > > (XEN) CPU: Processor Core ID: 2 > > (XEN) Intel machine check reporting enabled on CPU#2. > > (XEN) mce_init: init bank1 > > (XEN) CPU2: Thermal monitoring enabled (TM1) > > (XEN) CMCI: find owner on CPU2 > > (XEN) CMCI: CPU2 owner_map[2c], no_cmci_map[93] > > (XEN) CPU2: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > > (XEN) Booting processor 3/6 eip 8c000 > > (XEN) Initializing CPU#3 > > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > > (XEN) CPU: L2 cache: 256K > > (XEN) CPU: L3 cache: 8192K > > (XEN) CPU: Physical Processor ID: 0 > > (XEN) CPU: Processor Core ID: 3 > > (XEN) Intel machine check reporting enabled on CPU#3. > > (XEN) mce_init: init bank1 > > (XEN) CPU3: Thermal monitoring enabled (TM1) > > (XEN) CMCI: find owner on CPU3 > > (XEN) CMCI: CPU3 owner_map[2c], no_cmci_map[93] > > (XEN) CPU3: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > > (XEN) Booting processor 4/1 eip 8c000 > > (XEN) Initializing CPU#4 > > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > > (XEN) CPU: L2 cache: 256K > > (XEN) CPU: L3 cache: 8192K > > (XEN) CPU: Physical Processor ID: 0 > > (XEN) CPU: Processor Core ID: 0 > > (XEN) Intel machine check reporting enabled on CPU#4. > > (XEN) mce_init: init bank1 > > (XEN) CPU4: Thermal monitoring enabled (TM1) > > (XEN) CMCI: find owner on CPU4 > > (XEN) CMCI: CPU4 owner_map[0], no_cmci_map[93] > > (XEN) CPU4: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > > (XEN) Booting processor 5/3 eip 8c000 > > (XEN) Initializing CPU#5 > > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > > (XEN) CPU: L2 cache: 256K > > (XEN) CPU: L3 cache: 8192K > > (XEN) CPU: Physical Processor ID: 0 > > (XEN) CPU: Processor Core ID: 1 > > (XEN) Intel machine check reporting enabled on CPU#5. > > (XEN) mce_init: init bank1 > > (XEN) CPU5: Thermal monitoring enabled (TM1) > > (XEN) CMCI: find owner on CPU5 > > (XEN) CMCI: CPU5 owner_map[0], no_cmci_map[93] > > (XEN) CPU5: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > > (XEN) Booting processor 6/5 eip 8c000 > > (XEN) Initializing CPU#6 > > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > > (XEN) CPU: L2 cache: 256K > > (XEN) CPU: L3 cache: 8192K > > (XEN) CPU: Physical Processor ID: 0 > > (XEN) CPU: Processor Core ID: 2 > > (XEN) Intel machine check reporting enabled on CPU#6. > > (XEN) mce_init: init bank1 > > (XEN) CPU6: Thermal monitoring enabled (TM1) > > (XEN) CMCI: find owner on CPU6 > > (XEN) CMCI: CPU6 owner_map[0], no_cmci_map[93] > > (XEN) CPU6: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > > (XEN) Booting processor 7/7 eip 8c000 > > (XEN) Initializing CPU#7 > > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K > > (XEN) CPU: L2 cache: 256K > > (XEN) CPU: L3 cache: 8192K > > (XEN) CPU: Physical Processor ID: 0 > > (XEN) CPU: Processor Core ID: 3 > > (XEN) Intel machine check reporting enabled on CPU#7. > > (XEN) mce_init: init bank1 > > (XEN) CPU7: Thermal monitoring enabled (TM1) > > (XEN) CMCI: find owner on CPU7 > > (XEN) CMCI: CPU7 owner_map[0], no_cmci_map[93] > > (XEN) CPU7: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 > > (XEN) Total of 8 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 8 CPUs: passed. > > (XEN) Platform timer is 3.579MHz ACPI PM Timer > > (XEN) microcode.c:73:d32767 microcode: CPU1 resumed > > (XEN) microcode.c:73:d32767 microcode: CPU3 resumed > > (XEN) microcode.c:73:d32767 microcode: CPU4 resumed > > (XEN) microcode.c:73:d32767 microcode: CPU6 resumed > > (XEN) microcode.c:73:d32767 microcode: CPU7 resumed > > (XEN) microcode.c:73:d32767 microcode: CPU5 resumed > > (XEN) microcode.c:73:d32767 microcode: CPU2 resumed > > (XEN) Brought up 8 CPUs > > (XEN) I/O virtualisation disabled > > (XEN) CPUIDLE: disabled due to no HPET. Force enable with 'cpuidle'. > > (XEN) ACPI sleep modes: S3 > > (XEN) mcheck_poll: Machine check polling timer started. > > (XEN) *** LOADING DOMAIN 0 *** > > (XEN) Xen kernel: 64-bit, lsb, compat32 > > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2695000 > > (XEN) PHYSICAL MEMORY ARRANGEMENT: > > (XEN) Dom0 alloc.: 00000001b4000000->00000001b8000000 (245760 pages > > to be allocated) > > (XEN) VIRTUAL MEMORY ARRANGEMENT: > > (XEN) Loaded kernel: ffffffff81000000->ffffffff82695000 > > (XEN) Init. ramdisk: ffffffff82695000->ffffffff83006a00 > > (XEN) Phys-Mach map: ffffffff83007000->ffffffff83207000 > > (XEN) Start info: ffffffff83207000->ffffffff832074b4 > > (XEN) Page tables: ffffffff83208000->ffffffff83225000 > > (XEN) Boot stack: ffffffff83225000->ffffffff83226000 > > (XEN) TOTAL: ffffffff80000000->ffffffff83400000 > > (XEN) ENTRY ADDRESS: ffffffff819fd820 > > (XEN) Dom0 has maximum 8 VCPUs > > (XEN) Scrubbing Free > > RAM: ..................................................done. > > (XEN) Xen trace buffers: disabled > > (XEN) Std. Loglevel: All > > (XEN) Guest Loglevel: All > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch > > input to Xen) > > (XEN) Freed 128kB init memory. > > (XEN) mm.c:1697:d0 Bad L1 flags 800000 > > (XEN) traps.c:437:d0 Unhandled invalid opcode fault/trap [#6] on VCPU > > 0 [ec=0000] > > (XEN) domain_crash_sync called from entry.S > > (XEN) Domain 0 (vcpu#0) crashed on cpu#0: > > (XEN) ----[ Xen-3.4.1 x86_64 debug=n Not tainted ]---- > > (XEN) CPU: 0 > > (XEN) RIP: e033:[<ffffffff81a017f1>] > > (XEN) RFLAGS: 0000000000000282 EM: 1 CONTEXT: pv guest > > (XEN) rax: 00000000ffffffea rbx: ffffffff8182b000 rcx: > > 00000000001b582b > > (XEN) rdx: 0000000000000000 rsi: 80000001b582b061 rdi: > > ffffffff8182b000 > > (XEN) rbp: ffffffff8174ff98 rsp: ffffffff8174fef8 r8: > > 0000000000000000 > > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > > 0000000000000000 > > (XEN) r12: ffffffff8174ffa8 r13: ffffffff8174ff40 r14: > > 0000000000000080 > > (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: > > 00000000000026f0 > > (XEN) cr3: 00000001b7208000 cr2: 0000000000000000 > > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 > > (XEN) Guest stack trace from rsp=ffffffff8174fef8: > > (XEN) 00000000001b582b 0000000000000000 ffffffff81a017f1 > > 000000010000e030 > > (XEN) 0000000000010082 ffffffff8174ff38 000000000000e02b > > ffffffff81a017ed > > (XEN) 0000000000000000 0000000000000000 0000000000000000 > > 0000000000000000 > > (XEN) 000000000000182b 0000008000000000 ffffffff8100cc87 > > 0000000000000000 > > (XEN) 0000000000000000 0000000000000000 0000000000000000 > > 0000000000000000 > > (XEN) ffffffff8174ffc8 ffffffff81021271 ffff8182b000007f > > 000000000000ffff > > (XEN) 0000000000000000 0000000000000000 ffffffff8174fff8 > > ffffffff81a01b49 > > (XEN) 0000000000000000 0000000000000000 0000000000000000 > > 0000000000000000 > > (XEN) 0000000000000000 > > (XEN) Domain 0 crashed: rebooting machine in 5 seconds. > > > > Looking through that information, I don't see anything that really > > helps me out. Am I missing something? Anything else I should try > > BIOS level that could shed some light on the nature of the issue or is > > my best bet to try booting a debug version of Xen? > > > > On Sep 15, 2009, at 3:56 AM, Pasi Kärkkäinen wrote: > > > > >On Tue, Sep 15, 2009 at 10:17:30AM +0300, Pasi Kärkkäinen wrote: > > >>On Mon, Sep 14, 2009 at 09:44:25PM -0400, Charles Gruener wrote: > > >>>I have an ASRock X58 SuperComputer motherboard that refuses to boot > > >>>the latest xen-3.4.1 in Rawhide. > > >>> > > >>>This is the motherboard: > > >>>http://www.asrock.com/mb/overview.asp?Model=X58%20SuperComputer > > >>> > > >>>Here is a capture of the boot process: > > >>> > > >>>(XEN) Bad console= option 'tty' > > >> > > >>You should remove that unsupported 'tty' option. > > >> > > >>>(XEN) *** LOADING DOMAIN 0 *** > > >>>(XEN) Xen kernel: 64-bit, lsb, compat32 > > >>>(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2695000 > > >>>(XEN) PHYSICAL MEMORY ARRANGEMENT: > > >>>(XEN) Dom0 alloc.: 00000001b4000000->00000001b8000000 (1502490 > > >>>pages to be allocated) > > >>>(XEN) VIRTUAL MEMORY ARRANGEMENT: > > >>>(XEN) Loaded kernel: ffffffff81000000->ffffffff82695000 > > >>>(XEN) Init. ramdisk: ffffffff82695000->ffffffff83006a00 > > >>>(XEN) Phys-Mach map: ffffffff83007000->ffffffff83b9d8d0 > > >>>(XEN) Start info: ffffffff83b9e000->ffffffff83b9e4b4 > > >>>(XEN) Page tables: ffffffff83b9f000->ffffffff83bc2000 > > >>>(XEN) Boot stack: ffffffff83bc2000->ffffffff83bc3000 > > >>>(XEN) TOTAL: ffffffff80000000->ffffffff84000000 > > >>>(XEN) ENTRY ADDRESS: ffffffff819fd820 > > >>>(XEN) Dom0 has maximum 8 VCPUs > > >>>(XEN) Scrubbing Free RAM: .done. > > >>>(XEN) Xen trace buffers: disabled > > >>>(XEN) Std. Loglevel: Errors and warnings > > >>>(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > > > > > >Oh, and also enable logging.. like this: > > > > > >kernel /xen-3.4.gz dom0_mem=1024M loglvl=all guest_loglvl=all > > >com1=115200,8n1 console=com1 > > >module /vmlinuz-2.6.31 ro root=whatever console=hvc0 earlyprintk=xen > > >module /initrd.img > > > > > >-- Pasi > > > > > > > -- > Fedora-xen mailing list > Fedora-xen@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-xen ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot 2009-09-15 11:39 ` [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot Pasi Kärkkäinen 2009-09-15 11:53 ` Pasi Kärkkäinen @ 2009-09-15 14:41 ` Nathan Stratton 2009-09-15 19:58 ` Jeremy Fitzhardinge 2009-09-15 22:23 ` Jeremy Fitzhardinge 3 siblings, 0 replies; 13+ messages in thread From: Nathan Stratton @ 2009-09-15 14:41 UTC (permalink / raw) To: Pasi Kärkkäinen Cc: Jeremy Fitzhardinge, Charles Gruener, xen-devel, fedora-xen [-- Attachment #1: Type: TEXT/PLAIN, Size: 523 bytes --] On Tue, 15 Sep 2009, Pasi Kärkkäinen wrote: > Does this crash look familiar to you Jeremy? > > -- Pasi > >> (XEN) traps.c:437:d0 Unhandled invalid opcode fault/trap [#6] on VCPU >> 0 [ec=0000] I ran into the exact same thing on an install a few days ago. I did not run into it with rc-6. ><> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com [-- 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] 13+ messages in thread
* Re: [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot 2009-09-15 11:39 ` [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot Pasi Kärkkäinen 2009-09-15 11:53 ` Pasi Kärkkäinen 2009-09-15 14:41 ` Nathan Stratton @ 2009-09-15 19:58 ` Jeremy Fitzhardinge 2009-09-15 21:01 ` Charles Gruener 2009-09-15 22:23 ` Jeremy Fitzhardinge 3 siblings, 1 reply; 13+ messages in thread From: Jeremy Fitzhardinge @ 2009-09-15 19:58 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: Charles Gruener, xen-devel, fedora-xen On 09/15/09 04:39, Pasi Kärkkäinen wrote: >> (XEN) mm.c:1697:d0 Bad L1 flags 800000 >> This looks like something trying to set the NX bit in a mapping, which should be fine on this processor. Could it be disabled in BIOS or something? > Jeremy: More info about the dom0 kernel crash here.. > > -- Pasi > > On Tue, Sep 15, 2009 at 01:25:35PM +0100, M A Young wrote: > >> > >> >>> > > >>> > >gdb vmlinux >>> > >x/i ffffffff81a017f1 >>> >> > >> > That should of course have been >> > (gdb) x/i 0xffffffff81a017f1 >> > 0xffffffff81a017f1 <xen_load_gdt_boot+171>: ud2a >> Hm, OK. Maybe the problem is that we haven't enabled NX in EFER at that early point. I'll cook something up. J ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot 2009-09-15 19:58 ` Jeremy Fitzhardinge @ 2009-09-15 21:01 ` Charles Gruener 2009-09-15 21:14 ` [Fedora-xen] " Jeremy Fitzhardinge 0 siblings, 1 reply; 13+ messages in thread From: Charles Gruener @ 2009-09-15 21:01 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: xen-devel, fedora-xen [-- Attachment #1: Type: text/plain, Size: 219 bytes --] Well, for some reason, the BIOS had NX disabled by default. After enabling, I can now get further. I've attached the output I'm now seeing. Could this now be related to the myoung kernel? Many thanks. Charles [-- Attachment #2: nx_enabled.txt.gz --] [-- Type: application/x-gzip, Size: 8563 bytes --] [-- Attachment #3: Type: text/plain, Size: 819 bytes --] On Sep 15, 2009, at 3:58 PM, Jeremy Fitzhardinge wrote: > On 09/15/09 04:39, Pasi Kärkkäinen wrote: >>> (XEN) mm.c:1697:d0 Bad L1 flags 800000 >>> > > This looks like something trying to set the NX bit in a mapping, which > should be fine on this processor. Could it be disabled in BIOS or > something? > >> Jeremy: More info about the dom0 kernel crash here.. >> >> -- Pasi >> >> On Tue, Sep 15, 2009 at 01:25:35PM +0100, M A Young wrote: >> >>>> >>> >>>>>> >>>>>> gdb vmlinux >>>>>> x/i ffffffff81a017f1 >>>> >>>> >>>> That should of course have been >>>> (gdb) x/i 0xffffffff81a017f1 >>>> 0xffffffff81a017f1 <xen_load_gdt_boot+171>: ud2a >>> > > Hm, OK. Maybe the problem is that we haven't enabled NX in EFER at > that > early point. I'll cook something up. > > J [-- Attachment #4: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot 2009-09-15 21:01 ` Charles Gruener @ 2009-09-15 21:14 ` Jeremy Fitzhardinge 0 siblings, 0 replies; 13+ messages in thread From: Jeremy Fitzhardinge @ 2009-09-15 21:14 UTC (permalink / raw) To: Charles Gruener; +Cc: xen-devel, fedora-xen On 09/15/09 14:01, Charles Gruener wrote: > Well, for some reason, the BIOS had NX disabled by default. After > enabling, I can now get further. OK, good to know. I'll post a patch shortly which I hope will make it work either way. > I've attached the output I'm now seeing. Could this now be related to > the myoung kernel? It's crashing because dom0 is trying to manipulate the DMAR hardware, which Xen won't allow. I think there's a fix in Xen to hide the DMAR from dom0, but in the meantime you can disable it in BIOS. J ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot 2009-09-15 11:39 ` [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot Pasi Kärkkäinen ` (2 preceding siblings ...) 2009-09-15 19:58 ` Jeremy Fitzhardinge @ 2009-09-15 22:23 ` Jeremy Fitzhardinge 2009-09-16 8:47 ` M A Young 3 siblings, 1 reply; 13+ messages in thread From: Jeremy Fitzhardinge @ 2009-09-15 22:23 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: Charles Gruener, xen-devel, fedora-xen On 09/15/09 04:39, Pasi Kärkkäinen wrote: > On Tue, Sep 15, 2009 at 07:29:52AM -0400, Charles Gruener wrote: > >> Thanks for the help on configuring my boot options. I apologize that >> I forgot to mention I'm using the latest kernel from M. Young, >> 2.6.31-1.2.65.xendom0.fc12.x86_64. Here's what I get now that I've >> done all of what you've said: >> >> > Ok. I've CCd Jeremy and xen-devel. > > Does this crash look familiar to you Jeremy? > Does this fix it? >From 76ca2d74040210450a670df773d760867f07d519 Mon Sep 17 00:00:00 2001 From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Tue, 15 Sep 2009 14:18:12 -0700 Subject: [PATCH] xen: check EFER for NX before setting up GDT mapping x86-64 assumes NX is available by default, so we need to explicitly check for it before using NX. Some first-generation Intel x86-64 processors didn't support NX, and even recent systems allow it to be disabled in BIOS. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile index 72bb3a2..0088329 100644 --- a/arch/x86/mm/Makefile +++ b/arch/x86/mm/Makefile @@ -4,6 +4,7 @@ obj-y := init.o init_$(BITS).o fault.o ioremap.o extable.o pageattr.o mmap.o \ # Make sure __phys_addr has no stackprotector nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_ioremap.o := $(nostackp) +CFLAGS_init.o := $(nostackp) obj-$(CONFIG_SMP) += tlb.o diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 03644f9..5b55c92 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -1092,6 +1092,11 @@ asmlinkage void __init xen_start_kernel(void) __supported_pte_mask |= _PAGE_IOMAP; +#ifdef CONFIG_X86_64 + /* Work out if we support NX */ + check_efer(); +#endif + xen_setup_features(); /* Get mfn list */ @@ -1132,11 +1137,6 @@ asmlinkage void __init xen_start_kernel(void) pgd = (pgd_t *)xen_start_info->pt_base; -#ifdef CONFIG_X86_64 - /* Work out if we support NX */ - check_efer(); -#endif - /* Don't do the full vcpu_info placement stuff until we have a possible map and a non-dummy shared_info. */ per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0]; ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot 2009-09-15 22:23 ` Jeremy Fitzhardinge @ 2009-09-16 8:47 ` M A Young 2009-09-16 11:47 ` Pasi Kärkkäinen 0 siblings, 1 reply; 13+ messages in thread From: M A Young @ 2009-09-16 8:47 UTC (permalink / raw) To: fedora-xen; +Cc: xen-devel [-- Attachment #1: Type: TEXT/PLAIN, Size: 1183 bytes --] On Tue, 15 Sep 2009, Jeremy Fitzhardinge wrote: > On 09/15/09 04:39, Pasi Kärkkäinen wrote: >> On Tue, Sep 15, 2009 at 07:29:52AM -0400, Charles Gruener wrote: >> >>> Thanks for the help on configuring my boot options. I apologize that >>> I forgot to mention I'm using the latest kernel from M. Young, >>> 2.6.31-1.2.65.xendom0.fc12.x86_64. Here's what I get now that I've >>> done all of what you've said: >>> >>> >> Ok. I've CCd Jeremy and xen-devel. >> >> Does this crash look familiar to you Jeremy? >> > > Does this fix it? > >> From 76ca2d74040210450a670df773d760867f07d519 Mon Sep 17 00:00:00 2001 > From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > Date: Tue, 15 Sep 2009 14:18:12 -0700 > Subject: [PATCH] xen: check EFER for NX before setting up GDT mapping kernel-2.6.31-1.2.67.xendom0.fc12.x86_64.rpm has this fix in if you want to test it, at http://koji.fedoraproject.org/koji/getfile?taskID=1681664&name=kernel-2.6.31-1.2.67.xendom0.fc12.x86_64.rpm (the other kernel packages are available via http://koji.fedoraproject.org/koji/taskinfo?taskID=1681662 ) I haven't tested it so I don't know if it boots. Michael Young [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot 2009-09-16 8:47 ` M A Young @ 2009-09-16 11:47 ` Pasi Kärkkäinen 2009-09-16 16:09 ` Charles Gruener 0 siblings, 1 reply; 13+ messages in thread From: Pasi Kärkkäinen @ 2009-09-16 11:47 UTC (permalink / raw) To: M A Young; +Cc: xen-devel, fedora-xen On Wed, Sep 16, 2009 at 09:47:17AM +0100, M A Young wrote: > On Tue, 15 Sep 2009, Jeremy Fitzhardinge wrote: > > >On 09/15/09 04:39, Pasi Kärkkäinen wrote: > >>On Tue, Sep 15, 2009 at 07:29:52AM -0400, Charles Gruener wrote: > >> > >>>Thanks for the help on configuring my boot options. I apologize that > >>>I forgot to mention I'm using the latest kernel from M. Young, > >>>2.6.31-1.2.65.xendom0.fc12.x86_64. Here's what I get now that I've > >>>done all of what you've said: > >>> > >>> > >>Ok. I've CCd Jeremy and xen-devel. > >> > >>Does this crash look familiar to you Jeremy? > >> > > > >Does this fix it? > > > >>From 76ca2d74040210450a670df773d760867f07d519 Mon Sep 17 00:00:00 2001 > >From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > >Date: Tue, 15 Sep 2009 14:18:12 -0700 > >Subject: [PATCH] xen: check EFER for NX before setting up GDT mapping > > kernel-2.6.31-1.2.67.xendom0.fc12.x86_64.rpm has this fix in if you want > to test it, at > http://koji.fedoraproject.org/koji/getfile?taskID=1681664&name=kernel-2.6.31-1.2.67.xendom0.fc12.x86_64.rpm > (the other kernel packages are available via > http://koji.fedoraproject.org/koji/taskinfo?taskID=1681662 > ) I haven't tested it so I don't know if it boots. > Charles: Please try this updated kernel and let us know if it works for you. Thanks! -- Pasi ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot 2009-09-16 11:47 ` Pasi Kärkkäinen @ 2009-09-16 16:09 ` Charles Gruener 2009-09-21 19:07 ` Re: [Fedora-xen] " Jeremy Fitzhardinge 0 siblings, 1 reply; 13+ messages in thread From: Charles Gruener @ 2009-09-16 16:09 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: fedora-xen, xen-devel, M A Young This absolutely fixes my issue. With the latest patch, I can boot my system successfully if NX is enabled or disabled in the BIOS. Just a final note, I do need to make sure VT-d is disabled in the BIOS, and then I can boot. This was obviously not addressed in this patch nor was it requested to be. It would be nice to have it working at some point as this machine will hopefully have a bunch of NVidia cards in it that will need to be dedicated to each of the domU's for CUDA research. Thank you all for your prompt and courteous responses. It makes me proud to be a RHCE when I get support from a community of developers like you guys. Charles On Sep 16, 2009, at 7:47 AM, Pasi Kärkkäinen wrote: > On Wed, Sep 16, 2009 at 09:47:17AM +0100, M A Young wrote: >> On Tue, 15 Sep 2009, Jeremy Fitzhardinge wrote: >> >>> On 09/15/09 04:39, Pasi Kärkkäinen wrote: >>>> On Tue, Sep 15, 2009 at 07:29:52AM -0400, Charles Gruener wrote: >>>> >>>>> Thanks for the help on configuring my boot options. I apologize >>>>> that >>>>> I forgot to mention I'm using the latest kernel from M. Young, >>>>> 2.6.31-1.2.65.xendom0.fc12.x86_64. Here's what I get now that >>>>> I've >>>>> done all of what you've said: >>>>> >>>>> >>>> Ok. I've CCd Jeremy and xen-devel. >>>> >>>> Does this crash look familiar to you Jeremy? >>>> >>> >>> Does this fix it? >>> >>>> From 76ca2d74040210450a670df773d760867f07d519 Mon Sep 17 00:00:00 >>>> 2001 >>> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >>> Date: Tue, 15 Sep 2009 14:18:12 -0700 >>> Subject: [PATCH] xen: check EFER for NX before setting up GDT >>> mapping >> >> kernel-2.6.31-1.2.67.xendom0.fc12.x86_64.rpm has this fix in if you >> want >> to test it, at >> http://koji.fedoraproject.org/koji/getfile?taskID=1681664&name=kernel-2.6.31-1.2.67.xendom0.fc12.x86_64.rpm >> (the other kernel packages are available via >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1681662 >> ) I haven't tested it so I don't know if it boots. >> > > Charles: Please try this updated kernel and let us know if it works > for > you. > > Thanks! > > -- Pasi > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot 2009-09-16 16:09 ` Charles Gruener @ 2009-09-21 19:07 ` Jeremy Fitzhardinge 2009-09-21 19:24 ` Charles J Gruener 0 siblings, 1 reply; 13+ messages in thread From: Jeremy Fitzhardinge @ 2009-09-21 19:07 UTC (permalink / raw) To: Charles Gruener; +Cc: xen-devel, M A Young, fedora-xen On 09/16/09 09:09, Charles Gruener wrote: > This absolutely fixes my issue. With the latest patch, I can boot my > system successfully if NX is enabled or disabled in the BIOS. Great, thanks for the confirmation. I'll push this patch upstream. > Just a final note, I do need to make sure VT-d is disabled in the > BIOS, and then I can boot. This was obviously not addressed in this > patch nor was it requested to be. It would be nice to have it working > at some point as this machine will hopefully have a bunch of NVidia > cards in it that will need to be dedicated to each of the domU's for > CUDA research. Just to clarify this a bit: Are you saying that if you leave VT-d enabled in BIOS something bad happens? Does it crash? But ideally you'd like to enable it and have it working to allow NVidia cards work, which require it? Thanks, J ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot 2009-09-21 19:07 ` Re: [Fedora-xen] " Jeremy Fitzhardinge @ 2009-09-21 19:24 ` Charles J Gruener 0 siblings, 0 replies; 13+ messages in thread From: Charles J Gruener @ 2009-09-21 19:24 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: xen-devel, M A Young, fedora-xen This is coming from memory as I won't be in front of the machine experiencing the issue for another three weeks. Gotta love paternity leave. :) From what I recall, if I leave VT-d enabled in the BIOS, I experience the dom0 crash I had sent earlier as a .gz file. I can verify this at a later date. Ideally, I am looking to have the ability to assign the NVidia cards to the individual domU machines for CUDA development. We want to see how virtualization affects CUDA performance among other things. The patch that you provided earlier now allows the machine to boot no matter what the NX setting is in the BIOS. Does that help clarify the situation? Charles On Sep 21, 2009, at 3:07 PM, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote: > >> Just a final note, I do need to make sure VT-d is disabled in the >> BIOS, and then I can boot. This was obviously not addressed in this >> patch nor was it requested to be. It would be nice to have it >> working >> at some point as this machine will hopefully have a bunch of NVidia >> cards in it that will need to be dedicated to each of the domU's for >> CUDA research. > > Just to clarify this a bit: > > Are you saying that if you leave VT-d enabled in BIOS something bad > happens? Does it crash? > > But ideally you'd like to enable it and have it working to allow > NVidia cards work, which require it? > > Thanks, > J ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <alpine.GSO.2.00.0909151240230.27096@algedi.dur.ac.uk>]
[parent not found: <20090915121026.GV31123@reaktio.net>]
[parent not found: <alpine.LFD.2.00.0909151323110.16009@vega4.dur.ac.uk>]
* Re: [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot [not found] ` <alpine.LFD.2.00.0909151323110.16009@vega4.dur.ac.uk> @ 2009-09-15 12:46 ` Pasi Kärkkäinen 0 siblings, 0 replies; 13+ messages in thread From: Pasi Kärkkäinen @ 2009-09-15 12:46 UTC (permalink / raw) To: M A Young; +Cc: Jeremy Fitzhardinge, Charles Gruener, xen-devel, fedora-xen Jeremy: More info about the dom0 kernel crash here.. -- Pasi On Tue, Sep 15, 2009 at 01:25:35PM +0100, M A Young wrote: > > > > >gdb vmlinux > >x/i ffffffff81a017f1 > > That should of course have been > (gdb) x/i 0xffffffff81a017f1 > 0xffffffff81a017f1 <xen_load_gdt_boot+171>: ud2a > The context is > (gdb) x/60i xen_load_gdt_boot > 0xffffffff81a01746 <xen_load_gdt_boot>: push %rbp > 0xffffffff81a01747 <xen_load_gdt_boot+1>: mov %rsp,%rbp > 0xffffffff81a0174a <xen_load_gdt_boot+4>: push %r15 > 0xffffffff81a0174c <xen_load_gdt_boot+6>: xor %r15d,%r15d > 0xffffffff81a0174f <xen_load_gdt_boot+9>: push %r14 > 0xffffffff81a01751 <xen_load_gdt_boot+11>: push %r13 > 0xffffffff81a01753 <xen_load_gdt_boot+13>: push %r12 > 0xffffffff81a01755 <xen_load_gdt_boot+15>: mov %rdi,%r12 > 0xffffffff81a01758 <xen_load_gdt_boot+18>: push %rbx > 0xffffffff81a01759 <xen_load_gdt_boot+19>: sub $0x18,%rsp > 0xffffffff81a0175d <xen_load_gdt_boot+23>: movzwl (%rdi),%eax > 0xffffffff81a01760 <xen_load_gdt_boot+26>: mov 0x2(%rdi),%rbx > 0xffffffff81a01764 <xen_load_gdt_boot+30>: inc %eax > 0xffffffff81a01766 <xen_load_gdt_boot+32>: mov %eax,%r14d > 0xffffffff81a01769 <xen_load_gdt_boot+35>: mov %eax,-0x34(%rbp) > 0xffffffff81a0176c <xen_load_gdt_boot+38>: lea 0xfff(%r14),%rax > 0xffffffff81a01773 <xen_load_gdt_boot+45>: shr $0xc,%rax > 0xffffffff81a01777 <xen_load_gdt_boot+49>: lea 0x1e(,%rax,8),%rax > 0xffffffff81a0177f <xen_load_gdt_boot+57>: and $0x7f0,%eax > 0xffffffff81a01784 <xen_load_gdt_boot+62>: sub %rax,%rsp > 0xffffffff81a01787 <xen_load_gdt_boot+65>: lea 0xf(%rsp),%r13 > 0xffffffff81a0178c <xen_load_gdt_boot+70>: and > $0xfffffffffffffff0,%r13 > 0xffffffff81a01790 <xen_load_gdt_boot+74>: test $0xfff,%ebx > 0xffffffff81a01796 <xen_load_gdt_boot+80>: > je 0xffffffff81a01807 <xen_load_gdt_boot+193> > 0xffffffff81a01798 <xen_load_gdt_boot+82>: ud2a > 0xffffffff81a0179a <xen_load_gdt_boot+84>: > jmp 0xffffffff81a0179a <xen_load_gdt_boot+84> > 0xffffffff81a0179c <xen_load_gdt_boot+86>: mov %rbx,%rdi > 0xffffffff81a0179f <xen_load_gdt_boot+89>: > callq 0xffffffff81040b6c <__phys_addr> > 0xffffffff81a017a4 <xen_load_gdt_boot+94>: mov %rax,%rsi > 0xffffffff81a017a7 <xen_load_gdt_boot+97>: shr $0xc,%rsi > 0xffffffff81a017ab <xen_load_gdt_boot+101>: mov %rsi,%rdi > 0xffffffff81a017ae <xen_load_gdt_boot+104>: mov %rsi,-0x40(%rbp) > 0xffffffff81a017b2 <xen_load_gdt_boot+108>: > callq 0xffffffff8100b3ae <pfn_to_mfn> > 0xffffffff81a017b7 <xen_load_gdt_boot+113>: mov -0x40(%rbp),%rsi > 0xffffffff81a017bb <xen_load_gdt_boot+117>: mov %rax,%rcx > 0xffffffff81a017be <xen_load_gdt_boot+120>: mov > $0x8000000000000161,%rax > 0xffffffff81a017c8 <xen_load_gdt_boot+130>: > and -0x1e351f(%rip),%rax # 0xffffffff8181e2b0 > <__supported_pte_mask> > 0xffffffff81a017cf <xen_load_gdt_boot+137>: mov %rsi,%rdi > 0xffffffff81a017d2 <xen_load_gdt_boot+140>: shl $0xc,%rdi > 0xffffffff81a017d6 <xen_load_gdt_boot+144>: or %rax,%rdi > 0xffffffff81a017d9 <xen_load_gdt_boot+147>: callq *0xffffffff81798470 > 0xffffffff81a017e0 <xen_load_gdt_boot+154>: xor %edx,%edx > 0xffffffff81a017e2 <xen_load_gdt_boot+156>: mov %rax,%rsi > 0xffffffff81a017e5 <xen_load_gdt_boot+159>: mov %rbx,%rdi > 0xffffffff81a017e8 <xen_load_gdt_boot+162>: > callq 0xffffffff810091c0 <hypercall_page+448> > 0xffffffff81a017ed <xen_load_gdt_boot+167>: test %eax,%eax > 0xffffffff81a017ef <xen_load_gdt_boot+169>: > je 0xffffffff81a017f5 <xen_load_gdt_boot+175> > 0xffffffff81a017f1 <xen_load_gdt_boot+171>: ud2a > 0xffffffff81a017f3 <xen_load_gdt_boot+173>: > jmp 0xffffffff81a017f3 <xen_load_gdt_boot+173> > 0xffffffff81a017f5 <xen_load_gdt_boot+175>: movslq %r15d,%rax > 0xffffffff81a017f8 <xen_load_gdt_boot+178>: add $0x1000,%rbx > 0xffffffff81a017ff <xen_load_gdt_boot+185>: inc %r15d > 0xffffffff81a01802 <xen_load_gdt_boot+188>: mov > %rcx,0x0(%r13,%rax,8) > 0xffffffff81a01807 <xen_load_gdt_boot+193>: mov %r14,%rax > 0xffffffff81a0180a <xen_load_gdt_boot+196>: add 0x2(%r12),%rax > 0xffffffff81a0180f <xen_load_gdt_boot+201>: cmp %rax,%rbx > 0xffffffff81a01812 <xen_load_gdt_boot+204>: > jb 0xffffffff81a0179c <xen_load_gdt_boot+86> > 0xffffffff81a01814 <xen_load_gdt_boot+206>: mov -0x34(%rbp),%esi > 0xffffffff81a01817 <xen_load_gdt_boot+209>: mov %r13,%rdi > 0xffffffff81a0181a <xen_load_gdt_boot+212>: shr $0x3,%esi ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-09-21 19:24 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <976E8557-F11D-416E-84C2-CD12B180CA1B@rit.edu>
[not found] ` <20090915071730.GP31123@reaktio.net>
[not found] ` <20090915075613.GQ31123@reaktio.net>
[not found] ` <82B3AFF8-B4F1-4347-82F3-04F100002684@rit.edu>
2009-09-15 11:39 ` [Fedora-xen] 2.6.31-1.2.65.xendom0.fc12.x86_64 crash on boot Pasi Kärkkäinen
2009-09-15 11:53 ` Pasi Kärkkäinen
2009-09-15 14:41 ` Nathan Stratton
2009-09-15 19:58 ` Jeremy Fitzhardinge
2009-09-15 21:01 ` Charles Gruener
2009-09-15 21:14 ` [Fedora-xen] " Jeremy Fitzhardinge
2009-09-15 22:23 ` Jeremy Fitzhardinge
2009-09-16 8:47 ` M A Young
2009-09-16 11:47 ` Pasi Kärkkäinen
2009-09-16 16:09 ` Charles Gruener
2009-09-21 19:07 ` Re: [Fedora-xen] " Jeremy Fitzhardinge
2009-09-21 19:24 ` Charles J Gruener
[not found] ` <alpine.GSO.2.00.0909151240230.27096@algedi.dur.ac.uk>
[not found] ` <20090915121026.GV31123@reaktio.net>
[not found] ` <alpine.LFD.2.00.0909151323110.16009@vega4.dur.ac.uk>
2009-09-15 12:46 ` Pasi Kärkkäinen
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.