| Message ID | 20120228175914.GA28479@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 02/28/2012 11:59 AM, Michael S. Tsirkin wrote: > On Tue, Feb 28, 2012 at 02:25:42PM +0200, Avi Kivity wrote: >> [repost with pull info, brain not yet back up to speed] >> >> This is the current memory queue (posted as two separate series before >> my vacation). When applied, the overhead of 16 bytes/page is reduced to >> basically nil. >> >> Please pull from: >> >> git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/core >> > > This seems to make things worse for me: I used to see a crash with kvm when using > a 64 bit BAR, now it crashes very early, and without kvm as well: > > #0 0x00007ffff5fc4155 in malloc_consolidate () from /lib64/libc.so.6 FWIW, I'm processing this PULL request right now and I'm seeing a SEGV too. The backtrace is a malloc failure in QOM. It's either this pull or Gerd's USB pull. I'm debugging right now. Regards, Anthony Liguori
On 02/28/2012 08:13 PM, Anthony Liguori wrote: > > FWIW, I'm processing this PULL request right now and I'm seeing a SEGV > too. The backtrace is a malloc failure in QOM. > How do we reproduce this?
On 02/28/2012 12:15 PM, Avi Kivity wrote: > On 02/28/2012 08:13 PM, Anthony Liguori wrote: >> >> FWIW, I'm processing this PULL request right now and I'm seeing a SEGV >> too. The backtrace is a malloc failure in QOM. >> > > How do we reproduce this? It looks like just repeatedly running QEMU with a -device option does it. It's only about 10% reproducible for me. I'm thinking it's a heap corruption. Regards, Anthony Liguori >
On 02/28/2012 12:15 PM, Avi Kivity wrote: > On 02/28/2012 08:13 PM, Anthony Liguori wrote: >> >> FWIW, I'm processing this PULL request right now and I'm seeing a SEGV >> too. The backtrace is a malloc failure in QOM. >> > > How do we reproduce this? The guest never gets to run so I don't think the initrd/vmlinuz matter. /home/anthony/build/qemu/x86_64-softmmu/qemu-system-x86_64 -kernel bin/vmlinuz-3.0 -initrd .tmp-11243/initramfs-11243.img.gz -append "console=ttyS0 seed=57279" -nographic -enable-kvm -hda /home/anthony/images/linux.img -M pc-1.0 -drive file=/home/anthony/images/linux.img,if=virtio,snapshot=on -device virtio-balloon-pci -device virtio-serial -net nic,model=virtio -net user -snapshot #0 0x00007f031caf9b5d in malloc_consolidate (av=0x7f031ce111c0) at malloc.c:5169 #1 0x00007f031cafb472 in _int_malloc (av=0x7f031ce111c0, bytes=16512) at malloc.c:4373 #2 0x00007f031cafe31e in __libc_malloc (bytes=16512) at malloc.c:3660 #3 0x00007f03202f47ae in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x00007f03202f4aba in g_malloc0 () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x00007f0320d23f62 in qmp_input_visitor_new (obj=0x7f03223afc50) at /home/anthony/git/qemu/qapi/qmp-input-visitor.c:250 #6 0x00007f0320d41469 in object_property_set_qobject (obj=0x7f0322337f00, value=<value optimized out>, name=0x7f0320e844ed "ioeventfd", errp=0x7fff2beec7b0) at /home/anthony/git/qemu/qom/qom-qobject.c:23 #7 0x00007f0320d404ee in object_property_set_bool (obj=0x7f0322337f00, value=<value optimized out>, name=0x7f0320e844ed "ioeventfd", errp=0x7fff2beec7b0) at /home/anthony/git/qemu/qom/object.c:729 #8 0x00007f0320d29496 in qdev_prop_set_defaults (dev=0x7f0322337f00, props=0x7f03211f0d80) at /home/anthony/git/qemu/hw/qdev-properties.c:1101 #9 0x00007f0320d3f52d in object_init_with_type (obj=0x7f0322337f00, ti=0x7f03223130b0) at /home/anthony/git/qemu/qom/object.c:250 #10 0x00007f0320d3f52d in object_init_with_type (obj=0x7f0322337f00, ti=0x7f032230c7d0) at /home/anthony/git/qemu/qom/object.c:250 #11 0x00007f0320d3f70d in object_new_with_type (type=0x7f032230c7d0) at /home/anthony/git/qemu/qom/object.c:361 #12 0x00007f0320d2adb8 in qdev_try_create (bus=0x7f0322341e10, name=0x7f0320e7fa14 "virtio-net-pci") at /home/anthony/git/qemu/hw/qdev.c:123 #13 0x00007f0320d2ae29 in qdev_create (bus=0x7f0322341e10, name=0x7f0320e7fa14 "virtio-net-pci") at /home/anthony/git/qemu/hw/qdev.c:103 #14 0x00007f0320cde89f in pci_create_multifunction (bus=<value optimized out>, devfn=-1, multifunction=false, name=<value optimized out>) at /home/anthony/git/qemu/hw/pci.c:1541 #15 0x00007f0320cdea0a in pci_nic_init (nd=0x7f03219afc80, default_model=<value optimized out>, default_devaddr=<value optimized out>) at /home/anthony/git/qemu/hw/pci.c:1391 #16 0x00007f0320cdeade in pci_nic_init_nofail (nd=0x7f03219afc80, default_model=0x7f0320e79e67 "e1000", default_devaddr=0x0) at /home/anthony/git/qemu/hw/pci.c:1407 #17 0x00007f0320df4ed4 in pc_init1 (system_memory=<value optimized out>, system_io=0x7f0321c30000, ram_size=134217728, boot_device=0x7fff2beecd40 "cad", kernel_filename=<value optimized out>, kernel_cmdline=<value optimized out>, initrd_filename=0x7f0321c2e370 ".tmp-11243/initramfs-11243.img.gz", cpu_model=0x0, pci_enabled=1, kvmclock_enabled=1) at /home/anthony/git/qemu/hw/pc_piix.c:247 #18 0x00007f0320df55a8 in pc_init_pci (ram_size=134217728, boot_device=0x7fff2beecd40 "cad", kernel_filename=0x7f0321c2e2f0 "bin/vmlinuz-3.0", kernel_cmdline=0x7f0321c2e400 "console=ttyS0 seed=57279", initrd_filename=0x7f0321c2e370 ".tmp-11243/initramfs-11243.img.gz", cpu_model=<value optimized out>) at /home/anthony/git/qemu/hw/pc_piix.c:313 #19 0x00007f0320d04b80 in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /home/anthony/git/qemu/vl.c:3482 Regards, Anthony Liguori
On 02/28/2012 12:15 PM, Avi Kivity wrote: > On 02/28/2012 08:13 PM, Anthony Liguori wrote: >> >> FWIW, I'm processing this PULL request right now and I'm seeing a SEGV >> too. The backtrace is a malloc failure in QOM. >> > > How do we reproduce this? I don't trust this bisect completely, but here are the results: 5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3 is the first bad commit commit 5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3 Author: Avi Kivity <avi@redhat.com> Date: Sun Jan 8 19:46:17 2012 +0200 ioport: change portio_list not to use memory_region_set_offset() memory_region_set_offset() will be going away soon, so don't use it. Use an alias instead. Signed-off-by: Avi Kivity <avi@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net> :100644 100644 36fa3a477ebde72de4745bf4e13ad5146f4686fd 505b252491d1d4e618a5059d75f3cb560a24c61f M ioport.c :100644 100644 ae3e9da0b5487e68a16f28c459889496160e8e16 ab29c89fb3ac6bbe72b2b622172cb9ef7c462e62 M ioport.h bisect run success Regards, Anthony Liguori
On 02/28/2012 09:14 PM, Anthony Liguori wrote: > On 02/28/2012 12:15 PM, Avi Kivity wrote: >> On 02/28/2012 08:13 PM, Anthony Liguori wrote: >>> >>> FWIW, I'm processing this PULL request right now and I'm seeing a SEGV >>> too. The backtrace is a malloc failure in QOM. >>> >> >> How do we reproduce this? > > I don't trust this bisect completely, but here are the results: > > > 5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3 is the first bad commit > commit 5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3 > Author: Avi Kivity <avi@redhat.com> > Date: Sun Jan 8 19:46:17 2012 +0200 > > ioport: change portio_list not to use memory_region_set_offset() > > memory_region_set_offset() will be going away soon, so don't use it. > Use an alias instead. > > Signed-off-by: Avi Kivity <avi@redhat.com> > Reviewed-by: Richard Henderson <rth@twiddle.net> > > :100644 100644 36fa3a477ebde72de4745bf4e13ad5146f4686fd > 505b252491d1d4e618a5059d75f3cb560a24c61f M ioport.c > :100644 100644 ae3e9da0b5487e68a16f28c459889496160e8e16 > ab29c89fb3ac6bbe72b2b622172cb9ef7c462e62 M ioport.h > bisect run success That's the very first commit. You'd get this result if either this was the bad commit, of if the input to 'git bisect good' was also bad. Can you double-check this?
On 02/28/2012 01:17 PM, Avi Kivity wrote: > On 02/28/2012 09:14 PM, Anthony Liguori wrote: >> On 02/28/2012 12:15 PM, Avi Kivity wrote: >>> On 02/28/2012 08:13 PM, Anthony Liguori wrote: >>>> >>>> FWIW, I'm processing this PULL request right now and I'm seeing a SEGV >>>> too. The backtrace is a malloc failure in QOM. >>>> >>> >>> How do we reproduce this? >> >> I don't trust this bisect completely, but here are the results: >> >> >> 5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3 is the first bad commit >> commit 5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3 >> Author: Avi Kivity<avi@redhat.com> >> Date: Sun Jan 8 19:46:17 2012 +0200 >> >> ioport: change portio_list not to use memory_region_set_offset() >> >> memory_region_set_offset() will be going away soon, so don't use it. >> Use an alias instead. >> >> Signed-off-by: Avi Kivity<avi@redhat.com> >> Reviewed-by: Richard Henderson<rth@twiddle.net> >> >> :100644 100644 36fa3a477ebde72de4745bf4e13ad5146f4686fd >> 505b252491d1d4e618a5059d75f3cb560a24c61f M ioport.c >> :100644 100644 ae3e9da0b5487e68a16f28c459889496160e8e16 >> ab29c89fb3ac6bbe72b2b622172cb9ef7c462e62 M ioport.h >> bisect run success > > That's the very first commit. You'd get this result if either this was > the bad commit, of if the input to 'git bisect good' was also bad. Can > you double-check this? Looks like it was a bad bisect :-( I thought I had a 100% reproducible test case but it turned out not to be. Regards, Anthony Liguroi
On Tue, Feb 28, 2012 at 01:20:47PM -0600, Anthony Liguori wrote: > On 02/28/2012 01:17 PM, Avi Kivity wrote: > >On 02/28/2012 09:14 PM, Anthony Liguori wrote: > >>On 02/28/2012 12:15 PM, Avi Kivity wrote: > >>>On 02/28/2012 08:13 PM, Anthony Liguori wrote: > >>>> > >>>>FWIW, I'm processing this PULL request right now and I'm seeing a SEGV > >>>>too. The backtrace is a malloc failure in QOM. > >>>> > >>> > >>>How do we reproduce this? > >> > >>I don't trust this bisect completely, but here are the results: > >> > >> > >> 5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3 is the first bad commit > >>commit 5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3 > >>Author: Avi Kivity<avi@redhat.com> > >>Date: Sun Jan 8 19:46:17 2012 +0200 > >> > >> ioport: change portio_list not to use memory_region_set_offset() > >> > >> memory_region_set_offset() will be going away soon, so don't use it. > >> Use an alias instead. > >> > >> Signed-off-by: Avi Kivity<avi@redhat.com> > >> Reviewed-by: Richard Henderson<rth@twiddle.net> > >> > >>:100644 100644 36fa3a477ebde72de4745bf4e13ad5146f4686fd > >>505b252491d1d4e618a5059d75f3cb560a24c61f M ioport.c > >>:100644 100644 ae3e9da0b5487e68a16f28c459889496160e8e16 > >>ab29c89fb3ac6bbe72b2b622172cb9ef7c462e62 M ioport.h > >>bisect run success > > > >That's the very first commit. You'd get this result if either this was > >the bad commit, of if the input to 'git bisect good' was also bad. Can > >you double-check this? > > Looks like it was a bad bisect :-( I thought I had a 100% > reproducible test case but it turned out not to be. > > Regards, > > Anthony Liguroi > > OK, here it reproduces without issues, so I did a bisect. This is the 1st bad commit: memory: allow phys_map tree paths to terminate early When storing large contiguous ranges in phys_map, all values tend to be the same pointers to a single MemoryRegionSection. Collapse them by marking nodes with level > 0 as leaves. This reduces tree memory usage dramatically. Signed-off-by: Avi Kivity <avi@redhat.com> What I did, to allow bisect, is rebase Avi's patches on top of my bridge implementation, then run qemu with a bridge. bridge without Avi's patches at least starts booting, with Avi's patches crashes before guest start. If you want to play with that, take it from branch bisectme on my qemu tree on github.
On 02/29/2012 12:58 AM, Michael S. Tsirkin wrote: > > What I did, to allow bisect, is rebase Avi's patches on top > of my bridge implementation, then run qemu with a bridge. > bridge without Avi's patches at least starts booting, with > Avi's patches crashes before guest start. > > If you want to play with that, take it from branch bisectme > on my qemu tree on github. > How do you reproduce it? I tried qemu-system-x86_64 -device pci-bridge,chassis_nr=23 but that boots.
On Wed, Feb 29, 2012 at 12:09:14PM +0200, Avi Kivity wrote: > On 02/29/2012 12:58 AM, Michael S. Tsirkin wrote: > > > > What I did, to allow bisect, is rebase Avi's patches on top > > of my bridge implementation, then run qemu with a bridge. > > bridge without Avi's patches at least starts booting, with > > Avi's patches crashes before guest start. > > > > If you want to play with that, take it from branch bisectme > > on my qemu tree on github. > > > > How do you reproduce it? > > I tried > > qemu-system-x86_64 -device pci-bridge,chassis_nr=23 > > but that boots. It could be that you need more devices. This is my command line: qemu-system-x86_64 -m 1G -drive file=/home/mst/rhel6.qcow2 -netdev user,id=bar -net nic,netdev=bar,model=e1000,macaddr=52:54:00:12:34:57 -redir tcp:8022::22 -device pci-bridge,id=bog,chassis_nr=1 -netdev tap,id=foo,ifname=msttap0,script=/home/mst/ifup,downscript=no,vhost=on -nographic > -- > error compiling committee.c: too many arguments to function
On 02/29/2012 12:23 PM, Michael S. Tsirkin wrote: > On Wed, Feb 29, 2012 at 12:09:14PM +0200, Avi Kivity wrote: > > On 02/29/2012 12:58 AM, Michael S. Tsirkin wrote: > > > > > > What I did, to allow bisect, is rebase Avi's patches on top > > > of my bridge implementation, then run qemu with a bridge. > > > bridge without Avi's patches at least starts booting, with > > > Avi's patches crashes before guest start. > > > > > > If you want to play with that, take it from branch bisectme > > > on my qemu tree on github. > > > > > > > How do you reproduce it? > > > > I tried > > > > qemu-system-x86_64 -device pci-bridge,chassis_nr=23 > > > > but that boots. > > It could be that you need more devices. This is my command line: > qemu-system-x86_64 -m 1G -drive file=/home/mst/rhel6.qcow2 -netdev > user,id=bar -net nic,netdev=bar,model=e1000,macaddr=52:54:00:12:34:57 > -redir tcp:8022::22 -device pci-bridge,id=bog,chassis_nr=1 -netdev > tap,id=foo,ifname=msttap0,script=/home/mst/ifup,downscript=no,vhost=on > -nographic > Boots too, even after supplying a peer to foo. I did get an abort with -enable-kvm, but that looks like the old issue, no? Looking into it. Suggest a valgrind run.
On Wed, Feb 29, 2012 at 12:53:50PM +0200, Avi Kivity wrote: > On 02/29/2012 12:23 PM, Michael S. Tsirkin wrote: > > On Wed, Feb 29, 2012 at 12:09:14PM +0200, Avi Kivity wrote: > > > On 02/29/2012 12:58 AM, Michael S. Tsirkin wrote: > > > > > > > > What I did, to allow bisect, is rebase Avi's patches on top > > > > of my bridge implementation, then run qemu with a bridge. > > > > bridge without Avi's patches at least starts booting, with > > > > Avi's patches crashes before guest start. > > > > > > > > If you want to play with that, take it from branch bisectme > > > > on my qemu tree on github. > > > > > > > > > > How do you reproduce it? > > > > > > I tried > > > > > > qemu-system-x86_64 -device pci-bridge,chassis_nr=23 > > > > > > but that boots. > > > > It could be that you need more devices. This is my command line: > > qemu-system-x86_64 -m 1G -drive file=/home/mst/rhel6.qcow2 -netdev > > user,id=bar -net nic,netdev=bar,model=e1000,macaddr=52:54:00:12:34:57 > > -redir tcp:8022::22 -device pci-bridge,id=bog,chassis_nr=1 -netdev > > tap,id=foo,ifname=msttap0,script=/home/mst/ifup,downscript=no,vhost=on > > -nographic > > > > Boots too, even after supplying a peer to foo. > > I did get an abort with -enable-kvm, but that looks like the old issue, > no? Looking into it. > > Suggest a valgrind run. It does not crash under valgrind :) But valgrid did show some info: ==9202== Invalid write of size 8 ==9202== at 0x2F313D: portio_list_add_1 (ioport.c:379) ==9202== by 0x224473: parallel_isa_initfn (parallel.c:505) ==9202== by 0x274839: qdev_init (qdev.c:150) ==9202== by 0x3357F0: pc_basic_device_init (pc.h:53) ==9202== by 0x337DB2: pc_init1 (pc_piix.c:240) ==9202== by 0x3383E7: pc_init_pci (pc_piix.c:319) ==9202== by 0x24EFE7: main (vl.c:3397) ==9202== Address 0x27b202b8 is 0 bytes after a block of size 8 alloc'd ==9202== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==9202== by 0x24D4C5: malloc_and_trace (vl.c:2156) ==9202== by 0x506334D: ??? (in /lib64/libglib-2.0.so.0.2200.5) ==9202== by 0x5063707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) ==9202== by 0x2F2FBC: portio_list_init (ioport.c:331) ==9202== by 0x21A545: isa_register_portio_list (isa-bus.c:109) ==9202== by 0x224473: parallel_isa_initfn (parallel.c:505) ==9202== by 0x274839: qdev_init (qdev.c:150) ==9202== by 0x3357F0: pc_basic_device_init (pc.h:53) ==9202== by 0x337DB2: pc_init1 (pc_piix.c:240) ==9202== by 0x3383E7: pc_init_pci (pc_piix.c:319) ==9202== by 0x24EFE7: main (vl.c:3397) ==9202== ==9202== Invalid write of size 8 ==9202== at 0x2F312F: portio_list_add_1 (ioport.c:378) ==9202== by 0x2064FA: isabus_fdc_init1 (fdc.c:1893) ==9202== by 0x274839: qdev_init (qdev.c:150) ==9202== by 0x27491C: qdev_init_nofail (qdev.c:243) ==9202== by 0x3358ED: pc_basic_device_init (fdc.h:25) ==9202== by 0x337DB2: pc_init1 (pc_piix.c:240) ==9202== by 0x3383E7: pc_init_pci (pc_piix.c:319) ==9202== by 0x24EFE7: main (vl.c:3397) ==9202== Address 0x28f54d20 is 0 bytes after a block of size 16 alloc'd ==9202== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==9202== by 0x24D4C5: malloc_and_trace (vl.c:2156) ==9202== by 0x506334D: ??? (in /lib64/libglib-2.0.so.0.2200.5) ==9202== by 0x5063707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) ==9202== by 0x2F2FAB: portio_list_init (ioport.c:330) ==9202== by 0x21A545: isa_register_portio_list (isa-bus.c:109) ==9202== by 0x2064FA: isabus_fdc_init1 (fdc.c:1893) ==9202== by 0x274839: qdev_init (qdev.c:150) ==9202== by 0x27491C: qdev_init_nofail (qdev.c:243) ==9202== by 0x3358ED: pc_basic_device_init (fdc.h:25) ==9202== by 0x337DB2: pc_init1 (pc_piix.c:240) ==9202== by 0x3383E7: pc_init_pci (pc_piix.c:319) ==9202== ==9202== Invalid write of size 8 ==9202== at 0x2F313D: portio_list_add_1 (ioport.c:379) ==9202== by 0x2064FA: isabus_fdc_init1 (fdc.c:1893) ==9202== by 0x274839: qdev_init (qdev.c:150) ==9202== by 0x27491C: qdev_init_nofail (qdev.c:243) ==9202== by 0x3358ED: pc_basic_device_init (fdc.h:25) ==9202== by 0x337DB2: pc_init1 (pc_piix.c:240) ==9202== by 0x3383E7: pc_init_pci (pc_piix.c:319) ==9202== by 0x24EFE7: main (vl.c:3397) ==9202== Address 0x27b2ec78 is 8 bytes after a block of size 16 alloc'd ==9202== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==9202== by 0x24D4C5: malloc_and_trace (vl.c:2156) ==9202== by 0x506334D: ??? (in /lib64/libglib-2.0.so.0.2200.5) ==9202== by 0x5063707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) ==9202== by 0x2F2FBC: portio_list_init (ioport.c:331) ==9202== by 0x21A545: isa_register_portio_list (isa-bus.c:109) ==9202== by 0x2064FA: isabus_fdc_init1 (fdc.c:1893) ==9202== by 0x274839: qdev_init (qdev.c:150) ==9202== by 0x27491C: qdev_init_nofail (qdev.c:243) ==9202== by 0x3358ED: pc_basic_device_init (fdc.h:25) ==9202== by 0x337DB2: pc_init1 (pc_piix.c:240) ==9202== by 0x3383E7: pc_init_pci (pc_piix.c:319) ==9202== ==9202== Invalid write of size 8 ==9202== at 0x2F313D: portio_list_add_1 (ioport.c:379) ==9202== by 0x2169EF: pci_piix_ide_initfn (piix.c:137) ==9202== by 0x2269DD: pci_qdev_init (pci.c:1492) ==9202== by 0x274839: qdev_init (qdev.c:150) ==9202== by 0x27491C: qdev_init_nofail (qdev.c:243) ==9202== by 0x225DD7: pci_create_simple_multifunction (pci.c:1552) ==9202== by 0x216C7E: pci_piix3_ide_init (piix.c:224) ==9202== by 0x338036: pc_init1 (pc_piix.c:257) ==9202== by 0x3383E7: pc_init_pci (pc_piix.c:319) ==9202== by 0x24EFE7: main (vl.c:3397) ==9202== Address 0x28fc30a8 is 0 bytes after a block of size 8 alloc'd ==9202== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==9202== by 0x24D4C5: malloc_and_trace (vl.c:2156) ==9202== by 0x506334D: ??? (in /lib64/libglib-2.0.so.0.2200.5) ==9202== by 0x5063707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) ==9202== by 0x2F2FBC: portio_list_init (ioport.c:331) ==9202== by 0x21A545: isa_register_portio_list (isa-bus.c:109) ==9202== by 0x2169EF: pci_piix_ide_initfn (piix.c:137) ==9202== by 0x2269DD: pci_qdev_init (pci.c:1492) ==9202== by 0x274839: qdev_init (qdev.c:150) ==9202== by 0x27491C: qdev_init_nofail (qdev.c:243) ==9202== by 0x225DD7: pci_create_simple_multifunction (pci.c:1552) ==9202== by 0x216C7E: pci_piix3_ide_init (piix.c:224) ==9202== = Investigating. > -- > error compiling committee.c: too many arguments to function
On 02/29/2012 01:25 PM, Michael S. Tsirkin wrote: > It does not crash under valgrind :) > But valgrid did show some info: > > ==9202== Invalid write of size 8 > ==9202== at 0x2F313D: portio_list_add_1 (ioport.c:379) > Anthony, your "bad bisect" was in fact good - it was the very first patch that was bad: piolist->regions[piolist->nr++] = region; piolist->aliases[piolist->nr++] = alias; will fix.
On 02/29/2012 01:31 PM, Avi Kivity wrote: > On 02/29/2012 01:25 PM, Michael S. Tsirkin wrote: > > It does not crash under valgrind :) > > But valgrid did show some info: > > > > ==9202== Invalid write of size 8 > > ==9202== at 0x2F313D: portio_list_add_1 (ioport.c:379) > > > > Anthony, your "bad bisect" was in fact good - it was the very first > patch that was bad: > > piolist->regions[piolist->nr++] = region; > piolist->aliases[piolist->nr++] = alias; > > will fix. > Please retry with the new memory/core branch I just pushed. If using kvm, also apply the patch I posted elsewhere in this thread.
On Wed, Feb 29, 2012 at 01:45:49PM +0200, Avi Kivity wrote: > On 02/29/2012 01:31 PM, Avi Kivity wrote: > > On 02/29/2012 01:25 PM, Michael S. Tsirkin wrote: > > > It does not crash under valgrind :) > > > But valgrid did show some info: > > > > > > ==9202== Invalid write of size 8 > > > ==9202== at 0x2F313D: portio_list_add_1 (ioport.c:379) > > > > > > > Anthony, your "bad bisect" was in fact good - it was the very first > > patch that was bad: > > > > piolist->regions[piolist->nr++] = region; > > piolist->aliases[piolist->nr++] = alias; > > > > will fix. > > > > Please retry with the new memory/core branch I just pushed. If using > kvm, also apply the patch I posted elsewhere in this thread. Yes, seems to boot now. > -- > error compiling committee.c: too many arguments to function
diff --git a/hw/pci_bridge_dev.c b/hw/pci_bridge_dev.c index 9a4102a..60d9528 100644 --- a/hw/pci_bridge_dev.c +++ b/hw/pci_bridge_dev.c @@ -66,7 +66,8 @@ static int pci_bridge_dev_initfn(PCIDevice *dev) } /* TODO: spec recommends using 64 bit prefetcheable BAR. * Check whether that works well. */ - pci_register_bar(dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &bridge_dev->bar); + pci_register_bar(dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY | + PCI_BASE_ADDRESS_MEM_TYPE_64, &bridge_dev->bar); dev->config[PCI_INTERRUPT_PIN] = 0x1; return 0; slotid_error: