From owner-freebsd-bugs@FreeBSD.ORG Mon Nov 24 10:00:07 2008 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E92821065675 for ; Mon, 24 Nov 2008 10:00:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C72D38FC08 for ; Mon, 24 Nov 2008 10:00:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAOA075a064421 for ; Mon, 24 Nov 2008 10:00:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAOA07Tj064420; Mon, 24 Nov 2008 10:00:07 GMT (envelope-from gnats) Resent-Date: Mon, 24 Nov 2008 10:00:07 GMT Resent-Message-Id: <200811241000.mAOA07Tj064420@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Trevor Roydhouse Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10623106564A for ; Mon, 24 Nov 2008 09:56:57 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 000C68FC08 for ; Mon, 24 Nov 2008 09:56:56 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id mAO9uuf6020934 for ; Mon, 24 Nov 2008 09:56:56 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id mAO9uuNk020933; Mon, 24 Nov 2008 09:56:56 GMT (envelope-from nobody) Message-Id: <200811240956.mAO9uuNk020933@www.freebsd.org> Date: Mon, 24 Nov 2008 09:56:56 GMT From: Trevor Roydhouse To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: misc/129125: psm0: failed to reset the aux device. X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2008 10:00:08 -0000 >Number: 129125 >Category: misc >Synopsis: psm0: failed to reset the aux device. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Nov 24 10:00:07 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Trevor Roydhouse >Release: FreeBSD 7.1-PRERELEASE amd64 >Organization: n/a >Environment: FreeBSD xxx.sentry.org 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #34: Sun Nov 23 20:39:10 EST 2008 root@xxx.sentry.org:/usr/obj/usr/src/sys/xxx amd64 >Description: The psm driver fails to reset the aux device (mouse) when connected through a Uniclass USB-0880 8 port USB-PS/2 KVM Switch (see www.uniclass.com.tw). This results in the mouse not being found and no psm0 device node being created. On inspecting the driver code in psm.c, I noticed the following code: /* * NOTE: some controllers appears to hang the `keyboard' when * the aux port doesn't exist and `PSMC_RESET_DEV' is issued. * * Attempt to reset the controller twice -- this helps * pierce through some KVM switches. The second reset * is non-fatal. */ if (!reset_aux_dev(sc->kbdc)) { recover_from_error(sc->kbdc); restore_controller(sc->kbdc, command_byte); if (verbose) printf("psm%d: failed to reset the aux " "device.\n", unit); endprobe(ENXIO); } else if (!reset_aux_dev(sc->kbdc)) { recover_from_error(sc->kbdc); if (verbose >= 2) printf("psm%d: failed to reset the aux device " "(2).\n", unit); } and, unless I'm sorely mistaken, there's no way the second reset attempt will ever occur because: 1) The second condition is identical to the first and so logically can never be executed; 2) The first condition, if met, is fatal anyway. It would seem to me that this second condition (and associated code comment) should therefore be removed. >How-To-Repeat: Reboot with MS Intellimouse Explorer v2.0 wireless mouse connected to Uniclass USB-0880 KVM. >Fix: The fix was to comment out the fatal result of the aux device not being reset. That is, comment out the line: endprobe(ENXIO); By not making the failed reset of the aux device fatal, the subsequent probing of the aux device is successful, the mouse is correctly identified and the psm0 device node is created. Here is the output once the above line is commented out: psm0: current command byte:0065 psm0: failed to reset the aux device. psm0: found IntelliMouse Explorer psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 Perhaps the more elegant solution would be a kernel option to make the aux device reset non-fatal. I also tried extending the reset delay via the kernel options: options KBD_RESETDELAY=n (n=400-1000) options KBD_MAXWAIT=n (n=10-100) which had been flagged a a possible KVM mouse fix with no success. >Release-Note: >Audit-Trail: >Unformatted: