From owner-freebsd-hackers@FreeBSD.ORG Tue May 27 20:32:14 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 4518B106567C for ; Tue, 27 May 2008 20:32:14 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id AAC7E8FC1F for ; Tue, 27 May 2008 20:32:12 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1859416fgb.35 for ; Tue, 27 May 2008 13:32:11 -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=yO0Xs6FSs+enNTtVzpzlAV6HUd7qM3YaBezzE+bZg1c=; b=vIza82BBqG2HK9/Ru7EkYSqDRzW6fOfw2DgLGACzMOghC56w3i2F2Aawtqb2o36yS46jyF61m9nOpESHWU6J32i2gBidqztMtB9lrWs/nqlI9oUUg8Dl2WbUiUSfGLwdADHjs+9uKr15nnKnd1PnVAtxBAnvgTcdaLJliUYDY4c= 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=f27JTeeF3Ly/cit903zsEV/ujPQpYrcJv44ZyhSJ2k7LbMze38tvb/0l2buSvpY4XwXy5jFrBz8E+X8yjgZM6dmnYhK5/37+1EuloXDAXhAh4RDZv4RvrsL4yL3HM2TZPbKaHX3CGO5g3wUiRTFBC+VaN718pIUutVufmzrXY80= Received: by 10.86.89.4 with SMTP id m4mr7749597fgb.55.1211920330866; Tue, 27 May 2008 13:32:10 -0700 (PDT) Received: by 10.86.66.5 with HTTP; Tue, 27 May 2008 13:32:10 -0700 (PDT) Message-ID: Date: Tue, 27 May 2008 13:32:10 -0700 From: "Maksim Yevmenkin" To: rick-freebsd@kiwi-computer.com In-Reply-To: <20080527194554.GA79741@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> Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , m_evmenkin@yahoo.com, 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 20:32:14 -0000 On 5/27/08, Rick C. Petty wrote: > On Tue, May 27, 2008 at 10:34:47AM -0700, Maksim Yevmenkin wrote: > > > > > > Agreed. I was never able to pinpoint it myself, but it certainly didn't > > > show up before kbdmux. > > > > 1) what keyboards are used? usb only, ps2 only or mix? > > > > 2) what mice are used? usb only, ps2 only or mix? > > > > if ps2 devices (i.e. keyboard and mouse) are not used at all, does > > disabling atkbd(4) and/or psm(4) help? > > > I think I stated this in my original thread but let me restate. I've only > noticed the problem when both usbkbd and atkbd are both enabled (as in the > GENERIC kernel) and a USB keyboard (only) is attached. Once I plug in the > atkbd, the problem goes away. The problem also does not exist if just the > atkbd is plugged in with no USB keyboard. right, which (to me) seems to indicate that something is going wrong when kbdmux is trying to work on two keyboards (i.e. ukbd and atkbd) and one of them (i.e. atkbd) is "not present". the problem, as i see it, is that atkbd keyboard is always present even if no physical ps2 keyboard is connected to the ps2 port. i understand that people are doing this in order to be able to "hot plug" ps2 keyboard (which is a bad idea as ps2 port was never designed to be "hot pluggable", imo). now, kbdmux simply switches all slave keyboards into raw mode and pretends to have one keyboard with lots of duplicated keys. it also tries to preserve consistent state on all slave keyboards. so, for example, when num/scroll/capslock etc. key is pressed, ioctl is called to light up corresponding led on the keyboard. this ioctl calls driver specific routine which will talk to the hardware. because kbdmux tries to keep consistent state, it will call this ioctl for every slave keyboard. i suspect that because physical ps2 keyboard is not actually present, the atkbd driver will have to timeout while talking to non-present hardware. obviously the things "work" without kbdmux because without kbdmux it is not possible to have a keyboard without physical keyboard present. well, technically it is possible with atkbd, but then one could not press any keys to trigger atkbd driver to talk back to the non-present hardware. i suppose it is possible to write a simple program that uses console ioctl to flash keyboard leds and try to run it on a machine without kbdmux and no physical keyboard attached to the ps2 port to see if this triggers the same problem. so, as a suggestion, please try to specify 0x1 flag to atkbd, i.e. from atkbd(4) Driver Flags The atkbd driver accepts the following driver flags. They can be set either in /boot/device.hints, or else from within the boot loader (see loader(8)). bit 0 (FAIL_IF_NO_KBD) By default the atkbd driver will install even if a keyboard is not actually connected to the system. This option prevents the driver from being installed in this situation. ... and see if this helps. you wont be able to "hot plug" ps2 keyboards, but i suspect you probably can live without it. > I haven't noticed a problem with the mice, but I've not used a PS/2 mouse > in almost a decade. I have noticed a problem which has hit me rarely on a > 6.x system; perhaps because the problem is not easily reproducable have I > never seen it in 7.x. Basically I've seen the kernel get "stuck" and the > only way to unstick it was to move the USB mouse. Moving the mouse allowed > the interrupt to trigger and things would happen elsewhere in the kernel, > but as soon as I stopped moving the mouse everything else stopped (ata > reads/writes, graphics updates, etc.). Unplugging the mouse was a bad idea > because the plugin event never triggered. I've only witnessed this on > post-kbdmux systems but since it wasn't reproducable in any reliable > fashion, I couldn't pin the problem down. well, i'm not sure it is the same problem, but if you have a way to reproduce it reliably and believe that it is a kbdmux related problem please let me know. thanks, max