Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!mit-eddie!genrad!decvax!dartvax!steve
From: steve@dartvax.UUCP (Steve Campbell)
Newsgroups: comp.bugs.4bsd,comp.unix.wizards
Subject: Re: Cant access disks on second UDA50
Message-ID: <6732@dartvax.UUCP>
Date: Tue, 21-Jul-87 12:07:28 EDT
Article-I.D.: dartvax.6732
Posted: Tue Jul 21 12:07:28 1987
Date-Received: Fri, 24-Jul-87 05:23:10 EDT
References: <6683@dartvax.UUCP>
Reply-To: steve@dartvax.UUCP (Steve Campbell)
Distribution: world
Organization: Dartmouth College, Hanover, NH
Lines: 48
Keywords: unibus uda50
Summary: Hardware seems OK, so must be software
Xref: mnetor comp.bugs.4bsd:461 comp.unix.wizards:3359

In article <6683@dartvax.UUCP> I wrote:

>Although conventional wisdom says not to put more than 1 UDA50 per
>unibus, we are trying to do just that.  We have added a second UDA50 to
>the bus and a third-party device called a USI/HRS from a company named
>Shitashi which claims to enhance the unibus bandwidth enough to permit
>the second uda.  The other devices on the unibus are a DEUNA and 2 DZ11s.
>
>For testing purposes, we moved 2 RA81s from uda0 to uda1, so we have...
>
>controller	uda0	at uba0 csr 0172150		vector udintr
>disk		ra0	at uda0 drive 0
>disk		ra1	at uda0 drive 1
>controller	uda1	at uba0 csr 0172550		vector udintr
>disk		ra2	at uda1 drive 2
>disk		ra3	at uda1 drive 3
>
>As far as we can tell, the hardware is working just fine.  
>But ...  if we do a large number of accesses to files on any disk
>USING PATHNAMES, then do a sync, the 2 disks on the second uda cannot
>be accessed, and the command - and terminal - trying to do so hangs
>completely.

Several people replied with suggestions about the hardware, including
adjusting the delay jumper on the UDA50s, swapping the backplane position
of the 2 UDA's, and changing the value of UDABURST in the driver.  None
of these experiments made any difference; the system still hangs as
described.  I am therefore reasonably confident that the problem is not
in the hardware.

Further experimenting (always in single-user mode) has turned up the
following evidence that perhaps someone with more knowledge of the kernel
than I have might be able to use.  The following sequence ALWAYS hangs:

	[reboot]; mount -a; find ...; sync; ls ...

The find searches about 1000 files for a non-existant file name, so it
just chases around the file system.  The ls is of a directory on a disk
on the second UDA50, and it's this ls that hangs.  BUT, the hardware is
NOT hung; a dd of the raw disk done instead of the ls works fine.
Moreover, an extra sync done after the mount will postpone the hang, ie
the ls shown will not hang, but later one will.  A umount/mount sequence
will also postpone the problem for a few minutes only.

So what's going on?  Is the namei cache perhaps involved?  Any suggestions
or pointers toward further tests would be welcome.

						Steve Campbell