Re: [Qemu-devel] [memory] abort with head a8170e5

[Aurelien Jarno <aurelien@aurel32.net>]

On Thu, Oct 25, 2012 at 06:12:06PM +0200, Avi Kivity wrote:
> On 10/25/2012 04:39 PM, Aurelien Jarno wrote:
> > On Thu, Oct 25, 2012 at 03:47:34PM +0200, Avi Kivity wrote:
> >> On 10/24/2012 04:00 PM, Aurelien Jarno wrote:
> >> > 
> >> > mips is also broken but by commit 1c380f9460522f32c8dd2577b2a53d518ec91c6d:
> >> > 
> >> > | [    0.436000] PCI: Enabling device 0000:00:0a.1 (0000 -> 0001)
> >> > | Segmentation fault (core dumped)
> >> > 
> >> 
> >> How do you reproduce it?
> > 
> > You can use the mips kernel version 2.6.32 from:
> >   http://people.debian.org/~aurel32/qemu/mips/
> > 
> > Then just run it with the following command:
> >   qemu-system-mips -M malta -kernel vmlinux-2.6.32-5-4kc-malta -append "console=tty0"
> > 
> > (You can also get the README command line if you don't care about
> > downloading the disk image).
> 
> Doesn't reproduce here with this command line (upstream + the bridge patch).
> 
> [    0.568000] PCI: Enabling device 0000:00:12.0 (0000 -> 0002)
> [    0.572000] cirrusfb 0000:00:12.0: Cirrus Logic chipset on PCI bus,
> RAM (4096 kB) at 0x10000000
> 
> ...
> 
> [    1.172000] PCI: Enabling device 0000:00:0a.1 (0000 -> 0001)
> [    1.188000] scsi0 : ata_piix
> 
> (with console=ttyS0)

Ok, looks like I didn't provide the right command line. I am only able
to reproduce it when using -nographic, and only with -vga cirrus (yes it
starts to be quite strange). In that case it's better to pass 
console=ttyS0, even if you can reproduce it with console=tty0.

In short it seems heavily related to the cirrus VGA card.

> What's lp - p when the segfault occurs?  What's *index?

lp - p = 0xa0
*index = 0x100a0

> | #3  0x00007f4e10f3477f in phys_page_set (leaf=<optimized out>, nb=16,
> index=65696, d=0x7f4e124ffb50) at /home/aurel32/qemu/exec.c:458
> 
> We're setting 16 pages around address 269090816.  Should be totally
> straightforward.
> 
> If you make memory_region_transaction_begin()/_commit() no-ops, we can
> get a clearer stack trace.

I'll try to get that.

Thanks,
Aurelien

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net