HELP - Ikonas (Adage) RDS-3000 hangs kernel on 750 w/ bsd4.2

Liudvikas Bukys bukys at rochester.UUCP
Tue Jul 30 07:51:05 AEST 1985


There are two popular problems with the Adage 3000 (aka the Ikonas).
The one you describe can be fixed with software in the driver.

And, as a free bonus, I'll throw in a hardware fix that prevents the
Ikonas from hanging your machine when you try to use a certain feature.
But, who knows what Adage is distibuting for IK11Bs any more?
So make hardware modifications only after thoughtful consideration,
and at your own risk.

Here are some things assembled from my outgoing mail file....

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

One hanging problem that I know about is the driver's failure to clean
up when interrupted by a signal.  This causes a failure to deallocate a
BDP (buffered data path).  A 780 has 15 of them, so you don't notice it
right away, but a 750 has only 3, so one or two interrupt signals, and
the ikonas will seem to hang, because the next I/O will wait in the BDP
allocation routine, and the needed BDP will never be freed.  There are
two solutions to this.  BRL's solution in their drivers was to make the
driver sleep at a priority <= PZERO, which makes sleep()s
uninterruptible.  (Change the IKPRI definition in ik.c from PZERO+1 to
PZERO.)  My solution to this was to write a version of tsleep (timeout
sleep, which is what my driver uses everywhere) which would catch
longjmp's unraveling of the stack.  Tsleep() used to exist under 4.1,
and did just that, but it disappeared in 4.1c/4.2 and it was easiest
just to write another one.

If you think that this is what's happening, you can verify it by doing
a ps and looking at the WCHAN of the hung process.  It should be equal
to the address of uba_hd[uba_number].uh_bdpwant.  Just verifying that
it's waiting on some small offset from the front of uba_hd should be
close enough for a first check.  "nm /vmunix | grep uba_hd" will tell
you what value that is.

I hopes this helps.

Liud

>From bukys Thu Jun 20 15:05:48 1985
Subject: Re:  tsleep

The 4.1 tsleep uses fields in the user structure that don't exist any
more.  I wanted the installation of the ikonas driver to be
self-contained, so the tsleep I wrote used a field in the ikonas data
structures instead.  Here it is...

Add this to the declaration of the ik_softc[] structure...

-------------------------------------------------------------------------------
#ifdef IKTSLEEP
# define tsleep(chan,pri,seconds) ik_tsleep((chan),(pri),(seconds),dev) /* sleazy, but localized */
#define	TS_OK	0	/* normal wakeup */
#define	TS_TIME	1	/* timed-out wakeup */
#define	TS_SIG	2	/* asynchronous signal wakeup */
	caddr_t	sc_tsleep_chan;	/* channel I'm tsleeping on */
	int	sc_tsleep_rval;	/* return value for tsleep */
#endif
-------------------------------------------------------------------------------

Add this to the driver somewhere...

-------------------------------------------------------------------------------
#ifdef IKTSLEEP
#include "../h/proc.h"
/*
 * Sleep on chan at pri.
 * Return in no more than the indicated number of seconds.
 * (If seconds==0, no timeout implied)
 * Return	TS_OK if chan was awakened normally
 *		TS_TIME if timeout occurred
 *		TS_SIG if asynchronous signal occurred
 *
 * HISTORY
 * 24-Jan-84  Liudvikas Bukys (bukys) at University of Rochester
 *	complete with timeout!
 *	If somebody wants a general purpose tsleep (again), it should be
 *	easy to put tsleep_chan and tsleep_rval into the "u" structure
 *	instead of the ik_softc structure.
 * 16-Oct-83  Liudvikas Bukys (bukys) at University of Rochester
 *	kludged without timeout for now until I understand 4.1c kern_time better.
 */

ik_tsleep_timeout(dev)
int dev;
{
	register struct ik_softc *sc = &ik_softc[IKUNIT(dev)];

#ifdef IKDEBUG
	printf("ik%d: TSLEEP TIMEOUT\n", IKUNIT(dev));
#endif
	sc->sc_tsleep_rval = TS_TIME;
	wakeup(sc->sc_tsleep_chan);
}

ik_tsleep(chan, pri, seconds, dev)
caddr_t chan;
int pri, seconds;
int dev;
{
	label_t lqsav;
	register int n;
	register struct ik_softc *sc = &ik_softc[IKUNIT(dev)];

	n = spl7();
	sc->sc_tsleep_rval = TS_OK;
	sc->sc_tsleep_chan = chan;
	if (seconds)
		timeout(ik_tsleep_timeout, dev, seconds*hz);
	lqsav = u.u_qsave;
	if (setjmp(&u.u_qsave)) {
		sc->sc_tsleep_rval = TS_SIG;
#ifdef IKDEBUG
		printf("ik%d: TSLEEP SIGNAL\n", IKUNIT(dev));
#endif
	}
	else
		sleep(sc->sc_tsleep_chan, pri);
	u.u_qsave = lqsav;
	if (seconds)
		untimeout(ik_tsleep_timeout, dev);
	splx(n);
	return(sc->sc_tsleep_rval);
}
#endif IKTSLEEP
-------------------------------------------------------------------------------

And then make sure the code uses tsleep(), and not sleep().

Liud

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

>From bukys Wed Feb 13 12:20:39 1985
Subject: self clearing bps interrupt fix

Trying to use the BPS-interrupts-the-VAX feature of the Ikonas almost
invariably hangs the VAX enough to require power-down.  This fix to the
IK11B fixes that problem.  We got the same fix from two different
sources, one in Bell Labs and one in Adage.

We've installed it and have had no problems.

Please acknowledge so that I know that this is the right mail address.

Liud

-------

	Self clearing BPS interrupt change on ik11b.

	Cut and lift up the following:
		1. D8 pin4
		2. D8 pin1
		3. D11 pin17
		4. F4 pin2

	Connect the following:
		1. D8 pin4 to D7 pin4
		2. D11 pin17 to D8 pin5
		3. F4 pin2 to D8 pin5
		4. D8 pin1 to E5 pin8

	Tie together following 3 pins: (on back of PC)
		1. E5 9,10,11

	Connect the following:
		1. E5 pin12 to E9 pin4
		2. E5 pin13 to F2 pin8

	DONE.

-------

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Liudvikas Bukys
rochester!bukys (uucp) via allegra, decvax, seismo
bukys at rochester (arpa)



More information about the Comp.unix.wizards mailing list