> On Thu, 24 Jun 1999, Anders Magnusson wrote:
> 
> > I've heard that the problem may not go away with this fix also. Maybe
> > it is two problem? Anyway: It is the queue for active transfers. The
> > queue is only used to requeue transfers that were active when an
> > ubareset occurred.  I have never seen an ubareset on a qbus-based
> > machine, and very rarely on Unibus-based machines. (Only on a
> > heavily-loaded ftp server).
> 
> Well, I get hangs on my MicroVAX II and on my VAXstation 3100/M76 under
> 1.4. I've not yet tried the MSCP workaround on the MVII, but the M76 is
> only using NFS swap so I'd imagine that it's suffering from some other
> problem.  The hangs generally occur under large compiles.
> 
> -brian.

I followed up with anders about the MSCP workaround, but failed to include
the port-vax list in CC.

The workaround really improved things here, but I did eventually get
all processes hung in a "flt-noram5" context.   The end-results were
the same -- all processes hung, unresponsive (except to ^T status and
tty character echoing), and no way to effect a shutdown or panic.

I had gotten up to 3.5 mb swapped before this happened.

Anyone with suggestions, please bat them this-a-way :)

(Anders, if you can, please forward my followup to you earlier to
the list, just for completeness, as I don't have sent-copies of my
outgoing email.  Tak :)

Meanwhile, now that I've got things going stable enough, I'll get
KDB into a kernel and start looking about.  Speaking of which,
is there a mechanism built-in to the netbsd vax kernel for debugging,
or is the external gdb /kernel method the way?

Cheers,
			-skots
--
Scott G. Akmentins-Taylor     InterNet: staylor@mrynet.com
MRY Systems			        staylor@idt.net, staylor@mrynet.lv
Westlake Village, CA  USA		
    (Skots Gregorijs Akmentins-Teilors -- just call me "Skots")
		----- Labak miris neka sarkans -----