From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Lieven Subject: Re: [Qemu-devel] Ubuntu/Debian Installer + Virtio-BLK -> Bad ram pointer Date: Tue, 30 Oct 2012 10:43:42 +0100 Message-ID: <508FA14E.6020707@dlhnet.de> References: <508E8E21.6080406@dlhnet.de> <20121030083242.GC9918@stefanha-thinkpad.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , ronnie sahlberg To: Stefan Hajnoczi Return-path: Received: from ssl.dlhnet.de ([91.198.192.8]:46544 "EHLO ssl.dlh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757493Ab2J3Jnm (ORCPT ); Tue, 30 Oct 2012 05:43:42 -0400 In-Reply-To: <20121030083242.GC9918@stefanha-thinkpad.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 >> 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 >> 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