misc/129125: psm0: failed to reset the aux device.

Trevor Roydhouse fbsdbugs2 at sentry.org
Mon Nov 24 02:00:08 PST 2008

>Number:         129125
>Category:       misc
>Synopsis:       psm0: failed to reset the aux device.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Nov 24 10:00:07 UTC 2008
>Originator:     Trevor Roydhouse
>Release:        FreeBSD 7.1-PRERELEASE amd64
FreeBSD xxx.sentry.org 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #34: Sun Nov 23 20:39:10 EST 2008     root at xxx.sentry.org:/usr/obj/usr/src/sys/xxx  amd64
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)) {
                        restore_controller(sc->kbdc, command_byte);
                        if (verbose)
                                printf("psm%d: failed to reset the aux "
                                    "device.\n", unit);
                } else if (!reset_aux_dev(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.
Reboot with MS Intellimouse Explorer v2.0 wireless mouse connected to Uniclass USB-0880 KVM.
The fix was to comment out the fatal result of the aux device not being reset. That is, comment out the line:


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: <PS/2 Mouse> irq 12 on atkbdc0
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.


More information about the freebsd-bugs mailing list