Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 23 Jan 1999 11:55:49 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Peter Wemm <peter@netplex.com.au>
Cc:        current@FreeBSD.ORG
Subject:   Re: panic: found dirty cache page 0xf046f1c0 
Message-ID:  <199901231955.LAA48625@apollo.backplane.com>
References:   <199901231943.DAA00782@spinner.netplex.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help

:[..]
:> >     Try changing the panic in vm/vm_page.c to a printf() ( 
:> 
:> I'll do that.
:
:BTW; what are the dangers of this?  lost disk writes or corruption?  Can 
:we (as a workaround) push the page that we found back onto a dirty queue 
:and try again after some diagnostics?

    That's ok, don't worry about it...  Doug's debug output gives me the
    same info.

:It crashed in uniprocessor mode about 60 seconds after sending this mail. 
:It's got a really trimmed down kernel config and no modules loaded or in 
:use.  I have not disabled softupdates yet, that's next.

    I don't get it.... why can't I reproduce this problem?

    Can you email me your kernel configuration?  Are you using any
    special devices like vn or something ?

:Oh, one other thing that occurred to me..  Under 4.0-current, I regularly 
:(ie: within 30 seconds of boot) get if_de tranmitter underflows.  My 
:console corruption was happening at the instant that de0 was being 
:configured with ifconfig.  exmh is running to a remote display over that 
:de0 interface.
:
:Under Jan 16 3.0-current, I do not get that tranmitter underflow..
:
:The only thin I can think of about if_de that's unusual that is VM related
:(apart from the complexity of the code) is that it uses configmalloc().  I 
:wonder if this is somehow setting the scene for the later failures?  It's 
:certainly suspicious that has done strange things when being ifconfig'ed, 
:including things like trashing the serial console on no less than a dozen 
:occasions.
:
:Cheers,
:-Peter

    Hmmm..  HMMMMMM.  contigmalloc, eh?   You might be onto something here.
    I will investigate it.

    The problem was are having is that, somehow, a vm_page_t in the PQ_CACHE
    is being set dirty.  

    Sinc vm_page_cache() panics if m->dirty is set, then m->dirty must be getting
    set *after* the page has been moved to the cache.

    contigmalloc() looks suspicious.


					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901231955.LAA48625>