From owner-freebsd-current@FreeBSD.ORG Mon Oct 19 14:54:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 777B2106568F for ; Mon, 19 Oct 2009 14:54:17 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-px0-f192.google.com (mail-px0-f192.google.com [209.85.216.192]) by mx1.freebsd.org (Postfix) with ESMTP id 473B78FC20 for ; Mon, 19 Oct 2009 14:54:17 +0000 (UTC) Received: by pxi30 with SMTP id 30so3306169pxi.7 for ; Mon, 19 Oct 2009 07:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0Tj7U5FdDkfPWhhFuurQm+zRodxnCuzzP6k+A5xmfjM=; b=ZEmY+5MASizEhIDB1S1j5gIDuoKxfTAU92f/4twqWonW52SZFiUihKYFij0/9aPdhk RTu/+IQEOZ0mFdHpMZyoHKCsSeQ8mDBcQBgh71adBbqgGw+pA5+21ivN2PDJ3/qVNWb4 Wp9jVPsh42UQ4+6wqQOp6BhdTeAwGYQdq8AxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=A/7KhLMXOYuegsaMaGmzAC0aFBeRthFTztW2suK2eBkS/Kwpw1rpbVWPLhPgUuVC9q nUw29TY157Gq4jnxDOp4MGlSOg52X5KSmAQJGB0fPbJcFelZcIiZE9vMXXPRVVXPlO9G 2dcKbob7ns8T1EM3AdMhpSJQ52SVqFGhd+yo8= MIME-Version: 1.0 Received: by 10.114.50.17 with SMTP id x17mr6512135wax.168.1255964056582; Mon, 19 Oct 2009 07:54:16 -0700 (PDT) In-Reply-To: <58c737d70910181014u7c32ffd2s8c0732a707d40a2f@mail.gmail.com> References: <200909051806.07692.hselasky@c2i.net> <20090905182929.GB2829@hoeg.nl> <200910181450.11838.shoesoft@gmx.net> <58c737d70910181014u7c32ffd2s8c0732a707d40a2f@mail.gmail.com> Date: Mon, 19 Oct 2009 07:54:16 -0700 Message-ID: From: Maksim Yevmenkin To: Chris Ruiz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , freebsd-current@freebsd.org, Stefan Ehmann , Hans Petter Selasky Subject: Re: ukbd: short freeze when activating LEDs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:54:17 -0000 On Sun, Oct 18, 2009 at 10:14 AM, Chris Ruiz wrote: > On Sun, Oct 18, 2009 at 7:50 AM, Stefan Ehmann wrote: >> On Saturday 05 September 2009 20:29:29 Ed Schouten wrote: >>> * Hans Petter Selasky wrote: >>> > On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote: >>> > > Whenever I press capslock/numlock, the system shortly (< 0.5 ms) >>> > > freezes. >>> > >>> > It might also be because the USB keyboard driver is using Giant, whic= h >>> > can be congested. >>> >>> For half a second? I experience the same issue. I also have the same >>> issue with the Syscons VGA driver when switching windows. Some time ago >>> I talked about this with some other people and it may be possible it ha= s >>> something to do with SMIs. Not sure... >>> >> >> Recently, I got an off-list response pointing me the "Other" section of >> http://wiki.freebsd.org/BugBusting/Commonly_reported_issues: >> "When switching consoles (e.g. Alt-F2 to switch to ttyv1), a 2-3 second = delay >> is experienced" >> >> The suggested workaround (hint.kbdmux.0.disabled=3D"1") also helps in my= case. >> So it's not necessarily USB-related. > > I'm my experience the "switching consoles" delay goes away when you > remove atkbd and related options from your kernel if you only have a > usb keyboard. =A0I don't have that delay with kbdmux left compiled in. > The delay most likely has something to do with locking, re: GIANT. that's somewhat right, actually. last time i looked into this, nor usb nor kbdmux(4) had really nothing to do with the delay. all kbdmux(4) does is executes the same command on all the keyboards attached to the mux. in this particular case, console switching, led toggling, etc. triggers series of ioctl() calls. now, atkdb(4) is "special" is a way that it can be instructed to attach even if no actual keyboard is present. obviously this is done so it is possible to "hot-plug" keyboard and have it work. so, when kbdmux(4) tries to execute ioctl() on non-existent keyboard, atkbd(4) is basically trying to send data to a non-existent hardware and times out. the later is basically the delay people experiencing. it is really NOT required to disable kbdmux(4) completely. just remove atkbd(4) from the mux using kbdcontrol(1). it should have exactly the same effect. once again, all of the above applied only to the case when kbdmux(4) is used with non-existing atkbd(4) keyboard. thanks, max > > -- Chris > > ----------------------------------------- > http://twitter.com/chrisattack > http://chrisattack.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " >