Date: Tue, 7 Feb 2006 13:26:24 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Giorgos Keramidas <keramida@ceid.upatras.gr> 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: <20060207132335.W37594@fledge.watson.org> In-Reply-To: <20060207104411.GA1067@flame.pc> References: <20060201235556.GA708@troutmask.apl.washington.edu> <20060207104411.GA1067@flame.pc>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060207132335.W37594>