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