![]() | |||||||||||||
Messages in this thread |
Hugh Dickins wrote: > On Tue, 14 Nov 2006, Mel Gorman wrote: >> 2.6.19-rc5-mm2 >> >> Am seeing errors with systems using ext2. First machine is a plan old x86 >> using initramfs. Console output looks like; >> ... >> Configuring network interfaces...BUG: soft lockup detected on CPU#3! >> ... >> [<c01b3b80>] ext2_try_to_allocate+0xdb/0x152 >> [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2 >> >> I've not investigated yet what patches might be at fault. > > I expect you'll find it's > ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch > which gets stuck in a loop there for me too: back it out and all seems fine. > > It's not obvious which part of the patch is to blame: mostly it's > cleanup, but a few variables do change size: I'm currently narrowing > down to where a fix is needed. Humpf. that was meant to be one of those "so obvious I can't screw it up" patches. typedef unsigned long ext2_fsblk_t; typedef int ext2_grpblk_t; in ext2_alloc_blocks we do change from "unsigned long long" to "unsigned long" for new_blocks[], but akpm thinks that was garbage before (same for ext2_alloc_branch's current_block) The ext2_grpblk_t ones all look innocuous. - 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/ | ||||||||||||
| Last update: 2006-11-14 20:25 [from the cache] ©2003-2008 | |||||||||||||