[Top] [All Lists]

ADD 800992 - pagebuf_init call to kmem_cache_create BUG()

To: dxm@xxxxxxxxxxxx
Subject: ADD 800992 - pagebuf_init call to kmem_cache_create BUG()
From: pv@xxxxxxxxxxxxx (lord@xxxxxxx)
Date: Wed, 6 Sep 2000 08:05:58 -0700 (PDT)
Cc: linux-xfs@xxxxxxxxxxx
Reply-to: sgi.bugs.xfs@xxxxxxxxxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
Webexec: webpvupdate,pvincident
Webpv: jen.americas.sgi.com
View Incident: 

 Status : open                         Priority : 4                         
 Assigned Engineer : dxm               Submitter : dxm                      
*Modified User : lord                 *Modified User Domain : sgi.com       
*Description :
On my test box, I'd been playing with xfs, then
umounted, rmmoded and insmoded the modules. When
pagebuf was insmoded, this kernel BUG() was tripped.

I'll see if I can get some more info on this one.

kmem_cache_destroy: Can't free all objects c116d764
kernel BUG at slab.c:806!

Entering kdb (0xc215e000) Panic: invalid operand


From: lord@xxxxxxx (BugWorks)
Date: Sep 06 2000 08:05:57AM

This BUG in slab.c is a new introduction - this used to function
in that it let you reuse a slab name if the old one was still out
there. The real problem is that we failed to delete all the old
entries in the cache when doing the rmmod of pagebuf.

kmem_cache_destroy returns a value - 1 if it failed, 0 if it worked.
define PB_TRACKING in page_buf.c and make it call BUG if 
kmem_cache_destroy returns 1. This will result in a panic
where pb_array should be an array of pointers to all existing
page_bufs. Turning on page buf tracing might also help determine
where the pagebufs came from, although typically this gives you
only a very short term history.

Determining what is in the remaining pagebufs will certainly help
a lot in figuring out the reason for this.

<Prev in Thread] Current Thread [Next in Thread>