Date: Mon, 09 Jul 2007 08:00:07 -0500 From: Eric Anderson <anderson@freebsd.org> To: freebsd-emulation@freebsd.org, freebsd-ports@freebsd.org Subject: Re: experimental qemu-devel port update, please test! Message-ID: <46923157.9050702@freebsd.org> In-Reply-To: <20070708192150.GA86938@saturn.kn-bremen.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46923157.9050702>