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@xxxxxxxx>: > > On Sat, May 10, 2014 at 10:52 AM, Jörg Otte <jrg.otte@xxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
