From owner-freebsd-hackers Mon Nov 25 18:53:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA01052 for hackers-outgoing; Mon, 25 Nov 1996 18:53:42 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA01037; Mon, 25 Nov 1996 18:53:25 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id UAA16144; Mon, 25 Nov 1996 20:52:26 -0600 From: Joe Greco Message-Id: <199611260252.UAA16144@brasil.moneng.mei.com> Subject: Re: Hang your machine with ScrollLock To: bde@zeta.org.au (Bruce Evans) Date: Mon, 25 Nov 1996 20:52:26 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, sos@freebsd.org, hackers@freebsd.org, mtaylor@cybernet.com In-Reply-To: <199611260210.NAA20353@godzilla.zeta.org.au> from "Bruce Evans" at Nov 26, 96 01:10:40 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> > > As soon as I hit the scroll-lock key, everything was fine- > >> > > all of the uptime processes completed, and name serving > >> > > went on as usual. > >> > >> I belive this to be fixed in what was 2.2-current long ago... > > Nope. There is no bug to fix. Scroll lock says to stop output, so the > tty buffer fills up after a while and the tty driver sleeps on "ttywri". I agree that this is technically not a "bug" in the strictest sense. Syscons did the "right" thing. You may wish to explain that to the mechanical keyboard switch a friend of mine uses that caused a script to hang... fortunately since the script was not sitting there forking constantly, it did not kill the machine, it just looked real strange to see seven users listed as "on" with only one modem active. In my opinion, this makes the mandatory enabling of the "scroll lock" key an undesirable misfeature (at least in certain cases), and some people would argue that that means that it is a "bug" from the point of view of usability/reliability/practicality. > Workaround: `comcontrol /dev/console drainwait 10' times out the sleep > after 10 seconds. write() returns -1/EIO or a short count. Applications > may be confused by this. EIO normally means hangup. Can the scroll lock key be disabled? I mean, it can be done with a new keyboard map, remapping on _all_ vty's, but scrollback is a moderately useful function. That is why I was curious if it could be tied into "kbdcontrol -h 0" (currently illegal) or the cases where "kbdcontrol -h n" is smaller than the current screen size (kbdcontrol -h 1 causes scroll lock to function as scroll lock, and it looks like internally syscons does not even store a history for this case). It is certainly not a real important feature, but some of us do like to put up status displays, and it would be nice if one could protect the system from something like what happened to the fellow with the cron job. But whatever. ;-) ... JG