On Fri, Jul 18, 2014 at 11:58 PM, Andrey Korolyov <andrey@xxxxxxx> wrote: > Hello, > > 2.0 model works fine > > 2.1 crashes with following: > > /tmp/buildd/qemu-2.0.92+rev1/hw/i386/smbios.c:825: smbios_get_tables: > Assertion `smbios_smp_sockets >= 1' failed > > Not sure if bisect will help much, but the commit which introduced > this platform works well (3458b2b0). > > arg set follows: > > /usr/bin/kvm -name vm28456 -S -machine pc-i440fx-2.1,accel=kvm,usb=off > -cpu qemu32 -m 256 -realtime mlock=off -smp > 1,sockets=1,cores=12,threads=12 -numa node,nodeid=0,cpus=0,mem=256 > -uuid 46623576-d00b-42b4-b1cc-c5c780a8b5b3 -nographic -no-user-config > -nodefaults -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/vm28456.monitor,server,nowait > -mon chardev=charmonitor,id=monitor,mode=control -rtc > base=utc,clock=vm,driftfix=slew -global > kvm-pit.lost_tick_policy=discard -no-shutdown -boot strict=on -device > piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device > virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive > file=rbd:dev-rack2/vm28456-YoP:id=qemukvm:key=XXXXXX:auth_supported=cephx\;none:mon_host=10.6.0.1\:6789\;10.6.0.3\:6789\;10.6.0.4\:6789,if=none,id=drive-virtio-disk0,format=raw,cache=writeback > -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 > -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device > virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:10:03:a8,bus=pci.0,addr=0x3 > -netdev tap,fd=25,id=hostnet1,vhost=on,vhostfd=26 -device > virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:10:03:a9,bus=pci.0,addr=0x4 > -chardev pty,id=charserial0 -device > isa-serial,chardev=charserial0,id=serial0 -chardev > socket,id=charchannel0,path=/var/lib/libvirt/qemu/vm28456.sock,server,nowait > -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.1 Nevermind, that was a result from wrong config generation (1 vcpu and 12 topology cores in the config, probably libvirt folks may be interested for checking this because libvirt allows such configuration for now). _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
