From: Mohamed K. Ahmed (mkahmed@vsc.teksystems.com)
Date: Wed Oct 23 2002 - 14:36:09 EDT
Many many thanks to Dr. Tom Blinn....
My question was:
> Hi all,
>
> I just came in the morning and found out that out test box AS2100
> running UNIX V5.1 (updated from 4.0G 2 weeks ago) has its system bell
> on continously.
> I tried to find if there is any hang processes or hang keyboard
> buttons, but failed to find any.
>
> Did anyone saw something like this before?
>
> MKMA
________________
I quote the response from Dr. Blinn below
"The system bell is controlled by software, at least in theory. The
code that really controls it is low level stuff inside the kernel.
Other than using an application to send "bell" characters to an app
that controls the keyboard/mouse/screen/"bell", which MIGHT make it
reset, you might have to power cycle to clear it, because it might
be stuck in the hardware.
Most of the PCI based systems (like your AS2100) use a "PC style"
chip set that has the interfaces for the keyboard, the mouse, the
first two serial lines, a driver for the "bell" (which is usually
just a small loudspeaker mounted in the cabinet), and a number of
other primitive functions. Collectively, this stuff is referred
to by many people as the "junk I/O". The "bell" is primitive, it
can be turned on and off and not much more. The routine to ring
the "bell" is associated with the keyboard (since in the older
Digital designed LK200 series keyboards, the bell was actually a
part of the keyboard, so all the software assume that the way you
ring the bell is through a keyboard service routine); that code
just calls a low-level routine called "ring_bell" passing it the
pitch and duration requested. The code is pretty basic, it just
queues up the bell ringing requests, and if this request is the
one at the head of the list, it pokes the registers in the chip
and sets a timer for turning the bell off at the end of the time
for which it is supposed to be rung. Two things could go wrong;
one is that a kernel bug might lose the "turn the bell off" timer
interrupt, but this is VERY unlikely. The other would be that a
request might come in to ring the bell forever, but in fact, the
bell ringing code won't start a duration over one second. So the
most likely problem is stuck hardware. If the hardware works OK
but the "pc_bell_off" call got lost somehow, then a reboot will
clear the situation. As far as I know, there is no other way to
really reset the hardware. Determining what caused the problem
is really difficult in a running system, and difficult even in
a panic-d system (looking at a crash dump), because the hardware
in question is so primitive that it has no status registers or
other ways to query its state, and the software really works in
almost every case (I can't recall ever seeing the bell get stuck
when it wasn't a hardware fault, and it almost never happens in
any case).
Thanks a lot
MKMA
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:57 EDT