Subject: Re: panic: pmap_zero_page: lock botch
To: Manuel Bouyer <bouyer@antioche.eu.org>
From: Chuck Silvers <chuq@chuq.com>
List: port-i386
Date: 03/27/1999 16:23:46
Manuel Bouyer writes:
> On Fri, Mar 26, 1999 at 02:49:42PM -0800, Chuck Silvers wrote:
> > I experimented with this a bit this morning and I couldn't get it to happen.
> > it's most likely recursion due to interrupts like jason said.
> > can you get a backtrace?  we really should find out how this is happening.
> > 
> 
> Here is a sample stack trace. I repeated the panic several times, the
> addresses varied, but it always looked the same:
> pmap_zero_page(4910000,fe012f5c,f01b7774,f0391740,fdfdd24d4) + 0x1e
> uvm_pagezero(f0391740) + 0x12
> uvm_fault(fdfd24d4,68000,0,3,0) + 0xe24
> trap() +0x437
> trap (number 6)

I'd have thought there would be two instances of pmap_zero_page()
in the stack trace.  weird.

 
> I also got another panic and a core dump from make. I think all these can
> be related to the same problem.
> Jason's patche solved the problem for me.
> Just in cases it matters: I have 2 disks on my system: IDE for / and /usr,
> SCSI for /home (where my source tree lives). Using only one disk, or 2 disks
> on the same controller may serialize interrupts enouth to avoid the problem.
> 
> Let me know if you want more infos. I can also get a core dump really ealily.

I'd like to take a look at the dump... I'm curious what an interrupt handler
is page-faulting on.

-Chuck