From owner-freebsd-usb@FreeBSD.ORG Sun Jan 10 23:39:18 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6A0810656B0 for ; Sun, 10 Jan 2010 23:39:18 +0000 (UTC) (envelope-from google@vink.pl) Received: from mail-yw0-f120.google.com (mail-yw0-f120.google.com [209.85.211.120]) by mx1.freebsd.org (Postfix) with ESMTP id 975658FC12 for ; Sun, 10 Jan 2010 23:39:18 +0000 (UTC) Received: by ywh26 with SMTP id 26so3551220ywh.7 for ; Sun, 10 Jan 2010 15:39:14 -0800 (PST) Received: by 10.150.46.7 with SMTP id t7mr2814028ybt.118.1263166074980; Sun, 10 Jan 2010 15:27:54 -0800 (PST) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx.google.com with ESMTPS id 4sm8751322ywg.13.2010.01.10.15.27.51 (version=SSLv3 cipher=RC4-MD5); Sun, 10 Jan 2010 15:27:54 -0800 (PST) Received: by fxm10 with SMTP id 10so7324239fxm.14 for ; Sun, 10 Jan 2010 15:27:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.164.104 with SMTP id d40mr7867893fay.98.1263166070174; Sun, 10 Jan 2010 15:27:50 -0800 (PST) In-Reply-To: <201001101923.16236.hselasky@c2i.net> References: <201001101640.o0AGe37d002491@freefall.freebsd.org> <201001101923.16236.hselasky@c2i.net> Date: Mon, 11 Jan 2010 00:27:50 +0100 Message-ID: <2ae8edf31001101527w91928d0s51bf32ca47c52e7d@mail.gmail.com> From: Wiktor Niesiobedzki To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb Subject: Re: kern/141011: [usb] Encrypted root, geli password at boot; enter key never release X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2010 23:39:19 -0000 2010/1/10 Hans Petter Selasky : > On Sunday 10 January 2010 17:40:03 Wiktor Niesiobedzki wrote: >> The following reply was made to PR kern/141011; it has been noted by GNA= TS. > >> >> =C2=A0Hello Hans, >> >> =C2=A0I've tried to comment out this section in your version of ukbd.c, = but >> =C2=A0to no extent. Still some events get discarded somehow. Shall I ena= ble >> =C2=A0some usb debug-flags to help getting to the core of the problem? > > Hi, > > The information we need is inside ukbd.c . Try to add printfs in code ena= bling > and disabling the keyboard. Especially in the USB keyboard read character > function, and try to figure out where the missing characters are going. Hi, Nothing new in enabling and disabling the keyboard. The only intresting thing is, that although I have only one keyboard, the ukbd_enable is called twice. What I found somehow helping, is some additional printfs in ukbd_read_char. Especially in beginning part: printf("enter ukbd_read_char\n"); if (!KBD_IS_ACTIVE(kbd)) { printf("kbd is not active - exiting\n"); return (NOKEY); } if (sc->sc_flags & UKBD_FLAG_POLLING) { if (!mtx_owned(&Giant)) { /* XXX cludge */ printf("ukbd_read_char: UKBD_FLAG_POOLING is set and giant is not owned - recursing and locking giant\n"); int retval; mtx_lock(&Giant); retval =3D ukbd_read_char(kbd, wait); mtx_unlock(&Giant); return (retval); } } else { /* XXX the keyboard layer requires Giant */ if (!mtx_owned(&Giant)) printf("ukbd_read_char: UKBD_FLAG_POOLING is not set and Giant is not owned -> DISCARDING KEY!\n"); return (NOKEY); } Then i see this message: "ukbd_read_char: UKBD_FLAG_POOLING is set and giant is not owned - recursing and locking giant" Full message is (for entering one character is something like that): ukbd_read_char: UKBD_FLAG_POOLING is set and giant is not owned - recursing and locking giant enter ukbd_read_char a (echo from GELI) enter ukbd_read_char ukbd_read_char: UKBD_FLAG_POOLING is set and giant is not owned - recursing and locking giant enter ukbd_read_char enter ukbd_read_char And supriselingly - no characters were lost, when I was typing my passphare= ses. As far as I know (and I may know wrong - please correct me here) - there is some relation between Giant and printfs (something like - when you printf on console, you have to have a giant) but this is just my wild guessing (maybe from java - where System.out.println is synchronized method). Is it possible, that my printf's affected how Giant is handled within ukbd and thus - I don't see misbehaviour of ukbd now? Or was it just my luck now? (I hardly believe that - I usulally got ~8 characters lost for a boot sequence and now noone). Any hints for now? Cheers, Wiktor Niesiobedzki