From owner-freebsd-current@FreeBSD.ORG Wed Feb 8 10:57:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60D5416A420; Wed, 8 Feb 2006 10:57:19 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E4B043D53; Wed, 8 Feb 2006 10:57:16 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from flame.pc (patr530-a036.otenet.gr [212.205.215.36]) (authenticated bits=0) by igloo.linux.gr (8.13.5/8.13.5/Debian-3) with ESMTP id k18Aurw0000760; Wed, 8 Feb 2006 12:57:00 +0200 Received: by flame.pc (Postfix, from userid 1001) id AC4DA5C86; Wed, 8 Feb 2006 12:56:13 +0200 (EET) Date: Wed, 8 Feb 2006 12:56:13 +0200 From: Giorgos Keramidas To: Robert Watson Message-ID: <20060208105613.GA1181@flame.pc> References: <20060201235556.GA708@troutmask.apl.washington.edu> <20060207104411.GA1067@flame.pc> <20060207132335.W37594@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060207132335.W37594@fledge.watson.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.399, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 1.00, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr Cc: freebsd-amd64@freebsd.org, freebsd-current@freebsd.org, Olivier Houchard , Steve Kargl Subject: Re: HEADSUP: New pts code triggers panics on amd64 systems. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2006 10:57:19 -0000 On 2006-02-07 13:26, Robert Watson wrote: >On Tue, 7 Feb 2006, Giorgos Keramidas wrote: >>On 2006-02-01 15:55, Steve Kargl 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...