From owner-freebsd-current@FreeBSD.ORG Mon Oct 19 20:45:19 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F1B4106568F for ; Mon, 19 Oct 2009 20:45:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id A22E18FC2C for ; Mon, 19 Oct 2009 20:45:18 +0000 (UTC) Received: by fxm6 with SMTP id 6so5296258fxm.43 for ; Mon, 19 Oct 2009 13:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ge8YmJtbJ4RsOeoQm3qfxYsRFr8RtrE8q3EYKnY64A8=; b=xfqJJzgATRm6boW6O8O+resTXYHtVvP15VCDfX+G5IW02BzxN+xhRwlFL/ZBuFU9ai LfBai9JnMYEB/UoAvifLEiv33EFJC1oSp/zByv6bJQR4BllkkhqN8ewhojXp9hbzSnKm K7GgUv17sOnHYoguspaOhS20wHrjxJZQTXMOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=AE//JaHqb5yL/+p5qdzn4Sr0zaAdKAmy8l2MRJmxGYQYCjqenXoZYs4NwkrXbFE4Zt c/5HeNU9ZcyFu8VU0KKNmS3ZLmD9Dsk+4oqw3r6UkW8CXpqU4A/z1mWYIs0Xo5COGn15 uXbO3gKQfNddsOHbBFglKbg2iUts39EOLSrVs= Received: by 10.102.235.5 with SMTP id i5mr2350672muh.36.1255985117168; Mon, 19 Oct 2009 13:45:17 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 7sm125887mup.12.2009.10.19.13.45.15 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Oct 2009 13:45:16 -0700 (PDT) Sender: Alexander Motin Message-ID: <4ADCCFDA.3020706@FreeBSD.org> Date: Mon, 19 Oct 2009 23:45:14 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: current References: <200909051806.07692.hselasky@c2i.net> <20090905182929.GB2829@hoeg.nl> <200910181450.11838.shoesoft@gmx.net> <58c737d70910181014u7c32ffd2s8c0732a707d40a2f@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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 20:45:19 -0000 Maksim Yevmenkin wrote: > 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, which >>>>> 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 has >>>> 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="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. I 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. On one of my systems disabling USB legacy keyboard emulation in BIOS solved the problem. -- Alexander Motin