Date: Sun, 22 Jun 2014 12:02:29 +0300 From: Jukka Ukkonen <jau789@gmail.com> To: Kevin Oberman <rkoberman@gmail.com> Cc: ray@freebsd.org, "freebsd-x11@freebsd.org" <x11@freebsd.org> Subject: Re: Xorg 7.7 suddenly lost the keyboard Message-ID: <53A69BA5.2090100@gmail.com> In-Reply-To: <CAN6yY1uW5JD1ipEkq=1k4iubVxJk2hshjsdT0d5CbuoUGB=ZsQ@mail.gmail.com> References: <53A03A3F.9000503@gmail.com> <53A15FD1.6040206@gmail.com> <CAN6yY1sYuGZRAYcz7tioJ62690umptjfwfxHWfqi1uOTes7YvQ@mail.gmail.com> <53A4013A.2090904@gmail.com> <53A41B08.1080304@gmail.com> <CAN6yY1uW5JD1ipEkq=1k4iubVxJk2hshjsdT0d5CbuoUGB=ZsQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2014-06-20 20:48, Kevin Oberman wrote:
> On Fri, Jun 20, 2014 at 4:29 AM, Jukka Ukkonen <jau789@gmail.com
> <mailto:jau789@gmail.com>> wrote:
>
> On 2014-06-20 12:39, Jukka Ukkonen wrote:
>> On 2014-06-19 23:26, Kevin Oberman wrote:
>>> On Wed, Jun 18, 2014 at 2:45 AM, Jukka Ukkonen <jau789@gmail.com
>>> <mailto:jau789@gmail.com>> wrote:
>>>
>>>
>>> Hi all,
>>> I sent the following issue to questions@freebsd.org
>>> <mailto:questions@freebsd.org>, but it seems there are no
>>> ideas available there.
>>> So, in the hope that someone on the list x11@freebsd.org
>>> <mailto:x11@freebsd.org> might have some idea what has happened,
>>> I send the same issue to this mailing list as well.
>>> It would be really nice to get my keyboard working with
>>> x11/xorg again.
>>>
>>> --jau
>>>
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: Xorg 7.7 suddenly lost the keyboard
>>> Date: Tue, 17 Jun 2014 15:53:19 +0300
>>> From: Jukka Ukkonen <jau789@gmail.com
>>> <mailto:jau789@gmail.com>>
>>> To: questions@freebsd.org <mailto:questions@freebsd.org>
>>>
>>>
>>>
>>> After digging a bit deeper in the issue the most revealing
>>> symptom is
>>> this error in /var/log/Xorg.0.log...
>>>
>>> [ 585.774] (II) Using input driver 'kbd' for 'Keyboard0'
>>> [ 585.774] (**) Option "CoreKeyboard"
>>> [ 585.774] (**) Keyboard0: always reports core events
>>> [ 585.774] (**) Keyboard0: always reports core events
>>> [ 585.774] (**) Option "Protocol" "standard"
>>> [ 585.774] (**) Option "Device" "/dev/kbdmux0"
>>> [ 585.774] (EE) Keyboard0: cannot open "/dev/kbdmux0"
>>> [ 585.774] (EE) PreInit returned 8 for "Keyboard0"
>>> [ 585.774] (II) UnloadModule: "kbd"
>>>
>>> That "PreInit" is apparently kbdPreInit() and the returned
>>> code 8 stands
>>> for BadMatch.
>>>
>>> What should I make of this?
>>>
>>> --jau
>>>
>>>
>>> On 2014-06-15 17:32, Jukka Ukkonen wrote:
>>>
>>>
>>> Hello everybody,
>>>
>>> I recently had a very peculiar experience with Xorg 7.7
>>> on an amd64
>>> system running FreeBSD 10-stable.
>>> Suddenly any and all X11 applications lost the keyboard.
>>> When using
>>> vanilla vt only the same keyboard
>>> works just fine.
>>> I guess this happened after I had updated the ports tree
>>> using svn and
>>> run "portupgrade --batch -y -a".
>>> Does anyone have any idea what might be the root cause
>>> and how to get
>>> around this.
>>> Previously I have been using HAL configured devices with
>>> Xorg. Now
>>> even explicitly forcing the automatic
>>> device detection off did not bring the keyboard back.
>>> Rebuilding
>>> xorg-server to use devd instead of HAL
>>> did not help either. So, I am confused. Any ideas what
>>> to try?
>>>
>>> Cheers,
>>> --jau
>>>
>>>
>>> Just a few shots in the dark...
>>> Does /dev/kbdmux exist? Did it get dropped from your kernel? Did
>>> you fail to load it? Did your /boot/loader.conf file change?
>>>
>>> How did you change Xorg.conf? Looks like it is trying the right
>>> thing and jut not finding the device.
>>> --
>>> R. Kevin Oberman, Network Engineer, Retired
>>> E-mail: rkoberman@gmail.com <mailto:rkoberman@gmail.com>
>>
>> Indeed it looks like X fails to open the device.
>> The device entries are there as expected, though.
>>
>> crw------- 1 root wheel 0x3d Jun 20 11:07 /dev/atkbd0
>> lrwxr-xr-x 1 root wheel 6 Jun 20 11:07 /dev/kbd0 -> atkbd0
>> lrwxr-xr-x 1 root wheel 7 Jun 20 11:07 /dev/kbd1 -> kbdmux0
>> lrwxr-xr-x 1 root wheel 5 Jun 20 11:07 /dev/kbd2 -> ukbd0
>> crw------- 1 root wheel 0x1b Jun 20 11:07 /dev/kbdmux0
>> crw------- 1 root wheel 0x75 Jun 20 11:07 /dev/ukbd0
>>
>> The only thing I have changed in xorg.conf has been AutoAddDevices
>> on and off, and even that only when the keyboard was already lost in
>> an attempt to test whether hald was somehow out of its mind.
>> Otherwise xorg.conf is as it was before the keyboard was lost.
>>
>> It seems that BadMatch could only be triggered inside
>> OpenKeyboard() in
>> x11-drivers/xf86-input-keyboard/work/xf86-input-keyboard-1.8.0/src/bsd_kbd.c
>>
>> Apparently the message "cannot open ..." originates from this
>> code snippet...
>>
>> 424 pInfo->fd = open(s, O_RDONLY | O_NONBLOCK | O_EXCL);
>> 425 if (pInfo->fd == -1) {
>> 426 xf86Msg(X_ERROR, "%s: cannot open \"%s\"\n",
>> pInfo->name, s);
>> 427 free(s);
>> 428 return FALSE;
>> 429 }
>>
>> It would be useful to have those xf86Msg() calls also report
>> something like strerror(errno) when something goes wrong.
>> Without any further info one can only guess what might be
>> the true reason for failures. At the moment I can only imagine
>> there might be another program like hald holding the keyboard
>> device open still when X tries to open it.
>>
>> --jau
>>
>
> Wow... When I then changed the code snippet above to this...
>
>
> pInfo->fd = open(s, O_RDONLY | O_NONBLOCK | O_EXCL);
> if (pInfo->fd == -1) {
> xf86Msg(X_ERROR, "%s: cannot open \"%s\" (%s)\n",
> pInfo->name, s,
> strerror (errno));
> free(s);
> return FALSE;
> }
>
> what did I find in the Xorg.0.log...
>
> [ 1708.047] (II) Using input driver 'kbd' for 'Keyboard0'
> [ 1708.047] (**) Option "CoreKeyboard"
> [ 1708.047] (**) Keyboard0: always reports core events
> [ 1708.047] (**) Keyboard0: always reports core events
> [ 1708.047] (**) Option "Protocol" "standard"
> [ 1708.047] (**) Option "Device" "/dev/kbdmux0"
> [ 1708.047] (EE) Keyboard0: cannot open "/dev/kbdmux0" (*Device
> busy*)
> [ 1708.047] (EE) PreInit returned 8 for "Keyboard0"
> [ 1708.047] (II) UnloadModule: "kbd"
>
> After terminating the X session and returning to plain vt command
> line I tried running lsof to figure out whether some program was
> holding any kbd devices open. Nope!
>
> This is obviously some sort of timing issue / race condition such
> that something else opens /dev/kbdmux0 slightly before X tries to
> open it and while holding the handle open for a while manages to
> block X from opening kbdmux.
> At the moment I already know that neither hald nor dbus are likely
> culprits because disabling them did not make the keyboard available
> to X.
> Could gnome-settings-daemon try to do something to the keyboard?
>
>
> Gnome-settings-daemon is certainly a possibility.
>
> Can you log in remotely while X is running and use lsof or fstat to
> check on the device?
> --
> R. Kevin Oberman, Network Engineer, Retired
> E-mail: rkoberman@gmail.com <mailto:rkoberman@gmail.com>
Right, I had already done some lsof test while X is running already
and there was nothing helpful there.
Because fstat shows things a bit differently I tried that as well,
but it did not show any obvious symptoms. There were absolutely
no references to any *kbd* devices in the output. Some lines
matching console were shown, but I cannot quite see how any
of them could point out the culprit.
root console-kit-daemon 86344 0 /dev 11 crw-rw-rw- null rw
root console-kit-daemon 86344 1 /dev 11 crw-rw-rw- null rw
root console-kit-daemon 86344 2 /dev 11 crw-rw-rw- null rw
root console-kit-daemon 86344 10 /dev 9 crw-------
console r
root moused 17628 4 /dev 36 crw------- consolectl rw
root syslogd 66915 10 /dev 9 crw------- console w
root moused 44113 4 /dev 36 crw------- consolectl rw
The total lack of references to kbdmux or any kbd devices for that
matter in fstat output made me think again what might have changed
around 2014-05-16 give or take a few of days.
I had really updated consolekit on the afternoon of 2014-06-15,
but there is actually a better culprit.
The vt(9) device was apparently updated on 2014-06-16. It grabs
the kbdmux via kbd_allocate() and sticks to it pretty tightly.
I tested with 'kbdcontrol -K' and 'kbdcontrol -k /dev/kbdmux'
(as root) getting only "Operation not permitted" and "Device busy"
as the responses.
And even if vt(9) were willing to release the kbdmux device when
requested, there is nothing in startx, xinit, or xf86-input-keyboard
to make such a request.
So, AFAIK the culprit holding the kbdmux open is vt. I just did not
even think of having also updated the OS to the latest 10-stable
around the same time when I updated the ports kits.
I guess there is a risk that anyone that update their OS to the latest
10-stable using vt instead of syscons as well as Xorg to the latest
7.7 which depends on vt(9) could start seeing the same lost keyboard
problem when they launch X the next time.
I cc this also to ray@freebsd.org (the author of the commit to vt
on June 16th) hoping for a confirmation for the issue.
Can you test using the latest 10-stable and the latest Xorg?
--jau
PS.
In fact I already have a patch which helps with releasing the kbdmux
device. A lot of the calls to kbd_allocate() and kbd_release() were
passing as the token the keyboard id while other calls to the same
functions were passing as the token a pointer to struct vt_device.
This does not mean, though, that X were yet aware of how to wrestle
the kbdmux device out of vt's grab and then able to open it from within
xf86-input-keyboard.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53A69BA5.2090100>