HEADSUP: New pts code triggers panics on amd64 systems.

[Robert Watson]

On Tue, 7 Feb 2006, Giorgos Keramidas wrote:

> On 2006-02-01 15:55, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:
>> After a binary search, I have determined that the new pts code is
>> triggering kernel panics on an AMD64 system.
>
> It also makes syscons unusable here.
>
> I just rebuilt a HEAD snapshot from today's latest CVSup, installed it
> in /dev/ad0s1a (my test partition), and the behavior is still the same
> as a few days ago:
>
>    - single user mode shell works fine
>
>    - in multiuser mode, when syscons reaches a login prompt
>      i have to press RET twice to see the last line
>
> It seems that something is broken in the way syscons detects whether an 
> output line should be flushed out, but I'm not sure.
>
> A snapshot from -D '2006/01/26 01:30:00 UTC' works fine (just before the 
> first pts change).
>
> I don't know how to debug this or provide more useful feedback, but I'll 
> look at the diffs later today, when I'm done with $REALJOB stuff.

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 the 
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...

Robert N M Watson