drabik@lifia.UUCP (Pascal Drabik) (08/06/87)
Can anyone help us ? We encounter difficulties while we make use of our tape-reader on a VAX-750 under UNIX BSD-4.3 operating system. When we are writing or reading files (which size is greater than about 200 K bytes) on or from the tape, we get the error message : +------------------------------------------ | ts0: hard error bn2020 xs0=350<MOT,ONL,IES,PED><6> | xs1=100000<DLT><6> xs2=100000<OPM><6> xs3=40<REV><6> +------------------------------------------ This error happens as well as in multi-user as in single-user mode. It doesn't seem to be a problem of priority of the boards, nor a hardware problem. Small files can be read or written without problems. By another way, reading or writting from or to the tape work very well under UNIX BSD-4.2 O.S. (it is rather easy to switch from one version of the operating system to the other) We have an UNIBUS on which are connected : - 2 disks RA80 and RA81 thru UDA50 controller - 1 disk RLO2 thru RL11 controller (not in use) - 1 NP100 board for Ethernet - 2 DZ11 boards - 2 DHU11 boards - 1 DMF32 board - 1 DR11-W to connect a GRINNEL - 1 tape-reader M890-II (Cipher) thru TC12/FS (TS11 compatible controller) This is our configuration file to build the UNIX's kernel : +------------------------------------------ | # | # LIFIA VAX | # SWAP SUR RA80 ET RA81 | # | machine vax | # cpu "VAX780" | cpu "VAX750" | # cpu "VAX730" | ident LIFIA | timezone -1 dst 4 | maxusers 25 | options QUOTA | options INET | options "TCP_COMPAT_42" | options NS | options IMAG | | config ravmunix root on ra0 | config vmunix root on ra0 swap on ra0 and ra1 | | controller uba0 at nexus ? | controller uda0 at uba? csr 0172150 vector udintr | disk ra0 at uda0 drive 0 | disk ra1 at uda0 drive 1 | controller hl0 at uba? csr 0174400 vector rlintr | disk rl0 at hl0 drive 0 | device dz0 at uba? csr 0160100 flags 0xff vector dzrint dzxint | device dz1 at uba? csr 0160110 flags 0xff vector dzrint dzxint | controller zs0 at uba? csr 0172520 vector tsintr | device ts0 at zs0 drive 0 | device dmf0 at uba? csr 0160400 flags 0xfc | vector dmfsrint dmfsxint dmfdaint dmfdbint dmfrint dmfxint dmflint | device dhu0 at uba? csr 0160500 flags 0xffff | vector dhurint dhuxint | device dhu1 at uba? csr 0160520 flags 0xffff | vector dhurint dhuxint | pseudo-device pty | pseudo-device loop | pseudo-device inet | pseudo-device ether | device dr0 at uba? csr 0172410 flags 0x1 vector drintr | # | device np0 at uba? csr 0162000 vector npintr | # | pseudo-device gmr | # +------------------------------------------ Thank you for any help... Mailing Address : Drabik Pascal LIFIA INPG 46, avenue Felix Viallet 38031 Grenoble CEDEX France Electronic address : drabik@lifia.imag.fr
chris@mimsy.UUCP (Chris Torek) (08/10/87)
In article <2642@lifia.UUCP> drabik@lifia.UUCP (Pascal Drabik) writes: > We encounter difficulties while we make use of our tape-reader >on a VAX-750 under UNIX BSD-4.3 operating system. >... When we are writing or reading files (which size is greater than >about 200 K bytes) on or from the tape, we get the error message : > ts0: hard error bn2020 xs0=350<MOT,ONL,IES,PED><6> > xs1=100000<DLT><6> xs2=100000<OPM><6> xs3=40<REV><6> The important bit here is DLT, data late. > This error happens as well as in multi-user as in single-user mode. >It doesn't seem to be a problem of priority of the boards, nor a >hardware problem. Actually, it *is* a hardware problem, but one that is both caused and cured by software. >[hardware configuration] The configuration listed confirms the problem, which is that you have a 6250 bpi tape drive that cannot tolerate much Unibus access latency. The UDA50/RAxx driver in 4.3BSD was changed to set the DMA burst rate to 4; this is too high for some devices. 4.2BSD does not set the burst rate, which leaves it at 1. There are a number of solutions; the easiest is to lower the burst rate. The system may work with a burst rate of 3 or 2 words, or may require that it be set down to 1. This will slow all disk I/O through the UDA50 somewhat. Another solution is to install my driver (posted to some source group or another in April) and, if necessary, set the `bus hog' (ud_xclu) flag in the TS11 driver structure. Please do not now ask me for the driver; I will post changes or the updated version (whichever seems most appropriate) when I think it is ready---notably, *after* it has been tested on DW780s.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
mangler@cit-vax.Caltech.Edu (System Mangler) (08/12/87)
In article <2642@lifia.UUCP> drabik@lifia.UUCP (Pascal Drabik) writes: > We have an UNIBUS on which are connected : > - 1 tape-reader M890-II (Cipher) thru TC12/FS (TS11 compatible controller) [plus assorted DMA hogs: RL11, DR11W, UDA50, NP100] In article <7931@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > The important bit here is DLT, data late. > > The configuration listed confirms the problem, which is that you > have a 6250 bpi tape drive that cannot tolerate much Unibus access > latency. The UDA50/RAxx driver in 4.3BSD was changed to set the > DMA burst rate to 4; this is too high for some devices. According to the spec sheet in front of me, the M890-II is a 3200-bpi drive, with a recording rate of 160 KB/s. The transfer rate of the cache is settable, up to 120 KB/s. That's not really very high. (It might be useful to check this setting). If the TC12 is anything like the TC13, it may have a switch to select larger DMA bursts. Some brands of DR11W can be even worse DMA hogs than the UDA50. The DR11W should be the last DMA device on the bus. Try moving the TC12 to the first (quad) slot of the Unibus - in the CPU cabinet, not the expansion cabinet - and put the RL11 right behind it. Another possible reason why it worked with 4.2bsd and not with 4.3bsd is that tar et al are now so much faster, hence disk and tape I/O are more likely to overlap and interfere with each other. (The SunOS 3.0 xt driver had a race condition that was brought out just like this). Don Speck speck@vlsi.caltech.edu {rutgers,amdahl}!cit-vax!speck