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