Den 2016-09-20 kl. 23:55, skrev Johnny Billquist:
You aere using MSCP, eh? I would take a guess of that it loses MSCP buffers somewhere then. Next time it happens, please get a process list (ps axl or from ddb) so we can get further on diagnosing it.On 2016-09-20 21:24, Anders Magnusson wrote:Den 2016-09-20 kl. 19:12, skrev Johnny Billquist:Hi, Ragge... On 2016-09-20 18:01, Anders Magnusson wrote:Hi Johnny, Well, I run it, on a 4000/90 :-) But I do not build the system natively, not enough disk and NFS takes forever.I've been running it on and off on a 4000/90 as well. But not doing things natively means that a lot of problems are not seen.It's known that there are problems with gcc, gnats gives some hints about that.Unfortunately I cannot spend time to jump into gcc for debugging also...Me neither. Especially since I have found gcc to be almost impenetrable in the past.But, I do not have any hanging problems, must be something specific to the 8600. Have you checked where it actually hangs?Tried work that out many times, but never gotten far. You want console access to a hung or crashed system? :-)If you cannot get into DDB then something really evil has happened. Is this the case?No. Seems I must have really mis-stated this. The system hangs as in the OS stalls. The hardware is working fine, and I can break into DDB as well. If I were to make a guess, it appears that all processes that do disk I/O stalls. Other things continue running. But as most things touch disk sooner or later, pretty much everything draws to a standstill.
Massbus was always both more reliable and faster when I used it, but you don't have any 16-bit formatted RP07's, have you? :-) Fixing BDPs would also help to improve Unibus speed I assume. That wouldn't be too much worw.
-- Ragge