*BSD News Article 20996


Return to BSD News archive

Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!decwrl!netcomsv!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: Test of the Intel 8254 shut-down/parity-check command
Message-ID: <jmonroyCDDv0z.EB6@netcom.com>
Keywords: Intel 8254 timer shutdown parity error 
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Date: Wed, 15 Sep 1993 06:50:58 GMT
Lines: 69

 
                This is a condensed version of the internal "doc".
 
========================================================================
 
        Test of the Intel 8254 shut-down/parity-check command
        -----------------------------------------------------
 
version: 1.0.0
date: 09-14-1993
author: jmonroy@netcom.com
 
        Purpose:  Test the for parity errors by shutting down
                  the RAM refresh timer.
 
                  While looking for the reason for DMA overruns
                  in the development of an FDC driver for
                  386bsd, suggestions were made that shutting
                  down the timer has no effect on the system;
                  reasons for this varied.
 
        Compiling: I have made the code transportable.
                   It has been tested with:
 
                   MSDOS
                   -----
                   Zortech Personal C   v. 1.07
                   Turbo C              v. 2.01
                   Microsoft Quick C    v. 2.50
 
                   386BSD
                   ------
                   GNU C++              v. 1.39
 
 
 
        How this works.
        ---------------
                Simply the program issue a command to change
        to mode 4 (described in the notes) with a "count-down"
        value of 0x0a0a (2,570).  This is done to timers 1 and 2,
        the RAM refresh timer and the speaker timer, respectively.
        Timer 0 is left running because most OSes cannot operate
        without a timer for the "deadloop".
 
 
        What should happen.
        -------------------
                On most 286 systems nothing will happen till a
        interrupt is generated (I.E., keyboard pressed) or a RAM
        chip finally loses it's charge.  At this point, some system
        will hang for a long while, some will immediately parity
        error.
                On 386bsd expect a "csh" coredump followed by a
        system panic.  The system will then reboot.  On some systems
        a parity error will never register.
 
 
        What does this prove?
        ---------------------
                Namely that the RAM refresh is controllable via
        the i8254 timer on the IBM/ISA architecture.
 
___________________________________________________________________________
Jesus Monroy Jr                                          jmonroy@netcom.com
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________