On 08/12/15 10:19, Daniel Vetter wrote: > On Mon, Dec 07, 2015 at 07:32:42PM +0200, Tomi Valkeinen wrote: >> >> On 25/08/15 16:45, Daniel Vetter wrote: >>> When the usual fbcon legacy options are enabled we have >>> ->register_framebuffer >>> ->fb notifier chain calls into fbcon >>> ->fbcon sets up console on new fbi >>> ->fbi->set_par >>> ->drm_fb_helper_set_par exercises full kms api >>> >>> And because of locking inversion hilarity all of register_framebuffer >>> is done with the console lock held. Which means that the first time on >>> driver load we exercise _all_ the kms code (all probe paths and >>> modeset paths for everything connected) is under the console lock. >>> That means if anything goes belly-up in that big pile of code nothing >>> ever reaches logfiles (and the machine is dead). >>> >>> Usual tactic to debug that is to temporarily remove those console_lock >>> calls to be able to capture backtraces. I'm fed up writing this patch >>> and recompiling kernels. Hence this patch here to add an unsafe, >>> kernel-taining option to do this at runtime. >> >> I think this was never merged. This was part 4 of 4, were there >> dependencies or...? Should I apply this for 4.5? > > Patches 1-3 have all already landed in drm, and patch 4 is free standing. > Would be great if you can pull it in. Ok, I'll apply for 4.5. >> But then... I think my issues with console lock have been later at >> runtime, not at register. Maybe we need a module option to disable the >> console lock altogether. I wonder how much havoc that might create, though. > > Hm, where in fbdev do you hold the console_lock outside of > registering/unregistering an fbdev (because of fbcon)? There's of course > general trouble with console_lock deadlocks and fun like that, but ime > that all got a lot more manageable since I added lockdep annotations to > console_lock. I don't know... I just have a vague recollection that I was having trouble with the lock with... crashes during blanking, perhaps. I really can't remember, so possibly things are better now, or I just remember wrong. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
