[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
1Re: Customer Reports0
- To: gooch%tijeras.SW-SW.dialnet.symbolics.com@RIVERSIDE.SCRC.SYMBOLICS.COM
- Subject: 1Re: Customer Reports0
- From: miller@SOL.CS.ROCHESTER.EDU (Brad Miller)
- Date: Wed, 5 Dec 1990 17:55:00 -0500
- Cc: miller%SOL.CS.ROCHESTER.EDU@RIVERSIDE.SCRC.SYMBOLICS.COM, barmar%Think.COM@RIVERSIDE.SCRC.SYMBOLICS.COM, mac%trantor.harris-atd.com@RIVERSIDE.SCRC.SYMBOLICS.COM, slug%ai.sri.com@RIVERSIDE.SCRC.SYMBOLICS.COM
- Character-type-mappings: (1 0 (NIL 0) (NIL :CONDENSED NIL) "CPTFONTC") (2 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI")
- Default-character-style: (:FIX :CONDENSED :NORMAL)
- Fonts: CPTFONTC, CPTFONTC, CPTFONTI
- In-reply-to: <19901205024833.9.GOOCH@TIJERAS.SW-SW.Dialnet.Symbolics.COM>
- Organization: University of Rochester, Department of Computer Science
- Phone: 716-275-1118
- Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
- Reply-to: miller@SOL.CS.ROCHESTER.EDU
- Sender: miller@SOL.CS.ROCHESTER.EDU
Date: Tue, 4 Dec 90 20:48 CST
From: William D. Gooch <gooch@TIJERAS.SW-SW.Dialnet.Symbolics.COM>
Sorry, I meant to say that if you are running under the new flods and create
a FEP file (e.g. :create fep file, or copying worlds), you will run into
this problem. The work around is to boot under the old flods (it will handle
it fine). Don't ask me why, but it does happen.
I still don't understand. Are you saying that the problem is 2caused0
by creating FEP files for the new FLODs while running a world that was
booted using them? If so, does this imply that booting with the old
FLODs and creating files for the new ones will allow me to then run
successffully with the new ones? This would not be inconsistent with
my experience so far, although I'd have to see it work before I really
That is consistant with the explanation our CE gave me. His claim is that on
some very few machines (reason undetermined) the format of the disk is
readable with the new FLODs, however, when the FEP file system is written to
in any way (by genera when running the new Flods) the format becomes
corrupted. The session where the write occured will continue to run fine,
but the next boot will fail during clear machine.
I don't claim to either understand this or beleive it. I do know...
1) we have two identically configured 40s. One exhibits the abberant
behavior and one does not.
2) If the boards are swapped between the machines, the problem stays with
the frames, not the boards.
3) unplugging the disk that was modified by Genera when booted under the new
Flods (assuming only one) will allow the machine to come up. Also booting
under the old Flods works.
4) replacing the (faulty) disk with a new one (140 swapped for 190) was fine
until we installed the new microcode files on the disk (running under the
new flods). The next boot caused the failure. Using the old flods we could
reformat the disk. Then we used the new flods to reformat the disk again
(couldn't do this is one step because you have to run clear machine b4
loading the microcode, and we got the error). Note that this new disk was
factory formatted for 7-2, so presumably, they used the old flods.
5) we then brought the machine back up with the new flods, and tried adding
a paging file and then rebooting. It succeeded.
6) Trying to produce the failure on the other 40 didn't work.
7) Symbolics took away our 140 disk from step #4 above for further research.
8) I've heard nothing since.
Hope this helps (whew!).
Brad Miller U. Rochester Comp Sci Dept.