From owner-cvs-sys  Sat May 11 19:17:35 1996
Return-Path: owner-cvs-sys
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id TAA12773
          for cvs-sys-outgoing; Sat, 11 May 1996 19:17:35 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA12767
          Sat, 11 May 1996 19:17:26 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id MAA13485; Sun, 12 May 1996 12:11:41 +1000
Date: Sun, 12 May 1996 12:11:41 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199605120211.MAA13485@godzilla.zeta.org.au>
To: CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org,
        cvs-sys@freefall.freebsd.org, joerg@freefall.freebsd.org
Subject: Re: cvs commit:  src/sys/i386/isa syscons.c
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>  Modified:    sys/i386/isa  syscons.c
>  Log:
>  Give up waiting for a successful keyboard reset after some
>  unreasonable time.  I've got a PCI mainboard that simply doesn't grok
>  it, so continuing with a warning (and a keyboard that's working
>  nevertheless :) seems to be better than spin-looping forever.

Does it work if you fix the well known `!retries' logic bug (the infinite
loop always gets entered if the first loop fails (retries == -1)).

I have a keyboard with a partly broken cable or connector which causes
interesting problems for keyboard drivers.  The BIOS keyboard driver
seems to handle transient disconnections better than syscons.  Perhaps
it issues a reset when the keyboard stops working.

Bruce