Date: Mon, 09 Jul 2007 18:40:46 +0200 From: Attilio Rao <attilio@FreeBSD.org> To: Eric Anderson <anderson@freebsd.org> Cc: freebsd-emulation@freebsd.org Subject: Re: experimental qemu-devel port update, please test! Message-ID: <4692650E.6030304@FreeBSD.org> In-Reply-To: <46925324.9010908@freebsd.org> References: <20070702203027.GA45302@saturn.kn-bremen.de> <468DB791.9020502@freebsd.org> <200707071402.l67E2Gpm051150@saturn.kn-bremen.de> <469129C7.7090008@freebsd.org> <20070708192150.GA86938@saturn.kn-bremen.de> <46923157.9050702@freebsd.org> <46923FD2.4080503@freebsd.org> <46924627.7090004@FreeBSD.org> <46925324.9010908@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric Anderson wrote: > On 07/09/07 09:28, Attilio Rao wrote: >> Eric Anderson wrote: >>> On 07/09/07 08:00, Eric Anderson wrote: >>>> Juergen Lock wrote: >>>>> On Sun, Jul 08, 2007 at 01:15:35PM -0500, Eric Anderson wrote: >>>>>> On 07/07/07 09:02, Juergen Lock wrote: >>>>>>> In article <468EFF46.4060001@freebsd.org> you write: >>>>>>>> On 07/05/07 22:31, Eric Anderson wrote: >>>>>>>> [...] >>>>>>>> Although now I have the issue where using kqemu-kmod causes my >>>>>>>> system to reboot or power off. :( >>>>>>>> >>>>>>>> Any ideas? >>>>>>> This seems to be a -current issue, it doesn't happen for me at least >>>>>>> (6.2 and previously also 6.1.) You could check if it is dependent >>>>>>> on the version of the used qemu (the 0.9.0 port, the version of >>>>>>> qemu-devel in ports, or the not-yet-committed updated I posted), >>>>>>> but I doubt it. What may help is finding out which commit to >>>>>>> -current >>>>>>> started kqemu to break (find an older version that worked, then >>>>>>> binary-search), or at least a backtrace from a kernel compiled >>>>>>> without -fomit-frame-pointer (putting DDB in the config seems to do >>>>>>> that for amd64 at least, but rebuild the entire kernel.) There also >>>>>>> is an open issue for kqemu on amd64 smp, >>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=113430 >>>>>>> dunno if its related... >>>>>>> Juergen >>>>>> My host is i386, SMP, and it also happens with the current >>>>>> qemu-devel port. It must have been something in -CURRENT that >>>>>> changed, probably since May15th-ish. I can't do a binary search >>>>>> anytime soon to find it. In the past, I've recompiled kqemu and >>>>>> that has done the trick. I have all the debugging built in, but >>>>>> that doesn't stop the system from rebooting or powering off. >>>>> Hmm an UP kernel might be worth a try too... >>>>> >>>>> Juergen >>>> >>>> Hmm - with and without UP, I get a panic, but I managed to catch a >>>> panic in _vm_map_lock, something like: >>>> >>>> _vm_map_lock() >>>> vm_map_wire() >>>> kqemu_lock_user_page() >>>> mon_user_map() >>>> >>>> >>>> I'll try to get a real bt.. >>>> >>>> Eric >>> Hmm - I suspect this commit or something near it is the issue: >>> >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/vm_map.c.diff?r1=1.384;r2=1.385;sortby=date;f=h;f=u >> >> >> don't think so, as it just does a 1:1 translation with the old code >> (passing 0 as argument and casting the return value). >> >> What kind of panic it is (what message it prints out)? >> >> Attilio >> > > 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 > > Maybe not that exact file, but I think that series of commits is > related. I believe before that everything worked fine (around May 15th > or so). > > What else would you like me to try? Would you see if accesses to map structure are MPSAFE and don't present racy accesses? Thanks, Attilio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4692650E.6030304>