Subject: Re: cc1plus lockup? And kernel panic
To: None <current-users@NetBSD.org>
From: Bernd Ernesti <netbsd@lists.veego.de>
List: current-users
Date: 08/23/2007 21:34:18
On Thu, Aug 23, 2007 at 10:55:33AM +0100, Andrew Doran wrote:
> On Wed, Aug 22, 2007 at 08:23:23AM +0200, Bernhard Moellemann wrote:
> > On Mon, Aug 20, 2007 at 07:34:18PM +0200, Bernd Ernesti wrote:
> > > On Mon, Aug 20, 2007 at 04:36:09PM +0200, Bernd Ernesti wrote:
> > > > On Mon, Aug 20, 2007 at 04:26:45PM +0200, Tobias Nygren wrote:
> > > > > On Mon, 20 Aug 2007 12:54:57 +0200
> > > > > Bernd Ernesti <netbsd@lists.veego.de> wrote:
> > > >
> > > > [spinning gcc process, sucking 100% cpu cycles]
> > 
> > I had the same issue yesterday while building pkgsrc/sysutils/xosview.
> > It got struck in the configure script, when "checking for suffix of
> > object files".
> 
> I've noticed gcc doing this when it runs out of space in TMPDIR (usually
> /var/tmp), although it will loop trying to open a file getting ENOSPC.

Hmm, my TMPDIR points to /tmp which is a 256MB tmpfs.

But I can't say how much was used when the panic happend. At least I got not
kernel message that the filesystem was full.

Is there any way to get the disk usage and tmpfs usage out of a crash dump?

Btw, Chuck asked me if I did used a memory check recently, which I didn't but
did it now. There were no errors for 9 passes in 6hours.

> > > uvm_fault(0xc07f9820, 0xffeec000, 2) -> 0xe
> > > kernel: supervisor trap page fault, code=0
> > > Stopped in pid 3380.1 (cc1plus) at      netbsd:pmap_page_remove+0x10e:  xchgl   %edi,0(%eax)
> > > db> bt
> > > pmap_page_remove(c1a06240,d4ae97d8,ffffffff,c03704a7,dda1c034) at netbsd:pmap_page_remove+0x10e
> > > uvm_anfree(d4a7d814,d57df848,3a5a3c,bb0c2000,bb0c2000) at netbsd:uvm_anfree+0x9f
> > > [...]
> 
> Was the machine under memory pressure at the time? Was it paging?

I haven't manged to get any paging on my machine which has 2GB of ram.
This is an Amd X2 4600+ CPU running in i386 and non MP mode, so only
one single cpu, because java won't work correctly while the 2nd cpu
is active (kern/36505).

Bernd