On Mon, Dec 18, 2006 at 09:17:50AM +0100, Haar János wrote:
> From: "David Chinner" <dgc@xxxxxxx>
> > > The NBD serves through eth1, and it is on the CPU3, but the ide0 is on
> > > CPU0.
> > I'd say your NBD based XFS filesystem is having trouble.
> > > > Are you using XFS on a NBD?
> > >
> > > Yes, on the 3. source.
> > Ok, I've never heard of a problem like this before and you are doing
> > something that very few ppl are doing (i.e. XFS on NBD). I'd start
> > Hence I'd start by suspecting a bug in the NBD driver.
> Ok, if you have right, this also can be in context with the following issue:
> http://download.netcenter.hu/bughunt/20061217/messages.txt (10KB)
Which appears to be a crash in wake_up_process() when doing memory
reclaim (waking the xfsbufd).
> > > > > Dec 16 12:08:36 dy-base RSP: 0018:ffff81011fdedbc0 EFLAGS: 00010002
> > > > > Dec 16 12:08:36 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b
> > > > ^^^^^^^^^^^^^^^^
> > > > Anyone recognise that pattern?
Ok, I've found this pattern:
#define POISON_FREE 0x6b
Can you confirm that you are running with CONFIG_DEBUG_SLAB=y?
If so, we have a use after free occurring here and it would also
explain why no-one has reported it before.
FWIW, can you turn on CONFIG_XFS_DEBUG=y and see if that triggers
a different bug check prior to the above dump?
SGI Australian Software Group