🚀 go-pugleaf

In article <90318.082800GIAMPAL@auvm.auvm.edu> GIAMPAL@auvm.auvm.edu writes:
> 
> In article <15822@cbmvax.commodore.com>, bj@cbmvax.commodore.com (Brian Jackson)
> says:
> >'LS' program which would, if asked to do a full, long and sorted
> >listing of a *large* directory ( > 200 files or so ), hose something
> >internal and cause this "spurts" behavior. Only a reboot would fix it.
> 
> Any ideas what causes this sort of behavior?  I mean how does a program
> doing something wrong internally (assuming no reads/writes to protected mem)
> mess up the rest of the system?   Are we just talking about someone getting
> stuck in a tight loop for a little bit (or an infinite loop) and that bogging
> the system down?  Still seems a little strange.

Yes, it *is* strange.  The "ls" problem was isolated by Henrik Clausen, and
found to be due to "something" in the custom startup code (mycres.o).  It
was eliminated simply by using the standard Lattice cres.o module.

I still am not sure exactly *what* in the custom startup code was causing the
problem, nor whether it was specifis to a 3000 running 2.0x, or if it showed
up on 2x00 machines running 2.0x also (as I don't have either 2.0 or a 3000
yet).

There were other manifestations of the problem which didn't cause the "slowdown"
symptom, but did result in some other undesirable behavior (hang, crash, etc).

My *hunch* is that something in there was trying to access some non-existant
memory, and causing endless "bus errors", which would slow the system *way*
down, but I can't confirm that suspicion.


In any case, the beta version of v4.1k that I have sent to a number of people
has eliminated the problems they were experiencing, but I have not yet released
it, as I need to use the v5.10 version of cres.o (to fix a potential problem
that showed up when a version using the v5.05 cres.o was run under a beta test
copy of a 2.0 upgrade to a commercial product).

I have v5.10, but haven't installed it yet, as I need to keep v5.05 around for
awhile longer for reasons having nothing to do with "ls" (and I don't have the
disk space to put up both versions right now).

Soon, however.

/kim

-- 
UUCP:  kim@uts.amdahl.com   -OR-   ked01@juts.ccc.amdahl.com
  or:  {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim
DDD:   408-746-8462
USPS:  Amdahl Corp.  M/S 249,  1250 E. Arques Av,  Sunnyvale, CA 94086
BIX:   kdevaughn     GEnie:   K.DEVAUGHN     CIS:   76535,25