Date: Tue, 27 May 2008 13:32:10 -0700 From: "Maksim Yevmenkin" <maksim.yevmenkin@gmail.com> To: rick-freebsd@kiwi-computer.com Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick <koitsu@freebsd.org>, m_evmenkin@yahoo.com, Fraser Tweedale <frase@frase.id.au> Subject: Re: temporary freezes when pressing capslock / numlock Message-ID: <bb4a86c70805271332l7d0424dau1e498e41f2c92a6b@mail.gmail.com> In-Reply-To: <20080527194554.GA79741@keira.kiwi-computer.com> 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> <bb4a86c70805271034y5472efadsf239fac2995161e0@mail.gmail.com> <20080527194554.GA79741@keira.kiwi-computer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/27/08, Rick C. Petty <rick-freebsd@kiwi-computer.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70805271332l7d0424dau1e498e41f2c92a6b>