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

[Jörg Otte]

2014-05-12 21:03 GMT+02:00 Daniel Vetter <daniel at ffwll.ch>:
> 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.

Works without underruns, with standard and nightly kernel.

>> 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?

 (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
 (II) Module intel: vendor="X.Org Foundation"
 compiled for 1.11.3, module version = 2.17.0
 Module class: X.Org Video Driver
 ABI class: X.Org Video Driver, version 11.0

>> 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.
Sorry I forgot to mention this. It behaves like the standard kernel.
The FIFO underrun comes at boot-up. And than never again.

>
> Also please test
>
> http://patchwork.freedesktop.org/patch/25568/

For me it doesn't make any difference.

>it might help for your case. If it doesn't we need to look into what
>exactly goes wrong on driver load

Don't know if this matters: I always use kernels without loadable modules.
Everything is built-in.


Thanks, Jörg