Robert Watson writes: > Does the instability occur if kern.pts.enable=0, or only when > kern.pts.enable=1? If 0, if you back out the user space changes but leave > tty_pts.c compiled into the kernel, do the instability issues persist? How > about with the kernel code compiled out, but the user space code in place? > > Basically, it would be good to know if what you're seeing is a property of th > e > pts code being in the kernel at all, or a property of it actually in use. > The former might be indicate that a memory layout change or devfs behavioral > change has triggered an existing bug previously masked, whereas the latter > more likely signals a bug in the pts code or a bug in devfs generated by > virtue of the deletion of device nodes. That some of the panics happen very > early (perhaps before a pts device is actually allocated) is suggestive... I was running 32-bit so I rebooted to 64-bit. kern.pts.enable was 0 so I set it to 1 and started X. This automatically starts an mrxvt with 3 virtual terminals. Everything was OK and ``tty'' showed /dev/pts/{0,1,2}, as expected. I didn't try booting with an entry in loader.conf to set kern.pts.enable to 1. I'm now back running 32-bit with kern.pts.enable set to 1 in X with a whole slew of mrxvt's running and I see no problems here either. The only difference is that ``w'' doesn't show any of the /dev/pts entries although I have 7 active. --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTdeReceived on Tue Feb 07 2006 - 13:16:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:52 UTC