knudsen@ihwpt.ATT.COM (mike knudsen) (08/27/87)
In the last couple of days, My Coco-3 Level 2 system
has taken to creating "poison files."
(I think my earlier reported c.asm bug may have been
caused by a poisonous program.o file, tho I was able to LIST it.)
The symptoms of a poison file are that any attempt to
List or even Delete it will cause that window to hang.
The disk stops turning, but you can't BREAK the task.
You can't KILL it from another window because it still
has I/O pending. The poisoned rogue task continues
to soak up CPU cycles as evidenced by sparkles on other
screens.
Other windows can still do disk I/O normally.
This shows that the hung code is not in a critical section
of RBFMAN or CC3DISK.
However, if asked to do something to that same file
that hung the other window, your next window may hang too.
COPYing a poisoned file tries for a while, makes sick
twitching short moves of the disk head, then reports
a read error. Usually does NOT hang.
I noticed that DIR E reports poison files as being either
0 bytes long or many more bytes than they are (like 4000 Hex).
One theory is that the disk directory, or the RBFMAN routines
that handle it, have conflicting notions about the file's length;
the sector map for that file runs out so RBFMAN refuses
to deliver any more data to your task, but since the byte count
is less than the phony length, RBFMAN refuses to issue an EOF
to your task. I just hope my file system isn't corrupted;
a DCHECK reported everything OK.
A reboot so far has unpoisoned the file long enuf to delete
or copy it.
I don't know whether this is disk controller hardware problem,
RAM upgrade, bit-rot in OS9, or a subtle bug.
It usually doesn't happen till the system is pretty warm.
Maybe I'll have to run Commo-64 style, with the Coco case top off.
Or relocate that voltage regulator, stupidly buried in the
worst-ventilated part of the case.
BTW, the disk drive that gives me the most trouble does not
have a head-load solenoid, so that's not the problem.
Maybe the problem will disappear next week when my Sardis arrives.
--
Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T)
Delphi: RAGTIMER CIS: <memory failure, too many digits>
"Just say NO to MS-DOS!"pete@wlbr.EATON.COM (Pete Lyall) (08/29/87)
In article <1939@ihwpt.ATT.COM> knudsen@ihwpt.ATT.COM (mike knudsen) writes: >In the last couple of days, My Coco-3 Level 2 system >has taken to creating "poison files." > >The symptoms of a poison file are that any attempt to >List or even Delete it will cause that window to hang. Mike, Sounds a lot like file busy stuff - error #253. This and related symptoms can be caused by either a non-sharable file, or a file opened for write, etc. The file lengths of 0, $2000, $4000, etc. that you are seeing are products of the RBF manager value IT.SAS which preallocates that much space ($2000 = 32 sectors.. common for an HD) on each request for additional disk real estate. Now *why* you're getting into a busy files scenario, I don't know. Shell redirection to a file causes locking and blocking on that file. The bottom line is, if it's a NEW problem, and if it occurs primarily after the machine warms up, and you have altered nothing else ( i.e. rewritten RBF...), then you probably *do* have a hardware problem. -- Pete Lyall Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)
vodall@hpfcdq.UUCP (08/30/87)
> I don't know whether this is disk controller hardware problem, > RAM upgrade, bit-rot in OS9, or a subtle bug. > It usually doesn't happen till the system is pretty warm. > Maybe I'll have to run Commo-64 style, with the Coco case top off. > Or relocate that voltage regulator, stupidly buried in the > worst-ventilated part of the case. -- >Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) > Delphi: RAGTIMER CIS: <memory failure, too many digits> This first thing I did to help alleviate my Coco 2's heat problem was to use an exacto knife to carefully cut out the slots above the transformer. I guess they were there to protect the 115v from falling paper clips, etc. (I won't comment on a design that leaves 115v on the circuit board with the switch off.) My final solution to the overheating was to: First, throw away the cover. It kept getting in the way of all the wires and modifications anyway. Second, purchase one of the 12v DC fans that RS sell for $15. I used a couple screws to mount the fan on the side of the Coco so it's 2/3's blowing on the regulator and 1/3 on the transformer. This gives a nice flow of air across all the ic's and everything runs real cool. Lastly, I build a variable dc supply using a LM317 regulator to power the fan. Adjustable voltage = adjustable speed = NO NOISE... Turns out I didn't need the regulator. Next time I'll just run the fan on it's minimum voltage, about 6 volts. Bill Vodall Intuitively Obvious Disclaimer: Hewlett-Packard isn't responsible for the above. Use at your own risk!!!!!!
zog@laidbak.UUCP (Christian G. Herzog) (09/02/87)
In article <300007@hpfcdq.HP.COM> vodall@hpfcdq.HP.COM (Bill Vodall) writes: > >This first thing I did to help alleviate my Coco 2's heat problem was >to use an exacto knife to carefully cut out the slots above the transformer. >I guess they were there to protect the 115v from falling paper clips, etc. >(I won't comment on a design that leaves 115v on the circuit board with >the switch off.) > I was under the impression that the idea behind switching the secondary side of the transformer with the on/off switch had something to do with UL standards. A EE friend of mine once said that the UL standards apply only to areas operating above 40 volts (or something like that). It would seem that the UL standards would apply only to the cord, strain relief, and transformer in this case. __ __________ __ | ||_______ ||__| Christian G. Herzog | | _______| | __ | || ____ || | {amdahl,ihnp4,masscomp,sequent,sun}!laidbak!zog | || |____| || | | ||__________|| | Lachman Associates, Inc. | |___________ | | |______________||__|