Date: Wed, 8 Feb 2006 12:56:13 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-amd64@freebsd.org, freebsd-current@freebsd.org, Olivier Houchard <cognet@freebsd.org> Subject: Re: HEADSUP: New pts code triggers panics on amd64 systems. Message-ID: <20060208105613.GA1181@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? 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...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060208105613.GA1181>