lkml.org 
[lkml]   [2013]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fb: Rework locking to fix lock ordering on takeover
Am 28.12.2012 13:40, schrieb Borislav Petkov:
> On Fri, Dec 28, 2012 at 07:50:27PM +0800, Shawn Guo wrote:
>> +1
>>
>> http://thread.gmane.org/gmane.linux.kernel/1413953/focus=1415070
>
> Cool, works fine here too. Is Linus on CC? (/me checks.. ) Yes he is,
> good.
>
> Linus, Alan's patch works at least in 2 cases, you might consider
> picking it up directly since the fb maintainer is absent, reportedly.


Btw. I think all the usb-fb's (udlfb, smscufx and udl) are broken, at
least on ARM(v5). When I have linked in udlfb the following happens on
boot (with an attached USB-LCD and with or without the "Rework locking
patch):

dlfb_init_framebuffer_work() (work)
register_framebuffer() (lock mutex registration_lock)
(vt_console_print) (spinlock printing_lock)
(fbcon_scroll)
(fbcon_redraw)
(fbcon_putcs)
(bit_putcs)
dlfb_ops_imageblit()
dlfb_handle_damage()
dlfb_get_urb()
down_timeout(semaphore)
BUG: scheduling while atomic
(vt_console_print) (release spinlock printing_lock)
register_framebuffer() (unlock mutex registration_lock)

The above is without the "Rework locking" patch. But I get the same BUG
with the patch (so the patch doesn't do any harm), I just haven't looked
in detail what changed with the patch.

I don't get the BUG when I try the same on a x86_64 machine, not sure
why. I've just started to read me through the code, documentation and
the "Rework locking" patch. And I'm slow in doing so (spare time).
But maybe someone else with more knowledge about the inner workings of
this stuff is faster than I.

Regards,

Alexander


\
 
 \ /
  Last update: 2013-01-04 14:21    [W:0.110 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site