From swp@alumni.rice.edu Tue Nov 9 14:29:18 1999 Date: Tue, 9 Nov 1999 10:57:06 -0700 (MST) From: Steve Peurifoy To: Lazaro Daniel Salem Cc: port-hp300@netbsd.org Subject: Re: X HP server and UVM system in 1.4.1 > I recall some discussion in which Steve P. was involved, > about a conflict between the HPUX X server and the UVM > subsystem "officially" implemented in 1.4.x: > Dump core of the X server / system lock when quiting X. The HP-UX X server has dumped core on exit in NetBSD since I first started using it long before UVM came along. With the advent of UVM, I started getting kernel panics at exit instead. These are both because some unimplemented optional graphics driver features cause the server to rather bogusly attempt to unmap an unaligned internally generated address on exit. The grf driver passes this address into uvm_unmap(). It appears that some of the changes that have been made in UVM since I ran into this have made the panic much less likely although I maintain that the problem is still there - grfunmap() will pass an address into uvm_unmap() without any validity checking. I implemented a local fix for this that verifies that an address passed into grfunmap() was previously mapped by grfmap() before doing anything with it. I'm not thrilled with this solution at the moment because it has some ugly complications in the presence of fork() that are currently not handled and would require some sort of MD hook into fork() and exit() processing (ick). The X server won't encounter these complications but still... It might be better to do what munmap() does and page align the address before passing it to uvm_unmap() but the framebuffer size isn't really the right thing to use in this case either. If you just want to get running on 1.4.x and don't mind egregious hacks you can alter grfunmap() to reject anything other than 0x1000000 since that's the address grfmap() always returns for the HP X server's GCMAP request. Slightly less bogus would be to reject anything not page aligned. The X server won't care if you fail this particular request - it's on its way out anyway. > I vaguely remember there is even a PR about this. If my memory > serves me the discussion in the PR was in terms of file system > pollution when implementing HPUX emulation. I suspect you're thinking of a separate issue here (although it does involve the HP-UX X server again). The server creates its socket in /usr/spool/sockets/X11. The emulation code doesn't translate the path into the emulation tree for unix domain socket creation so one is forced to have this "alien" directory in the main file system. There are good arguments both for and against changing this behavior (but consistency, which is currently not present, would be nice). Personally, I just create a symlink from /usr/spool to /var/spool and stop worrying about it. -Steve