2.6.17-1.2439.fc6xen x86-64 xen-3.0.2-18 x86-64 xenguest-install.py tracebacks. `xm dmesg` shows a fault. 100% reproducible on at least affected system. [xenguest-install.py traceback] -(root@et-5:pts/0)-(0 jobs)-(349:41)-(Mon Jul 24:15:59:48)- -(~:$)-> xenguest-install.py -n test8 -f /root/test8.img -s 20 -r 1024 -p -l nfs:curly.devel.redhat.com:/vol/engineering/devarchive/redhat/nightly/rawhide-20060724/development/x86_64/os Starting install... libvir: Xen Daemon error : GET operation failed: No such domain test8 Traceback (most recent call last): File "/usr/sbin/xenguest-install.py", line 475, in ? main() File "/usr/sbin/xenguest-install.py", line 466, in main start_paravirt_install(name, ram, disk, mac, uuid, bridge, src, options.extra) File "/usr/sbin/xenguest-install.py", line 343, in start_paravirt_install dom = conn.createLinux(cfgxml, 0) File "/usr/lib64/python2.4/site-packages/libvirt.py", line 233, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed') libvirt.libvirtError: virDomainCreateLinux() failed [tail of xm dmesg output] (XEN) Dom0 has maximum 16 VCPUs (XEN) Initrd len 0x35c600, start at 0xffffffff805fe000 (XEN) Scrubbing Free RAM: .......................................................................................................done. (XEN) Xen trace buffers: disabled (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen). (XEN) (file=irq.c, line=459) Cannot bind IRQ 2 to guest. In use by 'cascade'. (XEN) (file=irq.c, line=459) Cannot bind IRQ 2 to guest. In use by 'cascade'. (XEN) domain_crash_sync called from entry.S (XEN) Domain 2 (vcpu#0) crashed on cpu#14: (XEN) ----[ Xen-3.0-unstable Not tainted ]---- (XEN) CPU: 14 (XEN) RIP: e033:[<ffffffff80200000>] (XEN) RFLAGS: 0000000000010202 CONTEXT: guest (XEN) rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) rdx: 0000000000000000 rsi: ffffffff80ec3000 rdi: 0000000000000000 (XEN) rbp: 0000000000000000 rsp: ffffffff80ed2000 r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 000000008005003b cr3: 00000001d95d4000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=ffffffff80ed2000: (XEN) Fault while accessing guest memory.
Also, selinux disabled at boot with selinux=0
2.6.17-1.2449.fc6xen behaves similar, with the difference that the output in xm dmesg differs slightly (stack empty): (XEN) domain_crash_sync called from entry.S (XEN) Domain 1 (vcpu#0) crashed on cpu#15: (XEN) ----[ Xen-3.0-unstable Not tainted ]---- (XEN) CPU: 15 (XEN) RIP: e033:[<ffffffff80200000>] (XEN) RFLAGS: 0000000000010202 CONTEXT: guest (XEN) rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) rdx: 0000000000000000 rsi: ffffffff80ec5000 rdi: 0000000000000000 (XEN) rbp: 0000000000000000 rsp: ffffffff80ed4000 r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 000000008005003b cr3: 00000001defd5000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=ffffffff80ed4000: (XEN) Stack empty.
Putting on the xen beta blocker list. Seems similar to bug 200126 comment 1. Note that this bug occurs on paravirt.
It's all guests -- the crash is before there's really a difference between FV and PV.
*** Bug 200126 has been marked as a duplicate of this bug. ***
On i686 I see the xenguest-install.py traceback (identical), but nothing new in `xm dmesg` output.
2.6.17-1.2454.fc6xen behaves identically.
The i686 guest creation crash is bug 200125. And there was output when we were building the HV with debug=y. Of course, I only realized that after I hacked libxenguest into itty bitty pieces :/
As a data point, I can start domains just fine on x86-64 with kernel 2.6.17-1.2157_FC5xen0.
It looks to be that linux-2.6-mm-tracking-dirty-pages.patch is causing the dom0 kernel to map the guests pages without VM_WRITE. This, in turn, is causing the guest to fault on its first instruction
Created attachment 133139 [details] linux-2.6-xenguest-no-writenotify.patch Probably incorrect patch ... Basic idea, though, is to catch these mappings in vma_wants_writenotify() using the flags added by privcmd_mmap()
With 2.6.17-1.2461.fc6xen, this works again for me. --> MODIFIED. bbrock -- when you verify, can you close?
Verified in rawhide-20060731 with 2.6.17-1.2478.fc6xen and xen-3.0.2-22 install progresses to lang selection with similar xenguest-install.py command. `xm dmesg` doesn't show the fault listed above at that point closing rawhide