* Test result of xen-unstable changeset 25259 @ 2012-05-07 14:12 Fantu 2012-05-08 12:38 ` Ian Campbell 0 siblings, 1 reply; 13+ messages in thread From: Fantu @ 2012-05-07 14:12 UTC (permalink / raw) To: xen-devel Dom0: Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and usb redirection. ------------------------- /etc/modules ------------ loop max_loop=64 xenfs xen-evtchn blktap ------------------------- hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is 25259:0f53540494f7) vi Makefile # removed dist-kernel to not compile kernel vi Config.mk # test seabios unstable PYTHON_PREFIX_ARG = QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git #commit 8f473dd104f0937ce98523fa6f9de0bd845aebbe SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git #commit 74f96123e7e37c219403b50e39dabc8e8c450948 SEABIOS_UPSTREAM_TAG ?= master ------------------------- Added some patches: - autoconf: add variable for pass arbitrary options to qemu upstream v3 - tools: Improve make deb ------------------------- ./configure --enable-qemuu-spice --enable-qemuu-usbredir --enable-qemuu-debug ------------------------- make deb ------------------------- Recent regression: ------------- - CRITICAL - PV domU unable to start: With pygrub: xl create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader: -3 With pv-grub: xl create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel Daemon running with PID 6136 Same error also with other linux pv domU. ------------------------- ------------------------- Old issue: - Save/restore not working with qemu-xen ------------- - Unable to get QXL vga working correctly and with full videoram ------------- - On hvm domU start, domU work also this output on xl create: libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of range, valid values are within range from 1 to 65535 ------------------------- -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153.html Sent from the Xen - Dev mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test result of xen-unstable changeset 25259 2012-05-07 14:12 Test result of xen-unstable changeset 25259 Fantu @ 2012-05-08 12:38 ` Ian Campbell 2012-05-08 13:22 ` Fantu 0 siblings, 1 reply; 13+ messages in thread From: Ian Campbell @ 2012-05-08 12:38 UTC (permalink / raw) To: Fantu; +Cc: xen-devel@lists.xensource.com On Mon, 2012-05-07 at 15:12 +0100, Fantu wrote: > Dom0: > Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version > 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and > usb redirection. > ------------------------- > /etc/modules > ------------ > loop max_loop=64 > xenfs > xen-evtchn > blktap > ------------------------- > hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is > 25259:0f53540494f7) > vi Makefile # removed dist-kernel to not compile kernel This should not be necessary at all. No kernel will be built, if you are seeing kernels getting built in the default configuration then please let me know. > vi Config.mk # test seabios unstable I don't think this will have any impact on any of the issues you relate below. But also note that results with SeaBIOS other than the one referenced by the tree would not be considered problems for Xen 4.2. > PYTHON_PREFIX_ARG = > QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git #commit > 8f473dd104f0937ce98523fa6f9de0bd845aebbe > SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git #commit > 74f96123e7e37c219403b50e39dabc8e8c450948 > SEABIOS_UPSTREAM_TAG ?= master > ------------------------- > Added some patches: > - autoconf: add variable for pass arbitrary options to qemu upstream v3 > - tools: Improve make deb > ------------------------- > ./configure --enable-qemuu-spice --enable-qemuu-usbredir > --enable-qemuu-debug > ------------------------- > make deb > > ------------------------- > Recent regression: > ------------- > - CRITICAL - PV domU unable to start: > With pygrub: > xl create /etc/xen/lucid.cfg > Parsing config file /etc/xen/lucid.cfg > libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader: > -3 > With pv-grub: > xl create /etc/xen/lucid.cfg > Parsing config file /etc/xen/lucid.cfg > xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: > kernel is not a bzImage: Invalid kernel > Daemon running with PID 6136 > Same error also with other linux pv domU. When we went through this on you last posting this seemed to be related to the python path stuff on Ubuntu/Debian. However you don't mention tweaking that in your setup -- are you sure you have corrected this issue? If this isn't the issue then please can you provide (separately) full logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases. > ------------------------- > > ------------------------- > Old issue: > - Save/restore not working with qemu-xen This is expected -- this support is not yet added to the tree. > ------------- > - Unable to get QXL vga working correctly and with full videoram I think we have now established that this is not currently a feature of Xen. If you or Zhou Peng are interested in doing the development work for then this is something we would likely accept as a new feature for Xen 4.3. It's not 4.2 material though. > ------------- > - On hvm domU start, domU work also this output on xl create: > libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of > range, valid values are within range from 1 to 65535 I have added this one to the TODO list as a bug, hopefully someone is looking into it. Ian. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test result of xen-unstable changeset 25259 2012-05-08 12:38 ` Ian Campbell @ 2012-05-08 13:22 ` Fantu 2012-05-08 13:30 ` Ian Campbell 0 siblings, 1 reply; 13+ messages in thread From: Fantu @ 2012-05-08 13:22 UTC (permalink / raw) To: xen-devel Ian Campbell-10 wrote > > When we went through this on you last posting this seemed to be related > to the python path stuff on Ubuntu/Debian. However you don't mention > tweaking that in your setup -- are you sure you have corrected this > issue? > > If this isn't the issue then please can you provide (separately) full > logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases. > "PYTHON_PREFIX_ARG =" in Config.mk solves python error on pygrub but not domU pv boot error. -------------------------------------- lucid.cfg -------- name="lucid" vcpus=2 memory=512 disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw', '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw'] vif=['bridge=xenbr0'] vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] bootloader = '/usr/bin/pygrub' #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" #extra = "(hd0,0)/grub/grub.cfg" -------------------------------------- With pygrub: -------------------------------------- xl -vvv create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda1, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda2, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=tap libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap) libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader: -3 xc: debug: hypercall buffer: total allocations:13 total releases:13 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:10 misses:2 toobig:1 ------------------------------- xl-lucid.log seems not to be created during this xl create -------------------------------------- With pv-grub: -------------------------------------- xl -vvv create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda1, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda2, using backend tap domainbuilder: detail: xc_dom_allocate: cmdline="(hd0,0)/grub/grub.cfg", features="(null)" domainbuilder: detail: xc_dom_kernel_file: filename="/usr/lib/xen/boot/pv-grub-x86_64.gz" domainbuilder: detail: xc_dom_malloc_filemap : 978 kB domainbuilder: detail: xc_dom_malloc : 14277 kB domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0xf4ac6 -> 0xdf17c6 domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, 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 domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe OK xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 xc: detail: elf_xen_parse: __xen_guest: "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" xc: detail: elf_xen_parse_guest_info: LOADER="generic" xc: detail: elf_xen_addr_calc_check: addresses: xc: detail: virt_base = 0x0 xc: detail: elf_paddr_offset = 0x0 xc: detail: virt_offset = 0x0 xc: detail: virt_kstart = 0x0 xc: detail: virt_kend = 0x99ef00 xc: detail: virt_entry = 0x0 xc: detail: p2m_base = 0xffffffffffffffff domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> 0x99ef00 domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x20000 pages domainbuilder: detail: xc_dom_boot_mem_init: called domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64 domainbuilder: detail: xc_dom_malloc : 1024 kB domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x0 -> 0x99f000 (pfn 0x0 + 0x99f pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x99f at 0x7f6a04b45000 xc: detail: elf_load_binary: phdr 0 at 0x0x7f6a04b45000 -> 0x0x7f6a054e3f00 domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0x99f000 -> 0xa9f000 (pfn 0x99f + 0x100 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x99f+0x100 at 0x7f6a04a45000 domainbuilder: detail: xc_dom_alloc_page : start info : 0xa9f000 (pfn 0xa9f) domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xaa0000 (pfn 0xaa0) domainbuilder: detail: xc_dom_alloc_page : console : 0xaa1000 (pfn 0xaa1) domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x0000000000000000 -> 0x000000003fffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s) domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xaa2000 -> 0xaab000 (pfn 0xaa2 + 0x9 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa2+0x9 at 0x7f6a04a3c000 domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xaab000 (pfn 0xaab) domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xaac000 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc00000 domainbuilder: detail: xc_dom_boot_image: called domainbuilder: detail: arch_setup_bootearly: doing nothing domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 <= matches domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64 domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x20000 domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x33f1c8 domainbuilder: detail: clear_page: pfn 0xaa0, mfn 0x33f1c9 domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa9f+0x1 at 0x7f6a04a3b000 domainbuilder: detail: start_info_x86_64: called domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2 domainbuilder: detail: domain builder memory footprint domainbuilder: detail: allocated domainbuilder: detail: malloc : 15368 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder: detail: mapped domainbuilder: detail: file mmap : 978 kB domainbuilder: detail: domU mmap : 10916 kB domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xbf111 domainbuilder: detail: shared_info_x86_64: called domainbuilder: detail: vcpu_x86_64: called domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa2 mfn 0x33f1c7 domainbuilder: detail: launch_vm: called, ctxt=0x7fff4b0bd640 domainbuilder: detail: xc_dom_release: called libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=tap libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: libxl: debug: libxl_dm.c:989:libxl__create_device_model: /usr/lib/xen/bin/qemu-system-i386 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-domid libxl: debug: libxl_dm.c:989:libxl__create_device_model: 21 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -chardev libxl: debug: libxl_dm.c:989:libxl__create_device_model: socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-21,server,nowait libxl: debug: libxl_dm.c:989:libxl__create_device_model: -mon libxl: debug: libxl_dm.c:989:libxl__create_device_model: chardev=libxl-cmd,mode=control libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-attach libxl: debug: libxl_dm.c:989:libxl__create_device_model: -name libxl: debug: libxl_dm.c:989:libxl__create_device_model: lucid libxl: debug: libxl_dm.c:989:libxl__create_device_model: -vnc libxl: debug: libxl_dm.c:989:libxl__create_device_model: 0.0.0.0:0,to=99 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -k libxl: debug: libxl_dm.c:989:libxl__create_device_model: it libxl: debug: libxl_dm.c:989:libxl__create_device_model: -M libxl: debug: libxl_dm.c:989:libxl__create_device_model: xenpv libxl: debug: libxl_dm.c:989:libxl__create_device_model: -m libxl: debug: libxl_dm.c:989:libxl__create_device_model: 513 libxl: debug: libxl_qmp.c:692:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-21 libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: qmp libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"qmp_capabilities","id":1}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-chardev","id":2}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-vnc","id":3}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return Daemon running with PID 9230 xc: debug: hypercall buffer: total allocations:154 total releases:154 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:149 misses:2 toobig:3 ------------------------------- /var/log/xen/xl-lucid.log ----------------------- Waiting for domain lucid (domid 21) to die [pid 9231] libxl: debug: libxl_event.c:406:watchfd_callback: watch event: epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x1bd0818 libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x1bcd920:21] from domid=21 nentries=1 rc=1 libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x1bcd920:21] got=domaininfos[0] got->domain=21 libxl: debug: libxl.c:844:domain_death_xswatch_callback: exists shutdown_reported=0 dominf.flags=ffff0020 libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all reported libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search done libxl: debug: libxl_event.c:406:watchfd_callback: watch event: epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x1bd0818 libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x1bcd920:21] from domid=21 nentries=1 rc=0 libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x1bcd920:21] got=domaininfos[0] got->domain=-1 libxl: debug: libxl.c:761:domain_death_occurred: empty list libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all reported libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search done Domain 21 has been destroyed. -------------------------------------- -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5694297.html Sent from the Xen - Dev mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test result of xen-unstable changeset 25259 2012-05-08 13:22 ` Fantu @ 2012-05-08 13:30 ` Ian Campbell 2012-05-08 13:38 ` Fantu 0 siblings, 1 reply; 13+ messages in thread From: Ian Campbell @ 2012-05-08 13:30 UTC (permalink / raw) To: Fantu; +Cc: xen-devel@lists.xensource.com On Tue, 2012-05-08 at 14:22 +0100, Fantu wrote: > Ian Campbell-10 wrote > > > > When we went through this on you last posting this seemed to be related > > to the python path stuff on Ubuntu/Debian. However you don't mention > > tweaking that in your setup -- are you sure you have corrected this > > issue? > > > > If this isn't the issue then please can you provide (separately) full > > logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases. > > > "PYTHON_PREFIX_ARG =" in Config.mk solves python error on pygrub but not > domU pv boot error. Your logs seem to show the opposite -- pygrub still fails by pvgrub works ok. > -------------------------------------- > lucid.cfg > -------- > name="lucid" > vcpus=2 > memory=512 > disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw', > '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw'] > vif=['bridge=xenbr0'] > vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] > bootloader = '/usr/bin/pygrub' > #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" > #extra = "(hd0,0)/grub/grub.cfg" > -------------------------------------- > > With pygrub: > -------------------------------------- > xl -vvv create /etc/xen/lucid.cfg > Parsing config file /etc/xen/lucid.cfg > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda1, using backend tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda2 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda2, using backend tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=tap > libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching > tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap) > libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader: > -3 Do you still get the same error about xen.lowlevel.xc as before if you run pygrub /mnt/vm/disks/lucid.disk1.xm by hand? Ian. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test result of xen-unstable changeset 25259 2012-05-08 13:30 ` Ian Campbell @ 2012-05-08 13:38 ` Fantu 2012-05-08 13:45 ` Ian Campbell 0 siblings, 1 reply; 13+ messages in thread From: Fantu @ 2012-05-08 13:38 UTC (permalink / raw) To: xen-devel Ian Campbell-10 wrote > > On Tue, 2012-05-08 at 14:22 +0100, Fantu wrote: >> Ian Campbell-10 wrote >> > >> > When we went through this on you last posting this seemed to be related >> > to the python path stuff on Ubuntu/Debian. However you don't mention >> > tweaking that in your setup -- are you sure you have corrected this >> > issue? >> > >> > If this isn't the issue then please can you provide (separately) full >> > logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases. >> > >> "PYTHON_PREFIX_ARG =" in Config.mk solves python error on pygrub but not >> domU pv boot error. > > Your logs seem to show the opposite -- pygrub still fails by pvgrub > works ok. > >> -------------------------------------- >> lucid.cfg >> -------- >> name="lucid" >> vcpus=2 >> memory=512 >> disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw', >> '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw'] >> vif=['bridge=xenbr0'] >> vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] >> bootloader = '/usr/bin/pygrub' >> #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" >> #extra = "(hd0,0)/grub/grub.cfg" >> -------------------------------------- >> >> With pygrub: >> -------------------------------------- >> xl -vvv create /etc/xen/lucid.cfg >> Parsing config file /etc/xen/lucid.cfg >> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk >> vdev=xvda1 spec.backend=unknown >> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, >> backend >> phy unsuitable as phys path not a block device >> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk >> vdev=xvda1, using backend tap >> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk >> vdev=xvda2 spec.backend=unknown >> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, >> backend >> phy unsuitable as phys path not a block device >> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk >> vdev=xvda2, using backend tap >> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk >> vdev=xvda1 spec.backend=tap >> libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally >> attaching >> tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap) >> libxl: error: libxl_create.c:603:do_domain_create: failed to run >> bootloader: >> -3 > > Do you still get the same error about xen.lowlevel.xc as before if you > run > pygrub /mnt/vm/disks/lucid.disk1.xm > by hand? > > Ian. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@.xen > http://lists.xen.org/xen-devel > --------------------------------------------- pygrub /mnt/vm/disks/lucid.disk1.xm Traceback (most recent call last): File "/usr/local/bin/pygrub", line 822, in <module> raise RuntimeError, "Unable to find partition containing kernel" RuntimeError: Unable to find partition containing kernel --------------------------------------------- About pv-grub I think it fails with: ... (from xl create...) xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel ... And after seems start as hvm domU but is not working and I must destroy it. -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5694426.html Sent from the Xen - Dev mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test result of xen-unstable changeset 25259 2012-05-08 13:38 ` Fantu @ 2012-05-08 13:45 ` Ian Campbell 2012-05-08 13:54 ` Fantu 2012-05-08 14:01 ` Ian Campbell 0 siblings, 2 replies; 13+ messages in thread From: Ian Campbell @ 2012-05-08 13:45 UTC (permalink / raw) To: Fantu; +Cc: xen-devel@lists.xensource.com On Tue, 2012-05-08 at 14:38 +0100, Fantu wrote: > --------------------------------------------- > pygrub /mnt/vm/disks/lucid.disk1.xm > Traceback (most recent call last): > File "/usr/local/bin/pygrub", line 822, in <module> > raise RuntimeError, "Unable to find partition containing kernel" > RuntimeError: Unable to find partition containing kernel /usr/local/bin? Are you sure this is the pygrub you built and installed just now and not some other cruft? Are you able to identify when it last worked and run a bisect? You don't need to do a full boot of the guest, just run pygrub manually at each stage. > --------------------------------------------- > > About pv-grub I think it fails with: > ... (from xl create...) > xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: > kernel is not a bzImage: Invalid kernel > ... > And after seems start as hvm domU but is not working and I must destroy it. I think this is just a warning (which needs to be toned down), since the pvgrub kernel isn't a bzImage, it's a simple elf file. Your logs show it building a Mini-OS domain, not an HVM one: domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe OK xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 xc: detail: elf_xen_parse: __xen_guest: "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" xc: detail: elf_xen_parse_guest_info: LOADER="generic" xc: detail: elf_xen_addr_calc_check: addresses: xc: detail: virt_base = 0x0 xc: detail: elf_paddr_offset = 0x0 xc: detail: virt_offset = 0x0 xc: detail: virt_kstart = 0x0 xc: detail: virt_kend = 0x99ef00 xc: detail: virt_entry = 0x0 xc: detail: p2m_base = 0xffffffffffffffff I think if you investigate more closely you would find it is working, at least as far as building an running something.. Ian ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test result of xen-unstable changeset 25259 2012-05-08 13:45 ` Ian Campbell @ 2012-05-08 13:54 ` Fantu 2012-05-08 14:21 ` Ian Campbell 2012-05-08 14:01 ` Ian Campbell 1 sibling, 1 reply; 13+ messages in thread From: Fantu @ 2012-05-08 13:54 UTC (permalink / raw) To: xen-devel Ian Campbell-10 wrote > > Your logs show it building a Mini-OS domain, not an HVM one: > domainbuilder: detail: xc_dom_find_loader: trying ELF-generic > loader ... > domainbuilder: detail: loader probe OK > xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 > xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 > xc: detail: elf_xen_parse: __xen_guest: > > "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" > xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" > xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" > xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" > xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" > xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" > xc: detail: elf_xen_parse_guest_info: LOADER="generic" > xc: detail: elf_xen_addr_calc_check: addresses: > xc: detail: virt_base = 0x0 > xc: detail: elf_paddr_offset = 0x0 > xc: detail: virt_offset = 0x0 > xc: detail: virt_kstart = 0x0 > xc: detail: virt_kend = 0x99ef00 > xc: detail: virt_entry = 0x0 > xc: detail: p2m_base = 0xffffffffffffffff > > I think if you investigate more closely you would find it is working, at > least as far as building an running something.. > Please try to see further in the xl create output on pv-grub test... ... libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: libxl: debug: libxl_dm.c:989:libxl__create_device_model: /usr/lib/xen/bin/qemu-system-i386 ... Is it right? -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5694597.html Sent from the Xen - Dev mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test result of xen-unstable changeset 25259 2012-05-08 13:54 ` Fantu @ 2012-05-08 14:21 ` Ian Campbell 0 siblings, 0 replies; 13+ messages in thread From: Ian Campbell @ 2012-05-08 14:21 UTC (permalink / raw) To: Fantu; +Cc: xen-devel@lists.xensource.com [...] > Please try to see further in the xl create output on pv-grub test... > ... > libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning > device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: > libxl: debug: libxl_dm.c:989:libxl__create_device_model: > /usr/lib/xen/bin/qemu-system-i386 > ... > Is it right? It's not inherently wrong. A PV guest can end up with a qemu service process to provide backends, like disk or VNC etc. So the presence of a qemu does not necessarily imply an HVM guest. Ian. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test result of xen-unstable changeset 25259 2012-05-08 13:45 ` Ian Campbell 2012-05-08 13:54 ` Fantu @ 2012-05-08 14:01 ` Ian Campbell 2012-05-09 9:21 ` Fantu 2012-05-09 13:35 ` Ian Jackson 1 sibling, 2 replies; 13+ messages in thread From: Ian Campbell @ 2012-05-08 14:01 UTC (permalink / raw) To: Fantu, Ian Jackson; +Cc: xen-devel@lists.xensource.com > > About pv-grub I think it fails with: > > ... (from xl create...) > > xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: > > kernel is not a bzImage: Invalid kernel > > ... > > And after seems start as hvm domU but is not working and I must destroy it. > > I think this is just a warning (which needs to be toned down), since the > pvgrub kernel isn't a bzImage, it's a simple elf file. # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1336485612 -3600 # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b # Parent 2fe12fc7bf1f863487920e06589641904b3d9466 libxc: do not "panic" if a kernel is not a bzImage. Up untul the point where we think this is a bzImage there is no point in printing panicy messages -- some other loader will have a go (probably the compressed ELF one) Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c --- a/tools/libxc/xc_dom_bzimageloader.c Tue May 08 14:25:27 2012 +0100 +++ b/tools/libxc/xc_dom_bzimageloader.c Tue May 08 15:00:12 2012 +0100 @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s if ( dom->kernel_size < sizeof(struct setup_header) ) { - xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, - "%s: kernel image too small", __FUNCTION__); + xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__); return -EINVAL; } @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 ) { - xc_dom_panic(dom->xch, XC_INVALID_KERNEL, - "%s: kernel is not a bzImage", __FUNCTION__); + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__); return -EINVAL; } ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test result of xen-unstable changeset 25259 2012-05-08 14:01 ` Ian Campbell @ 2012-05-09 9:21 ` Fantu 2012-05-09 9:32 ` Ian Campbell 2012-05-09 13:35 ` Ian Jackson 1 sibling, 1 reply; 13+ messages in thread From: Fantu @ 2012-05-09 9:21 UTC (permalink / raw) To: xen-devel Ian Campbell-10 wrote > >> > About pv-grub I think it fails with: >> > ... (from xl create...) >> > xc: error: panic: xc_dom_bzimageloader.c:588: >> xc_dom_probe_bzimage_kernel: >> > kernel is not a bzImage: Invalid kernel >> > ... >> > And after seems start as hvm domU but is not working and I must destroy >> it. >> >> I think this is just a warning (which needs to be toned down), since the >> pvgrub kernel isn't a bzImage, it's a simple elf file. > > # HG changeset patch > # User Ian Campbell <ian.campbell@> > # Date 1336485612 -3600 > # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b > # Parent 2fe12fc7bf1f863487920e06589641904b3d9466 > libxc: do not "panic" if a kernel is not a bzImage. > > Up untul the point where we think this is a bzImage there is no point in > printing panicy messages -- some other loader will have a go (probably the > compressed ELF one) > > Signed-off-by: Ian Campbell <ian.campbell@> > > diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c > --- a/tools/libxc/xc_dom_bzimageloader.c Tue May 08 14:25:27 2012 +0100 > +++ b/tools/libxc/xc_dom_bzimageloader.c Tue May 08 15:00:12 2012 +0100 > @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s > > if ( dom->kernel_size < sizeof(struct setup_header) ) > { > - xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, > - "%s: kernel image too small", __FUNCTION__); > + xc_dom_printf(dom->xch, "%s: kernel image too small", > __FUNCTION__); > return -EINVAL; > } > > @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s > > if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 ) > { > - xc_dom_panic(dom->xch, XC_INVALID_KERNEL, > - "%s: kernel is not a bzImage", __FUNCTION__); > + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", > __FUNCTION__); > return -EINVAL; > } > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@.xen > http://lists.xen.org/xen-devel > I rebuilt with this patch and on fully clean install on test server. With pygrub same result. With pv-grub: Vnc seems not to work (black screen), possible regression with qemu-xen as default for PV guest? Should I try to revert this (http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a095e157f280) on next build to make sure there aren't any bugs left on qemu-xen? With xl console I get the pv-grub "recovery mode", possible regression about disks? ----------------------------------- xl -vvv create /etc/xenlucid.cfg Parsing config file lucid.cfg libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda1, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda2, using backend tap domainbuilder: detail: xc_dom_allocate: cmdline="(hd0,0)/grub/grub.cfg", features="(null)" domainbuilder: detail: xc_dom_kernel_file: filename="/usr/lib/xen/boot/pv-grub-x86_64.gz" domainbuilder: detail: xc_dom_malloc_filemap : 978 kB domainbuilder: detail: xc_dom_malloc : 14274 kB domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0xf4abe -> 0xdf08ce domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, 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 domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe OK xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 xc: detail: elf_xen_parse: __xen_guest: "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" xc: detail: elf_xen_parse_guest_info: LOADER="generic" xc: detail: elf_xen_addr_calc_check: addresses: xc: detail: virt_base = 0x0 xc: detail: elf_paddr_offset = 0x0 xc: detail: virt_offset = 0x0 xc: detail: virt_kstart = 0x0 xc: detail: virt_kend = 0x99ef00 xc: detail: virt_entry = 0x0 xc: detail: p2m_base = 0xffffffffffffffff domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> 0x99ef00 domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x20000 pages domainbuilder: detail: xc_dom_boot_mem_init: called domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64 domainbuilder: detail: xc_dom_malloc : 1024 kB domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x0 -> 0x99f000 (pfn 0x0 + 0x99f pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x99f at 0x7fcf39dc4000 xc: detail: elf_load_binary: phdr 0 at 0x0x7fcf39dc4000 -> 0x0x7fcf3a762f00 domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0x99f000 -> 0xa9f000 (pfn 0x99f + 0x100 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x99f+0x100 at 0x7fcf39cc4000 domainbuilder: detail: xc_dom_alloc_page : start info : 0xa9f000 (pfn 0xa9f) domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xaa0000 (pfn 0xaa0) domainbuilder: detail: xc_dom_alloc_page : console : 0xaa1000 (pfn 0xaa1) domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x0000000000000000 -> 0x000000003fffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s) domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xaa2000 -> 0xaab000 (pfn 0xaa2 + 0x9 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa2+0x9 at 0x7fcf39cbb000 domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xaab000 (pfn 0xaab) domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xaac000 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc00000 domainbuilder: detail: xc_dom_boot_image: called domainbuilder: detail: arch_setup_bootearly: doing nothing domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 <= matches domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64 domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x20000 domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x41b9d0 domainbuilder: detail: clear_page: pfn 0xaa0, mfn 0x41b9d1 domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa9f+0x1 at 0x7fcf39cba000 domainbuilder: detail: start_info_x86_64: called domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2 domainbuilder: detail: domain builder memory footprint domainbuilder: detail: allocated domainbuilder: detail: malloc : 15364 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder: detail: mapped domainbuilder: detail: file mmap : 978 kB domainbuilder: detail: domU mmap : 10916 kB domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xcedda domainbuilder: detail: shared_info_x86_64: called domainbuilder: detail: vcpu_x86_64: called domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa2 mfn 0x41b9cf domainbuilder: detail: launch_vm: called, ctxt=0x7fffd27bcdf0 domainbuilder: detail: xc_dom_release: called libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=tap libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: libxl: debug: libxl_dm.c:989:libxl__create_device_model: /usr/lib/xen/bin/qemu-system-i386 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-domid libxl: debug: libxl_dm.c:989:libxl__create_device_model: 4 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -chardev libxl: debug: libxl_dm.c:989:libxl__create_device_model: socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-4,server,nowait libxl: debug: libxl_dm.c:989:libxl__create_device_model: -mon libxl: debug: libxl_dm.c:989:libxl__create_device_model: chardev=libxl-cmd,mode=control libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-attach libxl: debug: libxl_dm.c:989:libxl__create_device_model: -name libxl: debug: libxl_dm.c:989:libxl__create_device_model: lucid libxl: debug: libxl_dm.c:989:libxl__create_device_model: -vnc libxl: debug: libxl_dm.c:989:libxl__create_device_model: 0.0.0.0:0,to=99 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -k libxl: debug: libxl_dm.c:989:libxl__create_device_model: it libxl: debug: libxl_dm.c:989:libxl__create_device_model: -M libxl: debug: libxl_dm.c:989:libxl__create_device_model: xenpv libxl: debug: libxl_dm.c:989:libxl__create_device_model: -m libxl: debug: libxl_dm.c:989:libxl__create_device_model: 513 libxl: debug: libxl_qmp.c:692:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-4 libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: qmp libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"qmp_capabilities","id":1}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-chardev","id":2}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-vnc","id":3}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return Daemon running with PID 2616 xc: debug: hypercall buffer: total allocations:154 total releases:154 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:149 misses:2 toobig:3 -------------------------- xl-lucid.log ----------- libxl: debug: libxl_event.c:406:watchfd_callback: watch event: epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x7002a8 libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x6fbc90:4] from domid=4 nentries=1 rc=1 libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x6fbc90:4] got=domaininfos[0] got->domain=4 libxl: debug: libxl.c:844:domain_death_xswatch_callback: exists shutdown_reported=0 dominf.flags=ffff0020 libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all reported libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search done ----------------------------------- -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5696877.html Sent from the Xen - Dev mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test result of xen-unstable changeset 25259 2012-05-09 9:21 ` Fantu @ 2012-05-09 9:32 ` Ian Campbell 2012-05-09 9:51 ` Fantu 0 siblings, 1 reply; 13+ messages in thread From: Ian Campbell @ 2012-05-09 9:32 UTC (permalink / raw) To: Fantu, Stefano Stabellini; +Cc: xen-devel@lists.xensource.com On Wed, 2012-05-09 at 10:21 +0100, Fantu wrote: > Ian Campbell-10 wrote > > > >> > About pv-grub I think it fails with: > >> > ... (from xl create...) > >> > xc: error: panic: xc_dom_bzimageloader.c:588: > >> xc_dom_probe_bzimage_kernel: > >> > kernel is not a bzImage: Invalid kernel > >> > ... > >> > And after seems start as hvm domU but is not working and I must destroy > >> it. > >> > >> I think this is just a warning (which needs to be toned down), since the > >> pvgrub kernel isn't a bzImage, it's a simple elf file. > > > > # HG changeset patch > > # User Ian Campbell <ian.campbell@> > > # Date 1336485612 -3600 > > # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b > > # Parent 2fe12fc7bf1f863487920e06589641904b3d9466 > > libxc: do not "panic" if a kernel is not a bzImage. > > > > Up untul the point where we think this is a bzImage there is no point in > > printing panicy messages -- some other loader will have a go (probably the > > compressed ELF one) > > > > Signed-off-by: Ian Campbell <ian.campbell@> > > > > diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c > > --- a/tools/libxc/xc_dom_bzimageloader.c Tue May 08 14:25:27 2012 +0100 > > +++ b/tools/libxc/xc_dom_bzimageloader.c Tue May 08 15:00:12 2012 +0100 > > @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s > > > > if ( dom->kernel_size < sizeof(struct setup_header) ) > > { > > - xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, > > - "%s: kernel image too small", __FUNCTION__); > > + xc_dom_printf(dom->xch, "%s: kernel image too small", > > __FUNCTION__); > > return -EINVAL; > > } > > > > @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s > > > > if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 ) > > { > > - xc_dom_panic(dom->xch, XC_INVALID_KERNEL, > > - "%s: kernel is not a bzImage", __FUNCTION__); > > + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", > > __FUNCTION__); > > return -EINVAL; > > } > > > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@.xen > > http://lists.xen.org/xen-devel > > > I rebuilt with this patch and on fully clean install on test server. > > With pygrub same result. Can you bisect this please. > With pv-grub: > Vnc seems not to work (black screen), possible regression with qemu-xen as > default for PV guest? Should I try to revert this > (http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a095e157f280) on next > build to make sure there aren't any bugs left on qemu-xen? Yes please. Also setting "device_model_version" to qemu-xen-traditional should have the same overall effect as reverting. > With xl console I get the pv-grub "recovery mode", possible regression about > disks? > > ----------------------------------- > xl -vvv create /etc/xenlucid.cfg > Parsing config file lucid.cfg > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda1, using backend tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda2 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda2, using backend tap > domainbuilder: detail: xc_dom_allocate: cmdline="(hd0,0)/grub/grub.cfg", > features="(null)" > domainbuilder: detail: xc_dom_kernel_file: > filename="/usr/lib/xen/boot/pv-grub-x86_64.gz" > domainbuilder: detail: xc_dom_malloc_filemap : 978 kB > domainbuilder: detail: xc_dom_malloc : 14274 kB > domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0xf4abe -> 0xdf08ce > domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, 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 > domainbuilder: detail: xc_dom_parse_image: called > domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader > ... > domainbuilder: detail: loader probe failed > domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... > domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage > domainbuilder: detail: loader probe failed > domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... > domainbuilder: detail: loader probe OK > xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 > xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 > xc: detail: elf_xen_parse: __xen_guest: > "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" > xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" > xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" > xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" > xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" > xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" > xc: detail: elf_xen_parse_guest_info: LOADER="generic" > xc: detail: elf_xen_addr_calc_check: addresses: > xc: detail: virt_base = 0x0 > xc: detail: elf_paddr_offset = 0x0 > xc: detail: virt_offset = 0x0 > xc: detail: virt_kstart = 0x0 > xc: detail: virt_kend = 0x99ef00 > xc: detail: virt_entry = 0x0 > xc: detail: p2m_base = 0xffffffffffffffff > domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> > 0x99ef00 > domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k > each > domainbuilder: detail: xc_dom_mem_init: 0x20000 pages > domainbuilder: detail: xc_dom_boot_mem_init: called > domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64 > domainbuilder: detail: xc_dom_malloc : 1024 kB > domainbuilder: detail: xc_dom_build_image: called > domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x0 -> > 0x99f000 (pfn 0x0 + 0x99f pages) > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x99f at > 0x7fcf39dc4000 > xc: detail: elf_load_binary: phdr 0 at 0x0x7fcf39dc4000 -> 0x0x7fcf3a762f00 > domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0x99f000 -> > 0xa9f000 (pfn 0x99f + 0x100 pages) > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x99f+0x100 at > 0x7fcf39cc4000 > domainbuilder: detail: xc_dom_alloc_page : start info : 0xa9f000 (pfn > 0xa9f) > domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xaa0000 (pfn > 0xaa0) > domainbuilder: detail: xc_dom_alloc_page : console : 0xaa1000 (pfn > 0xaa1) > domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: > 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s) > domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: > 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s) > domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: > 0x0000000000000000 -> 0x000000003fffffff, 1 table(s) > domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: > 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s) > domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xaa2000 -> > 0xaab000 (pfn 0xaa2 + 0x9 pages) > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa2+0x9 at > 0x7fcf39cbb000 > domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xaab000 (pfn > 0xaab) > domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xaac000 > domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc00000 > domainbuilder: detail: xc_dom_boot_image: called > domainbuilder: detail: arch_setup_bootearly: doing nothing > domainbuilder: detail: xc_dom_compat_check: supported guest type: > xen-3.0-x86_64 <= matches > domainbuilder: detail: xc_dom_compat_check: supported guest type: > xen-3.0-x86_32p > domainbuilder: detail: xc_dom_compat_check: supported guest type: > hvm-3.0-x86_32 > domainbuilder: detail: xc_dom_compat_check: supported guest type: > hvm-3.0-x86_32p > domainbuilder: detail: xc_dom_compat_check: supported guest type: > hvm-3.0-x86_64 > domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x20000 > domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x41b9d0 > domainbuilder: detail: clear_page: pfn 0xaa0, mfn 0x41b9d1 > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa9f+0x1 at > 0x7fcf39cba000 > domainbuilder: detail: start_info_x86_64: called > domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2 > domainbuilder: detail: domain builder memory footprint > domainbuilder: detail: allocated > domainbuilder: detail: malloc : 15364 kB > domainbuilder: detail: anon mmap : 0 bytes > domainbuilder: detail: mapped > domainbuilder: detail: file mmap : 978 kB > domainbuilder: detail: domU mmap : 10916 kB > domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn > 0xcedda > domainbuilder: detail: shared_info_x86_64: called > domainbuilder: detail: vcpu_x86_64: called > domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa2 mfn 0x41b9cf > domainbuilder: detail: launch_vm: called, ctxt=0x7fffd27bcdf0 > domainbuilder: detail: xc_dom_release: called > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda2 spec.backend=tap > libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning > device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: > libxl: debug: libxl_dm.c:989:libxl__create_device_model: > /usr/lib/xen/bin/qemu-system-i386 > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-domid > libxl: debug: libxl_dm.c:989:libxl__create_device_model: 4 > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -chardev > libxl: debug: libxl_dm.c:989:libxl__create_device_model: > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-4,server,nowait > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -mon > libxl: debug: libxl_dm.c:989:libxl__create_device_model: > chardev=libxl-cmd,mode=control > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-attach > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -name > libxl: debug: libxl_dm.c:989:libxl__create_device_model: lucid > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -vnc > libxl: debug: libxl_dm.c:989:libxl__create_device_model: 0.0.0.0:0,to=99 > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -k > libxl: debug: libxl_dm.c:989:libxl__create_device_model: it > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -M > libxl: debug: libxl_dm.c:989:libxl__create_device_model: xenpv > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -m > libxl: debug: libxl_dm.c:989:libxl__create_device_model: 513 > libxl: debug: libxl_qmp.c:692:libxl__qmp_initialize: connected to > /var/run/xen/qmp-libxl-4 > libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: qmp > libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: > '{"execute":"qmp_capabilities","id":1}' > libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return > libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: > '{"execute":"query-chardev","id":2}' > libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return > libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: > '{"execute":"query-vnc","id":3}' > libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return > Daemon running with PID 2616 > xc: debug: hypercall buffer: total allocations:154 total releases:154 > xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 > xc: debug: hypercall buffer: cache current size:2 > xc: debug: hypercall buffer: cache hits:149 misses:2 toobig:3 > -------------------------- > xl-lucid.log > ----------- > libxl: debug: libxl_event.c:406:watchfd_callback: watch event: > epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x7002a8 > libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x6fbc90:4] > from domid=4 nentries=1 rc=1 > libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x6fbc90:4] > got=domaininfos[0] got->domain=4 > libxl: debug: libxl.c:844:domain_death_xswatch_callback: exists > shutdown_reported=0 dominf.flags=ffff0020 > libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all > reported > libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search > done > ----------------------------------- > > > -- > View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5696877.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test result of xen-unstable changeset 25259 2012-05-09 9:32 ` Ian Campbell @ 2012-05-09 9:51 ` Fantu 0 siblings, 0 replies; 13+ messages in thread From: Fantu @ 2012-05-09 9:51 UTC (permalink / raw) To: xen-devel Ian Campbell-10 wrote > > On Wed, 2012-05-09 at 10:21 +0100, Fantu wrote: >> Ian Campbell-10 wrote >> > >> >> > About pv-grub I think it fails with: >> >> > ... (from xl create...) >> >> > xc: error: panic: xc_dom_bzimageloader.c:588: >> >> xc_dom_probe_bzimage_kernel: >> >> > kernel is not a bzImage: Invalid kernel >> >> > ... >> >> > And after seems start as hvm domU but is not working and I must >> destroy >> >> it. >> >> >> >> I think this is just a warning (which needs to be toned down), since >> the >> >> pvgrub kernel isn't a bzImage, it's a simple elf file. >> > >> > # HG changeset patch >> > # User Ian Campbell <ian.campbell@> >> > # Date 1336485612 -3600 >> > # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b >> > # Parent 2fe12fc7bf1f863487920e06589641904b3d9466 >> > libxc: do not "panic" if a kernel is not a bzImage. >> > >> > Up untul the point where we think this is a bzImage there is no point >> in >> > printing panicy messages -- some other loader will have a go (probably >> the >> > compressed ELF one) >> > >> > Signed-off-by: Ian Campbell <ian.campbell@> >> > >> > diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c >> > --- a/tools/libxc/xc_dom_bzimageloader.c Tue May 08 14:25:27 2012 >> +0100 >> > +++ b/tools/libxc/xc_dom_bzimageloader.c Tue May 08 15:00:12 2012 >> +0100 >> > @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s >> > >> > if ( dom->kernel_size < sizeof(struct setup_header) ) >> > { >> > - xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, >> > - "%s: kernel image too small", __FUNCTION__); >> > + xc_dom_printf(dom->xch, "%s: kernel image too small", >> > __FUNCTION__); >> > return -EINVAL; >> > } >> > >> > @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s >> > >> > if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 ) >> > { >> > - xc_dom_panic(dom->xch, XC_INVALID_KERNEL, >> > - "%s: kernel is not a bzImage", __FUNCTION__); >> > + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", >> > __FUNCTION__); >> > return -EINVAL; >> > } >> > >> > >> > >> > >> > _______________________________________________ >> > Xen-devel mailing list >> > Xen-devel@.xen >> > http://lists.xen.org/xen-devel >> > >> I rebuilt with this patch and on fully clean install on test server. >> >> With pygrub same result. > > Can you bisect this please. > >> With pv-grub: >> Vnc seems not to work (black screen), possible regression with qemu-xen >> as >> default for PV guest? Should I try to revert this >> (http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a095e157f280) on >> next >> build to make sure there aren't any bugs left on qemu-xen? > > Yes please. > > Also setting "device_model_version" to qemu-xen-traditional should have > the same overall effect as reverting. > About bisect, I will do it. About qemu devices on pv I tried device_model_version="qemu-xen-traditional" but same problem on pygrub and pv-grub, it seems the problem is not about qemu-xen. -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5696949.html Sent from the Xen - Dev mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test result of xen-unstable changeset 25259 2012-05-08 14:01 ` Ian Campbell 2012-05-09 9:21 ` Fantu @ 2012-05-09 13:35 ` Ian Jackson 1 sibling, 0 replies; 13+ messages in thread From: Ian Jackson @ 2012-05-09 13:35 UTC (permalink / raw) To: Ian Campbell; +Cc: xen-devel@lists.xensource.com, Fantu Ian Campbell writes ("Re: [Xen-devel] Test result of xen-unstable changeset 25259"): > > libxc: do not "panic" if a kernel is not a bzImage. > > Up untul the point where we think this is a bzImage there is no point in > printing panicy messages -- some other loader will have a go (probably the > compressed ELF one) > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Looks plausible. Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-05-09 13:35 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-05-07 14:12 Test result of xen-unstable changeset 25259 Fantu 2012-05-08 12:38 ` Ian Campbell 2012-05-08 13:22 ` Fantu 2012-05-08 13:30 ` Ian Campbell 2012-05-08 13:38 ` Fantu 2012-05-08 13:45 ` Ian Campbell 2012-05-08 13:54 ` Fantu 2012-05-08 14:21 ` Ian Campbell 2012-05-08 14:01 ` Ian Campbell 2012-05-09 9:21 ` Fantu 2012-05-09 9:32 ` Ian Campbell 2012-05-09 9:51 ` Fantu 2012-05-09 13:35 ` Ian Jackson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).