HEADSUP: New pts code triggers panics on amd64 systems.

[Giorgos Keramidas]

On 2006-02-07 13:26, Robert Watson <rwatson at FreeBSD.org> wrote:
>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?

Both.  I rebuilt a kernel & userland from today's HEAD, and installed it
on a clean partition.  Both a GENERIC kernel and my own FLAME kernel
config (attached) were tested with kern.pts.enable=0 and kern.pts.enable=1.

There are no significant differences in "boot -v" dmesg output, apart
from minor reordering of things like pflog0 and atapi cam.

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

It looks like it's a property of having the code in the kernel.

FWIW, I don't see a /dev/pty subdir, even when the kernel reached
multiuser mode and I manage to log into ttyv0.  I'm off to test backing
out the kernel changes...