Re: [RFC 2/3] mei: unstaging mei driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Sun, 25 Mar 2012 16:11:43 +0000
"Winkler, Tomas" <tomas.winkler@xxxxxxxxx> 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
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel


[Video for Linux]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Photos]     [Yosemite Photos]     [Free Singles Community]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Devices]     [Yosemite Backpacking]

Add to Google Powered by Linux