From owner-freebsd-doc@FreeBSD.ORG Tue May 10 02:20:03 2005 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2774916A4EC for ; Tue, 10 May 2005 02:20:03 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E416943D66 for ; Tue, 10 May 2005 02:20:02 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j4A2K2UX025821 for ; Tue, 10 May 2005 02:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j4A2K2LQ025820; Tue, 10 May 2005 02:20:02 GMT (envelope-from gnats) Resent-Date: Tue, 10 May 2005 02:20:02 GMT Resent-Message-Id: <200505100220.j4A2K2LQ025820@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Harry Coin Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDAE316A4EB for ; Tue, 10 May 2005 02:13:56 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4E9843D60 for ; Tue, 10 May 2005 02:13:56 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j4A2DuqB013043 for ; Tue, 10 May 2005 02:13:56 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j4A2DujJ013042; Tue, 10 May 2005 02:13:56 GMT (envelope-from nobody) Message-Id: <200505100213.j4A2DujJ013042@www.freebsd.org> Date: Tue, 10 May 2005 02:13:56 GMT From: Harry Coin To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: docs/80843: Suggested doc fix for psm0 / handle driver load failure on some KVM's. X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2005 02:20:03 -0000 >Number: 80843 >Category: docs >Synopsis: Suggested doc fix for psm0 / handle driver load failure on some KVM's. >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue May 10 02:20:02 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Harry Coin >Release: 5.4 RC3 >Organization: >Environment: >Description: psm0, the PS/2 mouse driver, failed to load under all current versions of 5.4, but had no problem on the same box on 5.3. Research showed that the KBD_RESETDELAY kernel option was too small to allow mice connected via a KVM (keyboard, mouse and monitor shared among several system boxes) to reset via the aux port on the atkbd driver. The doc change below shows how KVM users can cause psm0 to load under 5.4. 1) I notice that the psm0 documentation actually documents options that actually only are referenced in the atkbdc driver, and are not used in the psm driver at all, except via a prodcedure call. That can't be good. 2) I agree it would be well to make the KBD_RESETDELAY option something folks can tune from the command line, over against having to compile and install a separate kernel. 3) It would be even better to have the KBD reset delay automagically increase by 50% each pass through a failed reset attempt and have debug writes noting it. Even three or four times through the loop wouldn't cause a meaningful boot time delay, and the change wouldn't affect existing users at all. HTH Harry >How-To-Repeat: Just boot. Happens every time with the generic 5.4 kernel and Dlink KVM. >Fix: --- psm.4 Mon May 9 21:03:15 2005 +++ psm.4.new Mon May 9 20:57:40 2005 @@ -207,7 +207,14 @@ .Nm driver will attempt to reset the pointing device during the boot process. It sometimes takes a long while before the device will respond after -reset. +reset. The driver will wait KBD_RESETDELAY msec for the aux device attached to the keyboard controller hosting the PS/2 port to respond per reset attempt. It will make KDB_MAXWAIT reset attempts before failing. +The default for KBD_RESETDELAY of about 200 is enough for most direcly connected pointing devices. If you are using a device such as a KVM +to share a mouse and perhaps keyboard and montior among more than one system box, or if your pointing +device takes longer than the default to reset, then the driver will not load even though bootup indications indicate the ps/2 pointing device is present. In these cases putting +.Pp +.Cd "options KBD_RESETDELAY=401" +.Pp +in a custom kernel configuration has been helpful. Later versions may make this a tunable system setting to avoid the need to compile a custom kernel. These options control how long the driver should wait before it eventually gives up waiting. The driver will wait @@ -740,7 +747,8 @@ The second line shows the result of the keyboard controller's test on the auxiliary port interface, with zero indicating no error; note that some controllers report no error even if -the port does not exist in the system, however. +the port does not exist in the system, however. If the driver doesn't load but you think the hardware +is working, read the information about the KBD_RESETDELAY option above. .Pp The third through fifth lines show the reset status of the pointing device. The functioning device should return the sequence of FA AA . >Release-Note: >Audit-Trail: >Unformatted: