Debian Bug report logs - #676950
qemu-kvm: Windows XP fails on Bulldozer CPUs

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Sun, 10 Jun 2012 14:01:33 -0400

Package: qemu-kvm
Version: 1.0+dfsg-11
Severity: important

Dear Maintainer,
   * What led up to the situation?
I have two working Windows XP/Pro VMs, one 32bit and one 64bit, that run 
fine on my older
Phenom II based machine. However, they run into all kinds of errors when 
I copy the img files
to my FX6100 based computer. Often Windows will fail to reach the login 
screen. If I do get
logged in, Windows hangs shortly afterward.

   * What exactly did you do (or not do) that was effective (or 
ineffective)?
Copying the img files back to a rebuilt Phenom II machine allowed them 
to run again. And I
can access them remotely from my FX6100 machine. However, the img files 
on my FX6100 still
fail to run preoperly locally.

   * What was the outcome of this action?
It appears that the img files are not compatible with the FX6100.

   * What outcome did you expect instead?
I expect the img files to run regardless of which AMD64 compatible 
processor hosts them.

*** End of the template - remove these lines ***


-- Package-specific info:


/proc/cpuinfo:

processor    : 0
vendor_id    : AuthenticAMD
cpu family    : 21
model        : 1
model name    : AMD FX(tm)-6100 Six-Core Processor
stepping    : 2
microcode    : 0x6000613
cpu MHz        : 1400.000
cache size    : 2048 KB
physical id    : 0
siblings    : 6
core id        : 0
cpu cores    : 3
apicid        : 16
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid 
aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes 
xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr 
topoext perfctr_core arat cpb npt lbrv svm_lock nrip_save tsc_scale 
vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bogomips    : 6630.13
TLB size    : 1536 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate [9]

processor    : 1
vendor_id    : AuthenticAMD
cpu family    : 21
model        : 1
model name    : AMD FX(tm)-6100 Six-Core Processor
stepping    : 2
microcode    : 0x6000613
cpu MHz        : 1400.000
cache size    : 2048 KB
physical id    : 0
siblings    : 6
core id        : 1
cpu cores    : 3
apicid        : 17
initial apicid    : 1
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid 
aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes 
xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr 
topoext perfctr_core arat cpb npt lbrv svm_lock nrip_save tsc_scale 
vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bogomips    : 6629.48
TLB size    : 1536 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate [9]

processor    : 2
vendor_id    : AuthenticAMD
cpu family    : 21
model        : 1
model name    : AMD FX(tm)-6100 Six-Core Processor
stepping    : 2
microcode    : 0x6000613
cpu MHz        : 1400.000
cache size    : 2048 KB
physical id    : 0
siblings    : 6
core id        : 2
cpu cores    : 3
apicid        : 18
initial apicid    : 2
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid 
aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes 
xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr 
topoext perfctr_core arat cpb npt lbrv svm_lock nrip_save tsc_scale 
vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bogomips    : 6629.53
TLB size    : 1536 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate [9]

processor    : 3
vendor_id    : AuthenticAMD
cpu family    : 21
model        : 1
model name    : AMD FX(tm)-6100 Six-Core Processor
stepping    : 2
microcode    : 0x6000613
cpu MHz        : 1400.000
cache size    : 2048 KB
physical id    : 0
siblings    : 6
core id        : 3
cpu cores    : 3
apicid        : 19
initial apicid    : 3
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid 
aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes 
xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr 
topoext perfctr_core arat cpb npt lbrv svm_lock nrip_save tsc_scale 
vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bogomips    : 6629.52
TLB size    : 1536 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate [9]

processor    : 4
vendor_id    : AuthenticAMD
cpu family    : 21
model        : 1
model name    : AMD FX(tm)-6100 Six-Core Processor
stepping    : 2
microcode    : 0x6000613
cpu MHz        : 1400.000
cache size    : 2048 KB
physical id    : 0
siblings    : 6
core id        : 4
cpu cores    : 3
apicid        : 20
initial apicid    : 4
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid 
aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes 
xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr 
topoext perfctr_core arat cpb npt lbrv svm_lock nrip_save tsc_scale 
vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bogomips    : 6629.55
TLB size    : 1536 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate [9]

processor    : 5
vendor_id    : AuthenticAMD
cpu family    : 21
model        : 1
model name    : AMD FX(tm)-6100 Six-Core Processor
stepping    : 2
microcode    : 0x6000613
cpu MHz        : 1400.000
cache size    : 2048 KB
physical id    : 0
siblings    : 6
core id        : 5
cpu cores    : 3
apicid        : 21
initial apicid    : 5
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid 
aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes 
xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr 
topoext perfctr_core arat cpb npt lbrv svm_lock nrip_save tsc_scale 
vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bogomips    : 6629.55
TLB size    : 1536 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate [9]




-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages qemu-kvm depends on:
ii  adduser           3.113+nmu3
ii  ipxe-qemu         1.0.0+git-20120202.f6840ba-3
ii  libaio1           0.3.109-2
ii  libasound2        1.0.25-3
ii  libbluetooth3     4.99-2
ii  libbrlapi0.5      4.3-2
ii  libc6             2.13-33
ii  libcurl3-gnutls   7.26.0-1
ii  libglib2.0-0      2.32.3-1
ii  libgnutls26       2.12.19-1
ii  libiscsi1         1.4.0-3
ii  libjpeg8          8d-1
ii  libncurses5       5.9-7
ii  libpng12-0        1.2.49-1
ii  libpulse0         2.0-3
ii  librados2         0.43-1
ii  librbd1           0.43-1
ii  libsasl2-2        2.1.25.dfsg1-4+b1
ii  libsdl1.2debian   1.2.15-3
ii  libspice-server1  0.10.1-2
ii  libtinfo5         5.9-7
ii  libuuid1          2.20.1-5
ii  libvdeplug2       2.3.2-4
ii  libx11-6          2:1.4.99.901-2
ii  python            2.7.2-10
ii  qemu-keymaps      1.0.1+dfsg-1
ii  qemu-utils        1.0.1+dfsg-1
ii  seabios           1.6.3-2
ii  vgabios           0.7a-2
ii  zlib1g            1:1.2.7.dfsg-11

Versions of packages qemu-kvm recommends:
ii  bridge-utils  1.5-3
ii  iproute       20120521-2

Versions of packages qemu-kvm suggests:
ii  debootstrap <none>
ii  samba <none>
ii  vde2         2.3.2-4

-- no debconf information

Message #10 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Gary Dale <gary@extremeground.com>, 676950@bugs.debian.org

Cc: Gary Dale <garydale@rogers.com>

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Sun, 10 Jun 2012 22:31:30 +0400

tags 676950 + unreproducible moreinfo
thanks

On 10.06.2012 22:01, Gary Dale wrote:
> Package: qemu-kvm
> Version: 1.0+dfsg-11
> Severity: important
> 
> Dear Maintainer,
>    * What led up to the situation?
> I have two working Windows XP/Pro VMs, one 32bit and one 64bit, that run fine on my older
> Phenom II based machine. However, they run into all kinds of errors when I copy the img files
> to my FX6100 based computer. Often Windows will fail to reach the login screen. If I do get
> logged in, Windows hangs shortly afterward.
> 
>    * What exactly did you do (or not do) that was effective (or ineffective)?
> Copying the img files back to a rebuilt Phenom II machine allowed them to run again. And I
> can access them remotely from my FX6100 machine. However, the img files on my FX6100 still
> fail to run preoperly locally.
> 
>    * What was the outcome of this action?
> It appears that the img files are not compatible with the FX6100.

Here virtual winXP runs just fine on a bulldozer cpu, I can run it on either
bulldozer, old turion (first-gen x2 64) or on a sandy bridge cpu -- the same
image.

So I need a way to reproduce this issue somehow.  At least, full command line
you use to start it.

/mjt

Message #17 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Sun, 10 Jun 2012 15:12:01 -0400

[Message part 1 (text/plain, inline)]

On 10/06/12 02:31 PM, Michael Tokarev wrote:
> tags 676950 + unreproducible moreinfo
> thanks
>
> On 10.06.2012 22:01, Gary Dale wrote:
>> Package: qemu-kvm
>> Version: 1.0+dfsg-11
>> Severity: important
>>
>> Dear Maintainer,
>>     * What led up to the situation?
>> I have two working Windows XP/Pro VMs, one 32bit and one 64bit, that run fine on my older
>> Phenom II based machine. However, they run into all kinds of errors when I copy the img files
>> to my FX6100 based computer. Often Windows will fail to reach the login screen. If I do get
>> logged in, Windows hangs shortly afterward.
>>
>>     * What exactly did you do (or not do) that was effective (or ineffective)?
>> Copying the img files back to a rebuilt Phenom II machine allowed them to run again. And I
>> can access them remotely from my FX6100 machine. However, the img files on my FX6100 still
>> fail to run preoperly locally.
>>
>>     * What was the outcome of this action?
>> It appears that the img files are not compatible with the FX6100.
> Here virtual winXP runs just fine on a bulldozer cpu, I can run it on either
> bulldozer, old turion (first-gen x2 64) or on a sandy bridge cpu -- the same
> image.
>
> So I need a way to reproduce this issue somehow.  At least, full command line
> you use to start it.
>
> /mjt
>
They're started with virt-mgr (see attached xml files).

The img was originally created using a Phenom II system. When I changed 
the main board and processor, it stopped running properly. When I built 
a new system using my old board & processor, I copied the img files to 
it and they worked fine. I can even access them remotely from my 
Bulldozer/FX6100 system. However, the local img files don't work 
directly on the Bulldozer system.

Note that the img files on the Phenom II system are copies of the ones 
that don't work on the Bulldozer/FX6100 system.

[ghostwheel32.xml (text/xml, attachment)]

Message #22 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Gary Dale <gary@extremeground.com>

Cc: Gary Dale <garydale@rogers.com>, 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Sun, 10 Jun 2012 23:43:29 +0400

On 10.06.2012 23:12, Gary Dale wrote:
> On 10/06/12 02:31 PM, Michael Tokarev wrote:
[]
>> So I need a way to reproduce this issue somehow.  At least, full command line
>> you use to start it.

> They're started with virt-mgr (see attached xml files).

Please read again what I asked for.  Qemu-kvm COMMAND LINE please.

Also, please perform another winXP installation on the new
hardware (on bulldozer) and check if that one will work.
I think this is the very obvious thing to try, even before
submitting such a bugreport.

Please note that the bulldozer system I mentioned in the
previous email wasn't mine, but I ran my virtual winXP in
there just in order to run symantec partition magic to
resize win7 partitions in there.  I'm unsure I will have
access to it in a reasonable future.

Thank you.

/mjt

Message #27 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Sun, 10 Jun 2012 16:15:56 -0400

On 10/06/12 03:43 PM, Michael Tokarev wrote:
> On 10.06.2012 23:12, Gary Dale wrote:
>> On 10/06/12 02:31 PM, Michael Tokarev wrote:
> []
>>> So I need a way to reproduce this issue somehow.  At least, full command line
>>> you use to start it.
>> They're started with virt-mgr (see attached xml files).
> Please read again what I asked for.  Qemu-kvm COMMAND LINE please.
>
> Also, please perform another winXP installation on the new
> hardware (on bulldozer) and check if that one will work.
> I think this is the very obvious thing to try, even before
> submitting such a bugreport.
>
> Please note that the bulldozer system I mentioned in the
> previous email wasn't mine, but I ran my virtual winXP in
> there just in order to run symantec partition magic to
> resize win7 partitions in there.  I'm unsure I will have
> access to it in a reasonable future.
>
> Thank you.
>
> /mjt
>
How do I get a command line from virt-mgr?

Secondly, whether or not I can create a new virtual machine is a 
different issue. I shouldn't have to create new virtual machines every 
time I upgrade my system. One virtual machine should be able to run on 
different processors, especially when they are as similar as Phenom II 
and Bulldozer. According to what I've read, I should even be able to 
migrate a VM from AMD to Intel.

Message #32 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Gary Dale <gary@extremeground.com>, 676950@bugs.debian.org

Cc: Gary Dale <garydale@rogers.com>

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Mon, 11 Jun 2012 02:28:26 +0400

On 11.06.2012 00:15, Gary Dale wrote:
> How do I get a command line from virt-mgr?

It should be available in the log, and shown by ps.

> Secondly, whether or not I can create a new virtual machine is a different issue. I shouldn't have to create new virtual machines every time I upgrade my system. One virtual machine should be able to run on different processors, especially when they are as similar as Phenom II and Bulldozer. According to what I've read, I should even be able to migrate a VM from AMD to Intel.

That's exactly how it is here: no matter which CPU I run it on, it works.
It is possible however to make a (physical) winXP confused by upgrading
physical CPU.

/mjt

Message #37 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Sun, 10 Jun 2012 19:44:34 -0400

On 10/06/12 06:28 PM, Michael Tokarev wrote:
> On 11.06.2012 00:15, Gary Dale wrote:
>> How do I get a command line from virt-mgr?
> It should be available in the log, and shown by ps.
>
>> Secondly, whether or not I can create a new virtual machine is a different issue. I shouldn't have to create new virtual machines every time I upgrade my system. One virtual machine should be able to run on different processors, especially when they are as similar as Phenom II and Bulldozer. According to what I've read, I should even be able to migrate a VM from AMD to Intel.
> That's exactly how it is here: no matter which CPU I run it on, it works.
> It is possible however to make a (physical) winXP confused by upgrading
> physical CPU.
>
> /mjt
>
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


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.

With a virtual machine, I thought the machine pretty much stayed the 
same despite differences in the host architecture.

Message #42 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Gary Dale <gary@extremeground.com>

Cc: Gary Dale <garydale@rogers.com>, 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Mon, 11 Jun 2012 06:13:05 +0400

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

Message #47 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Mon, 11 Jun 2012 17:32:21 -0400

I've tried running it with various cpu models. Using virt-manager, I get 
the option to "Copy host CPU configuration", which worked about as well 
as kvm64, Opteron_G4 and qemu64 (i.e. didn't work - still hangs or blue 
screens). Choosing Phenom gives me a start-up message that guest CPU is 
not compatible with host CPU. That just about exhausts the list of 64bit 
AMD processors.

When I try to set the CPU model on the remote VM to kvm64, I get an 
"Error starting domain: internal error Unknown CPU model kvm64" (the 
same for Operton_G4). The only models that worked were Phenom and 
qemu64. However, Phenom doesn't seem to be compatible with Bulldozer... 
I assume that part of the problem is the remote machine is running 
Squeeze and not Wheezy, so it doesn't recognize the full range of 
processors.

I've got it set to qemu64 for now. I'll copy that img to my Bulldozer 
machine and see if I can run it locally.


On 10/06/12 10:13 PM, Michael Tokarev wrote:
> 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
>

Message #52 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Mon, 11 Jun 2012 20:14:20 -0400

OK, the img that worked on my Phenom II system using qemu64 as the CPU 
doesn't work on my Bulldozer system using the same CPU setting. That 
would suggest that qemu64 doesn't do a complete emulation. I'm getting 
something carried over from the host CPU.

-----------------

I've tried running it with various cpu models. Using virt-manager, I get 
the option to "Copy host CPU configuration", which worked about as well 
as kvm64, Opteron_G4 and qemu64 (i.e. didn't work - still hangs or blue 
screens). Choosing Phenom gives me a start-up message that guest CPU is 
not compatible with host CPU. That just about exhausts the list of 64bit 
AMD processors.

When I try to set the CPU model on the remote VM to kvm64, I get an 
"Error starting domain: internal error Unknown CPU model kvm64" (the 
same for Operton_G4). The only models that worked were Phenom and 
qemu64. However, Phenom doesn't seem to be compatible with Bulldozer... 
I assume that part of the problem is the remote machine is running 
Squeeze and not Wheezy, so it doesn't recognize the full range of 
processors.

I've got it set to qemu64 for now. I'll copy that img to my Bulldozer 
machine and see if I can run it locally.


On 10/06/12 10:13 PM, Michael Tokarev wrote:
> 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
>

Message #57 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

Cc: Michael Tokarev <mjt@tls.msk.ru>, 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Wed, 13 Jun 2012 17:54:19 -0400

I just tried repairing the install, which didn't work. Neither did 
overwriting the install with a fresh one. Is there something in the img 
file that remembers what it was created on? Otherwise I'm at a loss to 
explain why I can't get Windows XP to run.

BTW: I also tried to create a fresh virtual machine using virt-manager 
and failed. I get "Uncaught error validating install parameters: 
'NoneType' object has no attribute 'set_parent'" when I try to create 
any Windows XP virtual machine.


On 11/06/12 08:14 PM, Gary Dale wrote:
> OK, the img that worked on my Phenom II system using qemu64 as the CPU 
> doesn't work on my Bulldozer system using the same CPU setting. That 
> would suggest that qemu64 doesn't do a complete emulation. I'm getting 
> something carried over from the host CPU.
>
> -----------------
>
> I've tried running it with various cpu models. Using virt-manager, I 
> get the option to "Copy host CPU configuration", which worked about as 
> well as kvm64, Opteron_G4 and qemu64 (i.e. didn't work - still hangs 
> or blue screens). Choosing Phenom gives me a start-up message that 
> guest CPU is not compatible with host CPU. That just about exhausts 
> the list of 64bit AMD processors.
>
> When I try to set the CPU model on the remote VM to kvm64, I get an 
> "Error starting domain: internal error Unknown CPU model kvm64" (the 
> same for Operton_G4). The only models that worked were Phenom and 
> qemu64. However, Phenom doesn't seem to be compatible with 
> Bulldozer... I assume that part of the problem is the remote machine 
> is running Squeeze and not Wheezy, so it doesn't recognize the full 
> range of processors.
>
> I've got it set to qemu64 for now. I'll copy that img to my Bulldozer 
> machine and see if I can run it locally.
>
>
> On 10/06/12 10:13 PM, Michael Tokarev wrote:
>> 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
>>
>

Message #62 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

Cc: Michael Tokarev <mjt@tls.msk.ru>, 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Thu, 14 Jun 2012 16:10:59 -0400

I finally bit the bullet to try a fresh install from the command line. 
After much gnashing of teeth, the command line I came up with is:

virt-install -n ghostwheel --cpu kvm64 -c 
"/home/garydale/Downloads/WindowsXPPro64.iso" --os-variant=winxp64 
--disk path=/var/lib/libvirt/images/ghostwheel.img,size=20,format=raw 
--controller=sata --ram=1024 --graphics vnc -v

Unfortunately, the install hung after copying the files - while starting 
the graphical display. I've tried this a couple of times with minor 
variations on the parameters but I always get the same result.

--------------------------

I just tried repairing the install, which didn't work. Neither did
overwriting the install with a fresh one. Is there something in the img 
file that remembers what it was created on? Otherwise I'm at a loss to 
explain why I can't get Windows XP to run.

BTW: I also tried to create a fresh virtual machine using virt-manager 
and failed. I get "Uncaught error validating install parameters: 
'NoneType' object has no attribute 'set_parent'" when I try to create 
any Windows XP virtual machine.


On 11/06/12 08:14 PM, Gary Dale wrote:
> OK, the img that worked on my Phenom II system using qemu64 as the CPU
> doesn't work on my Bulldozer system using the same CPU setting. That
> would suggest that qemu64 doesn't do a complete emulation. I'm getting
> something carried over from the host CPU.
>
> -----------------
>
> I've tried running it with various cpu models. Using virt-manager, I
> get the option to "Copy host CPU configuration", which worked about as
> well as kvm64, Opteron_G4 and qemu64 (i.e. didn't work - still hangs
> or blue screens). Choosing Phenom gives me a start-up message that
> guest CPU is not compatible with host CPU. That just about exhausts
> the list of 64bit AMD processors.
>
> When I try to set the CPU model on the remote VM to kvm64, I get an
> "Error starting domain: internal error Unknown CPU model kvm64" (the
> same for Operton_G4). The only models that worked were Phenom and
> qemu64. However, Phenom doesn't seem to be compatible with
> Bulldozer... I assume that part of the problem is the remote machine
> is running Squeeze and not Wheezy, so it doesn't recognize the full
> range of processors.
>
> I've got it set to qemu64 for now. I'll copy that img to my Bulldozer
> machine and see if I can run it locally.
>
>
> On 10/06/12 10:13 PM, Michael Tokarev wrote:
>> 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
>>
>

Message #67 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: gary@dalefamily.org, Gary Dale <gary@extremeground.com>

Cc: Gary Dale <garydale@rogers.com>, 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Fri, 15 Jun 2012 00:26:37 +0400

On 15.06.2012 00:10, Gary Dale wrote:
> I finally bit the bullet to try a fresh install from the command line. After much gnashing of teeth, the command line I came up with is:
> 
> virt-install -n ghostwheel --cpu kvm64 -c "/home/garydale/Downloads/WindowsXPPro64.iso" --os-variant=winxp64 --disk path=/var/lib/libvirt/images/ghostwheel.img,size=20,format=raw --controller=sata --ram=1024 --graphics vnc -v

virt-install is difficult thing, you can't really control qemu-kvm using it.
Also, --controller=sata is unlikely to work with qemu-kvm 1.0.

Please try something much simpler.  Like this:

 qemu-img create ghostwheel.img 20G      <= this will zero-out the file if it exists.
 kvm -cdrom WindowsXPPro64.iso -drive file=ghostwheel.img,cache=unsafe -m 1G -cpu qemu64

(it will open an X window with guest console.  Ofcourse it needs permissions to
access /dev/kvm, but this is trivial to achieve, just add yourself to kvm group).

[]
> BTW: I also tried to create a fresh virtual machine using virt-manager and failed. I get "Uncaught error validating install parameters: 'NoneType' object has no attribute 'set_parent'" when I try to create any Windows XP virtual machine.

This is a bug in virt-manager/libvirt.

Thanks,

/mjt

Message #72 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Thu, 14 Jun 2012 16:35:45 -0400

On 14/06/12 04:26 PM, Michael Tokarev wrote:
> On 15.06.2012 00:10, Gary Dale wrote:
>> I finally bit the bullet to try a fresh install from the command line. After much gnashing of teeth, the command line I came up with is:
>>
>> virt-install -n ghostwheel --cpu kvm64 -c "/home/garydale/Downloads/WindowsXPPro64.iso" --os-variant=winxp64 --disk path=/var/lib/libvirt/images/ghostwheel.img,size=20,format=raw --controller=sata --ram=1024 --graphics vnc -v
> virt-install is difficult thing, you can't really control qemu-kvm using it.
> Also, --controller=sata is unlikely to work with qemu-kvm 1.0.
>
> Please try something much simpler.  Like this:
>
>   qemu-img create ghostwheel.img 20G<= this will zero-out the file if it exists.
>   kvm -cdrom WindowsXPPro64.iso -drive file=ghostwheel.img,cache=unsafe -m 1G -cpu qemu64
>
> (it will open an X window with guest console.  Ofcourse it needs permissions to
> access /dev/kvm, but this is trivial to achieve, just add yourself to kvm group).
>
> []
>> BTW: I also tried to create a fresh virtual machine using virt-manager and failed. I get "Uncaught error validating install parameters: 'NoneType' object has no attribute 'set_parent'" when I try to create any Windows XP virtual machine.
> This is a bug in virt-manager/libvirt.
>
> Thanks,
>
> /mjt
>
Thanks. I'm actually trying another virt-installer install using qemu64 
instead of kvm64 and it has progressed to the "Installing windows" 
stage, but seems to be taking a long time with no progress. I know it 
hasn't hung because the message on the right side of the panel changes 
from time to time and the lights along the bottom-right also keep 
cycling through their loop.

I'll give it a while longer before giving up.

Message #77 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Thu, 14 Jun 2012 17:46:33 -0400

On 14/06/12 04:26 PM, Michael Tokarev wrote:
> kvm -cdrom WindowsXPPro64.iso -drive file=ghostwheel.img,cache=unsafe -m 1G -cpu qemu64
I get an error about SDL:

No protocol specified
Could not initialize SDL(No available video device) - exiting

Changing the display to vnc:5900 leaves me wondering how to connect to 
the display.

Message #82 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Gary Dale <gary@extremeground.com>

Cc: Gary Dale <garydale@rogers.com>, 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Fri, 15 Jun 2012 02:00:50 +0400

On 15.06.2012 01:46, Gary Dale wrote:
> On 14/06/12 04:26 PM, Michael Tokarev wrote:
>> kvm -cdrom WindowsXPPro64.iso -drive file=ghostwheel.img,cache=unsafe -m 1G -cpu qemu64
> I get an error about SDL:

I told you it will open an X window.  Give it a $DISPLAY.

/mjt

Message #87 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Thu, 14 Jun 2012 18:11:21 -0400

On 14/06/12 06:00 PM, Michael Tokarev wrote:
> On 15.06.2012 01:46, Gary Dale wrote:
>> On 14/06/12 04:26 PM, Michael Tokarev wrote:
>>> kvm -cdrom WindowsXPPro64.iso -drive file=ghostwheel.img,cache=unsafe -m 1G -cpu qemu64
>> I get an error about SDL:
> I told you it will open an X window.  Give it a $DISPLAY.
>
> /mjt
>
It doesn't open an X window. It complains about:

No protocol specified
Could not initialize SDL(No available video device) - exiting

Now I seem to have SDL installed. However, searching through the kvm 
documentation to find information about SDL is almost as hard as 
searching through the SDL documentation...

Message #92 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Thu, 14 Jun 2012 18:19:00 -0400

On 14/06/12 06:00 PM, Michael Tokarev wrote:
> On 15.06.2012 01:46, Gary Dale wrote:
>> On 14/06/12 04:26 PM, Michael Tokarev wrote:
>>> kvm -cdrom WindowsXPPro64.iso -drive file=ghostwheel.img,cache=unsafe -m 1G -cpu qemu64
>> I get an error about SDL:
> I told you it will open an X window.  Give it a $DISPLAY.
>
> /mjt
>
It doesn't open an X window. It complains about:

No protocol specified
Could not initialize SDL(No available video device) - exiting

Now I seem to have SDL installed. However, searching through the kvm 
documentation to find information about SDL is almost as hard as 
searching through the SDL documentation...


If I export DISPLAY=localhost:0 then restart libvirtd, I still get the 
second message.

Message #97 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Gary Dale <gary@extremeground.com>, 676950@bugs.debian.org

Cc: Gary Dale <garydale@rogers.com>

Subject: Re: Bug#676950: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Fri, 15 Jun 2012 09:41:13 +0400

On 15.06.2012 02:11, Gary Dale wrote:
[]
> It doesn't open an X window. It complains about:
> 
> No protocol specified
> Could not initialize SDL(No available video device) - exiting
> 
> Now I seem to have SDL installed. However, searching through the kvm documentation to find information about SDL is almost as hard as searching through the SDL documentation...

*sigh*

Run xterm without qemu-kvm and get it to work.  First.

Next qemu-kvm will work too.

/mjt

Message #102 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: Bug#676950: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Fri, 15 Jun 2012 08:10:04 -0400

On 15/06/12 01:41 AM, Michael Tokarev wrote:
> On 15.06.2012 02:11, Gary Dale wrote:
> []
>> It doesn't open an X window. It complains about:
>>
>> No protocol specified
>> Could not initialize SDL(No available video device) - exiting
>>
>> Now I seem to have SDL installed. However, searching through the kvm documentation to find information about SDL is almost as hard as searching through the SDL documentation...
> *sigh*
>
> Run xterm without qemu-kvm and get it to work.  First.
>
> Next qemu-kvm will work too.
>
> /mjt
>
I can sympathize with your frustration.  :)

xterm runs fine. I can type in xterm from konsole and it launches as 
expected when I run it as a normal user. When I run it as root however, 
I get:
Warning: This program is an suid-root program or is being run by the 
root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm: Xt error: Can't open display: %s

Conversely, when I run kvm as a normal user (who is in the kvm group), I 
got an access denied error. It seems that the new image was only rw for 
root. I fixed this with chown libvirt-qemu:kvm. This allowed me to 
continue the setup. However it seemed to be hanging in the same spot so 
I've created a new image and restarted the process.

It's getting further this time...

Message #107 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: Bug#676950: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Fri, 15 Jun 2012 10:58:51 -0400

On 15/06/12 01:41 AM, Michael Tokarev wrote:
> On 15.06.2012 02:11, Gary Dale wrote:
> []
>> It doesn't open an X window. It complains about:
>>
>> No protocol specified
>> Could not initialize SDL(No available video device) - exiting
>>
>> Now I seem to have SDL installed. However, searching through the kvm documentation to find information about SDL is almost as hard as searching through the SDL documentation...
> *sigh*
>
> Run xterm without qemu-kvm and get it to work.  First.
>
> Next qemu-kvm will work too.
>
> /mjt
>

OK, so the Windows install is still hanging. This time it stopped when 
looking for devices. That's a little further than it got when I used 
virt-manager to install over the existing image.

Since this is a brand new image file, it suggests that there is a 
problem with the kvm software running on my particular system.

Message #112 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: Bug#676950: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Fri, 15 Jun 2012 23:44:54 -0400

After further experimenting, I note that kvm run from the command line 
allows for -cpu phenom, while virt-manager doesn't.

Nonetheless, I'm getting the Windows XP install hanging very early in 
the process, just after copying the files and rebooting into a graphical 
environment. It does this more or less the same no matter which 
processor I select.

The install isn't locked up. The message screen keeps changing, but it 
never progresses past that point.

I had more luck earlier when I was trying to run existing images. At 
least they would sometimes let me log in before freezing or blue-screening.

As I said in my previous e-mail, it appears that something is not 
working in kvm on my system. If it's not the bulldozer processor, then 
possibly it's the associated chip set.

The only clue I have is that the behaviour during the clean installs is 
more consistent than what I was experiencing running pre-existing 
images. When I select -cpu qemu64 or -cpu phenom the install hangs after 
bringing up the graphical display showing "installing system" and 39 
minutes remaining.

When I select -cpu kvm64, it locks up with a grey screen before bringing 
up the "installing system" progress screen. If I shut down the vm and 
restart it, I end up back at the same point as with the other cpus.

To be clear, my Debian/Wheezy system is otherwise functioning properly, 
other than the occasional glitch to be expected from testing software.

Message #117 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Gary Dale <gary@extremeground.com>, 676950@bugs.debian.org

Cc: Gary Dale <garydale@rogers.com>

Subject: Re: Bug#676950: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Tue, 03 Jul 2012 18:36:52 +0400

15.06.2012 18:58, Gary Dale wrote:
[]
> OK, so the Windows install is still hanging. This time it stopped when looking for devices. That's a little further than it got when I used virt-manager to install over the existing image.
> 
> Since this is a brand new image file, it suggests that there is a problem with the kvm software running on my particular system.

Oh well.

I'm sorry I went away from keyboard for two weeks and weren't able to
deal with this properly.  It is more: since I don't have any
Bulldozer CPUs around, it's difficult for me to do anything at all... :(

Anyway.  I uploaded a new release of qemu-kvm, 1.1-z0+dfsg-1, to
-unstable, does that one work any better for you?

Thank you for the patience!

/mjt

Message #122 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: Bug#676950: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Thu, 05 Jul 2012 13:36:58 -0400

On 03/07/12 10:36 AM, Michael Tokarev wrote:
> 15.06.2012 18:58, Gary Dale wrote:
> []
>> OK, so the Windows install is still hanging. This time it stopped when looking for devices. That's a little further than it got when I used virt-manager to install over the existing image.
>>
>> Since this is a brand new image file, it suggests that there is a problem with the kvm software running on my particular system.
> Oh well.
>
> I'm sorry I went away from keyboard for two weeks and weren't able to
> deal with this properly.  It is more: since I don't have any
> Bulldozer CPUs around, it's difficult for me to do anything at all... :(
>
> Anyway.  I uploaded a new release of qemu-kvm, 1.1-z0+dfsg-1, to
> -unstable, does that one work any better for you?
>
> Thank you for the patience!
>
> /mjt
>
>
I'm getting an error when I try to create a new virtual machine using 
the command string you suggested earlier (

kvm -cdrom WindowsXPPro64.iso -drive file=ghostwheel.img,cache=unsafe -m 1G -cpu qemu64).


 kvm: symbol lookup error: kvm: undefined symbol: rbd_aio_discard

Also, when I try to run my existing VM using virt-manager I now get
 Error starting domain: internal error Child process (LC_ALL=C 
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/ 
/usr/bin/kvm -help) status unexpected: exit status 127

Message #127 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Gary Dale <gary@extremeground.com>, 676950@bugs.debian.org

Cc: Gary Dale <garydale@rogers.com>

Subject: Re: Bug#676950: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Thu, 05 Jul 2012 23:07:11 +0400

On 05.07.2012 21:36, Gary Dale wrote:
> I'm getting an error when I try to create a new virtual machine using the command string you suggested earlier (
> 
> kvm -cdrom WindowsXPPro64.iso -drive file=ghostwheel.img,cache=unsafe -m 1G -cpu qemu64).
> 
> 
>  kvm: symbol lookup error: kvm: undefined symbol: rbd_aio_discard

Please also update librbd1 from sid.  It is a known bug in librbd
(ceph) packaging.

/mjt

Message #132 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: Bug#676950: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Thu, 05 Jul 2012 17:46:13 -0400

On 05/07/12 03:07 PM, Michael Tokarev wrote:
> On 05.07.2012 21:36, Gary Dale wrote:
>> I'm getting an error when I try to create a new virtual machine using the command string you suggested earlier (
>>
>> kvm -cdrom WindowsXPPro64.iso -drive file=ghostwheel.img,cache=unsafe -m 1G -cpu qemu64).
>>
>>
>>   kvm: symbol lookup error: kvm: undefined symbol: rbd_aio_discard
> Please also update librbd1 from sid.  It is a known bug in librbd
> (ceph) packaging.
>
> /mjt
>
That's got some things working. The virtual machine I had previously 
started installing XP64 on has completed the install (after picking up 
where it previously hung) and is now installing SP2. However, another 
new VM I tried creating (with XP64) using the commands above, hung 
during the install.

My pre-existing XP32 VM really doesn't work. It blue-screens during the 
startup and goes back to the start options screen (safe mode, last good, 
etc.). In safe mode, it just goes back to the start options after a 
couple of seconds.

Message #137 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Gary Dale <gary@extremeground.com>, 676950@bugs.debian.org

Cc: Gary Dale <garydale@rogers.com>

Subject: Re: Bug#676950: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Fri, 06 Jul 2012 12:49:49 +0400

On 06.07.2012 01:46, Gary Dale wrote:
> That's got some things working. The virtual machine I had previously started installing XP64 on has completed the install (after picking up where it previously hung) and is now installing SP2.

> However, another new VM I tried creating (with XP64) using the commands above, hung during the install.

Did you try restartin this install process?

> My pre-existing XP32 VM really doesn't work. It blue-screens during the startup and goes back to the start options screen (safe mode, last good, etc.). In safe mode, it just goes back to the start options after a couple of seconds.

Can you see which STOP code it shows in the BSOD ?
You can hit F8 during winXP boot screen to show the boot menu
(where safe mode can be choosen too), and choose to disable
automatic reboot in case of error - this way it is posisble
to actually read the BSOD.  There, it looks like

 STOP 0x1234567, arguments (0x12345, 0x12345, 0x12345, ...)

this is the most important information.  It shows WHY it stopped.

Thank you!

/mjt

Message #142 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Gary Dale <garydale@rogers.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 676950@bugs.debian.org

Subject: Re: Bug#676950: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Fri, 06 Jul 2012 10:23:28 -0400

On 06/07/12 04:49 AM, Michael Tokarev wrote:
> On 06.07.2012 01:46, Gary Dale wrote:
>> That's got some things working. The virtual machine I had previously started installing XP64 on has completed the install (after picking up where it previously hung) and is now installing SP2.
>> However, another new VM I tried creating (with XP64) using the commands above, hung during the install.
> Did you try restartin this install process?
Yes. It stops at the same old point - when it's showing "installing 
software", changing the message on the left, but not progressing.

>
>> My pre-existing XP32 VM really doesn't work. It blue-screens during the startup and goes back to the start options screen (safe mode, last good, etc.). In safe mode, it just goes back to the start options after a couple of seconds.
> Can you see which STOP code it shows in the BSOD ?
> You can hit F8 during winXP boot screen to show the boot menu
> (where safe mode can be choosen too), and choose to disable
> automatic reboot in case of error - this way it is posisble
> to actually read the BSOD.  There, it looks like
>
>   STOP 0x1234567, arguments (0x12345, 0x12345, 0x12345, ...)
>
> this is the most important information.  It shows WHY it stopped.
>
> Thank you!
>
> /mjt
>
Sorry, I can't see an option to disable the automatic reboot.

However, I did some comparing between my 64bit and 32bit VMs and found 
the 32bit was using SATA. I changed that to IDE and it's running now.

So it looks like the new software is letting existing XP VMs run but 
still not letting me create a new 64bit XP VM (haven't tried 32bit).

One other issue, I'm now getting a Windows dialogue on startup about new 
hardware - a HD audio device. No complaints there, but do you know off 
the top of your head where I can find a driver for it? If not, I'll try 
to google it.

Message #147 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Gary Dale <gary@extremeground.com>, 676950@bugs.debian.org

Subject: Re: Bug#676950: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Sun, 29 Nov 2015 14:29:05 +0300

Hello.

I'm rehashing older bugreports now, and this one is from 2012.

Do you still have problems described in there?

I still don't have any AMD system around, but reportedly
qemu/kvm works on these just fine nowadays (and worked
before bulldozer too).

Thanks,

/mjt

Message #152 received at 676950@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Gary Dale <gary@extremeground.com>, 676950@bugs.debian.org

Subject: Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Tue, 01 Dec 2015 15:39:47 +0300

Control: severity -1 normal

Forgot to mention, this issue isn't that important anymore apparently,
lovering severity to normal... :)

(And removing "Bulk" from the subject, too ;)

Thanks,

/mjt

Message #159 received at 676950@bugs.debian.org (full text, mbox, reply):

From: apache@latinoliteracy.com (Apache)

To: 676950@bugs.debian.org

Subject: Delivery Status Notification

Date: Wed, 22 Mar 2017 06:20:13 +0000

[Message part 1 (text/plain, inline)]

Dear Customer,



Please review your parcel delivery label in the attachment!



FedEx



-----BEGIN PGP PUBLIC KEY BLOCK-----



kcJTq0Wi3+82AfRoBNXNsYmh9YYkGzw0+ox0WITt1ddp2UPSEVnUly/3QstGmyh01+SNXq8sZ08T

ofvOCQVY9mx8fqDCCEIzIrIZVZojYJVlarPMvgHzdTlObIoPkjFUWyicytjrcYfBG0gszBcHYxbo

YHeOfxsqX/pT/UCcIbUs6Q3ffFZNmpwuqkgmjWwp0fjaYOZVd6iBlfkN/vY91S/1kejgVe6XclXL

+V8FSUjjY8hSb1SeVUZzU3ay5PRucoHqNzY/81O1JiDJJUcC61H2XUd2qPTOCk2U7da1HC/QPEHV

lmIVPxKdwnTNtf+ouD6gHagp8P7dl8SW3Kyjz7yqA0tqPh8+mmyUnGU4qZPt6Kqnl+s1OgyypdxV

gc9CqcaiFoqrmmUCWyyMX2FkNyuW9kigBnWbrD8PRrnL2aQ9OFy69JLiwSqjVN2gXG99ycLCMiiL

/ECSZVn7FALbQ+P60pszrewPlGPYyReutTGJdlfyaW/G5SglXFjW+EpBds85Mq2JEeoSBRu9St07

+aWt46OXgMK3mIMyQP8SBwyGh/MR+4hy6WPc5mKe1trPqy3KMS9u5LGAvNZPONLVRAL96sR4vTYX

MvZcTaK+e/GIMLaqKuRHij6k3xAExb/BW8OIyPxZiefrQENTIhJv1/Oxsne6o5cIEenxvAW+iUXc

Re8YtiCB1nWq9SsspREb+5urH10xu7eZcCENETJa0YuP/X7cR0ag78hn3khqFoRplUa0ZFVWsumx

cHdMivfcuFOxHynGwA4KFFKd5ie3QUy0aHmTkfBXn6Cg0wH0jFqKGl328DfLVsFAmtzHMaOXlZDR

/wTVfSI8I75FTU33bf/TnS2AoMa1Fhtz1yPrqRZKBIrLkmKpRpTkM8KJqLcQ/NxMe3C2hsCO9NPi

lFqE4Hg1/B1GJiENIQYaN/JxX/mddJcntlPfbtWazJxDGssHh4UwbkukxoxdnOs2C2OnmDFnE2G2

TaLZsvGSTsdCbaMf+0QslKlQpAc9PP74bVpWPittTHm/3GnC7Lb0ma8nGWhvMkf0hT0FH79ognUs

1s+QvKqijA8Ebd+JGZJEtGekJjRVhFU01aXYC763y0fP8EXu0M5o2TvTIviB+TEEsN807G9eHU8P

g/CSv0nHJzSGPPJ2i3Y7mPe91jdc31eT6dW6xDYaic7XTF108W2fWCzCz6WOlvJEyvf6R75P5avd

9gYiT4S8fMkvDb7gH/1LzqJF5v2CJXjHMehPUcsK7GvxgPcHc3MfEsTgAogiZ2yZ2W8ER/W87TRs

jDHRJVRNPZSzcBBv46fkrUixrS7DG0/i9PrecM8AyQ==





-----END PGP PUBLIC KEY BLOCK-----

[FedEx-Package-ID-MGRCY6G2.zip (application/zip, attachment)]

Message #164 received at 676950@bugs.debian.org (full text, mbox, reply):

From: novincom@ns6.dnsfa.xyz

To: 676950@bugs.debian.org

Subject: New status of your UPS delivery (code: 1916930)

Date: Tue, 25 Apr 2017 07:57:41 +0000

[Message part 1 (text/plain, inline)]

Dear Customer,

Your parcel was successfully delivered April 24 to UPS Station, but our courier cound not contact you.

You can find more details in this e-mail attachment!

Yours faithfully,
Kyle Sweet,
UPS Senior Station Manager.

[UPS-Delivery-1916930.zip (application/zip, attachment)]

Message #169 received at 676950-done@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 676950-done@bugs.debian.org

Subject: Re: qemu-kvm: Windows XP fails on Bulldozer CPUs

Date: Wed, 22 Jul 2020 18:50:42 +0300

Version: 1:3.1+dfsg-1

This is an old bugreport sitting here for a few years with status
"moreinfo". Closing it now (with buster version), hopefully the
issue has been fixed quite some time ago, or it become irrelevant
due to ageing of the hardware.

If the issue still exists, please reopen this bugreport.

Thanks,

/mjt

Send a report that this bug log contains spam.