Mike Smith wrote:
> > Here is the _precise_ problem with older firmware:
> > The Belkin KVM switch uses the "on->off->on" or "off->on->off"
> > of this LED to signal a port change character is coming next,
> > and times out the port change request only after a little
> > while.
> Ah, so the problem is actually a design defect in the Belkin switch.
> Nice to have that part confirmed.
Toe-may-toe, Toe-mah-toe. Other vender's hacks are no
better; if there's a design defect in the switch, it's that
it doesn't take the double scroll-lock, instead of using the
LED from the host, such that if it's wedged, you have to
manually hit the "next console" button. On the other hand,
I can force a console switch from software on a machine by
toggling the scroll lock LED, and then forcing the keyboard
to send me a key-down for a digit by priming its buffer, which
is really handy if you want to do an automated rolling demo
for a trade show, etc..
> > The fundamental problem here is that FreeBSD _resets_ a
> > keyboard which has already been correctly reset by the BIOS,
> > if it is present.
> You can't be sure of this. Just as we reset everything else we
> talk to, we reset the keyboard. Specific examples where *not*
> resetting things gets us into trouble can typically be found by
> looking for "when I reboot from Windows XYZ doesn't work".
I think that depowering the thing and repowering it at POST
is enough to know its state...
The only historical fly in this ointment is that some old
systems didn't put a real flip-flop on the CPU reset line,
and latch it as a result of getting the keyboard reset
command from the keyboard controller. Most of these are
using XT keyboards, though, which won't work with any KVM
switches out there today, since the controller chip is on
the wrong side of the keyboard connector cable. 8-).
> > The FreeBSD keyboard detection is another matter; FreeBSD
> > will assume that there is no keyboard, and try to "helpfully"
> > drop you into serial console mode.
> No it won't, unless you explicitly configure it.
This is the "-P default" case; most people are not running
that recent a -current.
> > Some of this _used_ to
> > be mitigated by checking for the "extended keyboard bit" in
> > the "keyboard identify" BIOS call, but this was a problem
> > for people with antique keyboards.
> This is not the problem, as I have already mentioned in another message.
> BIOS vendors have *stopped* setting this bit.
I've checked 5 machines, including the Tyan and SuperMicro
(the latter is AMI BIOS), as well as my Sony VAIO... all set
That said, I agree that it's not a very good way of detecting
a keyboard being out there... 8-(.
> > My suggestion for a probe in this case would be to set up
> > a different handler for the reset signal, and then ask the
> > keyboard to send the reset signal. If it does, then there
> > is a keyboard present.
> Keyboard probing is a dead loss, which is why we don't do it
> by default.
I wish we could avoid resetting, as well. I think that the
BIOS you are seeing not setting the bit has decided to not
do the probe, too. That's understandable, given that KVM
switches are becoming more and more common: they probably saw
the same thing FreeBSD is seeing with these boxes.
> > More ideally, the FreeBSD box would detect whether or not
> > the video card had been disabled, and use _that_ to decide
> > whether or not to use a keyboard. It would become the job
> > of the video driver -- be it a regular driver, or be it an
> > LCD driver -- to make the distinction.
> There is no standardised way of detecting whether a display
> has been "disabled".
One gross way that I have never seen fail is to make an INT
10 call to set a standard (the default) video mode, and note
that the registers indicate a failure.
> > Absolutely ideally, FreeBSD would come up with the boot code
> > on _both_ (this is an option), and then be told by the user
> > to not use one of them -- or boot using _both_, until told
> > to do otherwise.
> We've tried this already; people didn't like it.
Well, I think the only option left here is explicit configuration.
The boot loader doesn't reset the keyboard, does it? I've
never seen the LEDs "flash dance", between the PST and the
FreeBSD keyboard probe, anyway. Perhaps we could elect to
reset the keyboard from the boot loader, as an option, and
not do it by default...
> > This would _also_ solve the Alpha serial console dance.
> Actually, it wouldn't, since we use the SRM console for quite a ways, and
> SRM doesn't do multi-source console I/O. (And when you have a version of
> SRM that allows you to 'pull' the console by sending a few keystrokes,
> you can't work out where it's actually directed anyway.)
Ugh. I was thinking more in terms of activating both drivers,
and sinking both inputs to the same /dev/console... not pretty,
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message