Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!ittvax!swatt
From: swatt@ittvax.UUCP (Alan S. Watt)
Newsgroups: net.unix-wizards
Subject: Re: system crashes trap type 8
Message-ID: <1033@ittvax.UUCP>
Date: Mon, 26-Sep-83 10:38:57 EDT
Article-I.D.: ittvax.1033
Posted: Mon Sep 26 10:38:57 1983
Date-Received: Tue, 27-Sep-83 04:37:20 EDT
References: astrovax.29
Lines: 52

The first thing to check when you get "trap type 8" coming from some
device interrupt routine in a long-stable kernel is the boot-time
configuration information printed out.  Look for some device which
has dropped a bit in the interrupt vector setting and is now assigned
to the same interrupt vector as some other device.

As the meaning of minor device numbers passed to each interrupt routine
varies from device to device, you can get havoc if you call the wrong
interrupt routine.  I have seen this happen with Interlan Ethernet
boards, where the vector assignment switch is prone to being brushed by
cables on insertion and removal.

Unfortunately, the 4.1bsd autoconfigure routines will not detect two
devices which both claim to interrupt on the same (or overlapping)
vectors.  The last device to claim a vector will get it.

Also the interrupt routines for most Unibus drivers I have seen are
much too trusting of the unit argument they get.  For example, the code
in dz.c (4.1bsd) now reads:

	/*ARGSUSED*/
	dzrint(dz)
		int dz;
	{
		register struct tty *tp;
		register int c;
		register struct device *dzaddr;
		register struct tty *tp0;
		register int unit;
		int overrun = 0;
	 
		if ((dzact & (1<<dz)) == 0)
			return;
		unit = dz * 8;
		dzaddr = dzpdma[unit].p_addr;
		tp0 = &dz_tty[unit];
		while ((c = dzaddr->dzrbuf) < 0) {	/* char present */

			<...>

Clearly, if the 'dz' unit argument passed is out of range for legal DZ
unit numbers, there are numerous opportunities to tromp on random
memory.  If you're lucky, you will get a segmentation violation and a
crash.  If you're not lucky, you will twiddle bits in some essentially
random location.  A check similer to that in "dzopen" would not be at
all out of place.  The problem of the DZ driver is more serious
however, because transmitter interrupts first gets vectored to the
machine language pseudo-dma routine, and range checks will have to be
performed there as well.

	- Alan S. Watt
	{decvax,purdue,lbl-csam,research,allegra}!ittvax!swatt