On Tue, Aug 3, 2010 at 8:47 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> Ilia,
>
> Can you send me the output of this for your kernel that the
> traces came from:
>
> $ gdb <path/to/vmlinux>
> (gdb) l *( xfs_write+0x2cc)
>
> You can run it against the vmlinux file in the kernel build
> directory. Basically I need to know which xfs_ilock() call in
> xfs_write() one of the mysqld-test processes is stuck on.
No problem - BTW, I'm running this on a 2.6.33.3 kernel (same as the
one before, although diff hardware). If you want (and are fine with me
"destroying" the current state), I can upgrade it to a kernel of your
choice and repeat the test overnight.
Naturally I didn't have CONFIG_DEBUG_INFO in there... just changed
that to Y and recompiled. I'm not entirely sure that this preserves
all the offsets, but at least the BUG-HUNTING doc makes allusions that
it would.
(gdb) l *( xfs_write+0x2cc)
0xffffffff8124342d is in xfs_write (fs/xfs/linux-2.6/xfs_lrw.c:597).
592 if (!need_i_mutex && (mapping->nrpages || pos
> xip->i_size)) {
593 xfs_iunlock(xip, XFS_ILOCK_EXCL|iolock);
594 iolock = XFS_IOLOCK_EXCL;
595 need_i_mutex = 1;
596 mutex_lock(&inode->i_mutex);
597 xfs_ilock(xip, XFS_ILOCK_EXCL|iolock);
598 goto start;
599 }
600 }
601
Well, at least it points at an xfs_ilock, so pretty good chance that
adding debug info didn't change anything else.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
