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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
