erek@helios.enea.se (Erik Ekstr|m) (08/21/89)
I am working on a site with one Pyramid 9035 and one Pyramid 9015. The 9035 have mirror disks and both of them have one Megatape (500MB) tapedriver. The controller is IOP/TPE. We are having very much trouble with the Megatape one both machines. 1. Sometimes we get a write error (BOT is found before EOT) on the tape (end of tape) when we're using cpio for dumping the filesystems. 2. We lose the microcode in the TPE once and a while. 3. Sometimes we get a systemcrash when we're re trying to reload the microcode on the living 9035. 4. We get a write error in the middle of the tape quite a few times. 5. The tape differs quite a lot in length. Does anyone know anything about these problems? -- Erik Ekstr|m - ENEA DATA, Sweden - erek@enea.se
steve@lewis.OZ (Steve Pattinson) (08/29/89)
In article <EREK.89Aug21094717@helios.enea.se>, erek@helios.enea.se (Erik Ekstr|m) writes: > > I am working on a site with one Pyramid 9035 and one Pyramid 9015. > The 9035 have mirror disks and both of them have one Megatape (500MB) > tapedriver. The controller is IOP/TPE. > We have a 500 Mbyte Megatape connected to a 9825 and previously a 98xe. We have seen some of the problems you are having in the past although we are reasonably happy with the device now. > 1. Sometimes we get a write error (BOT is found before EOT) > on the tape (end of tape) when we're using cpio for dumping > the filesystems. > This happened here too, although we were using 'dump'. A BOT is suddenly encountered in the middle of the tape. There were various theories about this, but in the end our Megatape service agency fixed the problem without reference to the Pyramid s/w or microcode etc. (New firmware may have been loaded into the Megatape.) I suggest you approach the matter as if it were a fault with the Megatape itself. > 2. We lose the microcode in the TPE once and a while. Yep, seen that. Our current 9825 running OSX4.4 seems to do it less often than the 98xe we had before, but that might be my imagination. I gather it's a generic fault. I've even seen it happen on a Nixdorf Targon 35 (a Pyramid clone) We could usually make it happen with a "mt fsf n" command, where n was of such a value that the search would take many minutes. It seemed that the TPE microcode timed out (perhaps timeouts setup for 9 track tape) and caused the microcode failure. We did have this problem partially fixed in a PTF about a year ago, although long searches still fail, and one has to do many "mt fsf 1"'s instead of going direct to the file you want. > 3. Sometimes we get a systemcrash when we're re trying to > reload the microcode on the living 9035. > We have not had this problem although we have loaded the microcode (as per /etc/brc command) on the fly many times. > 4. We get a write error in the middle of the tape quite a few > times. > Suggests your Megatape need attending to. We have this problem very rarely. > 5. The tape differs quite a lot in length. > More likely changes in efficiency in writing to the tape I would have thought. Have you tried a large block size? _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Stephen Pattinson. | ACSnet => steve@lewis.oz | Ph => +61 3 320 4700 Lewis Construction (Co) Pty.Ltd., 15 Batman St., West Melbourne 3003. Australia
csg@pyramid.pyramid.com (Carl S. Gutekunst) (08/30/89)
>> 2. We lose the microcode in the TPE once and a while. > >Yep, seen that.... We could usually make it happen with a "mt fsf n" command, >where n was of such a value that the search would take many minutes. It >seemed that the TPE microcode timed out (perhaps timeouts setup for 9 >track tape) and caused the microcode failure. Don't keep it to yourself; make sure you RTOC knows when you have problems like this! If you already have told them, tell them again. And tell them that you already told them. :-) Generally RTOC and Sustaining Engineering do a terrific job of bug tracking and fixes. For problems that require R&D involvement, though, they can only be as responsive as the responsible code pounder here in the white tower. (More like a garret than a tower. :-)) You tell RTOC, and they tell R&D, and the managers allocate us more time to work on bug fixes. <csg>
scott@zorch.SF-Bay.ORG (Scott Hazen Mueller) (08/30/89)
In article <82508@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >You tell RTOC, and they tell R&D, and the managers allocate us more time to >work on bug fixes. Let me second this most vigorously. When I was at Pyramid working in the RTOC, I recommended to several customers that they not only report their problems, but that they call in frequently for status updates. Since I don't work for Pyramid anymore, I can also feel free to advise you that if you aren't getting adequate response out of RTOC, call your salesman. If you are planning on buying anything additional from Pyramid and can threaten to hold the order up, you're in a great position from which to deal with them :-) -- Scott Hazen Mueller| scott@zorch.SF-Bay.ORG (ames|pyramid|vsi1)!zorch!scott 685 Balfour Drive | (408) 298-6213 |Mail to fusion-request@zorch.SF-Bay.ORG San Jose, CA 95111 |No room for quote.|for sci.physics.fusion digests via email
adams@swbatl.sbc.com (745) (06/05/90)
I'm having great difficulty installing two Megatape drives on a Pyramid 9815.
We have a single TPE, which had a Cipher drive and a Kennnedy daisy-chained off
of it. This seemed to work ok. We bought two Megatape units, and installed
them in the middle of that chain, so that there are four drives attached to
the TPE. Physically the units are Cipher, Megatape, Megatape, Kennedy.
The Kennedy is terminated & the Megatapes are not.
The Megatapes are configured as Unit 2 & 3 ( SW1 = UDUUUUUU & DDUUUUUU
: where D = DOWN = ON & U = UP = OFF {SW1 leftmost}) and a transfer rate
of 250 KB/sec. (SW2 = UDUDUUUD). The Kennedy is unit 0 and the Cipher
is Unit 1. I'd change the unit select settings to match physical location
but I don't have that data on the Cipher & Kennedy drives.
The Kennedy & Cipher still work fine, and it seems that we can write to the
Megatapes, but the write never completes (e.g. dump never returns).
If I futz with stuff long enough ( killing processes & retrying) I get
a message saying that the write timed out and the TPE is down. After this
I must reboot before I can use any tape drive. We are running OSX 4.4.
Also once I try to write to a Megatape the write select light comes on and
stays on until I power cycle the drive.
Is anyone using a similar configuration sucessfully?
--
uunet!swbatl!adams or adams@swbatl.sbc.com
Tom Adams: 314-235-7459: Southwestern Bell Telephone Advanced Technology Lab
BOOKS WANTED: pre-1930 radio, electrical & scientific topics