Hi,
I'm hitting the following recursive locking problem when unblanking
the framebuffer (echoing 3 then 0 to /sys/class/graphics/fb0/blank).
Basically this is what's happening:
* the fb_blank function sends the blank notification
* fbcon gets the blank notification, and calls fbcon_switch
* fbcon_switch calls fb_set_var
* fb_set_var actually makes a change, which triggers another
notification (mode change), which tries to lock fb_notifier_list.rwsem
again, which triggers the lockdep warning (and presumably potentially
a deadlock).
The reason fb_set_var makes a change is because the mode list has been
updated since the last mode change, so the current mode is effectively
out of date. E.g. this could be done by writing to
/sys/class/graphics/fb0/modes, or in my case an HDMI driver updates
the modelist on a monitor hotplug event after reading the EDID in the
same way as the sysfs interface.
So, a few questions:
(1) Is this situation a valid situation, where the modelist has been
overwritten but current mode left unchanged?
(2) If (1), any ideas how the recursive locking situation should be resolved?
(3) If not (1), should updating the modelist using sysfs (and
similarly on a monitor hotplug event), also update the current mode to
the nearest mode in the list (fb_new_modelist would seem an
appropriate place)?
Thanks
James
======================[ INFO: possible recursive locking detected ]
2.6.37-rc7+ #1435
---------------------------------------------
sh/382 is trying to acquire lock:
((fb_notifier_list).rwsem){.+.+.+}, at: [<40040a60>]
___blocking_notifier_call_chain+0x34/0x80
43 more lines