Date: Thu, 12 Jul 2007 13:30:51 -0500 From: Eric Anderson <anderson@freebsd.org> To: Craig Boston <craig@yekse.gank.org>, Juergen Lock <nox@jelal.kn-bremen.de>, attilio@freebsd.org, freebsd-emulation@freebsd.org, freebsd-ports@freebsd.org Subject: Re: experimental qemu-devel port update, please test! Message-ID: <4696735B.7070604@freebsd.org> In-Reply-To: <20070712180750.GB77654@nowhere> References: <20070702203027.GA45302@saturn.kn-bremen.de> <46925324.9010908@freebsd.org> <3bbf2fe10707091140h6cdc7469nac5be03a8c8a60cb@mail.gmail.com> <200707092000.29768.dfr@rabson.org> <200707092149.l69LnXe9023835@saturn.kn-bremen.de> <20070712175252.GA77654@nowhere> <20070712180750.GB77654@nowhere>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4696735B.7070604>