HEADSUP: New pts code triggers panics on amd64 systems.

[Gary Jennejohn]

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 garyjATdenxDOTde