On Wed, 26 Mar 2014, Vince Weaver wrote:
> On Tue, 25 Mar 2014, Thomas Gleixner wrote:
> > Do you happen to have the full bootlog up to the crash handy?
>
> attached is the full bootlog followed by the tracedump.
Ok. So we know now what we are looking for.
[ 1.579996] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
ΓΏ[ 1.607279] 00:09: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a
16550A
[ 1.615032] kobject: 'ttyS1' (ffff88011772ac10): kobject_release, parent
(null) (delayed 250)
[ 1.624534] kobject: '(null)' (ffff8801177400f0): kobject_release, parent
(null) (delayed 500)
[ 1.654213] 0000:00:16.3: ttyS1 at I/O 0xf0e0 (irq = 19, base_baud = 115200)
is a 16550A
[ 3.294047] Invalid timer base: tmr ffff880117740150 tmr->base
(null) base ffff880118898000
1634110us : obj: ffff880117740130 initialized kobject_delayed_cleanup+0x0/0x90
So that happens in the context of the 8250 serial driver.
> > Adding "initcall_debug" to the kernel command line might give us a
> > further hint what is adding the delayed_work, but I guess once we see
> > the function in the trace we have a good chance to find the place
> > right away. Then we have to figure out what scribbles over it .....
>
> I haven't tried the initcall_debug yet but can if needed.
Below is a patch which gives us the call path of the unnamed object
which causes the crash.
Greg???
Thanks,
tglx
---
lib/kobject.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6/lib/kobject.c
===================================================================
--- linux-2.6.orig/lib/kobject.c
+++ linux-2.6/lib/kobject.c
@@ -645,6 +645,9 @@ static void kobject_release(struct kref
struct kobject *kobj = container_of(kref, struct kobject, kref);
#ifdef CONFIG_DEBUG_KOBJECT_RELEASE
unsigned long delay = HZ + HZ * (get_random_int() & 0x3);
+
+ WARN_ON(!kobject_name(kobj));
+
pr_info("kobject: '%s' (%p): %s, parent %p (delayed %ld)\n",
kobject_name(kobj), kobj, __func__, kobj->parent, delay);
INIT_DELAYED_WORK(&kobj->release, kobject_delayed_cleanup);
