From owner-freebsd-hackers Thu Aug 15 13:49:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA19604 for hackers-outgoing; Thu, 15 Aug 1996 13:49:55 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA19588; Thu, 15 Aug 1996 13:49:51 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA03955; Thu, 15 Aug 1996 22:49:49 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA06630; Thu, 15 Aug 1996 22:49:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id UAA01372; Thu, 15 Aug 1996 20:52:51 +0200 (MET DST) From: J Wunsch Message-Id: <199608151852.UAA01372@uriah.heep.sax.de> Subject: Re: locking up To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Thu, 15 Aug 1996 20:52:51 +0200 (MET DST) Cc: sos@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199608140700.JAA11609@ra.dkuug.dk> from "sos@freebsd.org" at "Aug 14, 96 09:00:35 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As sos@freebsd.org wrote: > Hmm, this one I know about, the suggested fix is to disable the > LED update sequence (or get another KBD controller)... > This will hang the keyboard both under X and in text mode... I don't think that's a keyboard _controller_ problem, it's merely a problem in handling the keyboard bus. Basically, the keyboard bus has been designed in the IBM PC era to be a uni-directional serial bus. There's a simple `clock' line where the initial signal slope indicates the start of a character transmission. When going to the AT however, IBM decided to abuse this bus for bi- directional transfer, e.g. in order to update the keyboard LEDs, and a few other functions. Of course, the hardware remained the same, and no method of bus arbitration has been added. Thus, if both sides assert the keyboard clock simultaneously, they start sending data then, and will eventually time out in getting no further response. The `Update LEDs' command is the most obvious offender, since it often happens together with scan codes being sent by the keyboard. Even systems like SCO suffer from this problem, i could reproducibly hang the latest SCO on one of the newer (supported!) HP Vectra machines we have been setting up on behalf of a customer. I'm not sure offhand, but there must be a possible recovery strategy in trying to abort the pending transfers, and re-initializing every- thing (the keyboard controller _and_ the keyboard). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)