From owner-freebsd-current@FreeBSD.ORG Fri Feb 24 23:36:18 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2F0C16A420 for ; Fri, 24 Feb 2006 23:36:18 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65EE043D45 for ; Fri, 24 Feb 2006 23:36:18 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id k1ONaGM27263 for ; Fri, 24 Feb 2006 18:36:17 -0500 Message-ID: <43FF986E.9030205@savvis.net> Date: Fri, 24 Feb 2006 15:36:14 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: [PATCH] kbdmux(4) update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2006 23:36:18 -0000 dear Hackers, i was finally able to trace hard lockup problem with kbdmux(4), ps/2 keyboard and ps/2 mouse under x11. the problem was traced back to the following code in kbdmux(4) == /* read all chars from the keyboard */ while (KBDMUX_CHECK_CHAR(kbd)) { c = KBDMUX_READ_CHAR(kbd, 0); if (c == NOKEY) continue; if (c == ERRKEY) continue; /* XXX ring bell */ if (!KBD_IS_BUSY(kbd)) continue; /* not open - discard the input */ putc(c, &state->ks_inq); } == it turns out that atkbd(4) check_char() method may return "true" while read_char() method returns NOKEY. kbdmux(4) was simply stuck in the dead loop. this is only happening when kbdmux(4), ps/2 keyboard and ps/2 mouse used together, and, here is why: atkbd_check_char() calls kbdc_data_ready(). the later will return "true" if there are pending data in either kbd or aux queue. so, could someone with atkbd(4) and psm(4) knowledge verify this? also there is similar code in genkbd_event(), i.e. == /* read all pending input */ while ((*kbdsw[kbd->kb_index]->check_char)(kbd)) { c = (*kbdsw[kbd->kb_index]->read_char)(kbd, FALSE); if (c == NOKEY) continue; == the following patch should fix the problem with kbdmux(4). please give it a try and let me know if it works for you. == --- kbdmux.c.orig Mon Oct 17 23:38:14 2005 +++ kbdmux.c Fri Feb 24 15:27:51 2006 @@ -250,7 +250,7 @@ while (KBDMUX_CHECK_CHAR(kbd)) { c = KBDMUX_READ_CHAR(kbd, 0); if (c == NOKEY) - continue; + break; if (c == ERRKEY) continue; /* XXX ring bell */ if (!KBD_IS_BUSY(kbd)) == while i'm here, could someone please review the following patch for ukbd(4). this patch makes ukbd(4) to not delay break scancodes in "raw" mode. == --- ukbd.c.orig Wed Mar 30 00:32:41 2005 +++ ukbd.c Thu Feb 23 17:18:37 2006 @@ -1145,9 +1145,7 @@ state = (ukbd_state_t *)kbd->kb_data; if (!(state->ks_flags & COMPOSE) && (state->ks_composed_char > 0)) return TRUE; - if (state->ks_inputs > 0) - return TRUE; - return FALSE; + return ukbd_check(kbd); } /* some useful control functions */ == thanks, max