Re: 2.6.17-mm6
From: Andrew Morton
Date: Mon Jul 03 2006 - 15:37:52 EST
On Mon, 3 Jul 2006 20:27:21 +0100
Alistair John Strachan <s0348365@xxxxxxxxxxxx> wrote:
> On Monday 03 July 2006 11:03, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17
> >-mm6/
>
> Doesn't boot reliably as an x86-64 kernel on my X2 system, 3/4 times it oopses
> horribly. Is there some way to supress an oops flood so I can get a decent
> picture of it with vga=extended? Right now I get two useless oopses after the
> first (probably useful) one.
Try adding `pause_on_oops=100000' to the kernel boot command line.
> The one time I did get it to boot, I get a lockdep problem (possibly already
> reported, if so I'm sorry);
>
> =============================================
> [ INFO: possible recursive locking detected ]
> ---------------------------------------------
> mount/1095 is trying to acquire lock:
> (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>]
> xfs_ilock+0x67/0xa0
>
> but task is already holding lock:
> (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>]
> xfs_ilock+0x67/0xa0
>
> other info that might help us debug this:
> 2 locks held by mount/1095:
> #0: (&inode->i_mutex){--..}, at: [<ffffffff8026ead5>] mutex_lock+0x25/0x30
> #1: (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>]
> xfs_ilock+0x67/0xa0
>
> stack backtrace:
>
> Call Trace:
> [<ffffffff8027479e>] show_trace+0xae/0x280
> [<ffffffff80274985>] dump_stack+0x15/0x20
> [<ffffffff802afa06>] __lock_acquire+0x936/0xcd0
> [<ffffffff802afe28>] lock_acquire+0x88/0xc0
> [<ffffffff802abe49>] down_write+0x39/0x50
> [<ffffffff80328ef7>] xfs_ilock+0x67/0xa0
> [<ffffffff80329b3a>] xfs_iget+0x2da/0x760
> [<ffffffff80341804>] xfs_trans_iget+0xc4/0x150
> [<ffffffff8032df8e>] xfs_ialloc+0x9e/0x4d0
> [<ffffffff803423df>] xfs_dir_ialloc+0x7f/0x2d0
> [<ffffffff80348e24>] xfs_create+0x364/0x6d0
> [<ffffffff80352e9a>] xfs_vn_mknod+0x16a/0x300
> [<ffffffff8035304b>] xfs_vn_create+0xb/0x10
> [<ffffffff8023f92d>] vfs_create+0x8d/0xf0
> [<ffffffff8021cd42>] open_namei+0x1c2/0x700
> [<ffffffff80229e32>] do_filp_open+0x22/0x50
> [<ffffffff8021b78a>] do_sys_open+0x5a/0xf0
> [<ffffffff80235e5b>] sys_open+0x1b/0x20
> [<ffffffff8026894e>] system_call+0x7e/0x83
> [<000000337b1ac6e2>]
> XFS mounting filesystem sdb1
That could be deliberate nesting of the same lock in XFS. Or it could be a
false-positive due to an earlier oops.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/