Bug 478700 - WARNING: at lib/debugobjects.c:253 __debug_object_init+0x2a8/0x353()
WARNING: at lib/debugobjects.c:253 __debug_object_init+0x2a8/0x353()
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-03 14:32 EST by Tom London
Modified: 2009-02-26 16:39 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-26 16:39:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of "dmesg" showing above spew (44.32 KB, text/plain)
2009-01-03 14:32 EST, Tom London
no flags Details

  None (edit)
Description Tom London 2009-01-03 14:32:59 EST
Created attachment 328116 [details]
output of "dmesg" showing above spew

Description of problem:
Get the following on boot, early in the process:

Jan  3 10:59:44 tlondon kernel: hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
Jan  3 10:59:44 tlondon kernel: hpet0: 3 comparators, 64-bit 14.318180 MHz counter
Jan  3 10:59:44 tlondon kernel: ODEBUG: object is on stack, but not annotated
Jan  3 10:59:44 tlondon kernel: ------------[ cut here ]------------
Jan  3 10:59:44 tlondon kernel: WARNING: at lib/debugobjects.c:253 __debug_object_init+0x2a8/0x353()
Jan  3 10:59:44 tlondon kernel: Hardware name: 76734NU
Jan  3 10:59:44 tlondon kernel: Modules linked in:
Jan  3 10:59:44 tlondon kernel: Pid: 1, comm: swapper Not tainted 2.6.29-0.9.rc0.git4.fc11.x86_64 #1
Jan  3 10:59:44 tlondon kernel: Call Trace:
Jan  3 10:59:44 tlondon kernel: [<ffffffff8104997f>] warn_slowpath+0xb1/0xed
Jan  3 10:59:44 tlondon kernel: [<ffffffff81016e8b>] ? native_sched_clock+0x32/0x66
Jan  3 10:59:44 tlondon kernel: [<ffffffff8137632d>] ? printk+0x3c/0x3f
Jan  3 10:59:44 tlondon kernel: [<ffffffff8119863b>] __debug_object_init+0x2a8/0x353
Jan  3 10:59:44 tlondon kernel: [<ffffffff815f0140>] ? early_idt_handler+0x0/0x72
Jan  3 10:59:44 tlondon kernel: [<ffffffff81198713>] debug_object_init+0x14/0x19
Jan  3 10:59:44 tlondon kernel: [<ffffffff810539fb>] init_timer+0x18/0x5b
Jan  3 10:59:44 tlondon kernel: [<ffffffff81028d12>] hpet_cpuhp_notify+0x93/0x105
Jan  3 10:59:44 tlondon kernel: [<ffffffff81028e4f>] ? hpet_work+0x0/0x22e
Jan  3 10:59:44 tlondon kernel: [<ffffffff81011f3e>] ? restore_args+0x0/0x30
Jan  3 10:59:44 tlondon kernel: [<ffffffff8120e56e>] ? hpet_alloc+0x34f/0x3ae
Jan  3 10:59:44 tlondon kernel: [<ffffffff81604e98>] hpet_late_init+0x161/0x198
Jan  3 10:59:44 tlondon kernel: [<ffffffff8118ce20>] ? __next_cpu_nr+0x22/0x2b
Jan  3 10:59:44 tlondon kernel: [<ffffffff81604d37>] ? hpet_late_init+0x0/0x198
Jan  3 10:59:44 tlondon kernel: [<ffffffff8100a070>] do_one_initcall+0x70/0x187
Jan  3 10:59:44 tlondon kernel: [<ffffffff8106c00e>] ? mark_lock+0x22/0x3ae
Jan  3 10:59:44 tlondon kernel: [<ffffffff8106c00e>] ? mark_lock+0x22/0x3ae
Jan  3 10:59:44 tlondon kernel: [<ffffffff8118d7d7>] ? ida_get_new_above+0x18d/0x1ae
Jan  3 10:59:44 tlondon kernel: [<ffffffff81016e8b>] ? native_sched_clock+0x32/0x66
Jan  3 10:59:44 tlondon kernel: [<ffffffff81016ec8>] ? sched_clock+0x9/0xc
Jan  3 10:59:44 tlondon kernel: [<ffffffff8106ab50>] ? lock_release_holdtime+0x2c/0x123
Jan  3 10:59:44 tlondon kernel: [<ffffffff811975b0>] ? _raw_spin_unlock+0x8e/0x93
Jan  3 10:59:44 tlondon kernel: [<ffffffff81378e9b>] ? _spin_unlock+0x26/0x2a
Jan  3 10:59:44 tlondon kernel: [<ffffffff811248d5>] ? proc_register+0x17f/0x193
Jan  3 10:59:44 tlondon kernel: [<ffffffff81124a11>] ? create_proc_entry+0x7e/0x94
Jan  3 10:59:44 tlondon kernel: [<ffffffff810970f6>] ? register_irq_proc+0xb0/0xcc
Jan  3 10:59:44 tlondon kernel: [<ffffffff81120000>] ? proc_reg_unlocked_ioctl+0xb2/0xda
Jan  3 10:59:44 tlondon kernel: [<ffffffff815f073f>] kernel_init+0x1c1/0x212
Jan  3 10:59:44 tlondon kernel: [<ffffffff81378a06>] ? trace_hardirqs_on_thunk+0x3a/0x3f
Jan  3 10:59:44 tlondon kernel: [<ffffffff8101262a>] child_rip+0xa/0x20
Jan  3 10:59:44 tlondon kernel: [<ffffffff81011f3e>] ? restore_args+0x0/0x30
Jan  3 10:59:44 tlondon kernel: [<ffffffff815f057e>] ? kernel_init+0x0/0x212
Jan  3 10:59:44 tlondon kernel: [<ffffffff81012620>] ? child_rip+0x0/0x20
Jan  3 10:59:44 tlondon kernel: ---[ end trace 4eaa2a86a8e2da22 ]---
Jan  3 10:59:44 tlondon kernel: pnp: PnP ACPI init
Jan  3 10:59:44 tlondon kernel: ACPI: bus type pnp registered
Jan  3 10:59:44 tlondon kernel: pnp: PnP ACPI: found 11 devices
Jan  3 10:59:44 tlondon kernel: ACPI: ACPI bus type pnp unregistered
Jan  3 10:59:44 tlondon kernel: system 00:00: iomem range 0x0-0x9ffff could not be reserved

Not sure, but I think this happens during "Starting udev" 

System appears to hang there for quite a while, but then continues to boot successfully.

I'll attach complete "dmesg" output.

System is Thinkpad X61 running kernel-2.6.29-0.9.rc0.git4.fc11.x86_64.

Version-Release number of selected component (if applicable):
kernel-2.6.29-0.9.rc0.git4.fc11.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Christopher Beland 2009-01-11 02:27:10 EST
I'm seeing the same spew on a Toshiba Satellite and 2.6.29-0.24.rc0.git13.fc11.x86_64.
Comment 2 sangu 2009-01-15 21:26:07 EST
in kernel-2.6.29-0.38.rc1.git4.fc11.i686
$ dmesg
<skip>
hpet0: at MMIO 0xfeff0000, IRQs 2, 8, 31
hpet0: 3 comparators, 32-bit 25.000000 MHz counter
ODEBUG: object is on stack, but not annotated
------------[ cut here ]------------
WARNING: at lib/debugobjects.c:253 __debug_object_init+0x25c/0x2f1() (Not tainte
d)
Hardware name: System Product Name
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.29-0.38.rc1.git4.fc11.i686 #1
Call Trace:
 [<c0430479>] warn_slowpath+0x77/0xb3
 [<c0430700>] ? update_console_cmdline+0x41/0x76
 [<c044e0eb>] ? trace_hardirqs_off_caller+0x18/0xa3
 [<c044e0eb>] ? trace_hardirqs_off_caller+0x18/0xa3
 [<c044e181>] ? trace_hardirqs_off+0xb/0xd
 [<c06e2d65>] ? _spin_unlock_irqrestore+0x39/0x50
 [<c0430956>] ? release_console_sem+0x1b3/0x1e0
 [<c0407fa3>] ? sched_clock+0x8/0xb
 [<c044d817>] ? lock_release_holdtime+0x30/0x131
 [<c0541db5>] ? __debug_object_init+0x164/0x2f1
 [<c0541ead>] __debug_object_init+0x25c/0x2f1
 [<c0541f6d>] debug_object_init+0x13/0x16
 [<c043894f>] init_timer+0x11/0x47
 [<c0419e0c>] hpet_cpuhp_notify+0x78/0xca
 [<c0419f0f>] ? hpet_work+0x0/0x1b9
 [<c05a7fbc>] ? hpet_alloc+0x337/0x37f
 [<c08c6ba8>] hpet_late_init+0x14a/0x181
 [<c08c6a5e>] ? hpet_late_init+0x0/0x181
 [<c040114d>] _stext+0x65/0x17a
 [<c053c49e>] ? put_dec+0x2a/0xff
 [<c0407fa3>] ? sched_clock+0x8/0xb
 [<c044dc39>] ? register_lock_class+0x17/0x290
 [<c044dc39>] ? register_lock_class+0x17/0x290
 [<c044e9b9>] ? mark_lock+0x1e/0x349
 [<c0407fa3>] ? sched_clock+0x8/0xb
 [<c044d817>] ? lock_release_holdtime+0x30/0x131
 [<c049f409>] ? check_valid_pointer+0x1f/0x4e
 [<c044e9b9>] ? mark_lock+0x1e/0x349
 [<c044ef33>] ? trace_hardirqs_on+0xb/0xd
 [<c0407fa3>] ? sched_clock+0x8/0xb
 [<c044d817>] ? lock_release_holdtime+0x30/0x131
 [<c04de86b>] ? proc_register+0x146/0x157
 [<c0541114>] ? _raw_spin_unlock+0x74/0x78
 [<c06e2d99>] ? _spin_unlock+0x1d/0x20
 [<c04de86b>] ? proc_register+0x146/0x157
 [<c04de994>] ? create_proc_entry+0x7b/0x91
 [<c0471a7d>] ? register_irq_proc+0x7f/0x9b
 [<c0471aec>] ? init_irq_proc+0x53/0x60
 [<c08b3382>] kernel_init+0x17e/0x1cf
 [<c08b3204>] ? kernel_init+0x0/0x1cf
 [<c040443f>] kernel_thread_helper+0x7/0x10
---[ end trace 4eaa2a86a8e2da22 ]---
<skip>
Comment 3 James 2009-01-16 04:06:41 EST
kernel-2.6.29-0.38.rc1.git4.fc11.x86_64, Clevo M720R:

hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
hpet0: 3 comparators, 64-bit 14.318180 MHz counter
ODEBUG: object is on stack, but not annotated
------------[ cut here ]------------
WARNING: at lib/debugobjects.c:253 __debug_object_init+0x2a8/0x353() (Not tainte
d)
Hardware name: M720R
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.29-0.38.rc1.git4.fc11.x86_64 #1
Call Trace:
 [<ffffffff8104a4b1>] warn_slowpath+0xb9/0xfe
 [<ffffffff81016e66>] ? native_sched_clock+0x32/0x66
 [<ffffffff81380eb6>] ? printk+0x3c/0x3e
 [<ffffffff8119bf67>] __debug_object_init+0x2a8/0x353
 [<ffffffff81602140>] ? early_idt_handler+0x0/0x71
 [<ffffffff8119c03f>] debug_object_init+0x14/0x19
 [<ffffffff810543bb>] init_timer+0x18/0x5b
 [<ffffffff81028ef6>] hpet_cpuhp_notify+0x93/0x105
 [<ffffffff81029033>] ? hpet_work+0x0/0x216
 [<ffffffff81011f3e>] ? restore_args+0x0/0x30
 [<ffffffff81219b12>] ? hpet_alloc+0x34f/0x3ae
 [<ffffffff81616f14>] hpet_late_init+0x16e/0x1ac
 [<ffffffff81616da6>] ? hpet_late_init+0x0/0x1ac
 [<ffffffff8100a070>] do_one_initcall+0x70/0x187
 [<ffffffff8106ceb7>] ? mark_lock+0x22/0x3ad
 [<ffffffff8106ceb7>] ? mark_lock+0x22/0x3ad
 [<ffffffff811910ca>] ? ida_get_new_above+0x18d/0x1ae
 [<ffffffff81016e66>] ? native_sched_clock+0x32/0x66
 [<ffffffff81016ea3>] ? sched_clock+0x9/0xc
 [<ffffffff8106b9e8>] ? lock_release_holdtime+0x2c/0x123
 [<ffffffff8119aedb>] ? _raw_spin_unlock+0x8e/0x93
 [<ffffffff81383ba3>] ? _spin_unlock+0x26/0x2a
 [<ffffffff81127b6f>] ? proc_register+0x17f/0x193
 [<ffffffff81127cab>] ? create_proc_entry+0x7e/0x94
 [<ffffffff8109800e>] ? register_irq_proc+0xb0/0xcc
 [<ffffffff81120000>] ? find_tree_dqentry+0x28/0x1ac
 [<ffffffff81602752>] kernel_init+0x1d4/0x22a
 [<ffffffff8101262a>] child_rip+0xa/0x20
 [<ffffffff81011f3e>] ? restore_args+0x0/0x30
 [<ffffffff8160257e>] ? kernel_init+0x0/0x22a
 [<ffffffff81012620>] ? child_rip+0x0/0x20
---[ end trace 4eaa2a86a8e2da22 ]---
Comment 4 Eric Paris 2009-01-21 14:24:21 EST
It's not a problem.  It's meaningless.  It's been silenced upstream

http://git.kernel.org/?p=linux/kernel/git/mingo/linux-2.6-x86.git;a=commitdiff;h=6d612b0f943289856c6e8186c564cda922cd040e

Please just ignore anything you see that says "__debug_object_init"
Comment 5 Kyle McMartin 2009-02-26 16:39:52 EST
Looks like it's sorted upstream. Closing.

Note You need to log in before you can comment on or make changes to this bug.