When doing "make linux-2.6-xen0-build", it failed with: make[3]: `arch/xen/x86_64/kernel/asm-offsets.s'' is up to date. CHK include/linux/compile.h CHK usr/initramfs_list GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 arch/xen/x86_64/kernel/built-in.o(.text+0x291): In function `xen_idle'': : undefined reference to `set_timeout_timer'' make[2]: *** [.tmp_vmlinux1] Error 1 make[2]: Leaving directory `/home/xin/bk/xeno-unstable.bk/linux-2.6.11-xen0'' make[1]: *** [build] Error 2 make[1]: Leaving directory `/home/xin/bk/xeno-unstable.bk'' make: *** [linux-2.6-xen0-build] Error 2 -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Actually xen itself is broken (again) too on x86-64. It dies like the below. I think the breakage happened very recently (today, yesterday, or the day before yesterday). --- Xen version 3.0-devel (jnakajim@sc.intel.com) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) Mon May 30 21:26:28 PDT 2005 Latest ChangeSet: 2005/05/30 20:19:59 1.1577 429bd7dfnKHSDeYeOeCr4yRO7YCrFQ (XEN) Physical RAM map: (XEN) 0000000000000000 - 000000000009fc00 (usable) (XEN) 000000000009fc00 - 00000000000a0000 (reserved) (XEN) 00000000000e6000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 000000003f630000 (usable) (XEN) 000000003f630000 - 000000003f640000 (ACPI data) (XEN) 000000003f640000 - 000000003f6f0000 (ACPI NVS) (XEN) 000000003f6f0000 - 000000003f800000 (reserved) (XEN) 00000000cff00000 - 00000000f0000000 (reserved) (XEN) 00000000fed13000 - 00000000fed1a000 (reserved) (XEN) 00000000fed1c000 - 00000000fed90000 (reserved) (XEN) System RAM: 1013MB (1038140kB) (XEN) Xen heap: 14MB (14828kB) (XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K (XEN) CPU: L2 cache: 2048K (XEN) Unknown interrupt Li, Xin B wrote:> When doing "make linux-2.6-xen0-build", it failed with: > > make[3]: `arch/xen/x86_64/kernel/asm-offsets.s'' is up to date. > CHK include/linux/compile.h > CHK usr/initramfs_list > GEN .version > CHK include/linux/compile.h > UPD include/linux/compile.h > CC init/version.o > LD init/built-in.o > LD .tmp_vmlinux1 > arch/xen/x86_64/kernel/built-in.o(.text+0x291): In function > `xen_idle'': >> undefined reference to `set_timeout_timer'' > make[2]: *** [.tmp_vmlinux1] Error 1 > make[2]: Leaving directory > `/home/xin/bk/xeno-unstable.bk/linux-2.6.11-xen0'' > make[1]: *** [build] Error 2 > make[1]: Leaving directory `/home/xin/bk/xeno-unstable.bk'' > make: *** [linux-2.6-xen0-build] Error 2 > > -Xin > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-develJun --- Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nakajima, Jun wrote:> Actually xen itself is broken (again) too on x86-64. It dies like the > below. I think the breakage happened very recently (today, yesterday, > or the day before yesterday).Did a quick debugging. It''s failing at phys_pkg_id (it''s NULL) in detect_ht because genacpi is not set yet when this is called. Putting "apic=default" makes it boot. I think it should be initialized as "default". void __init detect_ht(struct cpuinfo_x86 *c) { ... phys_proc_id[cpu] = phys_pkg_id((ebx >> 24) & 0xFF, index_msb); Jun --- Intel Open Source Technology Center> --- > Xen version 3.0-devel (jnakajim@sc.intel.com) (gcc version 3.4.2 > 20041017 (Red > Hat 3.4.2-6.fc3)) Mon May 30 21:26:28 PDT 2005 > Latest ChangeSet: 2005/05/30 20:19:59 1.1577 > 429bd7dfnKHSDeYeOeCr4yRO7YCrFQ > > (XEN) Physical RAM map: > (XEN) 0000000000000000 - 000000000009fc00 (usable) > (XEN) 000000000009fc00 - 00000000000a0000 (reserved) > (XEN) 00000000000e6000 - 0000000000100000 (reserved) > (XEN) 0000000000100000 - 000000003f630000 (usable) > (XEN) 000000003f630000 - 000000003f640000 (ACPI data) > (XEN) 000000003f640000 - 000000003f6f0000 (ACPI NVS) > (XEN) 000000003f6f0000 - 000000003f800000 (reserved) > (XEN) 00000000cff00000 - 00000000f0000000 (reserved) > (XEN) 00000000fed13000 - 00000000fed1a000 (reserved) > (XEN) 00000000fed1c000 - 00000000fed90000 (reserved) > (XEN) System RAM: 1013MB (1038140kB) > (XEN) Xen heap: 14MB (14828kB) > (XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K > (XEN) CPU: L2 cache: 2048K > (XEN) Unknown interrupt > > Li, Xin B wrote: >> When doing "make linux-2.6-xen0-build", it failed with: >> >> make[3]: `arch/xen/x86_64/kernel/asm-offsets.s'' is up to date. >> CHK include/linux/compile.h >> CHK usr/initramfs_list >> GEN .version >> CHK include/linux/compile.h >> UPD include/linux/compile.h >> CC init/version.o >> LD init/built-in.o >> LD .tmp_vmlinux1 >> arch/xen/x86_64/kernel/built-in.o(.text+0x291): In function >> `xen_idle'': >>> undefined reference to `set_timeout_timer'' >> make[2]: *** [.tmp_vmlinux1] Error 1 >> make[2]: Leaving directory >> `/home/xin/bk/xeno-unstable.bk/linux-2.6.11-xen0'' >> make[1]: *** [build] Error 2 >> make[1]: Leaving directory `/home/xin/bk/xeno-unstable.bk'' >> make: *** [linux-2.6-xen0-build] Error 2 >> >> -Xin >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > > > Jun > --- > Intel Open Source Technology Center > > _______________________________________________ > 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
Nakajima, Jun wrote:> Nakajima, Jun wrote: >> Actually xen itself is broken (again) too on x86-64. It dies like the >> below. I think the breakage happened very recently (today, yesterday, >> or the day before yesterday). > > Did a quick debugging. It''s failing at phys_pkg_id (it''s NULL) in > detect_ht because genacpi is not set yet when this is called. Putting > "apic=default" makes it boot. I think it should be initialized as > "default".Attached is a patch to this. Signed-off-by: Jun Nakajima <jun.nakajima@intel.com> Jun --- Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 31 May 2005, at 07:15, Nakajima, Jun wrote:> Did a quick debugging. It''s failing at phys_pkg_id (it''s NULL) in > detect_ht because genacpi is not set yet when this is called. Putting > "apic=default" makes it boot. I think it should be initialized as > "default".This one slipped through because I do not usually boot-test on an HT-capable system. :-) I checked in a better fix -- we were doing initial identify_cpu() much earlier than we needed to. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Using the latest source from BK, on x86_64 SLES 9 installation, I am seeing this error: gcc -Wl,-T,/tmp/xen-unstable/tools/ioemu/x86_64.ld -o qemu-dm vl.o exec.o monitor.o osdep.o block.o readline.o pci.o console.o block-cloop.o ide.o ne2000.o pckbd.o vga.o dma.o fdc.o mc146818rtc.o serial.o i8259.o i8254.o pc.o port-e9.o cirrus_vga.o libqemu.a -lm -L../../libxc -lxc -lz -lutil /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-linux/bin/ld:/tmp/xen-unstable/tools/ioemu/x86_64.ld:62: syntax error collect2: ld returned 1 exit status make[5]: *** [qemu-dm] Error 1 make[5]: Leaving directory `/tmp/xen-unstable/tools/ioemu/target-i386-dm'' make[4]: *** [all] Error 1 make[4]: Leaving directory `/tmp/xen-unstable/tools/ioemu'' make[3]: *** [ioemuinstall] Error 2 make[3]: Leaving directory `/tmp/xen-unstable/tools'' make[2]: *** [install] Error 2 make[2]: Leaving directory `/tmp/xen-unstable/tools'' make[1]: *** [tools] Error 2 make[1]: Leaving directory `/tmp/xen-unstable'' make: *** [world] Error 2 On Mon, 2005-05-30 at 23:37 -0700, Nakajima, Jun wrote:> Nakajima, Jun wrote: > > Nakajima, Jun wrote: > >> Actually xen itself is broken (again) too on x86-64. It dies like the > >> below. I think the breakage happened very recently (today, yesterday, > >> or the day before yesterday). > > > > Did a quick debugging. It''s failing at phys_pkg_id (it''s NULL) in > > detect_ht because genacpi is not set yet when this is called. Putting > > "apic=default" makes it boot. I think it should be initialized as > > "default". > > Attached is a patch to this. > > Signed-off-by: Jun Nakajima <jun.nakajima@intel.com> > > Jun > --- > Intel Open Source Technology Center > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Regards, David F Barrera Linux Technology Center Systems and Technology Group, IBM "The wisest men follow their own direction. " Euripides _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 31 May 2005, at 16:16, David F Barrera wrote:> Using the latest source from BK, on x86_64 SLES 9 installation, I am > seeing this error: > > gcc -Wl,-T,/tmp/xen-unstable/tools/ioemu/x86_64.ld -o qemu-dm vl.o > exec.o > monitor.o osdep.o block.o readline.o pci.o console.o block-cloop.o > ide.o > ne2000.o pckbd.o vga.o dma.o fdc.o mc146818rtc.o serial.o i8259.o > i8254.o pc.o > port-e9.o cirrus_vga.o libqemu.a -lm -L../../libxc -lxc -lz -lutil > /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse- > linux/bin/ld:/tmp/xen-unstable/tools/ioemu/x86_64.ld:62: > syntax errorWe should not have to be specially linking qemu-dm for x86/64 at all. The x86/32 excuse of inadequate address space to map all the foreign domain''s pages does not hold on x86/64. Would it break anything simply to remove the linker script for x86/64? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
The attached patch gets me past early boot. sRp On Tue, May 31, 2005 at 06:16:10PM +0100, Keir Fraser wrote:> > On 31 May 2005, at 18:01, David F Barrera wrote: > > >OK. This is the first time that I''ve been able to build Xen on SLES 9 > >x86_64. When attempting to boot, Dom0 crashes. Although there is > >already > >a defect open (Bugzilla #26) for a failure to boot Dom0 on x86_64 on > >FC4, I am opening a new defect (Bugzilla #65) since the failures appear > >different. > > I wouldn''t be surprised if the 32-bit PAE patch has broken guest > pagetable management for x86/64. I fixed a bug that caused a crash > during Xen bootstrap, but I didn''t check domain0 booting. Lots of > things have changed in the dom0 builder and in arch/x86/mm.c though. > > -- Keir > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >-- Scott Parish Signed-off-by: srparish@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Uh, this patch is completely wrong, please ignore, k thanks. sRp On Tue, May 31, 2005 at 04:52:09PM +0000, Scott Parish wrote:> The attached patch gets me past early boot. > > sRp > > On Tue, May 31, 2005 at 06:16:10PM +0100, Keir Fraser wrote: > > > > > On 31 May 2005, at 18:01, David F Barrera wrote: > > > > >OK. This is the first time that I''ve been able to build Xen on SLES 9 > > >x86_64. When attempting to boot, Dom0 crashes. Although there is > > >already > > >a defect open (Bugzilla #26) for a failure to boot Dom0 on x86_64 on > > >FC4, I am opening a new defect (Bugzilla #65) since the failures appear > > >different. > > > > I wouldn''t be surprised if the 32-bit PAE patch has broken guest > > pagetable management for x86/64. I fixed a bug that caused a crash > > during Xen bootstrap, but I didn''t check domain0 booting. Lots of > > things have changed in the dom0 builder and in arch/x86/mm.c though. > > > > -- Keir > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > -- > Scott Parish > Signed-off-by: srparish@us.ibm.com> diff -rN -u -p old-xen-64-4/xen/arch/x86/mm.c new-xen-64-4/xen/arch/x86/mm.c > --- old-xen-64-4/xen/arch/x86/mm.c 2005-05-31 16:15:06.000000000 +0000 > +++ new-xen-64-4/xen/arch/x86/mm.c 2005-05-31 16:47:32.000000000 +0000 > @@ -103,6 +103,7 @@ > #include <asm/ldt.h> > #include <asm/x86_emulate.h> > > +#define VERBOSE 1 > #ifdef VERBOSE > #define MEM_LOG(_f, _a...) \ > printk("DOM%u: (file=mm.c, line=%d) " _f "\n", \ > @@ -446,7 +447,7 @@ get_page_from_l1e( > > if ( unlikely(l1e_get_flags(l1e) & L1_DISALLOW_MASK) ) > { > - MEM_LOG("Bad L1 flags %x\n", l1e_get_flags(l1e) & L1_DISALLOW_MASK); > + MEM_LOG("Bad L1 flags %lx\n", l1e_get_flags(l1e) & L1_DISALLOW_MASK); > return 0; > } > > @@ -492,7 +493,7 @@ get_page_from_l2e( > > if ( unlikely((l2e_get_flags(l2e) & L2_DISALLOW_MASK)) ) > { > - MEM_LOG("Bad L2 flags %x\n", l2e_get_flags(l2e) & L2_DISALLOW_MASK); > + MEM_LOG("Bad L2 flags %lx\n", l2e_get_flags(l2e) & L2_DISALLOW_MASK); > return 0; > } > > @@ -525,7 +526,7 @@ get_page_from_l3e( > > if ( unlikely((l3e_get_flags(l3e) & L3_DISALLOW_MASK)) ) > { > - MEM_LOG("Bad L3 flags %x\n", l3e_get_flags(l3e) & L3_DISALLOW_MASK); > + MEM_LOG("Bad L3 flags %lx\n", l3e_get_flags(l3e) & L3_DISALLOW_MASK); > return 0; > } > > @@ -558,7 +559,7 @@ get_page_from_l4e( > > if ( unlikely((l4e_get_flags(l4e) & L4_DISALLOW_MASK)) ) > { > - MEM_LOG("Bad L4 flags %x\n", l4e_get_flags(l4e) & L4_DISALLOW_MASK); > + MEM_LOG("Bad L4 flags %lx\n", l4e_get_flags(l4e) & L4_DISALLOW_MASK); > return 0; > } > > diff -rN -u -p old-xen-64-4/xen/include/asm-x86/x86_64/page.h new-xen-64-4/xen/include/asm-x86/x86_64/page.h > --- old-xen-64-4/xen/include/asm-x86/x86_64/page.h 2005-05-31 16:15:06.000000000 +0000 > +++ new-xen-64-4/xen/include/asm-x86/x86_64/page.h 2005-05-31 16:50:24.000000000 +0000 > @@ -61,12 +61,12 @@ typedef l4_pgentry_t root_pgentry_t; > #define get_pte_flags(x) ((int)((x) >> 40) | ((int)(x) & 0xFFF)) > #define put_pte_flags(x) ((((intpte_t)((x) & ~0xFFF)) << 40) | ((x) & 0xFFF)) > > -#define _PAGE_NX (cpu_has_nx ? (1U<<23) : 0U) > +#define _PAGE_NX (cpu_has_nx ? (1UL<<63) : 0UL) > > -#define L1_DISALLOW_MASK (0xFFFFF180U & ~_PAGE_NX) /* PAT/GLOBAL */ > -#define L2_DISALLOW_MASK (0xFFFFF180U & ~_PAGE_NX) /* PSE/GLOBAL */ > -#define L3_DISALLOW_MASK (0xFFFFF180U & ~_PAGE_NX) /* must-be-zero */ > -#define L4_DISALLOW_MASK (0xFFFFF180U & ~_PAGE_NX) /* must-be-zero */ > +#define L1_DISALLOW_MASK _PAGE_NX > +#define L2_DISALLOW_MASK _PAGE_NX > +#define L3_DISALLOW_MASK _PAGE_NX > +#define L4_DISALLOW_MASK _PAGE_NX > > #endif /* __X86_64_PAGE_H__ */ > >> _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Scott Parish Signed-off-by: srparish@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
OK. This is the first time that I''ve been able to build Xen on SLES 9 x86_64. When attempting to boot, Dom0 crashes. Although there is already a defect open (Bugzilla #26) for a failure to boot Dom0 on x86_64 on FC4, I am opening a new defect (Bugzilla #65) since the failures appear different. __ __ _____ ___ _ _ \ \/ /___ _ __ |___ / / _ \ __| | _____ _____| | \ // _ \ ''_ \ |_ \| | | |__ / _` |/ _ \ \ / / _ \ | / \ __/ | | | ___) | |_| |__| (_| | __/\ V / __/ | /_/\_\___|_| |_| |____(_)___/ \__,_|\___| \_/ \___|_| http://www.cl.cam.ac.uk/netos/xen University of Cambridge Computer Laboratory Xen version 3.0-devel (root@ltc.austin.ibm.com) (gcc version 3.3.3 (SuSE Linux)) Tue May 31 06:20:43 CDT 2005 Latest ChangeSet: information unavailable (XEN) Physical RAM map: (XEN) 0000000000000000 - 000000000009d400 (usable) (XEN) 000000000009d400 - 00000000000a0000 (reserved) (XEN) 00000000000e0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 000000003ffbe680 (usable) (XEN) 000000003ffbe680 - 000000003ffd0000 (ACPI data) (XEN) 000000003ffd0000 - 0000000040000000 (reserved) (XEN) 00000000fec00000 - 0000000100000000 (reserved) (XEN) System RAM: 1023MB (1047916kB) (XEN) Xen heap: 14MB (14804kB) (XEN) found SMP MP-table at 0009d540 (XEN) DMI 2.3 present. (XEN) Using APICSH\uffff(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled) (XEN) Processor #6 15:4 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) (XEN) Processor #1 15:4 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled) (XEN) Processor #7 15:4 APIC version 20 (XEN) ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_i9\uffff\u0455\uffff\u0455\uffff5!\uffff\uffff\u027d\uffff\uffff\uffff\u037d\uffffXEN) Using scheduler: Borrowed Virtual Time (bvt) (XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K (XEN) CPU: L2 cache: 1024K (XEN) CPU: Physical Processor ID: 0 (XEN) CPU0: Intel(R) Xeon(TM) CPU 3.60GHz stepping 01 (XEN) Booting processor 1/1 eip 90000 (XEN) Initializing CPU#1 (XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K (XEN) CPU: L2 cache: 1024K (XEN) CPU: Physical Processor ID: 0 (XEN) CPU1: Intel(R) Xeon(TM) CPU 3.60GHz stepping 01 (XEN) Booting proc AU!\uffff\uffff\u0455\uffff\uffff\uffff\uffff\uffffXEN) Total of 4 processors activated. (XEN) ENABLING IO-APIC IRQs (XEN) ..TIMER: vector=0x31 pin1=2 pin2=-1 (XEN) checking TSC synchronization across 4 CPUs: passed. (XEN) Time init: (XEN) .... cpu_freq: 00000000:D6980F54 (XEN) .... scale: 00000001:1C6BEB88 (XEN) .... Wall Clock: 1117540311s 180000us (XEN) Brought up 4 CPUs (XEN) mtrr: v2.0 (20020519) (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen-ELF header found: ''GUEST_OS=linux,GUEST_VER=2.6,XEN_VER=3.0,VIRT_BASE=0xffffffff80100000,LOADER=generic'' (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000010000000->0000000020000000 (62464 pages to be allocated) (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff80100000->ffffffff80576086 (XEN) Init. ramdisk: ffffffff80577000->ffffffff80577000 (XEN) Phys-Mach map: ffffffff80577000->ffffffff805f4000 (XEN) Page tables: ffffffff805f4000->ffffffff805fb000 (XEN) Start info: ffffffff805fb000->ffffffff805fc000 (XEN) Boot stack: ffffffff805fc000->ffffffff805fd000 (XEN) TOTAL: ffffffff80000000->ffffffff80800000 (XEN) ENTRY ADDRESS: ffffffff80100000 (XEN) Scrubbing Free RAM: ...........done. (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch input to Xen). (XEN) CPU: 0 (XEN) EIP: e030:[<0000000000000000>] (XEN) EFLAGS: 0000000000010282 (XEN) rax: 00000000ffffffea rbx: 00000000105f5000 rcx: 0000000000000000 rdx: 0000000000000000 (XEN) rsi: 0000000000000001 rdi: ffffffff804ebf40 rbp: 0000000000000808 rsp: ffffffff804ebf08 (XEN) r8: 0000000000000000 r9: 0000000000000000 r10: 0000000000007ff0 r11: 0000000000000282 (XEN) r12: 0000000000000000 r13: ffffffff805f4000 r14: ffffffff80102000 r15: ffffffff804ebfb0 (XEN) Xen stack trace from rsp=ffffffff804ebf08: (XEN) ffffffff80118d9d 0000000000000202 ffffffff80118da1 000000000001e030 0000000000010282 ffffffff804ebf40 000000000000e02b 00000000105f5808 (XEN) 0000000010101065 0000000000000000 ffffffff80115d08 0000000000000000 0000000000000000 ffffffff804d8080 ffffffff80 on CPU0: Domain 0 crashed! **************************************** Reboot in five seconds... (XEN) Reboot disabled on cmdline: require manual reset On Tue, 2005-05-31 at 16:49 +0100, Keir Fraser wrote:> On 31 May 2005, at 16:16, David F Barrera wrote: > > > Using the latest source from BK, on x86_64 SLES 9 installation, I am > > seeing this error: > > > > gcc -Wl,-T,/tmp/xen-unstable/tools/ioemu/x86_64.ld -o qemu-dm vl.o > > exec.o > > monitor.o osdep.o block.o readline.o pci.o console.o block-cloop.o > > ide.o > > ne2000.o pckbd.o vga.o dma.o fdc.o mc146818rtc.o serial.o i8259.o > > i8254.o pc.o > > port-e9.o cirrus_vga.o libqemu.a -lm -L../../libxc -lxc -lz -lutil > > /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse- > > linux/bin/ld:/tmp/xen-unstable/tools/ioemu/x86_64.ld:62: > > syntax error > > We should not have to be specially linking qemu-dm for x86/64 at all. > The x86/32 excuse of inadequate address space to map all the foreign > domain''s pages does not hold on x86/64. > > Would it break anything simply to remove the linker script for x86/64? > > -- Keir > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >-- Regards, David F Barrera Linux Technology Center Systems and Technology Group, IBM "The wisest men follow their own direction. " Euripides _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 31 May 2005, at 18:01, David F Barrera wrote:> OK. This is the first time that I''ve been able to build Xen on SLES 9 > x86_64. When attempting to boot, Dom0 crashes. Although there is > already > a defect open (Bugzilla #26) for a failure to boot Dom0 on x86_64 on > FC4, I am opening a new defect (Bugzilla #65) since the failures appear > different.I wouldn''t be surprised if the 32-bit PAE patch has broken guest pagetable management for x86/64. I fixed a bug that caused a crash during Xen bootstrap, but I didn''t check domain0 booting. Lots of things have changed in the dom0 builder and in arch/x86/mm.c though. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
David F Barrera wrote:> OK. This is the first time that I''ve been able to build Xen on SLES 9 > x86_64. When attempting to boot, Dom0 crashes. Although there is > already > a defect open (Bugzilla #26) for a failure to boot Dom0 on x86_64 on > FC4, I am opening a new defect (Bugzilla #65) since the failures > appear different. > > (XEN) Scrubbing Free RAM: ...........done. > (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch > input to Xen). (XEN) CPU: 0 > (XEN) EIP: e030:[<0000000000000000>] > (XEN) EFLAGS: 0000000000010282 > (XEN) rax: 00000000ffffffea rbx: 00000000105f5000 rcx: > 0000000000000000 > rdx: 0000000000000000 > (XEN) rsi: 0000000000000001 rdi: ffffffff804ebf40 rbp: > 0000000000000808 > rsp: ffffffff804ebf08 > (XEN) r8: 0000000000000000 r9: 0000000000000000 r10: > 0000000000007ff0 > r11: 0000000000000282 > (XEN) r12: 0000000000000000 r13: ffffffff805f4000 r14: > ffffffff80102000 > r15: ffffffff804ebfb0 > (XEN) Xen stack trace from rsp=ffffffff804ebf08: > (XEN) ffffffff80118d9d 0000000000000202 ffffffff80118da1 > 000000000001e030 0000000000010282 ffffffff804ebf40 000000000000e02b > 00000000105f5808 (XEN) 0000000010101065 0000000000000000 > ffffffff80115d08 0000000000000000 0000000000000000 ffffffff804d8080 > ffffffff80 on CPU0: > Domain 0 crashed! > **************************************** >This is different from the other ones, but we need more hints as I don''t see this problem on our machines. For example, can you show the instructions around 0xffffffff80118d9d? Please do like 1. objdump -d vmlinux > out (in linux-2.6.11-xen0) 2. search ffffffff80118d9d in ''out'' 3. cut and send the disassembled instructions around ffffffff80118d9d. Jun --- Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2005-05-31 at 12:32 -0700, Nakajima, Jun wrote:> David F Barrera wrote: > > OK. This is the first time that I''ve been able to build Xen on SLES 9 > > x86_64. When attempting to boot, Dom0 crashes. Although there is > > already > > a defect open (Bugzilla #26) for a failure to boot Dom0 on x86_64 on > > FC4, I am opening a new defect (Bugzilla #65) since the failures > > appear different. > > > > (XEN) Scrubbing Free RAM: ...........done. > > (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch > > input to Xen). (XEN) CPU: 0 > > (XEN) EIP: e030:[<0000000000000000>] > > (XEN) EFLAGS: 0000000000010282 > > (XEN) rax: 00000000ffffffea rbx: 00000000105f5000 rcx: > > 0000000000000000 > > rdx: 0000000000000000 > > (XEN) rsi: 0000000000000001 rdi: ffffffff804ebf40 rbp: > > 0000000000000808 > > rsp: ffffffff804ebf08 > > (XEN) r8: 0000000000000000 r9: 0000000000000000 r10: > > 0000000000007ff0 > > r11: 0000000000000282 > > (XEN) r12: 0000000000000000 r13: ffffffff805f4000 r14: > > ffffffff80102000 > > r15: ffffffff804ebfb0 > > (XEN) Xen stack trace from rsp=ffffffff804ebf08: > > (XEN) ffffffff80118d9d 0000000000000202 ffffffff80118da1 > > 000000000001e030 0000000000010282 ffffffff804ebf40 000000000000e02b > > 00000000105f5808 (XEN) 0000000010101065 0000000000000000 > > ffffffff80115d08 0000000000000000 0000000000000000 ffffffff804d8080 > > ffffffff80 on CPU0: > > Domain 0 crashed! > > **************************************** > > > > This is different from the other ones, but we need more hints as I don''t > see this problem on our machines. For example, can you show the > instructions around 0xffffffff80118d9d? Please do like > 1. objdump -d vmlinux > out (in linux-2.6.11-xen0) > 2. search ffffffff80118d9d in ''out'' > 3. cut and send the disassembled instructions around ffffffff80118d9d.OK. Here they are:(ffffffff80118d9d is in the middle) ffffffff80118d4f: 90 nop ffffffff80118d50: 48 b8 00 00 00 00 00 mov $0x780000000000,% rax ffffffff80118d57: 78 00 00 ffffffff80118d5a: 48 8d 0c 38 lea (%rax,%rdi,1),% rcx ffffffff80118d5e: 48 8b 15 1b 15 37 00 mov 3609883(%rip),% rdx # ffffffff8048a280 <phys_to_machine_mapping> ffffffff80118d65: 48 89 e7 mov %rsp,%rdi ffffffff80118d68: 48 89 c8 mov %rcx,%rax ffffffff80118d6b: 81 e1 ff 0f 00 00 and $0xfff,%ecx ffffffff80118d71: 48 c1 e8 0c shr $0xc,%rax ffffffff80118d75: 89 c0 mov %eax,%eax ffffffff80118d77: 8b 04 82 mov (%rdx,%rax,4),% eax ffffffff80118d7a: 48 89 74 24 08 mov %rsi,0x8(%rsp) ffffffff80118d7f: be 01 00 00 00 mov $0x1,%esi ffffffff80118d84: 31 d2 xor %edx,%edx ffffffff80118d86: 48 c1 e0 0c shl $0xc,%rax ffffffff80118d8a: 48 09 c8 or %rcx,%rax ffffffff80118d8d: 48 89 04 24 mov %rax,(%rsp) ffffffff80118d91: 48 89 f0 mov %rsi,%rax ffffffff80118d94: 49 c7 c2 f0 7f 00 00 mov $0x7ff0,%r10 ffffffff80118d9b: 0f 05 syscall ffffffff80118d9d: 85 c0 test %eax,%eax ffffffff80118d9f: 79 0f jns ffffffff80118db0 <xen_l1_entry_update+0x80> ffffffff80118da1: 0f 0b ud2a ffffffff80118da3: 03 41 3a add 0x3a(%rcx),%eax ffffffff80118da6: 80 ff ff cmp $0xff,%bh ffffffff80118da9: ff (bad) ffffffff80118daa: ff 35 00 66 66 90 pushq -1872337408(%rip) # ffffffff1077f3b0 <__start___xen_guest+0xffffffff10779a52> ffffffff80118db0: 48 83 c4 18 add $0x18,%rsp ffffffff80118db4: c3 retq ffffffff80118db5: 66 data16 ffffffff80118db6: 66 data16 ffffffff80118db7: 66 data16 ffffffff80118db8: 90 nop ffffffff80118db9: 66 data16 ffffffff80118dba: 66 data16 ffffffff80118dbb: 66 data16 ffffffff80118dbc: 90 nop ffffffff80118dbd: 66 data16 ffffffff80118dbe: 66 data16 ffffffff80118dbf: 90 nop ffffffff80118dc0 <allocate_empty_lowmem_region>: ffffffff80118dc0: 41 57 push %r15 ffffffff80118dc2: 48 c1 e7 0c shl $0xc,%rdi ffffffff80118dc6: 48 8d 47 ff lea 0xffffffffffffffff(%rdi),%rax ffffffff80118dca: 41 56 push %r14> > Jun > --- > Intel Open Source Technology Center > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >-- Regards, David F Barrera Linux Technology Center Systems and Technology Group, IBM "The wisest men follow their own direction. " Euripides _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
David F Barrera wrote:> On Tue, 2005-05-31 at 12:32 -0700, Nakajima, Jun wrote: >> David F Barrera wrote: >>> OK. This is the first time that I''ve been able to build Xen on SLES >>> 9 x86_64. When attempting to boot, Dom0 crashes. Although there is >>> already a defect open (Bugzilla #26) for a failure to boot Dom0 on >>> x86_64 on FC4, I am opening a new defect (Bugzilla #65) since the >>> failures appear different. >>> >>> (XEN) Scrubbing Free RAM: ...........done. >>> (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch >>> input to Xen). (XEN) CPU: 0 >>> (XEN) EIP: e030:[<0000000000000000>] >>> (XEN) EFLAGS: 0000000000010282 >>> (XEN) rax: 00000000ffffffea rbx: 00000000105f5000 rcx: >>> 0000000000000000 rdx: 0000000000000000 >>> (XEN) rsi: 0000000000000001 rdi: ffffffff804ebf40 rbp: >>> 0000000000000808 rsp: ffffffff804ebf08 >>> (XEN) r8: 0000000000000000 r9: 0000000000000000 r10: >>> 0000000000007ff0 r11: 0000000000000282 >>> (XEN) r12: 0000000000000000 r13: ffffffff805f4000 r14: >>> ffffffff80102000 r15: ffffffff804ebfb0 >>> (XEN) Xen stack trace from rsp=ffffffff804ebf08: >>> (XEN) ffffffff80118d9d 0000000000000202 ffffffff80118da1 >>> 000000000001e030 0000000000010282 ffffffff804ebf40 000000000000e02b >>> 00000000105f5808 (XEN) 0000000010101065 0000000000000000 >>> ffffffff80115d08 0000000000000000 0000000000000000 ffffffff804d8080 >>> ffffffff80 on CPU0: Domain 0 crashed! >>> **************************************** >>> >> >> This is different from the other ones, but we need more hints as I >> don''t see this problem on our machines. For example, can you show the >> instructions around 0xffffffff80118d9d? Please do like >> 1. objdump -d vmlinux > out (in linux-2.6.11-xen0) >> 2. search ffffffff80118d9d in ''out'' >> 3. cut and send the disassembled instructions around >> ffffffff80118d9d. > OK. Here they are:(ffffffff80118d9d is in the middle)Looks like xen_l1_entry_update is failing because xen did not like the page. Can you do the same thing with 0xffffffff80115d08? Jun --- Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Scott Parish
2005-May-31 23:28 UTC
[patch] "flags" bits need shifting (was Re: [Xen-devel] Latest bk can NOT compile on x86_64)
This patch gets me to a prompt on dom0 x86_64. Its probably not the perfect solution, but the hypercall interface is under discussion anyway. Should be pretty self explanitory--l?e_create_phys is expecting flag bits in the scruntched format, and we were passing in the unscruntched format. sRp -- Scott Parish Signed-off-by: srparish@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel