I found three occurrences of the "Poison overwritten" BUG in my logs. These occurred in one session (with a suspend/resume cycle between the second and third BUG). I've lumped these three occurrences in this one report. I have no idea what's going on an haven't yet dived deeper into this. This might as well be just a one time issue. I recorded it here in case some else runs into this too (or I manage to trigger this again). 1st: ============================================================================= BUG dentry: Poison overwritten ----------------------------------------------------------------------------- INFO: 0xffff8801313f2000-0xffff8801313f201f. First byte 0x0 instead of 0x6b INFO: Allocated in d_alloc+0x27/0x1b3 age=2345298 cpu=1 pid=32047 INFO: Freed in __d_free+0x59/0x5e age=2345298 cpu=1 pid=32047 INFO: Slab 0xffffea00042c5cf0 objects=12 used=11 fp=0xffff8801313f2000 flags=0x400000000000c1 INFO: Object 0xffff8801313f2000 @offset=0 fp=0x (null) Object 0xffff8801313f2000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0xffff8801313f2010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0xffff8801313f2020: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f2030: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f2040: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f2050: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f2060: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f2070: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f2080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f2090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f20a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f20b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f20c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f20d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f20e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f20f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f2100: 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkk� Redzone 0xffff8801313f2108: bb bb bb bb bb bb bb bb �������� Padding 0xffff8801313f2148: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ Pid: 1262, comm: mandb Not tainted 3.0.1.1-1.local0.fc14.x86_64 #1 Call Trace: [<ffffffff8112f5eb>] print_trailer+0x133/0x13c [<ffffffff8112f908>] check_bytes_and_report+0xc1/0xff [<ffffffff8113069d>] check_object+0xc5/0x1b0 [<ffffffff81155836>] ? d_alloc+0x27/0x1b3 [<ffffffff811309a2>] alloc_debug_processing+0x7f/0x120 [<ffffffff811319c5>] __slab_alloc+0x302/0x372 [<ffffffff81155836>] ? d_alloc+0x27/0x1b3 [<ffffffff8104a356h>] ? should_resched+0xe/0x2e [<ffffffff81155836>] ? d_alloc+0x27/0x1b3 [<ffffffff81132d7b>] kmem_cache_alloc+0x53/0x105 [<ffffffff811568b0>] ? __d_lookup+0xf8/0x10a [<ffffffff81155836>] d_alloc+0x27/0x1b3 [<ffffffff8114c595>] d_alloc_and_lookup+0x2c/0x6d [<ffffffff8114d9a3>] walk_component+0x1ea/0x3da [<ffffffff8114ccd4>] ? handle_dots+0x218/0x218 [<ffffffff8114f00a>] path_lookupat+0xae/0x34b [<ffffffff81252cd1>] ? __strncpy_from_user+0x1f/0x4e [<ffffffff8114f2d1>] do_path_lookup+0x2a/0x99 [<ffffffff8114f70b>] user_path_at+0x56/0x93 [<ffffffff81147037>] vfs_fstatat+0x49/0x74 [<ffffffff8114709d>] vfs_stat+0x1b/0x1d [<ffffffff811471b3>] sys_newstat+0x1f/0x39 [<ffffffff8108fcea>] ? trace_hardirqs_on_caller+0x10b/0x12f [<ffffffff810b4759>] ? audit_syscall_entry+0x11c/0x148 [<ffffffff81252a3e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff814f6242>] system_call_fastpath+0x16/0x1b FIX dentry: Restoring 0xffff8801313f2000-0xffff8801313f201f=0x6b FIX dentry: Marking all objects used 2nd: ============================================================================= BUG buffer_head: Poison overwritten ----------------------------------------------------------------------------- INFO: 0xffff8801313f4000-0xffff8801313f401f. First byte 0x0 instead of 0x6b INFO: Allocated in alloc_buffer_head+0x21/0x49 age=35663788 cpu=0 pid=9854 INFO: Freed in free_buffer_head+0x24/0x33 age=2354764 cpu=0 pid=32425 INFO: Slab 0xffffea00042c5d60 objects=23 used=7 fp=0xffff8801313f4000 flags=0x400000000000c1 INFO: Object 0xffff8801313f4000 @offset=0 fp=0xffff8801313f4580 Object 0xffff8801313f4000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0xffff8801313f4010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0xffff8801313f4020: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f4030: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f4040: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f4050: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f4060: 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkk� Redzone 0xffff8801313f4068: bb bb bb bb bb bb bb bb �������� Padding 0xffff8801313f40a8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ Pid: 1277, comm: updatedb Not tainted 3.0.1.1-1.local0.fc14.x86_64 #1 Call Trace: [<ffffffff8112f5eb>] print_trailer+0x133/0x13c [<ffffffff8112f908>] check_bytes_and_report+0xc1/0xff [<ffffffff8113069d>] check_object+0xc5/0x1b0 [<ffffffff811687c1>] ? alloc_buffer_head+0x21/0x49 [<ffffffff811309a2>] alloc_debug_processing+0x7f/0x120 [<ffffffff811319c5>] __slab_alloc+0x302/0x372 [<ffffffff811687c1>] ? alloc_buffer_head+0x21/0x49 [<ffffffff8104a356>] ? should_resched+0xe/0x2e [<ffffffff811687c1>] ? alloc_buffer_head+0x21/0x49 [<ffffffff81132d7b>] kmem_cache_alloc+0x53/0x105 [<ffffffff810fd692>] ? get_page+0x2c/0x4d [<ffffffff811687c1>] alloc_buffer_head+0x21/0x49 [<ffffffff81168ee0>] alloc_page_buffers+0x32/0xce [<ffffffff8116a58a>] __getblk+0x17a/0x211 [<ffffffff8116a633>] __breadahead+0x12/0x39 [<ffffffff811a9d77>] __ext4_get_inode_loc+0x2bd/0x377 [<ffffffff811ab43d>] ext4_iget+0x58/0x6eb [<ffffffff811b379a>] ext4_lookup+0x97/0xec [<ffffffff8114c5ae>] d_alloc_and_lookup+0x45/0x6d [<ffffffff8114d9a3>] walk_component+0x1ea/0x3da [<ffffffff8114ccd4>] ? handle_dots+0x218/0x218 [<ffffffff8114f00a>] path_lookupat+0xae/0x34b [<ffffffff81252cd1>] ? __strncpy_from_user+0x1f/0x4e [<ffffffff8114f2d1>] do_path_lookup+0x2a/0x99 [<ffffffff8114f70b>] user_path_at+0x56/0x93 [<ffffffff8110fe25>] ? might_fault+0xa5/0xac [<ffffffff81146d96>] ? cp_new_stat+0xf3/0x10b [<ffffffff81147037>] vfs_fstatat+0x49/0x74 [<ffffffff81147080>] vfs_lstat+0x1e/0x20 [<ffffffff811471ec>] sys_newlstat+0x1f/0x39 [<ffffffff8108fcea>] ? trace_hardirqs_on_caller+0x10b/0x12f [<ffffffff810b4759>] ? audit_syscall_entry+0x11c/0x148 [<ffffffff81252a3e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff814f6242>] system_call_fastpath+0x16/0x1b FIX buffer_head: Restoring 0xffff8801313f4000-0xffff8801313f401f=0x6b FIX buffer_head: Marking all objects used 3rd: ============================================================================= BUG buffer_head: Poison overwritten ----------------------------------------------------------------------------- INFO: 0xffff8801313f8000-0xffff8801313f801f. First byte 0x0 instead of 0x6b INFO: Allocated in alloc_buffer_head+0x21/0x49 age=65625325 cpu=0 pid=7495 INFO: Freed in free_buffer_head+0x24/0x33 age=3288593 cpu=0 pid=32425 INFO: Slab 0xffffea00042c5e40 objects=23 used=18 fp=0xffff8801313f8000 flags=0x400000000000c1 INFO: Object 0xffff8801313f8000 @offset=0 fp=0xffff8801313f8210 Object 0xffff8801313f8000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0xffff8801313f8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0xffff8801313f8020: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f8030: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f8040: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f8050: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff8801313f8060: 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkk� Redzone 0xffff8801313f8068: bb bb bb bb bb bb bb bb �������� Padding 0xffff8801313f80a8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ Pid: 2088, comm: yumBackend.py Not tainted 3.0.1.1-1.local0.fc14.x86_64 #1 Call Trace: [<ffffffff8112f5eb>] print_trailer+0x133/0x13c [<ffffffff8112f908>] check_bytes_and_report+0xc1/0xff [<ffffffff8113069d>] check_object+0xc5/0x1b0 [<ffffffff811687c1>] ? alloc_buffer_head+0x21/0x49 [<ffffffff811309a2>] alloc_debug_processing+0x7f/0x120 [<ffffffff811319c5>] __slab_alloc+0x302/0x372 [<ffffffff811687c1>] ? alloc_buffer_head+0x21/0x49 [<ffffffff8104a356>] ? should_resched+0xe/0x2e [<ffffffff811687c1>] ? alloc_buffer_head+0x21/0x49 [<ffffffff81132d7b>] kmem_cache_alloc+0x53/0x105 [<ffffffff810f3c88>] ? add_to_page_cache_locked+0x86/0x10c [<ffffffff811687c1>] alloc_buffer_head+0x21/0x49 [<ffffffff81168ee0>] alloc_page_buffers+0x32/0xce [<ffffffff81168f9e>] create_empty_buffers+0x22/0xb1 [<ffffffff8110baf7>] ? __inc_zone_page_state+0x23/0x25 [<ffffffff8116a7a6>] __block_write_begin+0x71/0x2a7 [<ffffffff811adcab>] ? ext4_block_truncate_page+0x26/0x26 [<ffffffff810f3d61>] ? add_to_page_cache_lru+0x53/0x5b [<ffffffff810f3e05>] ? grab_cache_page_write_begin+0x9c/0xae [<ffffffff811aeda0>] ext4_da_write_begin+0x176/0x21b [<ffffffff810f2f1c>] generic_file_buffered_write+0xfd/0x240 [<ffffffff810f498e>] __generic_file_aio_write+0x248/0x278 [<ffffffff810f4a21>] generic_file_aio_write+0x63/0xbe [<ffffffff811a6d11>] ext4_file_write+0x1f8/0x253 [<ffffffff81172dc5>] ? fsnotify+0x86/0x41e [<ffffffff8108f8ce>] ? lock_acquire+0xd3/0xfb [<ffffffff81172dc5>] ? fsnotify+0x86/0x41e [<ffffffff81142a1a>] do_sync_write+0xcb/0x108 [<ffffffff81206cff>] ? selinux_file_permission+0x57/0xb6 [<ffffffff812015ff>] ? security_file_permission+0x2e/0x33 [<ffffffff811430c1>] vfs_write+0xaf/0x102 [<ffffffff8114468d>] ? fget_light+0x3a/0xa1 [<ffffffff811432d4>] sys_write+0x4d/0x74 [<ffffffff814f6242>] system_call_fastpath+0x16/0x1b FIX buffer_head: Restoring 0xffff8801313f8000-0xffff8801313f801f=0x6b FIX buffer_head: Marking all objects used
I marked this as a regression. I *think* it's a 2.6.39->3.0 regression?
(In reply to comment #1) > I marked this as a regression. I *think* it's a 2.6.39->3.0 regression? 0) That might well be correct. But please note that the 3.0.1 kernel I triggered this issue with seems to be the first I ran on this machine that has CONFIG_SLUB_DEBUG_ON set. So on this machine this issue - if it's more than a one time goof - would never have showed up in the logs unless I manually booted with "slub_debug" on the command line. And I can't remember booting with "slub_debug". (1) Background: mm/slub.c:check_bytes_and_report() and work your way up in code and CONFIG_* options.) (2) Uninteresting detail: I changed the way I built the kernel for this machine - which still tracks Fedora 14 - after it was made clear that v2.6.39.4 would be the last stable release for v2.6.39. I now sort of rebuilt a Fedora Rawhide kernel, but dropping Fedora's non-upstreamed patches.)
On Tuesday, August 30, 2011, Paul Bolle wrote: > On Sun, 2011-08-28 at 21:01 +0200, Rafael J. Wysocki wrote: > > Please verify if it still should > > be listed and let the tracking team know (either way). > > From comment #2: > > [...] please note that the 3.0.1 kernel I > > triggered this issue with seems to be the first I ran on this machine that > has > > CONFIG_SLUB_DEBUG_ON set. So on this machine this issue - if it's more than > a > > one time goof - would never have showed up in the logs unless I manually > booted > > with "slub_debug" on the command line. And I can't remember booting with > > "slub_debug". > > At this moment I see little reason to track this bug entry as a > regression.
Dropping from the list of recent regressions.
(0) This is a copy of a message I sent directly to one of the people tracking this bug on Sep 11, 2011, since kernel.org was down at that time. I forgot to update this report once bugzilla.kernel.org was up again. I add this to this report on the odd chance that someone running v3.0.x runs into something similar.) 1) I've hit this again (that is, the first of the free "Poison overwritten" messages). Thawing from hibernation seems to be a possible cause of this. Kernel is now v3.0.4. So it seems not to be just a one time goof and might even be reproducible. (I haven't yet dared to reproduce this.) 2) And this was what I found in the logs: ============================================================================= BUG dentry: Poison overwritten ----------------------------------------------------------------------------- INFO: 0xffff88012f6ef000-0xffff88012f6ef01f. First byte 0x0 instead of 0x6b INFO: Allocated in d_alloc+0x27/0x1b3 age=8009211 cpu=1 pid=9833 INFO: Freed in __d_free+0x59/0x5e age=10700 cpu=1 pid=13756 INFO: Slab 0xffffea0004260448 objects=12 used=5 fp=0xffff88012f6ef000 flags=0x400000000000c1 INFO: Object 0xffff88012f6ef000 @offset=0 fp=0xffff88012f6efbd0 Object 0xffff88012f6ef000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0xffff88012f6ef010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0xffff88012f6ef020: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef030: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef040: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef050: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef060: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef070: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef0a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef0b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef0c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef0d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef0e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef0f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff88012f6ef100: 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkk� Redzone 0xffff88012f6ef108: bb bb bb bb bb bb bb bb �������� Padding 0xffff88012f6ef148: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ Pid: 14674, comm: pm-powersave Not tainted 3.0.4-local0.fc14.x86_64 #1 Call Trace: [<ffffffff8112f7db>] print_trailer+0x133/0x13c [<ffffffff8112faf8>] check_bytes_and_report+0xc1/0xff [<ffffffff8113088d>] check_object+0xc5/0x1b0 [<ffffffff81155a26>] ? d_alloc+0x27/0x1b3 [<ffffffff81130b92>] alloc_debug_processing+0x7f/0x120 [<ffffffff81131bb5>] __slab_alloc+0x302/0x372 [<ffffffff81155a26>] ? d_alloc+0x27/0x1b3 [<ffffffff8104a356>] ? should_resched+0xe/0x2e [<ffffffff81155a26>] ? d_alloc+0x27/0x1b3 [<ffffffff81132f6b>] kmem_cache_alloc+0x53/0x105 [<ffffffff81156aa0>] ? __d_lookup+0xf8/0x10a [<ffffffff81155a26>] d_alloc+0x27/0x1b3 [<ffffffff8114c785>] d_alloc_and_lookup+0x2c/0x6d [<ffffffff8114db93>] walk_component+0x1ea/0x3da [<ffffffff8114cec4>] ? handle_dots+0x218/0x218 [<ffffffff8114f1fa>] path_lookupat+0xae/0x34b [<ffffffff81252fb1>] ? __strncpy_from_user+0x1f/0x4e [<ffffffff8114f4c1>] do_path_lookup+0x2a/0x99 [<ffffffff8114f8fb>] user_path_at+0x56/0x93 [<ffffffff8107eb40>] ? up_read+0x2b/0x33 [<ffffffff814f2b9a>] ? do_page_fault+0x31e/0x3a8 [<ffffffff8110ffcc>] ? might_fault+0x5c/0xac [<ffffffff81147227>] vfs_fstatat+0x49/0x74 [<ffffffff8108f8e7>] ? lock_release+0x18a/0x1b2 [<ffffffff8114728d>] vfs_stat+0x1b/0x1d [<ffffffff811473a3>] sys_newstat+0x1f/0x39 [<ffffffff8114c5a1>] ? path_put+0x22/0x26 [<ffffffff8110ffcc>] ? might_fault+0x5c/0xac [<ffffffff810b4949>] ? audit_syscall_entry+0x11c/0x148 [<ffffffff81252d1e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff814f62c2>] system_call_fastpath+0x16/0x1b FIX dentry: Restoring 0xffff88012f6ef000-0xffff88012f6ef01f=0x6b FIX dentry: Marking all objects used
(0) And this is a copy of a message I sent directly to one of the people tracking this bug on Sep 20, 2011, since kernel.org was still down at that time. I again add this to this report on the odd chance that someone running v3.0.x runs into something similar.) 1) I've just hit an almost identical message, and again after thawing from hibernation. Kernel is still now v3.0.4. So it really seems to be reproducible by thawing from hibernation. We're making progress, I'd guess. (2) But I have to note that I've stopped using hibernation on this machine some time after sending this message. I seem to remember running into filesystem trouble after thawing. The filesystem concerned gave me a Desktop Manager with one of its executables having the contents of some PNG. Try debugging that! Anyhow, this machine has an Intel 965M chipset, and so it uses the i915 module. Perhaps this all is related to the issues fixed with commit 3fa016a0b5c5237e9c387fc3249592b2cb5391c6 ("drm/i915: suspend fbdev device around suspend/hibernate"), which shipped in v3.4-rc1 and later. See bug #37142 for some background. Perhaps I'll try again once this machine is running v3.4.)
Did 3.4 help ?
(In reply to comment #7) 0) Thanks for taking the time take a look at this report. I, of course, had already forgotten it. > Did 3.4 help ? 1) I'd have to check. I don't think I ever ran v3.4 with SLUB_DEBUG_ON set. Nor did I ever use the slub_debug parameter. And, more importantly, after filing this report I stopped using hibernation (see comment #6). 2) So feel free to close this report (with insufficient data or whatever). 3) In the mean time I'll have to think whether I again dare to hibernate this machine. And if I do dare to do that, I'll do so with "slub_debug" set. Then we'll see whether v3.4 helped. If not, I could always reopen this report.