2014-05-12 21:03 GMT+02:00 Daniel Vetter <daniel@xxxxxxxx>: > 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. 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
