Date: Fri, 28 May 1999 09:29:21 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru> Cc: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>, alpha@FreeBSD.ORG Subject: Re: Panic: warning: pmap_changebit didn't. Message-ID: <Pine.BSF.4.05.9905280922430.413-100000@herring.nlsystems.com> In-Reply-To: <199905272307.DAA01718@tejblum.dnttm.rssi.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9905280922430.413-100000>