From owner-freebsd-hackers@FreeBSD.ORG Tue May 27 21:28:28 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9188F1065670 for ; Tue, 27 May 2008 21:28:28 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 197388FC22 for ; Tue, 27 May 2008 21:28:27 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1871697fgb.35 for ; Tue, 27 May 2008 14:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=fWnWjXR0T7Zf/C9c7HAAYE7RbbTM35iBH4enJ3TCTxI=; b=xnAAEtrI027hwVeFGvXvaAi68jJ4wLkCoAJ9AjRN8+6Jo771JlBLQ3M65o+aaC/JoHg434vwPH1szwJlSD5lsSMdOnhSuN029x6piepcVKNRZdFmmoDqgC1XMDDWXCpAxQdaHmS0tWqjxsAssCwHXzqLm522RxOhCzOey/SGO9Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OdnSnfuk87cqFqeo7nk3YTh4K0ZS2/LqgqiqiI8jxRgARrF9v6D3L6yPaFmrG8VBRxmC8SaHQlmOyiDrymjDLiOydfiMoUYbsHdeegIZrPPlALFs3lNrcdbRwuo7Y7zQb5TXgy+WfAkTtBXQ3LTXN2y1uXbPW+RFv74k9JSlqzk= Received: by 10.86.98.10 with SMTP id v10mr7605076fgb.46.1211923706051; Tue, 27 May 2008 14:28:26 -0700 (PDT) Received: by 10.86.66.5 with HTTP; Tue, 27 May 2008 14:28:26 -0700 (PDT) Message-ID: Date: Tue, 27 May 2008 14:28:26 -0700 From: "Maksim Yevmenkin" To: rick-freebsd@kiwi-computer.com In-Reply-To: <20080527210158.GB81555@keira.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48378DA0.8040506@frase.id.au> <20080524201633.GA81364@eos.sc1.parodius.com> <20080527041236.GB68298@keira.kiwi-computer.com> <20080527051109.GA26502@eos.sc1.parodius.com> <20080527054842.GA69670@keira.kiwi-computer.com> <20080527194554.GA79741@keira.kiwi-computer.com> <20080527210158.GB81555@keira.kiwi-computer.com> Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , Fraser Tweedale Subject: Re: temporary freezes when pressing capslock / numlock X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2008 21:28:28 -0000 On 5/27/08, Rick C. Petty wrote: > On Tue, May 27, 2008 at 01:32:10PM -0700, Maksim Yevmenkin wrote: > > [...] > > i suspect that because physical ps2 keyboard is not actually > > present, the atkbd driver will have to timeout while talking to > > non-present hardware. > > Sure, but this timeout shouldn't be ~0.4 seconds. I believe the spec says > the maximum wait period to tell if the device is nonresponsive is around or > less than 20ms. Certainly, blocking the entire kernel for the timeout is a > bad thing, especially since the driver should make full use of the > asynchronous onboard keyboard controller. well, i just took a brief look at atkbd(4). specifically one function - wait_while_controller_busy(). this function polls status every KBDC_DELAYTIME (20) usec with retry count of 5000. so, just this function alone can give up to 100 msec delay. keep in mind that wait_while_controller_busy() is apparently called every time driver need to talk to the hardware. i can see how we could delay kernel for 400 msec or even more. > > so, as a suggestion, please try to specify 0x1 flag to atkbd, i.e. from atkbd(4) > > ... > > > > and see if this helps. you wont be able to "hot plug" ps2 keyboards, > > but i suspect you probably can live without it. > > I'm almost certain this will help, but I believe this shouldn't be the > answer to this problem. There's no reason atkbdc(4) should block the > entire kernel for any appreciable amount of time. agree. all i was trying to say is that kbdmux is only as good as underlying low level keyboard drivers. if a low level keyboard driver uses completely synchronous approach to poll the hardware, there is not much kbdmux can do about it. thanks, max