Re: temporary freezes when pressing capslock / numlock

On 5/27/08, Rick C. Petty <rick-freebsd@xxxxxxxxxxxxxxxxx> 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
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: keyboard mux driver (straw man proposal & code)
    ... i have changed the proposed kbdmux code a bit. ... > i'd like to follow up on keyboard mux driver discussion with some code. ... > as you can see it is not usable from the kernel just yet, ...
    (freebsd-current)
  • Re: temporary freezes when pressing capslock / numlock
    ... and one of them (i.e. atkbd) is "not present". ... keyboard is connected to the ps2 port. ... TVS or line driver protection which could blow the serial driver chips (on ...
    (freebsd-hackers)
  • kbd strugglings
    ... my keyboard dos not respond anymore, doesn't matter if I use kbdmux or not ... then when I compile kbdmux in then my keyboard does not ...
    (freebsd-current)
  • Re: keyboard mux driver (straw man proposal & code)
    ... > i have changed the proposed kbdmux code a bit. ... > much pure keyboard driver. ... > Maksim Yevmenkin wrote: ... >> i'd like to follow up on keyboard mux driver discussion with some ...
    (freebsd-current)
  • Re: HEADSUP: kbdmux(4)/syscons(4) patch is in the tree
    ... kbdmux/sysconspatch was committed to -current. ... the system will be automatically added to the kbdmux. ... will this all just work if I boot single-user with kbdmux ... that have a AT keyboard, a USB keyboard through a local KVM ...
    (freebsd-current)