Subject: Re: More on kernel hangs -- gcc
To: Rafal Boni <rafal@attbi.com>
From: sgimips NetBSD list <sgimips@mrynet.com>
List: port-sgimips
Date: 02/16/2002 16:22:46
Hi Rafal,

> In message <200202161628.g1GGSpW10385@mrynet.com>, you write: 
> 
> -> I'm now realising that the hangs I'm experiencing on my INDYs are
> -> provoked more when building profiled libraries.
> [...]
> -> Stopped in pid 364 (cc1) at     cpu_Debugger+0x4:       jr      ra
> ->                 bdslot: nop
> -> db> trace
> 
> [...this is the call sequence arising from you hitting break...]
> -> cpu_Debugger+4 (100,bfbd9830,0,10) ra 88187024 sz 0
> -> 88186f54+d0 (100,bfbd9830,0,10) ra 881888b0 sz 48
> -> zsc_intr_hard+114 (100,bfbd9830,0,10) ra 88187d14 sz 32
> -> 88187cb0+64 (100,bfbd9830,0,10) ra 88189a20 sz 40
> -> ip22_mappable_intr+cc (100,bfbd9830,0,10) ra 88189c20 sz 48
> -> ip22_local1_intr+b0 (100,bfbd9830,0,10) ra 881898c0 sz 48
> -> ip22_intr+d0 (100,bfbd9830,0,10) ra 8818d570 sz 64
> -> cpu_intr+48 (100,bfbd9830,0,10) ra 8806a208 sz 32
> -> mips3_KernIntr+84 (7fff805e,37d59e,0,37d59e) ra 8817ed1c sz 128
> 
> [...and this is actually where it's stuck...]
> -> pmap_enter+6ac (7fff805e,37d59e,0,37d59e) ra 88165c3c sz 80
> -> uvm_fault+c58 (88cb5d48,7fff8000,0,2) ra 88181360 sz 280
> -> trap+4e4 (2000ff13,20c,0,2) ra 88069ec4 sz 72
> -> mips3_UserGenException+cc (2000ff13,20c,0,5f7ffc) ra 0 sz 0
> -> User-level: pid 364
> 
> Are you short of memory or do not have (enough?) swap enabled?  It looks
> like UVM is somehow grinding to a halt, and if it is a VM issue, it's
> probably not  SGI specific (the pmap code is shared by all mips ports).

Memory:
	128 MB memory, 115 MB free, 768 KB for ARCS, 6656 KB in 1664 buffers
Swap:
	mod80 (12)# swapctl -l
	Device      1K-blocks     Used    Avail Capacity  Priority
	/dev/sd3b      262477        0   262477     0%    0

> This is certainly worth a PR, and it would be interesting to check where
> in the code it's stuck (ie, trying to figure out where in uvm_fault()/
> pmap_enter() things are when you break in).  I also wonder if the spl
> level is somehow out of whack, but then I'd expect more problems; a
> register dump would probably prove useful, as might a complete kernel
> dump.

I really should get send-pr working from my islolated machines :)

I'll try to map out the uvm_faul/pmap_enter addresses.

-scott