I've seen an awful lot of oopses out there on this path,
kswapd->shrink_icache_memory; some get a little further and oops in
ext3_discard_reservation.
A few were chalked up to bad memory, but others were not. Do you happen
to use suspend/resume?
Thanks to kerneloops.org... :)
All code
========
0: 12 11 adc (%ecx),%dl
2: f8 clc
3: ff 66 90 jmp *0xffffff90(%esi)
6: 83 ec 0c sub $0xc,%esp
9: 89 1c 24 mov %ebx,(%esp)
c: 8d 98 60 ff ff ff lea 0xffffff60(%eax),%ebx
12: 89 74 24 04 mov %esi,0x4(%esp)
16: 89 c6 mov %eax,%esi
18: 89 7c 24 08 mov %edi,0x8(%esp)
1c: 8b 53 70 mov 0x70(%ebx),%edx
1f: 8b 7b 54 mov 0x54(%ebx),%edi
22: 85 d2 test %edx,%edx
24: 74 16 je 0x3c
26: 83 fa ff cmp $0xffffffff,%edx
29: 74 11 je 0x3c
2b:* f0 ff 0a lock decl (%edx) <-- trapping instruction
Looks like it blew up in (inlined) posix_acl_release(), I think
EXT3_I(inode)->i_acl passed to it was 66e88e66, in %edx.
I think %edi is the i_block_alloc_info, 0f01c883, which also looks
crunchy. Use after free perhaps?
Nice symmetric number, anyway. :)
I've seen enough of these now, something real seems to be going on but I
don't know what yet.
-Eric
--