experimental qemu-devel port update, please test!

Attilio Rao attilio at freebsd.org
Mon Jul 9 19:18:05 UTC 2007


2007/7/9, Doug Rabson <dfr at rabson.org>:
> On Monday 09 July 2007, Attilio Rao wrote:
> > 2007/7/9, Eric Anderson <anderson at freebsd.org>:
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid = 0; apic id = 00
> > > fault virtual address   = 0x82
> > > fault code              = supervisor read, page not present
> > > instruction pointer     = 0x20:0xc0928f00
> > > stack pointer           = 0x28:0xe57b7a3c
> > > frame pointer           = 0x28:0xe57b7a50
> > > code segment            = base 0x0, limit 0xfffff, type 0x1b
> > >                          = DPL 0, pres 1, def32 1, gran 1
> > > processor eflags        = interrupt enabled, resume, IOPL = 0
> > > current process         = 69 (qemu)
> > >
> > >
> > > #9  0xc0928f00 in _vm_map_lock (map=0x1, file=0x0, line=0) at
> > > /usr/src/sys/vm/vm_map.c:421
> > > #10 0xc092986d in vm_map_wire (map=0x1, start=677306368,
> > > end=677310464, flags=1) at /usr/src/sys/vm/vm_map.c:1964
> >
> > Please also note that stack here seems highly corrupted since values
> > passed to _vm_map_lock are not possible (or there is something
> > serious going on with them).
>
> I had this exact same crash when attempting to use kqemu on a recent
> current. It appears as if the value it got for curproc was bad. Is
> kqemu messing with the kernel's %fs value perhaps?

I don't know about kqemu, but in this case I would expect sorta of
larger corruption due to the wider pcpu accesses done through %fs.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein


More information about the freebsd-emulation mailing list