On Sun, 25 Mar 2012 16:11:43 +0000
"Winkler, Tomas" <[email protected]> wrote:
> > >
> > > Anyway, sorry, but the request still stands, I would like to see
> > > Alan's or other core kernel developers at Intel's acks on this
> > > before I will move it out of staging.
> >
> > Sure, this is understandable. Alan is involved so I will check
> > where this stands.
>
>
> It looks like Alan was too busy with his other tasks in order to
> review the code.
I gave it a first spin today on a T61 with Fedora 15
- the userspace lms code didn't build but adding a missing include
<cstdio> fixed that trivially
- the kernel side seems a bit more broken however
mei 0000:00:03.0: setting latency timer to 64
mei 0000:00:03.0: irq 49 for MSI/MSI-X
and when I tried opening it I get the following spew and an error of
-ENODEV.
======================================================
[ INFO: possible circular locking dependency detected ]
3.3.0-next-20120328 #1 Tainted: G C
-------------------------------------------------------
cat/1248 is trying to acquire lock:
(&dev->device_lock){+.+.+.}, at: [<ffffffffa01348ce>]
mei_open+0x57/0x199 [mei ]
but task is already holding lock:
(misc_mtx){+.+.+.}, at: [<ffffffff8124a57f>] misc_open+0x25/0x149
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (misc_mtx){+.+.+.}:
[<ffffffff81067cd3>] lock_acquire+0x8a/0xa2
[<ffffffff8138908c>] __mutex_lock_common+0x58/0x40b
[<ffffffff81389526>] mutex_lock_nested+0x36/0x3b
[<ffffffff8124a807>] misc_register+0x24/0x105
[<ffffffff812d525a>] watchdog_dev_register+0x41/0x7e
[<ffffffff812d4d99>] watchdog_register_device+0x61/0x80
[<ffffffffa0135f5f>] mei_watchdog_register+0x59/0xb2 [mei]
[<ffffffffa0130e6e>] mei_interrupt_thread_handler+0x6ab/0x21f5
[mei] [<ffffffff810895fe>] irq_thread_fn+0x1b/0x3f
[<ffffffff81089481>] irq_thread+0xac/0x16a
[<ffffffff8104277c>] kthread+0xaa/0xb2
[<ffffffff8138d5d4>] kernel_thread_helper+0x4/0x10
-> #0 (&dev->device_lock){+.+.+.}:
[<ffffffff8106759b>] __lock_acquire+0xa80/0xd74
[<ffffffff81067cd3>] lock_acquire+0x8a/0xa2
[<ffffffff8138908c>] __mutex_lock_common+0x58/0x40b
[<ffffffff81389526>] mutex_lock_nested+0x36/0x3b
[<ffffffffa01348ce>] mei_open+0x57/0x199 [mei]
[<ffffffff8124a664>] misc_open+0x10a/0x149
[<ffffffff810da7ba>] chrdev_open+0x11c/0x145
[<ffffffff810d56c7>] __dentry_open+0x16d/0x27f
[<ffffffff810d6797>] nameidata_to_filp+0x63/0x6a
[<ffffffff810e3202>] do_last+0x55b/0x595
[<ffffffff810e3338>] path_openat+0xce/0x31f
[<ffffffff810e3672>] do_filp_open+0x33/0x81
[<ffffffff810d6808>] do_sys_open+0x6a/0xfc
[<ffffffff810d68b6>] sys_open+0x1c/0x1e
[<ffffffff8138c1e2>] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(misc_mtx);
lock(&dev->device_lock);
lock(misc_mtx);
lock(&dev->device_lock);
*** DEADLOCK ***
1 lock held by cat/1248:
#0: (misc_mtx){+.+.+.}, at: [<ffffffff8124a57f>] misc_open+0x25/0x149
stack backtrace:
Pid: 1248, comm: cat Tainted: G C 3.3.0-next-20120328 #1
Call Trace:
[<ffffffff81383d07>] print_circular_bug+0x1f8/0x209
[<ffffffff8106759b>] __lock_acquire+0xa80/0xd74
[<ffffffff81063ef8>] ? lock_release_holdtime.part.6+0x59/0x61
[<ffffffffa01348ce>] ? mei_open+0x57/0x199 [mei]
[<ffffffff81067cd3>] lock_acquire+0x8a/0xa2
[<ffffffffa01348ce>] ? mei_open+0x57/0x199 [mei]
[<ffffffff8138908c>] __mutex_lock_common+0x58/0x40b
[<ffffffffa01348ce>] ? mei_open+0x57/0x199 [mei]
[<ffffffff810657d8>] ? trace_hardirqs_on_caller+0x151/0x197
[<ffffffff81389526>] mutex_lock_nested+0x36/0x3b
[<ffffffffa01348ce>] mei_open+0x57/0x199 [mei]
[<ffffffff8124a664>] misc_open+0x10a/0x149
[<ffffffff810da7ba>] chrdev_open+0x11c/0x145
[<ffffffff810da69e>] ? cdev_put+0x10/0x10
[<ffffffff810d56c7>] __dentry_open+0x16d/0x27f
[<ffffffff810d6797>] nameidata_to_filp+0x63/0x6a
[<ffffffff810e3202>] do_last+0x55b/0x595
[<ffffffff810e3338>] path_openat+0xce/0x31f
[<ffffffff8104eb9a>] ? sched_clock_cpu+0xba/0xc8
[<ffffffff81063a42>] ? trace_hardirqs_off+0xd/0xf
[<ffffffff810e3672>] do_filp_open+0x33/0x81
[<ffffffff8138b44f>] ? _raw_spin_unlock+0x3c/0x49
[<ffffffff810edcff>] ? alloc_fd+0x16f/0x181
[<ffffffff810d6808>] do_sys_open+0x6a/0xfc
[<ffffffff810d68b6>] sys_open+0x1c/0x1e
[<ffffffff8138c1e2>] system_call_fastpath+0x16/0x1b
_______________________________________________
devel mailing list
[email protected]
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
