Re: [Qemu-devel] Ubuntu/Debian Installer + Virtio-BLK -> Bad ram pointer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30.10.2012 09:32, Stefan Hajnoczi wrote:
On Mon, Oct 29, 2012 at 03:09:37PM +0100, Peter Lieven wrote:
Hi,
Bug subject should be virtio-blk, not virtio-scsi.  virtio-scsi is a
different virtio device type from virtoi-blk and is not present in the
backtrace you posted.
you are right, sorry for that.

Sounds pedantic but I want to make sure this gets chalked up against the
right device :).

If I try to Install Ubuntu 12.04 LTS / 12.10 64-bit on a virtio
storage backend that supports iSCSI
qemu-kvm crashes reliably with the following error:
Are you using vanilla qemu-kvm-1.2.0 or are there patches applied?
I use vanilla qemu-kvm 1.2.0 except for one virtio-blk related patch (CVE-2011-4127):
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=1ba1f2e319afdcb485963cd3f426fdffd1b725f2
that for some reason did not made it into qemu-kvm 1.2.0 and two aio related patchs:
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=00f78533326c5ba2e62fafada16655aa558a5520
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=2db2bfc0ccac5fd68dbf0ceb70fbc372c5d8a8c7

this is why I can circumvent the issue with scsi=off i guess.

Have you tried qemu-kvm.git/master?
not yet.

Have you tried a local raw disk image to check whether libiscsi is
involved?
I have, here it does not happen. For a raw device scsi is scsi=off, isn't it?

Bad ram pointer 0x3039303620008000

This happens directly after the confirmation of the Timezone before
the Disk is partitioned.

If I specify  -global virtio-blk-pci.scsi=off in the cmdline this
does not happen.

Here is a stack trace:

Thread 1 (Thread 0x7ffff7fee700 (LWP 8226)):
#0 0x00007ffff63c0a10 in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 <https://github.com/sahlberg/libiscsi/issues/1>
0x00005555557b751d in qemu_ram_addr_from_host_nofail (
ptr=0x3039303620008000) at /usr/src/qemu-kvm-1.2.0/exec.c:2835
ram_addr = 0
#2 <https://github.com/sahlberg/libiscsi/issues/2>
0x00005555557b9177 in cpu_physical_memory_unmap (
buffer=0x3039303620008000, len=4986663671065686081, is_write=1,
access_len=1) at /usr/src/qemu-kvm-1.2.0/exec.c:3645
buffer and len are ASCII junk.  It appears to be hex digits and it's not
clear where they come from.

It would be interesting to print *elem one stack frame up in #3
virtqueue_fill() to show the iovecs and in/out counts.
I will collect that info for you.

Peter

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux