[Intel-gfx] [3.14.0-rc4] regression: drm FIFO underruns

[Daniel Vetter]

On Mon, May 12, 2014 at 01:25:24PM +0200, Jörg Otte wrote:
> 2014-05-11 18:49 GMT+02:00 Daniel Vetter <daniel.vetter at ffwll.ch>:
> > On Sat, May 10, 2014 at 10:52 AM, Jörg Otte <jrg.otte at gmail.com> wrote:
> >>> On Fri, May 09, 2014 at 05:14:38PM +0100, Damien Lespiau wrote:
> >>>> On Fri, May 09, 2014 at 06:11:37PM +0200, Jörg Otte wrote:
> >>>> > > Jörg, can you please boot with drm.debug=0xe, reproduce the issue and
> >>>> > > then attach the complete dmesg? Please make sure that the dmesg
> >>>> > > contains the boot-up stuff too.
> >>>> > >
> >>>> > > Thanks, Daniel
> >>>> > Here it is. I should mention it only happens at boot-up.
> >>>>
> >>>> [    0.374095] [drm] Wrong MCH_SSKPD value: 0x20100406
> >>>> [    0.374096] [drm] This can cause pipe underruns and display issues.
> >>>> [    0.374097] [drm] Please upgrade your BIOS to fix this.
> >>>
> >>> That can be a factor, but I think we may have some more general issue
> >>> in the modeset sequence which causes these to get reported. I'm getting
> >>> some on my machine as well where SSKPD looks more sane. Maybe we turn on
> >>> the error reporting too early or something.
> >>>
> >>> But I'm not going to spend time worrying about these before my previous
> >>> watermark stuff gets merged. Also the underrun reporting code itself
> >>> would need some kind of rewrite to be really useful.
> >>>
> >>> If the display doesn't blank out during use everything is more or less
> >>> fine and you can ignore these errors. It's quite likely that the
> >>> errors were always present and you didn't know it. We just made them
> >>> more prominent recently.
> >>>
> >>> --
> >>> Ville Syrjälä
> >>> Intel OTC
> >>
> >> It comes out on the boot-up screen which is normally clean. So it becomes
> >> highly visible for anyone.
> >
> > To make sure that you're only seeing this at boot up and not elseplace
> > please check that it doesn't show up when you do anything of the
> > below:
> > a) suspend/resume
> > b) changing the output mode (e.g. with xrandr --mode)
> > c) changing the output pipe (e.g. with xrandr --crtc)
> > d) all of the above but with heavy system load, e.g. compile kernels
> > with make -j <num-cores*2>
> >
> > Also please test the latest drm-intel-nightly branch from
> > http://cgit.freedesktop.org/drm-intel to make sure we haven't yet
> > fixed this in our -next branch.
> >
> 
> Ok, that was a lot of homework ;)
> 
> I checked a,b,d):  All worked without FIFO underruns.
> 
> For c): I must admit I don't know what --crtc is good for and
> the man page isn't very useful. I can't enter a meaningful command.

$ xrandr --output <output> --auto --crtc 0

and 

$ xrandr --output <output> --auto --crtc 1

should do the trick, presuming you only have one output in total. Then
switch a bit between them.

> Branch drm-intel-nightly as of
> ed60c27 drm-intel-nightly: 2014y-05m-09d-21h-51m-45s integration manifest
> looks badly:
>    - KDE splash screen on boot-up is not visible
>    - x-windows don't have title and menu bars
>    - KDE system menu is not visible
>    - moving windows around destroys its content

Ugh, that's ugly. Nothing else change like e.g. the version of
xfree-video-intel?

> apart from that: Via control key I can open a terminal and I checked
> a,b), both worked without FIFO underruns.

And what about at boot? If -nightly regresses even on that that's pretty
awful.

Also please test

http://patchwork.freedesktop.org/patch/25568/

it might help for your case. If it doesn't we need to look into what
exactly goes wrong on driver load and where we need to adjust the logic a
bit.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch