Re: Mouse / psm0 via D-Link KVM won't load on 5.4, does on 5.3

From: Harry Coin <harrycoin_at_qconline.com>
Date: Thu, 05 May 2005 14:04:16 -0500
Doug,

I'm not sure I have a 5.3 around anymore.  But I can take the kernel option 
I inserted to delay the reset out of the 5.4 kernel and give you a boot -v 
of it failing to load psm0, and then give you a boot -v of the 5.4 kernel 
with the reset time set to 401 (default is 201) where it has no 
problem.  It would take time but I could do it if that would be 
helpful.  Let me know.

Apropos: I'm not presuming this comes as news to most, but I'd like to 
share a bit of a 'real life' thing that happens for those of us who use 
KVM's.  KVM's let one keyboard, mouse and monitor be connected to more than 
one system box.  Various schemes allow a near instant switch of the screen, 
mouse and keyboard from one system box to another with no cable fussing. 
They are sold with various capacities, some let 2 systems attach, some let 
4, 6, 8 or more attach.   When you live in the world of having that many 
systems in one spot, sooner or later a few more systems show up than 
whatever number of systems the KVM you have supports.  So the higher-end 
KVM's allow for ways to gang KVM's up, so what in a normal case would be a 
system box attached to the rear of a KVM is in fact a cable to the output 
port of an entire further KVM attached to however many systems, or even 
another KVM and so on.  Usually the deepest permitted 'depth' to a KVM tree 
is 8 while the breadth can be limited to 1 (say on an N port KVM, N-1 
attach to real system boxes, N attaches to the next KVM down the 
tree).  The KVM's gang up in a way that minimizes video loss and eases 
selecting the system box desired.  Also KVM's emulate a mouse on all ports 
even when the 'real one' is not attached or any given port is not selected, 
so BIOS reboot logic detects the presence of a mouse at all times without 
regard to requiring the system be selected and so have access to 'live' 
mouse electronic signals at boot time.

The Microsoft OS's are aware of this, their mouse drivers allow for ample 
aux reset settling time as the various KVM's pass signals 'up the chain' 
eventually reaching whatever mouse is attached.   (I've written several 
time-sensitive device drivers for MS OS's so I have some history with this 
stuff.)  The increase in reset wait time needed is still a second or less, 
and it only happens once at boot time.  Seems an acceptable change to suggest.

HTH

Harry


At 10:36 AM 5/5/2005 -0700, Doug White wrote:
>On Mon, 2 May 2005, Harry Coin wrote:
>
> > I've found that 5.4 as of today won't load the psm0 driver if the box is
> > connected through a KVM instead of directly to the mouse.
> >
> > When I plug the mouse directly into the box, 5.4 and 5.3 load psm0 no
> > problem.
> >
> > When I plug the mouse in via the KVM, 5.4 won't load psm0 but 5.3 will.
> >
> > If I plug the mouse in directly at boot time under 5.4, so psm0 loads, then
> > (don't do this at home) hot-unplug it and plug in the kvm-- the mouse works
> > via the KVM.
>
>Can you get boot -v output from both situations? This shows some of the
>probe communication that may indicate why the port isn't probing with the
>kvm attached.
>
>--
>Doug White                    |  FreeBSD: The Power to Serve
>dwhite_at_gumbysoft.com          |  www.FreeBSD.org
Received on Thu May 05 2005 - 17:04:37 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:34 UTC