experimental qemu-devel port update, please test!

[John Nielsen]

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