WEITEK Technical Note 24DD

October 13, 1994

INTRODUCTION

The WEITEK SPARC POWER uP CPU is fully compatible with SunSoft's
SunOS and Solaris operating systems and applications.  The following
is relevant only if you are developing a custom device driver, or
compiling a device driver from source code.  WEITEK is working with
SunSoft and third-party device driver writers to assure continued
compatibility.  If you are using an add-in SBus card and experience
unexpected behavior, contact your board manufacturer and inquire 
about their compliance with this Technical Note.

The following describes an anomaly which can occur if you compile
device drivers for hardware with a particular, unusual
characteristic.


DESCRIPTION

To enhance system performance, the SPARC POWER uP chip set performs
read-ahead from memory.  When a processor register window underflow
occurs, it is possible for the processor to issue a spurious read to
the address in register %o7 of the invalid register window.

Normally, this is entirely harmless.  The results of these spurious
reads are ignored by the CPU, even when they cause a memory fault
through accessing nonexistent memory.  The spurious reads are too
infrequent to have an effect on system performance.

Reading memory, of course, does not change its contents.  Most
peripheral devices are also unaffected by reads.  Only a few devices
alter their behavior on a read.  In such a device, reading a register
can change its internal state: for example, a device might be
designed so that reading its interrupt register cleared all pending
interrupts.  Most devices don't do this.  In fact, we have only
identified one hardware device to date that can exhibit problems due
to spurious reads: the SCSI controller on the SPARCstation 2 and IPX
motherboards.  The problem surfaced briefly in a beta version of
Solaris 2.4.  WEITEK and Sun worked together to implement a
work-around, and the released version of Solaris 2.4 works fine with
WEITEK's SPARC POWER uP, as does every previous version of Sun's
operating systems, both Solaris and SunOS.

Still, the possibility exists that there is an add-in card out there
with susceptible hardware.  The next section describes the work-
arounds.

SOLUTION

Several things all have to be true for the problem to present
itself:

1. The peripheral hardware must be capable of having its state
   changed on a read.

2. The compiler being used must put something other than valid
   return addresses in %o7.  The SunPro 2.0.1 C compiler will use
   %o7 in leaf routines for values other than return addresses.
   The sensitive hardware address MUST END UP IN %o7 for the spurious
   read to affect the hardware.

3. The peripheral memory space must be accessible.  Thus, user
   code is very unlikely to ever exercise this problem.

There are several work-arounds that can be used:

1. Before leaving any device driver routine that references
   a sensitive address of the sensitive device, use an asm
   statement to force zero into %o7:

   asm("        clr %o7");

2. Use a compiler that does not use %o7 for temporary storage
   in leaf routines.

3. Make sure %o7 is not used to hold device addresses, by examining
   the output of the compiler with the -S option flag.  Reordering the
   C source can coax the compiler to use different registers.

4. Hand-edit the assembly output of the compiler to use a
   different register than %o7.  (Swap %o7 with another register
   that is either unused, or never contains the device address.)

IF YOU NEED ASSISTANCE

If you need further assistance, send e-mail to support@weitek.com,
or call WEITEK at 1-408-526-0300.