Subject: Re: options "BLINK" in config file for kernel?
To: None <,>
From: Michael C. Richardson <>
List: current-users
Date: 01/20/1999 11:03:40

>>>>> "Kurt" == Kurt J Lidl <> writes:

    >> Perhaps the reason that some have suggested the lights blink faster as
    >> the load gets higher is that the current range is 1s -> 2s -> 3s -> 4s
    >> and that people don't percieve phenomenon under 1Hz very well.
    >> Perhaps a suggestion would be to start the blink at a faster rate at
    >> load=0, like 10 blinks per second, and get slower as load goes up
    >> [...]

    Kurt> The original hack made to 386bsd (0.0), I remember well.

    Kurt> It was a change to the idle loop.  Basically, there was a static
    Kurt> counter in the idle loop, that was incremented each time the idle
    Kurt> loop was entered.  Every 4 or 8 (something that is easy to divide
    Kurt> via a shift :-) counts, the led output was shifted one position in
    Kurt> the direction it was going, or reversed in direction, and also
    Kurt> shifted a position.  (Otherwise, it would have an annoying "lag" at
    Kurt> the end bits in the LED display.)

    Kurt> (Of course, it was entirely machine dependent, and just smacked the
    Kurt> correct values into the latch on the parallel port.)

  Since there seems to be so much memory of this, I extraced my old tar
file and stuck it at:

  (give it until noon EST for my web server to do the CVS checkout)

  Basically it did:

	call	_spl0
	cmpl	$0,_whichqs
	jne	sw1
	call	_moveled
#endif /* CYLONLED */
	hlt		# wait for interrupt
	jmp	idle

	pushl	$sw0
	call	_panic

  [Andrew Low,, aka hacked this code with me
in... August 1992 after some pizza and a bunch of beer. Soldering drunk...]

  And yes, it hacked the port directly.
  The theory was that the only time one spends in the idle routine is
when the CPU has some idle time. The clock interrupt breaks the hlt
instruction HZ times per second and this provides the basic "fast" rate
of the movement. 
  If the CPU is busy, then the clock interrupt won't be interrupting in the
idle routine, so the LED's don't get moved. It worked well. I don't have
this code in any kernels as I don't have systems in places where I can 
see them (intentially! since they make noise). I do like mouse's stuff for
Sun 3. Very distinct from the SunOS stuff... At one point very useful in 
determine what OS a stack of Sun3s was running.

  The problem with this routine is that if you have a system that is low
in CPU load, but *HIGH* in interrupts then the LEDs go *FASTER* even though
the CPU may not be that loaded.

   :!mcr!:            |  Network and security consulting/contract programming
   Michael Richardson |         Firewalls, TCP/IP and Unix administration
	ON HUMILITY: To err is human, to moo bovine.

Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface