Debian Bug report logs - #717724
qemu: any disk accesses broken

Toggle useless messages

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

From: Christoph Anton Mitterer <calestyo@scientia.net>

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

Subject: qemu: any disk accesses broken

Date: Wed, 24 Jul 2013 11:46:31 +0200

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

Source: qemu
Version: 1.5.0+dfsg-5
Severity: grave
Justification: renders package unusable


Hi.

Seems since the -5 update, any disk accesses in the VMs lead to errors.
An I also get pty starting errors (in the VMs).

In the HOST, the kernel log shows:
[  232.110748] Bridge firewalling registered
[  232.139083] tun: Universal TUN/TAP device driver, 1.6
[  232.139085] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[  232.329819] device virbr1-nic entered promiscuous mode
[  232.579756] virbr1: topology change detected, propagating
[  232.579760] virbr1: port 1(virbr1-nic) entered forwarding state
[  232.579772] virbr1: port 1(virbr1-nic) entered forwarding state
[  232.612300] virbr1: port 1(virbr1-nic) entered disabled state
[  237.889048] device vnet0 entered promiscuous mode
[  237.933074] virbr1: topology change detected, propagating
[  237.933083] virbr1: port 2(vnet0) entered forwarding state
[  237.933105] virbr1: port 2(vnet0) entered forwarding state
[  242.479951] kvm [7790]: vcpu0 unhandled rdmsr: 0x345
[  242.483683] kvm [7790]: vcpu0 unhandled wrmsr: 0x680 data 0
[  242.483687] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c0 data 0
[  242.483689] kvm [7790]: vcpu0 unhandled wrmsr: 0x681 data 0
[  242.483691] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c1 data 0
[  242.483693] kvm [7790]: vcpu0 unhandled wrmsr: 0x682 data 0
[  242.483696] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c2 data 0
[  242.483698] kvm [7790]: vcpu0 unhandled wrmsr: 0x683 data 0
[  242.483700] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c3 data 0
[  242.483702] kvm [7790]: vcpu0 unhandled wrmsr: 0x684 data 0
[  242.483704] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c4 data 0
[  242.988307] kvm [7790]: vcpu0 unhandled rdmsr: 0xe8
[  242.988312] kvm [7790]: vcpu0 unhandled rdmsr: 0xe7
[  242.988314] kvm [7790]: vcpu0 unhandled rdmsr: 0xce
[  242.988316] kvm [7790]: vcpu0 unhandled rdmsr: 0xce
[  242.988318] kvm [7790]: vcpu0 unhandled rdmsr: 0x1ad
[  242.988320] kvm [7790]: vcpu0 unhandled rdmsr: 0xce
[  242.988322] kvm [7790]: vcpu0 unhandled rdmsr: 0xe8
[  242.988324] kvm [7790]: vcpu0 unhandled rdmsr: 0xe7
[  242.988598] kvm [7790]: vcpu0 unhandled rdmsr: 0xce
[  849.180661] virbr1: port 2(vnet0) entered disabled state
[  849.180769] device vnet0 left promiscuous mode
[  849.180772] virbr1: port 2(vnet0) entered disabled state
[  964.618958] device vnet0 entered promiscuous mode
[  964.650976] virbr1: topology change detected, propagating
[  964.650987] virbr1: port 2(vnet0) entered forwarding state
[  964.651009] virbr1: port 2(vnet0) entered forwarding state
[  968.654130] kvm_get_msr_common: 5 callbacks suppressed
[  968.654132] kvm [22296]: vcpu0 unhandled rdmsr: 0x345
[  968.656979] kvm_set_msr_common: 22 callbacks suppressed
[  968.656981] kvm [22296]: vcpu0 unhandled wrmsr: 0x680 data 0
[  968.656983] kvm [22296]: vcpu0 unhandled wrmsr: 0x6c0 data 0
[  968.656986] kvm [22296]: vcpu0 unhandled wrmsr: 0x681 data 0
[  968.656988] kvm [22296]: vcpu0 unhandled wrmsr: 0x6c1 data 0
[  968.656990] kvm [22296]: vcpu0 unhandled wrmsr: 0x682 data 0
[  968.656992] kvm [22296]: vcpu0 unhandled wrmsr: 0x6c2 data 0
[  968.656994] kvm [22296]: vcpu0 unhandled wrmsr: 0x683 data 0
[  968.656996] kvm [22296]: vcpu0 unhandled wrmsr: 0x6c3 data 0
[  968.656998] kvm [22296]: vcpu0 unhandled wrmsr: 0x684 data 0
[  968.657009] kvm [22296]: vcpu0 unhandled wrmsr: 0x6c4 data 0
[  969.151358] kvm [22296]: vcpu0 unhandled rdmsr: 0xe8
[  969.151363] kvm [22296]: vcpu0 unhandled rdmsr: 0xe7
[  969.151366] kvm [22296]: vcpu0 unhandled rdmsr: 0xce
[  969.151368] kvm [22296]: vcpu0 unhandled rdmsr: 0xce
[  969.151370] kvm [22296]: vcpu0 unhandled rdmsr: 0x1ad
[  969.151373] kvm [22296]: vcpu0 unhandled rdmsr: 0xce
[  969.151375] kvm [22296]: vcpu0 unhandled rdmsr: 0xe8
[  969.151377] kvm [22296]: vcpu0 unhandled rdmsr: 0xe7
[  969.151672] kvm [22296]: vcpu0 unhandled rdmsr: 0xce
[ 1117.807946] virbr1: port 2(vnet0) entered disabled state
[ 1117.808244] device vnet0 left promiscuous mode
[ 1117.808247] virbr1: port 2(vnet0) entered disabled state


Example screenshot of the guest attached.

Cheers,
Chris.

[image.png (image/png, attachment)]

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

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

To: Christoph Anton Mitterer <calestyo@scientia.net>, 717724@bugs.debian.org

Subject: Re: Bug#717724: qemu: any disk accesses broken

Date: Wed, 24 Jul 2013 19:42:32 +0400

Control: tag -1 + unreproducible moreinfo

24.07.2013 13:46, Christoph Anton Mitterer wrote:
> Source: qemu
> Version: 1.5.0+dfsg-5
> Severity: grave
> Justification: renders package unusable
> 
> 
> Hi.
> 
> Seems since the -5 update, any disk accesses in the VMs lead to errors.
> An I also get pty starting errors (in the VMs).

Hm.  I don't see anything like that here.  I tried several linux guests
and a few windows guests, with different devices (disk -- virtio, ide
and sata) -- all works fine with 1.5.0+dfsg-5.  Linux guest kernels
varies from 3.2 to 3.10, 32 and 64bits, windows - winXP, win7 32bit
and win7 64bit.

It looks like I need a reproducer for your issue... ;)

Thanks,

/mjt

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

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

To: Michael Tokarev <mjt@tls.msk.ru>, 717724@bugs.debian.org

Cc: Christoph Anton Mitterer <calestyo@scientia.net>

Subject: Re: Bug#717724: qemu: any disk accesses broken

Date: Wed, 24 Jul 2013 19:45:55 +0400

> 24.07.2013 13:46, Christoph Anton Mitterer wrote:
>> An I also get pty starting errors (in the VMs).

Also, I don't understand what you are saying here, what is "pty starting" ?

Thanks,

/mjt

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

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 717724@bugs.debian.org

Subject: Re: Bug#717724: qemu: any disk accesses broken

Date: Thu, 25 Jul 2013 00:33:28 +0200

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

On Wed, 2013-07-24 at 19:42 +0400, Michael Tokarev wrote: 
> Hm.  I don't see anything like that here.  I tried several linux guests
> and a few windows guests, with different devices (disk -- virtio, ide
> and sata) -- all works fine with 1.5.0+dfsg-5.
hmm really weird... I tried a Windows/ide image now.. that seems to work
as well (at least it runs smoothly,.. Windows doesn't really print a lot
of errors to the console ;) )...

I tried around a bit more with my linux image (which is just another
sid)... different CPUs (kvm64,qemu64 vs. SandyBridge what I had now... I
disabled the CPU features (all))... that leads to no more:
[  242.483704] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c4 data 0
[  242.988307] kvm [7790]: vcpu0 unhandled rdmsr: 0xe8
[  242.988312] kvm [7790]: vcpu0 unhandled rdmsr: 0xe7
...

But still I get gazillion of ATA errors and the VM breaks already during
boot...


I tried also a copy of my Linux VM image from a few days ago (where not
all updates would have been in)... same issue... also, when looking at
the last few days... there weren't any updates (in the guest) like
kernel or so... which could have changed really a lot.


Attaching some more images, which also shows what I meant with tty
restarting... it's nothing special... just getty which breaks due to the
disk problems.


Note that I use libvirt and that seems to have some other storage
problem as well (#715510)... but I can't believe this is related,... and
even though I suffered from this... my existing VMs still booted all the
last days.


Perhaps an upstream issue.. with the two changes?
  * new upstream 1.5.1 stable/bugfix release (as qemu-1.5.1.diff)
    removed qemu_openpty_raw-helper.patch (included upstream)
  * configure-explicitly-disable-virtfs-if-softmmu=no.patch -- do not
    build virtfs-proxy-helper stuff if not building system emulator
    (fix FTBFS on s390)


Is there some problem since the package has versions 1.5.0 but you
removed some patch from 1.5.1?


Thanks,
Chris.

[image4.png (image/png, attachment)]

[image3.png (image/png, attachment)]

[image2.png (image/png, attachment)]

[smime.p7s (application/x-pkcs7-signature, attachment)]

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

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

To: Christoph Anton Mitterer <calestyo@scientia.net>, 717724@bugs.debian.org

Subject: Re: Bug#717724: qemu: any disk accesses broken

Date: Thu, 25 Jul 2013 10:20:37 +0400

25.07.2013 02:33, Christoph Anton Mitterer wrote:

> hmm really weird... I tried a Windows/ide image now.. that seems to work
> as well (at least it runs smoothly,.. Windows doesn't really print a lot
> of errors to the console ;) )...
> 
> I tried around a bit more with my linux image (which is just another
> sid)... different CPUs (kvm64,qemu64 vs. SandyBridge what I had now... I
> disabled the CPU features (all))... that leads to no more:
> [  242.483704] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c4 data 0
> [  242.988307] kvm [7790]: vcpu0 unhandled rdmsr: 0xe8
> [  242.988312] kvm [7790]: vcpu0 unhandled rdmsr: 0xe7

These are harmless (you provided these in your original report), --
guest tries to read (or write) some model-specific CPU registers
which are not emulated by qemu/kvm.  It is usually stuff like CPU
frequency scaling, power management and similar, which is all
handled by the host anyway.  It is definitely not related to the
disk i/o errors.

> But still I get gazillion of ATA errors and the VM breaks already during
> boot...

Ok.  Please provide command line(s) which is used to start your guest.
And please start from the real bugreport - at least indicate your
environment, your host bitness, versions of packages which qemu
uses and so on -- all this is collected automatically when you
run `reportbug qemu-system-x86' (and it really is qemu-system-x86,
not qemu which is a meta-package which does not depend on other
packages).

This is what I refer to when said I need a reproducer.

And a few more points.

 o When you collect guest dmesg and similar, enable serial console.
   On qemu side:

     qemu... -serial file:/some/where/pathname

   on guest (linux) side, in a bootloader:

     linux... console=ttyS0 console=tty1

   This will let you collect guest messages in a much easier way.

 o Please try different storage controller (IDE vs SATA vs VIRTIO),
   to find out if the problem is in a common i/o layer or in a
   particular I/O controller.

 o Note

> I tried also a copy of my Linux VM image from a few days ago (where not
> all updates would have been in)... same issue... also, when looking at
> the last few days... there weren't any updates (in the guest) like
> kernel or so... which could have changed really a lot.

No changes except of the kernel are relevant in the guest, because
only the kernel "talks" with qemu.  And all guest kernels should
Just Work (tm).

> Attaching some more images, which also shows what I meant with tty
> restarting... it's nothing special... just getty which breaks due to the
> disk problems.
> 
> 
> Note that I use libvirt and that seems to have some other storage
> problem as well (#715510)... but I can't believe this is related,... and
> even though I suffered from this... my existing VMs still booted all the
> last days.
> 
> 
> Perhaps an upstream issue.. with the two changes?
>   * new upstream 1.5.1 stable/bugfix release (as qemu-1.5.1.diff)
>     removed qemu_openpty_raw-helper.patch (included upstream)
>   * configure-explicitly-disable-virtfs-if-softmmu=no.patch -- do not
>     build virtfs-proxy-helper stuff if not building system emulator
>     (fix FTBFS on s390)

This actually is just one change - adding a ton of upstream bugfixes
between 1.5.0 and 1.5.1.  This is the current version of qemu which is
used by all other current qemu users.

Another possible issue is toolchain problem (like, a gcc bug which
results in wrong code generation).

> Is there some problem since the package has versions 1.5.0 but you
> removed some patch from 1.5.1?

I don't understand what you're saying here.

Thanks,

/mjt

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

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 717724@bugs.debian.org

Subject: Re: Bug#717724: qemu: any disk accesses broken

Date: Thu, 25 Jul 2013 14:35:23 +0200

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

On Thu, 2013-07-25 at 10:20 +0400, Michael Tokarev wrote: 
> > [  242.483704] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c4 data 0
> > [  242.988307] kvm [7790]: vcpu0 unhandled rdmsr: 0xe8
> > [  242.988312] kvm [7790]: vcpu0 unhandled rdmsr: 0xe7
> These are harmless (you provided these in your original report), --
> guest tries to read (or write) some model-specific CPU registers
> which are not emulated by qemu/kvm.  It is usually stuff like CPU
> frequency scaling, power management and similar, which is all
> handled by the host anyway.  It is definitely not related to the
> disk i/o errors.
Sure? Cause they seem to appear at the same time, when the guest tries
to mount root..


> Ok.  Please provide command line(s) which is used to start your guest.
As mentioned I use libvirt, and it seems to run: 
qemu-system-x86_64 -machine accel=kvm:tcg -name Debian-amd64-unstable_Base-Template -S -machine pc-1.1,accel=kvm,usb=off -cpu SandyBridge,+erms,+smep,+fsgsbase,+rdrand,+f16c,+osxsave,+pcid,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid b68a6e41-ae45-bbca-43f0-45219eb41044 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Debian-amd64-unstable_Base-Template.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device ahci,id=ahci0,bus=pci.0,addr=0x5 -drive file=/var/lib/libvirt/images/Debian-amd64-unstable_Base-Template.img,if=none,id=drive-sata0-0-0,format=raw -device ide-hd,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 -netdev tap,fd=25,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:02:32:71,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,seamless-migration=on -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4



> And please start from the real bugreport - at least indicate your
> environment, your host bitness, versions of packages which qemu
> uses and so on -- all this is collected automatically when you
> run `reportbug qemu-system-x86' (and it really is qemu-system-x86,
> not qemu which is a meta-package which does not depend on other
> packages).
Sure.. sorry for removing that before:
-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu           1.0.0+git-20120202.f6840ba-3
ii  libaio1             0.3.109-4
ii  libasound2          1.0.27.2-1
ii  libbluetooth3       4.101-2
ii  libbrlapi0.6        4.5-3
ii  libc6               2.17-7
ii  libcurl3-gnutls     7.31.0-2
ii  libfdt1             1.3.0-4
ii  libglib2.0-0        2.36.3-3
ii  libgnutls26         2.12.23-5
ii  libiscsi1           1.4.0-3
ii  libjpeg8            8d-1
ii  libncurses5         5.9+20130608-1
ii  libpixman-1-0       0.26.0-4
ii  libpng12-0          1.2.49-4
ii  libpulse0           4.0-6
ii  libsasl2-2          2.1.25.dfsg1-14
ii  libsdl1.2debian     1.2.15-5
ii  libseccomp1         1.0.1-2
ii  libspice-server1    0.12.3-0nocelt1
ii  libssh2-1           1.4.3-1
ii  libtinfo5           5.9+20130608-1
ii  libusb-1.0-0        2:1.0.16-1
ii  libusbredirparser1  0.6-2
ii  libuuid1            2.20.1-5.5
ii  libvdeplug2         2.3.2-4
ii  libx11-6            2:1.6.0-1
ii  libxen-4.2          4.2.2-1
ii  libxenstore3.0      4.2.2-1
ii  qemu-keymaps        1.5.0+dfsg-5
ii  qemu-system-common  1.5.0+dfsg-5
ii  seabios             1.7.3-1
ii  vgabios             0.7a-3
ii  zlib1g              1:1.2.8.dfsg-1
Versions of packages qemu-system-x86 recommends:
ii  qemu-utils  1.5.0+dfsg-5

Versions of packages qemu-system-x86 suggests:
ii  kmod     9-3
pn  samba    <none>
ii  sgabios  0.0~svn8-1
pn  vde2     <none>

-- no debconf information



$ cat /proc/cpuinfo 
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3612QM CPU @ 2.10GHz
stepping : 9
microcode : 0x12
cpu MHz : 2289.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
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 dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx
est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
smep erms
bogomips : 4190.18
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3612QM CPU @ 2.10GHz
stepping : 9
microcode : 0x12
cpu MHz : 1617.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 1
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 dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx
est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
smep erms
bogomips : 4190.18
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3612QM CPU @ 2.10GHz
stepping : 9
microcode : 0x12
cpu MHz : 2646.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 4
apicid : 2
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 dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx
est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
smep erms
bogomips : 4190.18
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3612QM CPU @ 2.10GHz
stepping : 9
microcode : 0x12
cpu MHz : 1449.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 4
apicid : 3
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 dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx
est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
smep erms
bogomips : 4190.18
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 4
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3612QM CPU @ 2.10GHz
stepping : 9
microcode : 0x12
cpu MHz : 2499.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 2
cpu cores : 4
apicid : 4
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 dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx
est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
smep erms
bogomips : 4190.18
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3612QM CPU @ 2.10GHz
stepping : 9
microcode : 0x12
cpu MHz : 2919.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 2
cpu cores : 4
apicid : 5
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 dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx
est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
smep erms
bogomips : 4190.18
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3612QM CPU @ 2.10GHz
stepping : 9
microcode : 0x12
cpu MHz : 1197.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
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 dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx
est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
smep erms
bogomips : 4190.18
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3612QM CPU @ 2.10GHz
stepping : 9
microcode : 0x12
cpu MHz : 2751.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
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 dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx
est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
smep erms
bogomips : 4190.18
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:




Well... if you need anything else... just ask..



>  o When you collect guest dmesg and similar, enable serial console.
>    On qemu side:
> 
>      qemu... -serial file:/some/where/pathname
> 
>    on guest (linux) side, in a bootloader:
> 
>      linux... console=ttyS0 console=tty1
> 
>    This will let you collect guest messages in a much easier way.
> 
>  o Please try different storage controller (IDE vs SATA vs VIRTIO),
>    to find out if the problem is in a common i/o layer or in a
>    particular I/O controller.
I'll try to try around with that... problem is that the initrd were
created with modules=dep... so the machine doesn't bot ide/virtio...



> No changes except of the kernel are relevant in the guest, because
> only the kernel "talks" with qemu.  And all guest kernels should
> Just Work (tm).
Yeah... well guest utils could have been relevant... but I haven't even
installed them... anyway.. just wanted to mention... that nothing has
changend in the guest


> This actually is just one change - adding a ton of upstream bugfixes
> between 1.5.0 and 1.5.1.  This is the current version of qemu which is
> used by all other current qemu users.
> 
> Another possible issue is toolchain problem (like, a gcc bug which
> results in wrong code generation).
> 
> > Is there some problem since the package has versions 1.5.0 but you
> > removed some patch from 1.5.1?
> 
> I don't understand what you're saying here.
What I meant is

$ qemu -version
QEMU emulator version 1.5.1 (Debian 1.5.0+dfsg-5), Copyright (c)
2003-2008 Fabrice Bellard

=> 1.5.1

But the package version is 1.5.0-5 ... (.0 vs. .1) so I just blindly
guessed there might have been some mix ups.



Thanks,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

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

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 717724@bugs.debian.org

Subject: Re: Bug#717724: qemu: any disk accesses broken

Date: Thu, 25 Jul 2013 14:50:38 +0200

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

Can it be this?

https://bugzilla.redhat.com/show_bug.cgi?id=981723


Cheers,
Chris.

[qemu-sata.log (text/x-log, attachment)]

[smime.p7s (application/x-pkcs7-signature, attachment)]

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

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

To: Christoph Anton Mitterer <calestyo@scientia.net>, 717724@bugs.debian.org

Subject: Re: Bug#717724: qemu: any disk accesses broken

Date: Fri, 26 Jul 2013 00:11:06 +0400

25.07.2013 16:50, Christoph Anton Mitterer пишет:
> Can it be this?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=981723

Apparently no, this bugfix is included in 1.5.1.
Well, maybe this bugfix _causes_ the issue you're
seeing.  After all, FLUSH_CACHE is what's failing
in your case.

Hmm.

Okay. Please, try with virtio instead of ide, and
we may also try reverting this change to sort it out.

Thanks,

/mjt

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

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 717724@bugs.debian.org

Subject: Re: qemu: any disk accesses broken

Date: Tue, 30 Jul 2013 04:19:13 +0200

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

Hi.

So long it doesn't turn out that this is Debian specific, I'll place all
further information in the upstream bug.

(I already have a bit, which I'll post in a few minutes)... so please
keep a look or even subscribe to that.

Thanks,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

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

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

To: 717724-done@bugs.debian.org

Subject: Re: Bug#717724: qemu: any disk accesses broken

Date: Tue, 06 Aug 2013 12:25:29 +0400

Version: 1.6.0~rc0+dfsg-1exp
Control: tag -1 + upstream patch
Severity: -1 normal

This is an upstream issue which were introduced by commit
0565700d7859bca6cb0e74c3c98f5fd1201559b5 in 1.5.1-stable
series (original commit f68ec8379e88502b4841a110c070e9b118d3151c),
"ide: Set BSY bit during FLUSH".

The fix is in commit a62eaa26c1d6d48fbdc3ac1d32bd1314f5fdc8c9
"ahci: Fix FLUSH command", which went into upstream 1.6 branch
and is queueud for the next 1.5-stable series.

Since 1.6-rc0 version is packaged in debian, and it does not have
this bug anymore, I'm closing this bugreport now.

This bug only affects ahci, so setting severity accordingly --
it does not make whole package unusable, only for those who
uses ahci/sata.

Thanks,

/mjt

Send a report that this bug log contains spam.