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