Date: Mon, 9 Jul 2007 23:49:33 +0200 (CEST) From: Juergen Lock <nox@jelal.kn-bremen.de> To: attilio@freebsd.org Cc: freebsd-emulation@freebsd.org, freebsd-ports@freebsd.org Subject: Re: experimental qemu-devel port update, please test! Message-ID: <200707092149.l69LnXe9023835@saturn.kn-bremen.de> In-Reply-To: <3bbf2fe10707091218p713b7e3ela2833eec0ba2df13@mail.gmail.com> References: <20070702203027.GA45302@saturn.kn-bremen.de> <46925324.9010908@freebsd.org> <3bbf2fe10707091140h6cdc7469nac5be03a8c8a60cb@mail.gmail.com> <200707092000.29768.dfr@rabson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <3bbf2fe10707091218p713b7e3ela2833eec0ba2df13@mail.gmail.com> you write: >2007/7/9, Doug Rabson <dfr@rabson.org>: >> On Monday 09 July 2007, Attilio Rao wrote: >> > 2007/7/9, Eric Anderson <anderson@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. Actually it might use %fs while in the monitor (for running guest code), but if I read the code right it doesn't let host kernel code run while in there (it catches interrupts and leaves the monitor, restoring state, to run them.) Also, it still seems to be in kqemu_init when this happened, and I don't think it enters the monitor from in there already. Juergen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707092149.l69LnXe9023835>