From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgGGy-0001Xr-J4 for qemu-devel@nongnu.org; Sun, 17 Jun 2012 10:16:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SgGGw-0004lS-Mf for qemu-devel@nongnu.org; Sun, 17 Jun 2012 10:16:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgGGw-0004lL-E3 for qemu-devel@nongnu.org; Sun, 17 Jun 2012 10:16:10 -0400 Message-ID: <4FDDE6A1.5050706@redhat.com> Date: Sun, 17 Jun 2012 17:16:01 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4FDBD645.1070004@suse.de> <4FDD9746.4030603@redhat.com> <4FDDE4E1.40807@suse.de> In-Reply-To: <4FDDE4E1.40807@suse.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [qom-next] Bisecting virtio-scsi issue List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Andreas_F=E4rber?= Cc: Stefan Hajnoczi , mengcong , qemu-devel , Anthony Liguori On 06/17/2012 05:08 PM, Andreas F=E4rber wrote: > Am 17.06.2012 10:37, schrieb Avi Kivity: >> On 06/16/2012 03:41 AM, Andreas F=E4rber wrote: >>> Hi, >>> >>> After multiple runs of not-so-successful bisecting, it appears as if = the >>> qom-next commit "qbus: Make child devices links" [1] is causing >>> assertions for both virtio-scsi and ahci but not for qemu-system-x86_= 64 >>> without parameters: >>> >>> $ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -device >>> virtio-scsi-pci,id=3Dmcbus >>> qemu-system-x86_64: /home/andreas/QEMU/qemu-rcar/memory.c:1259: >>> memory_region_add_subregion_common: Assertion `!subregion->parent' fa= iled. >>=20 >> A stack trace would be helpful, >=20 > $ gdb --ex run --args x86_64-softmmu/qemu-system-x86_64 -enable-kvm > -device virtio-scsi-pci,id=3Dmcbus > [...] > qemu-system-x86_64: /home/andreas/QEMU/qemu-rcar/memory.c:1259: > memory_region_add_subregion_common: Assertion `!subregion->parent' fail= ed. >=20 > Program received signal SIGABRT, Aborted. > 0x00007ffff5769d95 in raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x00007ffff5769d95 in raise () from /lib64/libc.so.6 > #1 0x00007ffff576b2ab in abort () from /lib64/libc.so.6 > #2 0x00007ffff57628fe in __assert_fail_base () from /lib64/libc.so.6 > #3 0x00007ffff57629a2 in __assert_fail () from /lib64/libc.so.6 > #4 0x000055555576764c in memory_region_add_subregion_common ( > mr=3D, offset=3D, subregion=3D) > at /home/andreas/QEMU/qemu-rcar/memory.c:1259 > #5 memory_region_add_subregion_common (mr=3D, > offset=3D, subregion=3D) > at /home/andreas/QEMU/qemu-rcar/memory.c:1253 > #6 0x000055555574203f in apic_init (apic_id=3D0 '\000', env=3D0x555556= 468d90) > at /home/andreas/QEMU/qemu-rcar/hw/i386/../pc.c:911 > #7 pc_new_cpu (cpu_model=3D0x55555583aec3 "qemu64") > at /home/andreas/QEMU/qemu-rcar/hw/i386/../pc.c:948 > #8 pc_cpus_init (cpu_model=3D0x55555583aec3 "qemu64") > at /home/andreas/QEMU/qemu-rcar/hw/i386/../pc.c:969 > #9 0x0000555555742d6c in pc_init1 (system_memory=3D0x5555564627b0, sys= tem_io=3D > 0x555556462880, ram_size=3D134217728, boot_device=3D0x7fffffffdd50 = "cad", > kernel_filename=3D0x0, kernel_cmdline=3D0x555555813c57 "", initrd_f= ilename=3D > 0x0, cpu_model=3D0x0, pci_enabled=3D1, kvmclock_enabled=3D1) > at /home/andreas/QEMU/qemu-rcar/hw/i386/../pc_piix.c:151 > #10 0x00005555557437c8 in pc_init_pci (ram_size=3D134217728, boot_devic= e=3D > 0x7fffffffdd50 "cad", kernel_filename=3D0x0, kernel_cmdline=3D > ---Type to continue, or q to quit--- > 0x555555813c57 "", initrd_filename=3D0x0, cpu_model=3D) > at /home/andreas/QEMU/qemu-rcar/hw/i386/../pc_piix.c:296 > #11 0x00005555555c3429 in main (argc=3D, argv=3D, > envp=3D) at /home/andreas/QEMU/qemu-rcar/vl.c:3517 >=20 >> as well as a printout of what >> subregion->parent actually is. >=20 > (gdb) select-frame 4 > (gdb) print subregion->parent > value has been optimized out >=20 > Any suggestion? --enable-debug or look for it in another frame or both >=20 >> You can also run 'qemu mtree' from gdb after including scripts/qemu-gd= b.py. >=20 > Unfortunately neither the script nor the commit introducing it nor > Google offer any usage instructions... >=20 > (gdb) include > Undefined command: "include". Try "help". >=20 > (gdb) shell sh ../qemu-rcar/scripts/qemu-gdb.py > ^C(gdb) Quit (gdb) source /path/to/qemu/scripts/qemu-gdb.py (gdb) qemu mtree There is a facility to autoload those scripts, we should use it. >=20 > BTW if some write is going wrong somewhere then this symptom here could > be just accidental. After all we don't seem to be changing any > MemoryRegion in this commit. >=20 Right. If subregion->parent points at garbage then this would prove it. --=20 error compiling committee.c: too many arguments to function