Date: Thu, 12 Jul 2007 15:11:54 -0400 From: John Nielsen <lists@jnielsen.net> To: freebsd-emulation@freebsd.org Cc: Craig Boston <craig@yekse.gank.org>, attilio@freebsd.org, Juergen Lock <nox@jelal.kn-bremen.de>, freebsd-ports@freebsd.org, Eric Anderson <anderson@freebsd.org> Subject: Re: experimental qemu-devel port update, please test! Message-ID: <200707121511.55250.lists@jnielsen.net> In-Reply-To: <4696735B.7070604@freebsd.org> References: <20070702203027.GA45302@saturn.kn-bremen.de> <20070712180750.GB77654@nowhere> <4696735B.7070604@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 12 July 2007 02:30:51 pm Eric Anderson wrote: > Craig Boston wrote: > > On Thu, Jul 12, 2007 at 12:52:52PM -0500, Craig Boston wrote: > >> For some reason when the ioctl is issued, curproc points to a totally > >> bogus proc structure. curthread seems to be sane as far as I can tell, > >> but the process it claims to belong to is full of junk. > > > > Aha! The problem isn't that curproc is garbage, but rather that it's > > being interpreted wrong. > > > > struct proc has some extra fields when KSE is #defined. KSE recently > > became a kernel option and was put in the DEFAULTS file, so everyone's > > kernel has it defined. But kqemu is being compiled without it. > > > > I compiled with -DKSE and now kqemu works! > > > > This seems like it would be a common problem for modules compiled > > outside the kernel tree. Is there an established way to get the > > standard configuration options? > > > > I'm thinking also about other options like SMP, that for instance > > changes the way mutexes work. > > Great work! Thanks for chugging on it.. > > Do you think this could affect nvidia kernel modules? I think there was > an alternate thread about nvidia modules causing systems to panic/lock up. I just did a quick test (added a CFLAGS+=-DKSE to the nvidia driver port's Makefile) and it does appear to fix the problems I was having. I can now reboot, switch to a text virtual terminal and back, and run glx apps without panicking. I'm running -CURRENT from a couple days ago, xorg 7.2+, and the 9639 version of the nvidia driver (I hand-rolled a new slave port based on the 9631 port). JN
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707121511.55250.lists>