experimental qemu-devel port update, please test!
lists at jnielsen.net
Thu Jul 12 19:51:44 UTC 2007
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).
More information about the freebsd-ports