From owner-freebsd-x11@FreeBSD.ORG Sun Jun 22 09:02:30 2014 Return-Path: Delivered-To: x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2F286FC; Sun, 22 Jun 2014 09:02:30 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BC882330; Sun, 22 Jun 2014 09:02:30 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id w62so5393286wes.24 for ; Sun, 22 Jun 2014 02:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=N2uQetkpeZYCSu/cH+UxqiPi0FJcToASIdJHaAfBJ7E=; b=QtDkllALLY9AkZS+ZZ0jpxl8g/TFd7RKZtOnfaf8Dbq+PVqvtqz/3ulc818u55z6GY rFf1KCBISZeNHT32pTQNLxE/rx9wz/TxMsUxUEyZ+4mG5Vd7ewZMWmcUP6+oElZwCudi S2yZYGsdNH7rsVTBEVjc5kbT28Jf5NxckmBu65tfNGIr/YyGVFfOI2Oz80c2dAMklZw+ d5u8oIMCyONl/TvRcMG9VdBpkVV5cyzHdxIK049GaWW7Zj8Pc4pJ/kORwFPqKU3X5JGJ Qwi3Iox7U8yooYrHNsu4W4bmgpSI712rs1dvhZ1BNBDHL7rhqZ7xTF1MIk8GDM9TnkRC tdWw== X-Received: by 10.180.81.102 with SMTP id z6mr17161713wix.54.1403427748366; Sun, 22 Jun 2014 02:02:28 -0700 (PDT) Received: from [192.168.1.197] (xdsl-205-163.nblnetworks.fi. [83.145.205.163]) by mx.google.com with ESMTPSA id m3sm21743097wik.7.2014.06.22.02.02.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Jun 2014 02:02:27 -0700 (PDT) Message-ID: <53A69BA5.2090100@gmail.com> Date: Sun, 22 Jun 2014 12:02:29 +0300 From: Jukka Ukkonen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: Xorg 7.7 suddenly lost the keyboard References: <53A03A3F.9000503@gmail.com> <53A15FD1.6040206@gmail.com> <53A4013A.2090904@gmail.com> <53A41B08.1080304@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: ray@freebsd.org, "freebsd-x11@freebsd.org" X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 09:02:31 -0000 On 2014-06-20 20:48, Kevin Oberman wrote: > On Fri, Jun 20, 2014 at 4:29 AM, Jukka Ukkonen > 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 >> > wrote: >>> >>> >>> Hi all, >>> I sent the following issue to questions@freebsd.org >>> , but it seems there are no >>> ideas available there. >>> So, in the hope that someone on the list 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 >> > >>> To: 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 >> >> 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 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.