Date: Tue, 14 Jun 2005 08:34:12 +0200 From: "Norbert Koch" <NKoch@demig.de> To: "Maksim Yevmenkin" <maksim.yevmenkin@savvis.net> Cc: "Freebsd-Hackers@Freebsd.Org" <freebsd-hackers@freebsd.org> Subject: RE: using vkbd device Message-ID: <001e01c570ab$13e1a280$4801a8c0@ws-ew-3.W2KDEMIG> In-Reply-To: <42ADB4F8.5040701@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > seems to work, although I still have some stability issues with
> > dynamically attaching/detaching a usb keyboard. For your reference I
>
> would you share with us what sort of issues you are having? feel free to
> move this into private email if you are not comfortable discussing it on
> public mailing list.
Hello Max,
I'm not yet finished with that issue, but it is _not_ related to kbdmux.
Here is my scenario:
An embedded device with a builtin at type keyboard and a usb connector.
From usbd I call attach/detach scripts for ukbd.
<pseudo-code>
Attach: kbdcontrol -K
kbdmuxctl -m /dev/kbd2 -ak 0 # at
kbdmuxctl -m /dev/kbd2 -ak 1 # usb
kbdcontrol -k /dev/kbd2
kbdcontrol -l <specificlayout>
Detach:
kbdcontrol -K
kbdmuxctl -m /dev/kbd2 -rk 0 # at
kbdmuxctl -m /dev/kbd2 -rk 1 # usb
kbdcontrol -k /dev/kbd0
kbdcontrol -l <defaultlayout>
</pseudo-code>
The ukbd-specific detaching only works, because I implemented something in
ukbd.c,
that Hans Petter Selasky [hselasky@c2i.net] suggested in thread "usbd.conf:
detach ukbd".
(See the patch files, I posted there)
When the kernel panics, it does this in usb0 kernel thread.
I figured out that this is only related to connecting/disconnecting
the usb keyboard. It panics without kbdmux loaded and it panics with
unmodified ukbd.c. So I'll have to try to remote debug it, as
my embedded device has no swap space at all and so no core dump device
(256MB flash/256 MD dram).
> no problem. in one of your previous emails you have been concerned about
> possible keyboard interrupt miss (in vkbd(4)). kbdmux(4) have the same
> issue. is that something you just did not fix yet, or it is not a
> problem anymore? in my local tree a added an extra callout that goes 10
> times a second and queues interrupt if needed. also i'm curious why do
> you use splhigh() instead of spltty()? is this an issue with usb? (not
> sure which spl level usb runs on in 4.x)
I didn't see any missed keys. I just think it could happen in theory.
There is no special reason for using splhigh(). Usb has - as far as I know -
its own splusb(). I'm not a kernel expert, so I'm not sure, if spltty()
would be ok here. The thing I not yet understand is, in what context will
taskqueue_swi be executed? Is it some process context?
Norbert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001e01c570ab$13e1a280$4801a8c0>