Date: Mon, 09 Jul 2007 09:01:54 -0500 From: Eric Anderson <anderson@freebsd.org> To: freebsd-emulation@freebsd.org, freebsd-ports@freebsd.org, attilio@freebsd.org Subject: Re: experimental qemu-devel port update, please test! Message-ID: <46923FD2.4080503@freebsd.org> In-Reply-To: <46923157.9050702@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 Or the 1.384 -> 1.385 change by attilio@ (cc'ed). Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46923FD2.4080503>