From owner-freebsd-alpha Fri May 28 1:29:46 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id BFF0014CA6 for ; Fri, 28 May 1999 01:29:41 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA32983; Fri, 28 May 1999 09:29:22 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 28 May 1999 09:29:21 +0100 (BST) From: Doug Rabson To: Dmitrij Tejblum Cc: Hidetoshi Shimokawa , alpha@FreeBSD.ORG Subject: Re: Panic: warning: pmap_changebit didn't. In-Reply-To: <199905272307.DAA01718@tejblum.dnttm.rssi.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 28 May 1999, Dmitrij Tejblum wrote: > Doug Rabson wrote: > > On Wed, 19 May 1999, Hidetoshi Shimokawa wrote: > > > > > (gdb) print pa > > > $1 = 350412800 > > > (gdb) print *pte > > > $2 = 183717226090783 > > > (gdb) print faultoff > > > $3 = 10 > > > (gdb) print /x pa > > > $4 = 0x14e2e000 > > > (gdb) print /x *pte > > > $5 = 0xa7170000111f > > > (gdb) print /x faultoff > > > $6 = 0xa > > > (gdb) > > > > This is very odd. The page isn't marked as PG_MANAGED somehow but that > > doesn't make sense. The page is in user space but doesn't have any user > > read/write permissions. > > Actually, it seems the page is in the upages, since the fault is in > |#5 0xfffffc000046a1dc in swapout (p=0xfffffe000cdf9340) > | at ../../vm/vm_glue.c:510 > on this line: > ++p->p_stats->p_ru.ru_nswap; > So, it's ok that the page isn't marked PG_MANAGED and don't have any > user read/write permission, but it isn't ok that it is marked > PG_FOR | PG_FOW | PG_FOE. > > It may happen if something accessed upages of a swapped out process. > In this case vm_fault will pmap_enter a zero page in place of the upages. > That may explain this panic and 'pv_table is inconsistent' panic. > > Recently a couple of potential invalid access to upages were fixed: the > ones related to calcru() and in alpha/alpha/mem.c. Frankly, I thought > that fixed the panic. But today I implemented reliable detection of > invalid access to upages, and found another one. > > In trap(ALPHA_IF_CODE_FEN), and probably in other places, fpcurproc may be > swapped out. > > I see following solutions: > - move pcb out of upages > - keep fpcurproc locked in memory: when we change fpcurproc, PRELE > old and PHOLD new. > - fault fpcurproc in when the FPU state need to be saved > - disable swapping forever I think the simplest is to do the second option. I'd like to keep the fix small so that it can be back-ported to 3.2. Do you want to work on fixing this or shall I? I probably won't be able to get to it before the weekend. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message