On 11.06.2012 03:44, Gary Dale wrote: [] > Here's the qemu/ghoswheel64.log entries for the startup of the local copy: > > 2012-06-10 23:38:23.205+0000: starting up > LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin > HOME=/ QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 2048 -smp > 2,sockets=2,cores=1,threads=1 -name ghostwheel64 -uuid > 68bbcceb-f8c4-6a58-9a79-c50e177f8641 -nodefconfig -nodefaults -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/ghostwheel64.monitor,server,nowait > -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime > -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive > file=/var/lib/libvirt/images/ghostwheel64.img,if=none,id=drive-ide0-0-0,format=raw > -device > ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 > -netdev tap,fd=20,id=hostnet0 -device > rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:74:2f:af,bus=pci.0,addr=0x3 > -chardev > pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device > usb-tablet,id=input0 -vnc 127.0.0.1:1 -vga std -device > intel-hda,id=sound0,bus=pci.0,addr=0x4 -device > hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 > char device redirected to /dev/pts/4
Umm. That's what I was afraid of. Most important thing, cpu type, is not specified at all. And there, qemu-kvm gives some mix of a pseudo-cpu and real host cpu to the guest. Please try running your guest -- with -snapshot maybe -- with -cpu host and -cpu kvm64. It might be enough. One possible reason of this issue is that with the default pseudo-cpu, some extra CPUID levels which a bulldozer have gets exposed to the guest but should not. Also, you may try some specific cpu model, like -cpu phenom. > I'm confused by your statement about the physical WInXP. Granted, I can't > upgrade the mainboard and processor on a physical Windows computer without > Windows complaining but that's mainly a licensing issue. Once the proper > drivers are installed, it should work. I'm not talking about licensing issues - even if license is at problem, windows should at least start and display the license warning somehow. But in practice, it occured more than once when that wasn't possible. Maybe due to drivers - for example, once AMD CPUFREQ drivers are installed on windowsXP, this image can't be run on an Intel machine anymore, it will crash (BSOD) at boot. Sometimes the same happens when different chipset drivers are installed (so it looks like different drivers may not be compatible with each other). Ofcourse we don't have that case here, I'm just trying to say that things aren't always simple. And this is one of the reasons why I'd say installing a virtual machine afresh on bulldozer is the first thing to do in such a situation -- to determine if it does not work at all on bulldozer or only when installed on pre-bulldozer. > With a virtual machine, I thought the machine pretty much stayed the same > despite differences in the host architecture. If you explicitly specify devices, yes. But you didn't: you didn't specify the CPU. This makes a whole lot of a difference. And this is exactly why I asked for the command line (resulting, after your libvirt translation). Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
