On 12/16/2014 10:10 AM, Daniel Vetter wrote: > On Tue, Dec 16, 2014 at 4:00 PM, Peter Hurley <pe...@hurleysoftware.com> > wrote: >>> The fix will be anyway the same in principal even after Daniel's planned >>> rework for fbcon/fbdev: not holding the console_lock while freeing the >>> sysfs entries. >> >> Oh, I didn't know Daniel was planning to rework fbcon/fbdev. > > I don't. I've tried, cried and failed, so maybe in my next live ;-) > But what I've tried was "let's fix fbcon" which was probably a bit too > ambigitous. Splitting the notifier chains should be a lot more doable > (but still lots of work I guess). The problem is it's not just the > notifier chain that's broken with fbcon, but a lot more things: > - initial modeset is done while holding the console lock. Would be > true even after we fix this, since it's done as part of the con setup > done by con_register. We'd need to do the modeset upfront, before > registering fbcon. > - panic handling is a joke with drm drivers and fbdev emulation plus > fbcon - there's way too many sleeps and way too much code in the > fbcon+drm panic path for this to ever work reliably as is. Would need > massive rework. One of the most glaring things is that we have about 3 > things that tried to set up fbcon on panic (drm fbdev emulation panic > handler, console unblanking on panic and fbcon panic handling).
yep - vt + printk + console lock + fbcon/fbdev + drm helper + kms driver is a total nightmare. > It's imo unfixable overall, so my long term plan is to get rid of > fbdev emulation, fbcon and all console_lock paths from kms drivers (we > have that now with I915_FBDEV=n). And then provide consoles with > userspace deamons (kmscon) and a very minimalistic crash-dump tooling > for panic handling on bare-bones kms drivers (not yet there, but > patches from David Herrmann are floating around). Interesting, I'll have to look into that. Regards, Peter Hurleykmscon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
