Date: Sat, 11 Feb 2006 01:09:50 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, Olivier Houchard <cognet@FreeBSD.org>, Steve Kargl <sgk@troutmask.apl.washington.edu>, freebsd-amd64@FreeBSD.org Subject: Re: HEADSUP: New pts code triggers panics on amd64 systems. Message-ID: <20060210230950.GA938@flame.pc> In-Reply-To: <20060207132335.W37594@fledge.watson.org> References: <20060201235556.GA708@troutmask.apl.washington.edu> <20060207104411.GA1067@flame.pc> <20060207132335.W37594@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2006-02-07 13:26, Robert Watson <rwatson@FreeBSD.org> wrote:
>On Tue, 7 Feb 2006, Giorgos Keramidas wrote:
>>On 2006-02-01 15:55, Steve Kargl <sgk@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.
I'm not sure if what I see is a pts side-effect. I rebuilt a snapshot
of HEAD again today, and discovered something else that may help us
track this down.
A few more observations, in case they prove helpful to someone more
acquainted with the way syscons output is supposed to work:
- If I keep hitting Scroll-Lock again and again, then syscons output
*does* eventually appear.
- If I type stuff without seeing it and then press RETURN twice, the
previous from last line *does* appear in my terminal.
- When pressing CTRL-ALT-ESC, the debugger starts normally, but after
typing many times commands that have large output, i.e.:
show witness
the console locks up entirely.
This looks like a locking problem, instead of a pts/syscons one :-/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060210230950.GA938>