From owner-freebsd-current Mon Feb 19 18:27:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA12351 for current-outgoing; Mon, 19 Feb 1996 18:27:08 -0800 (PST) Received: from fw.ast.com (fw.ast.com [165.164.6.25]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA12346 for ; Mon, 19 Feb 1996 18:27:06 -0800 (PST) Received: from nemesis by fw.ast.com with uucp (Smail3.1.29.1 #2) id m0tohl3-0007zaC; Mon, 19 Feb 96 20:24 CST Received: by nemesis.lonestar.org (Smail3.1.27.1 #20) id m0tohh7-000CeZC; Mon, 19 Feb 96 20:20 WET Message-Id: Date: Mon, 19 Feb 96 20:20 WET To: freebsd-current@freebsd.org From: uhclem@nemesis.lonestar.org (Frank Durda IV) Sent: Mon Feb 19 1996, 20:20:44 CST Subject: Re: Keyboard lockout on 2.x.x Sender: owner-current@freebsd.org Precedence: bulk [1]Ohh, sorry, I've seen this mentioned here before so I guess I thought [1]it was a well known problem. I'm using syscon and when flipping to a [1]different vt you'll get locked out. It appears to happen when there [1]is also SCSI activity. I've seen it both on machines with PS/2 keyboards, [1]and standard AT keyboards. SCSI cards have been Adaptec or Buslogic. [1] [1]Only way I've found is to rlogin and re-boot but I thought someone [1]mentioned having a work-around once. I haven't seen this problem in 2.1.0, but used to see it. I could get the console alive again by unplugging and replugging the keyboard cable. It was as though the computer felt it was caught up and the keyboard refused to generate anything new until the CPU did something for the keyboard (which it didn't). Unplugging it broke the stalemate. Since I haven't seen it in 2.1.0, I haven't looked into the issue further. Frank Durda IV |"What are we going to do tonite?" or uhclem%nemesis@rwsystr.nkn.net |"Same thing we do every night: ^------(this is the fastest route)| Try to annoy Microsoft!" or ...letni!rwsys!nemesis!uhclem | - Gatesy and the Brain