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. 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? Have you tried qemu-kvm.git/master? Have you tried a local raw disk image to check whether libiscsi is involved? > 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. > addr1 = 93825009559312 > #3 <https://github.com/sahlberg/libiscsi/issues/3> > 0x000055555580a9ca in virtqueue_fill (vq=0x5555565da710, > elem=0x555556722238, len=1, idx=0) > at /usr/src/qemu-kvm-1.2.0/hw/virtio.c:240 > size = 1 > offset = 0 > i = 0 Stefan -- 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
