linux-kernel - Re: [Intel-gfx] blank screen on boot with i915/DRM_FBDEV

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Mar 2016 08:29:57 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Florian Zumbiehl <florz@...rz.de>
Cc:	intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org,
	Daniel Vetter <daniel.vetter@...el.com>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	David Airlie <airlied@...ux.ie>
Subject: Re: [Intel-gfx] blank screen on boot with i915/DRM_FBDEV_EMULATION

On Tue, Mar 29, 2016 at 06:44:57PM +0200, Florian Zumbiehl wrote:
> Hi,
> 
> > FBDEV_EMULATION vs. I915_FBDEV is probably a read herring, more likely is
> > that for some odd reason the very first modeset fails. Once X has
> > resurrect the screen, can you then switch to fbcon? Also please check in
> > /sys/class/vtconsole whether the fbdev driver is loaded and bound (check
> > the name and bind files). And make sure there's that dmesg still says it
> > initialized the "inteldrmfb" driver.
> 
> Trying to collect that information actually solved the problem: fbcon
> didn't actually get loaded during boot, only the graphics drivers, which
> caused the screen to go blank, loading fbcon happened only when starting
> the X server ... seems weird to me, but I guess there is some non-obvious
> logic behind that, and in any case it seems to be a change in behaviour.
> Well, thanks for the pointer anyway, I guess! ;-)
> 
> Now, while at it: I also have a bunch of WARN_ONs and ERRORs happening (the
> former primarily when an Xv window disappears from the screen, it seems,
> the latter primarily during boot), which don't seem to have any immediate
> negative effects at the surface, like this:
> 
> | [   14.815467] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
> | [   14.815642] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe B underrun
> | [   14.815806] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
> | [   14.823686] [drm] initialized overlay support
> | [   14.873165] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

We've fixed piles of those in recent kernels, but didn't backport all the
fixes (since usually it's a silent failure, but it can correlate with
black screens).
 
> | [ 2520.457732] WARNING: CPU: 0 PID: 3193 at drivers/gpu/drm/i915/i915_gem.c:4508 i915_gem_free_object+0x277/0x280 [i915]()
> | [ 2520.457736] WARN_ON(obj->frontbuffer_bits)

Hm, this one should be fixed, and the patches should all be correctly
marked for stable. Either there's a backlog somewhere, or we failed.

Would be great if you can test a drm-intel-nightly build (or 4.6-rc1) for
either and confirm that they're gone. And for the later we really should
hunt down the bugfix if it's stuck.

> Also, I have occasional X server crashes (every few weeks or so) which
> started with 4.1.9, I think (I had 3.11.0 before that), and I had some kind
> of problem with Xv not working anymore until reboot with 4.1.9 which hasn't
> happened with 4.4.5 yet ... do you think any of those would be worth
> further investigation? If so, any suggestions as to how to split it all
> into separate issues/how to go about it?

No idea about X stuff, not my expertise ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch