From owner-freebsd-alpha Thu May 27 16:10:49 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from helios.dnttm.ru (dnttm-gw.rssi.ru [193.232.0.205]) by hub.freebsd.org (Postfix) with ESMTP id B154315A58 for ; Thu, 27 May 1999 16:10:21 -0700 (PDT) (envelope-from dima@tejblum.dnttm.rssi.ru) Received: (from uucp@localhost) by helios.dnttm.ru (8.9.1/8.9.1/IP-3) with UUCP id DAA17345; Fri, 28 May 1999 03:02:22 +0400 Received: from tejblum.dnttm.rssi.ru (localhost [127.0.0.1]) by tejblum.dnttm.rssi.ru (8.9.3/8.9.1) with ESMTP id DAA01718; Fri, 28 May 1999 03:07:11 +0400 (MSD) (envelope-from dima@tejblum.dnttm.rssi.ru) Message-Id: <199905272307.DAA01718@tejblum.dnttm.rssi.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: Doug Rabson Cc: Hidetoshi Shimokawa , alpha@FreeBSD.ORG Subject: Re: Panic: warning: pmap_changebit didn't. In-reply-to: Your message of "Tue, 18 May 1999 21:19:00 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 May 1999 03:07:11 +0400 From: Dmitrij Tejblum Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message