netnews@wnuxb.UUCP (Heiby) (04/28/85)
Unix Technical Digest Sat, 27 Apr 85 Volume 1 : Issue 50
Today's Topics:
Administrivia
750 not rebooting
SYS V.2.2 virtual info wanted
UNIX Attached Processors
TU78 Tape Drive Problem.
----------------------------------------------------------------------
Date: Sat, 27 Apr 85 22:25:29 GMT
From: Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP>
Subject: Administrivia
This digest includes an article which discusses a problem with a tape drive
on a VAX system. I'm not really sure at all that it belongs here, as it
seems to be only loosely associated with the Unix system. Looking through
the list of newsgroups, I could not find anywhere else that seemed to be
a better spot. If a group net.hw.vax existed, then it would go there.
In the future, I plan to reject articles with this type of slant. Perhaps
the VAX users out there should look into starting up a hardware discussion
group (maybe mod.hw.vax?). If I'm missing something, let me know. Thanks.
Ron.
------------------------------
Date: Fri, 19 Apr 85 01:31:23 est
From: Gene Spafford <gatech!spaf>
Subject: 750 not rebooting
In digest #40 (<477@wnuxb.UUCP>), the following articles appeared:
>... the 750 repeatedly fails to reboot after a panic. It
>will load the boot, the vmunix, list the devices, and then just sit
>there. Upon typing a carriage return, the system responds with:
>"Automatic reboot in progress..." and then continues on its merry way.
I had the same problem with our 3 750s and it was really baffling me.
The problem is a bit obscure -- it's caused by your console! (You are
probably running with Letterwriter 100's, or equivalent). What happens
is that the startup messages come too fast for the console, and it
automagically sends a control "S" to the system so its buffers don't
overflow. However, Unix has not started polling the console yet, so the
^S isn't taken from the device register. When the console sends the
^Q almost immediately, it gets thrown away because the register is
already full. The overrun bit gets set, but it is ignored by the
console routines. When Unix does poll the console the first time, it
finds the ^S and halts output -- stopping the output (and thus the process)
from the init process before it can finish the startup.
How's that for obscure? The fix is simple -- configure your console
so it doesn't send out control S's and Q's. Taking the Letterwriter
out of "letter" mode and into "draft" mode also works in many cases.
Credit for finding the fix originally must go to Paul Manno and Dan
Forsyth of Medical Systems Development (msdc!paul, msdc!dan) who
tell a wonderful horror story about DEC field service trying to
locate this problem....
---
Gene Spafford
The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332
CSNet: Spaf @ GATech ARPA: Spaf%GATech.CSNet @ CSNet-Relay.ARPA
uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spaf
------------------------------
Date: Fri, 22 Mar 85 13:31:49 GMT
From: Gareth Howell <decvax!mcvax!ukc!stc-a!idec!howellg>
Subject: SYS V.2.2 virtual info wanted
Hi There,
This is a question from someone (me) who isn't too sure of his
ground, so please be gentle.
Q: Is sys V.2.2 (virtual memory) available anywhere yet.
Q: Has anybody got it up and running on a 68000 or better still
a 68020, and if so what MMU have you used, and what sort of
improvement have you experienced over a swapping kernel.
Any tips and/or warnings about porting V.2.2 would be gratefully
received. If I get any decent replies I will post the results.
Please mail me with any replies. Thanking you in advance.
--
Gareth H Howell <howellg@idec.UUCP>
<UK>ukc!stc-a!idec!howellg
STC IDEC LIMITED Stevenage Herts England (0)438 738294
------------------------------
Date: Thu, 4 Apr 85 19:05:11 pst
From: ihnp4!alberta!ubc-vision!winston!pajari (George Pajari)
Subject: UNIX Attached Processors
> we are looking for micros to hook up to the vax for text
> processing type jobs to take some of the loading off of the computers.
> ...ihp4!tellab1!tellab2!smith
> todd smith
A company exhibiting at UniForum in Dallas had a board which included a
CPU and memory that plugged into a VAX and ran compiles/troffs/etc.
offloading the host VAX. The bus connection also got around the speed
problem of linking the attached processor using RS-232. I think the company
is called Avalon Computer Systems, Pasadena, CA (818) 796-0861.
No experience with the unit but would love to hear comments from
anyone who has.
George Pajari
{ihnp4!alberta, decvax!microsoft}!ubc-vision!winston!pajari
------------------------------
Date: Thu, 11 Apr 85 11:00:39 cst
From: fidder@isucs1.CSNET
Subject: Re: TU78 Tape Drive Problem.
Back around Christmas I posted a note concerning a problem I was having
with a DEC TU78 tape drive under 4.2. At that time I received several
comments many of which were from people having the same problems.
Well after several months a new DEC FE finally decided he was going to
fix the problem no matter how long it took! The moral of this story is
that he did indeed correct the problem, and I hope that anyone else having
the same problem finds this useful.
-----
Initial Posting:
> I have a problem with a tu78 tape drive; here are the symptoms:
> Returns a hard error when "dumping" at 6250
> mu0: hard error bn1440 mbsr=3080<DTCMP,DTABT,MBEXC> er=6519 ds=162200<RDY,PRES,ONL,BOT,AVAIL>
> note: bn varies from 400 to 30000.
> Problem seemed to occur after we had an air-conditioner breakdown,
> but I am not 100% sure of this.
> Doesn't return any errors when "tar"ing at 6250 or "dump"ing at 1600bpi
> Dec ran diag. and swapped read & write boards with no luck.
> They gave the drive a clean bill of health, and said dig a little
> further and call when you have more information... Well I am digging ...
> Has anyone seen this problem before, or can decode the error code
> given ?
The problem turned out to be a bad port module in the TM78 (M8955). After
swapping this board all problems went away.
-----------------------
Here is a summary of comments that I received on the original posting:
-----------------------
I have a pair of tu78's, one of which has all sorts of troubles, and I have
had to teach my dec field engineer about a neat little book I have around
that he was surprised to find not only told us what was wrong, but was
actually a standard dec manual he wasn't familiar with. I refer to the
'peripherals handbook', order code EB-20443-20. We seem to have gotten
one with a 780 a couple of years ago, although last years 780 didn't have
one. The manual describes all the registers of all the devices
in great detail. (we were actually taught about it by a Systems Industries
FE who was trying to figure out what was wrong with their massbus controller
emulation on our machine - I've found it invaluable since then.)
mu0: hard error bn1440 mbsr=3080<DTCMP,DTABT,MBEXC> er=6519 ds=162200<RDY,PRES,ONL,BOT,AVAIL>
Your message shows nothing unusual except for the non-zero
contents of the 'er' register. An examination of the description of this
register yields a 'data transfer failure code' and a 'data transfer
interrupt code' - the top and bottom 6 bits of the word respectively.
These are both 31(octal - the error message has them in hex), so looking
in the following table (P411-420 of my 81-82 manual) yields :
interrupt code of 31 => 'TU fault A - transport has failed'
given above interrupt, failure code of 31 indicates a failure described
as 'Read path terminated before entire record was written'. Try giving
that info to your FE and see if he can do anything with it - at least it's
specific.
Good Luck
Tom Quarles
ucbvax!quarles
quarles@ucbcad
-------------------------
Date: Thu, 17 Jan 85 10:31:05 est
From: umn-cs!ihnp4!ulysses!ggs (Griff Smith)
Subject: Re: TU78 Tape Drive Problem.
My TM78 user guide says the error is "TU Fault A, Failed to write
density ID burst correctly", which says the drive is broken.
Berkeley has a new TU78 driver that translates the error codes
into English; you might ask them whether you could have an
advance copy of it. The driver also does better error recovery.
Griff Smith, AT&T Bell Laboratories, ...ihnp4!ulysses!ggs
[I have not yet asked for the new driver. If anyone has this could they please
send a copy, or indicate who one might contact for more info.]
-------------------------
Ted Fidder
Iowa State University
Ames Iowa
USENET: ...umn-cs!fidder
CSNET: fidder@iowa-state
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)