Messages in this thread | | | Date | Mon, 3 Jul 2006 12:39:20 -0700 | From | Andrew Morton <> | Subject | Re: 2.6.17-mm6 |
| |
On Mon, 3 Jul 2006 20:27:21 +0100 Alistair John Strachan <s0348365@sms.ed.ac.uk> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |