docs/80843: Suggested doc fix for psm0 / handle driver load failure on some KVM's.

Harry Coin harrycoin at qconline.com
Tue May 10 02:20:03 UTC 2005


>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 <ID>.

>Release-Note:
>Audit-Trail:
>Unformatted:



More information about the freebsd-doc mailing list