[Intel-gfx] Current drm-intel-next status on broadwell platform
Hello, I tested drm-intel-next published Aug 9th 2016. I'm facing two major bugs: 1) hard lockups with fbc enabled (neverending story it seems to be) 2) screen tearing in browsers and video players (I do not use any kind of compositor) Should I fire a bug report? both of these two were OK in drm-intel-next published on May 23rd 2016 but in that release, color calibration via LUTs (xcalib) was completely broken. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] vsync + vaapi question
Hi, On Thu, Dec 24, 2015 at 08:42:01PM +0100, Lukas Hejtmanek wrote: > > Hard? The fault isn't in libva this time at least. > > applied patch results in hard lockup when playing a movie (short sound loop > and even sysrq keys are not working). I thought that driver would reset gpu > eventualy but it seems to be completely dead. > > So I reverted the patch and it seems lockups are gone. For ubuntu, that vaapi sync patch just landed. Had to switch to xv from vaapi to avoid frequent lockup. Anything out there I can try to fix lockups? -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] vsync + vaapi question
On Thu, Dec 24, 2015 at 06:54:44PM -0500, Robert Hooker wrote: > The 3.19 distro kernel in ubuntu is using 4.2-ish drm backported on broadwell, > try http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19.8-ckt12-vivid/ > instead which is stock upstream. tried, lockup as well.. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] vsync + vaapi question
On Thu, Dec 24, 2015 at 08:05:33PM +, Chris Wilson wrote: > On Thu, Dec 24, 2015 at 08:59:49PM +0100, Lukas Hejtmanek wrote: > > On Thu, Dec 24, 2015 at 07:55:42PM +, Chris Wilson wrote: > > > That's a kernel panic or total machine lockup. Do you have a few > > > different kernels you can try? Hopefully it's a recent regression. > > > > the same for ubuntu's kernel 4.2.0 and 4.3.0. > > Keep going... Jump to about 3.19 tried 3.19.0-42 from ubuntu. lockup as well it just took more time.. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] vsync + vaapi question
On Thu, Dec 24, 2015 at 10:22:24PM +, Chris Wilson wrote: > > tried 3.19.0-42 from ubuntu. lockup as well it just took more time.. > > Hmm. What hardware? Baytrail? Lenovo X1 Carbon 2015. Intel(R) HD Graphics 5500 (according to log) pci id 8086:1616 (rev 09) -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] vsync + vaapi question
On Thu, Dec 24, 2015 at 03:50:17PM +, Chris Wilson wrote: > On Thu, Dec 24, 2015 at 10:44:46AM +0100, Lukas Hejtmanek wrote: > > On Wed, Dec 23, 2015 at 01:38:26PM +, Chris Wilson wrote: > > > Try (libva): > > > > seems to be much better. I got one lockup though but it may be unrelated. > > Unfortunately probably related, since we now enforce synchronisation to > vblank there are a few more bit and pieces involved. > > > Thanks, hope you push it into mainstream. > > Patch sent. huh, maybe it is not good idea. Had to revert it because of number of hard lockups :( or are there any patches I can try to fix those lockups? -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] vsync + vaapi question
On Thu, Dec 24, 2015 at 07:37:18PM +, Chris Wilson wrote: > > huh, maybe it is not good idea. Had to revert it because of number of hard > > lockups :( > > > > or are there any patches I can try to fix those lockups? > > Hard? The fault isn't in libva this time at least. applied patch results in hard lockup when playing a movie (short sound loop and even sysrq keys are not working). I thought that driver would reset gpu eventualy but it seems to be completely dead. So I reverted the patch and it seems lockups are gone. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] vsync + vaapi question
On Thu, Dec 24, 2015 at 07:55:42PM +, Chris Wilson wrote: > That's a kernel panic or total machine lockup. Do you have a few > different kernels you can try? Hopefully it's a recent regression. the same for ubuntu's kernel 4.2.0 and 4.3.0. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] vsync + vaapi question
On Wed, Dec 23, 2015 at 01:38:26PM +, Chris Wilson wrote:
> Try (libva):
seems to be much better. I got one lockup though but it may be unrelated.
Thanks, hope you push it into mainstream.
> diff --git a/va/x11/dri2_util.c b/va/x11/dri2_util.c
> index d076fb3..9ff5e95 100644
> --- a/va/x11/dri2_util.c
> +++ b/va/x11/dri2_util.c
> @@ -95,8 +95,9 @@ dri2SwapBuffer(VADriverContextP ctx, struct dri_drawable
> *dri_drawable)
> if (dri2_drawable->has_backbuffer) {
> if (gsDRI2SwapAvailable) {
> CARD64 ret;
> -VA_DRI2SwapBuffers(ctx->native_dpy, dri_drawable->x_drawable, 0,
> 0,
> - 0, );
> +VA_DRI2SwapBuffers(ctx->native_dpy, dri_drawable->x_drawable,
> + 0, 1, 0,
> + );
> } else {
> xrect.x = 0;
> xrect.y = 0;
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
Lukáš Hejtmánek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] vsync + vaapi question
On Wed, Dec 23, 2015 at 12:01:44PM +, Chris Wilson wrote: > The clipped extents of the va-api Window is used to determine which CRTC > to use as the vblank source. Hmm, the Primary Output is used as the > preference (i.e. if any part of that Window is on the Primary, it is > used as the CRTC - the idea being that Primary is important and this > should share the vblank source for more Windows and prevent arbitrary > jumps between vblank sources as the Window moves). just tested, with xv output, vsync seems to be quite ok. however, with va-api it not ok on both LVDS and HDMI. HDMI seems to be far worse with va-api (i.e. out of sync). Maybe a bug in va-api sync code? -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] vsync + vaapi question
On Tue, Dec 22, 2015 at 08:54:08PM +, Chris Wilson wrote: > Not really. The Primary output will be used as the vsync so long as a > single pixel of the Window is upon it. Fundamentally, we need to use the > output that the Window is on in order to driver the vblank update. Which window? Any window or the va-api window? In the latter case, it would be quite ok to setup left-of instead of clone and move mplayer window solely to the external monitor. Do I understand it correctly? > Ville once upon a time mentioned plans to try and synchronise the > vblanks on matched outputs, i.e. start two 60Hz monitors at precisely > the same time so they remain reasonably in sync. hmm, well, right now, LVDS is running on 60Hz while HDMI2 runs at 30Hz. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] vsync + vaapi question
Hello, is it possible to switch vsync from internal LCD (laptop) to external monitor when playing movie via VA-API? I can drop vsync with internal LCD and keep vsync only with external monitor. I tried to use --primary for excernal monitor when enabling output but no luck. Is there any way to sync with external monitor? Chris once told me that anything is possible. So? :) -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Render bug
Hello, is it known problem that running remote java application (over ssh + x11 forwarding) causes text corruption? Images attached. Using latest git X11 driver + 4.2.0 kernel. HW is broadwell Lenovo thinkpad X1 Carbon 3rd gen (2015). -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel Driver and 4K video output
On Fri, Apr 24, 2015 at 02:15:09PM +0100, Chris Wilson wrote: Check panning afterwards? What does xrandr --verbose say before/after? even with explicit: xrandr --output eDP1 --off --fb 3840x2160 --panning 3840x2160 no luck. looks like you need at least one outout that keeps fb/panning, disconnected are not counted. pitty I cannot use VIRTUAL1 for this purpose. xrandr --verbose Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 32767 x 32767 eDP1 connected (normal left inverted right x axis y axis) Identifier: 0x43 Timestamp: 308974 Subpixel: unknown Clones: CRTCs: 0 1 2 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: EDID: 000030e41904 00170103a01f1178024295a15a579427 0d50540001010101010101010101 010101010101e45c00a0a0a011503020 230036ae101a 00fe004c 4720446973706c61790a202000fe 004c503134305148312d5350423100bc BACKLIGHT: 852 range: (0, 852) Backlight: 852 range: (0, 852) scaling mode: Full aspect supported: None, Full, Center, Full aspect Broadcast RGB: Automatic supported: Automatic, Full, Limited 16:235 audio: auto supported: force-dvi, off, auto, on 2560x1440 (0x4a) 237.8MHz +HSync -VSync +preferred h: width 2560 start 2608 end 2640 total 2720 skew0 clock 87.4KHz v: height 1440 start 1442 end 1445 total 1457 clock 60.0Hz 1920x1440 (0xdf) 234.0MHz -HSync +VSync h: width 1920 start 2048 end 2256 total 2600 skew0 clock 90.0KHz v: height 1440 start 1441 end 1444 total 1500 clock 60.0Hz 1856x1392 (0xe0) 218.3MHz -HSync +VSync h: width 1856 start 1952 end 2176 total 2528 skew0 clock 86.4KHz v: height 1392 start 1393 end 1396 total 1439 clock 60.0Hz 1792x1344 (0xe1) 204.8MHz -HSync +VSync h: width 1792 start 1920 end 2120 total 2448 skew0 clock 83.7KHz v: height 1344 start 1345 end 1348 total 1394 clock 60.0Hz 1920x1200 (0xe2) 154.0MHz +HSync -VSync h: width 1920 start 1968 end 2000 total 2080 skew0 clock 74.0KHz v: height 1200 start 1203 end 1209 total 1235 clock 60.0Hz 1920x1080 (0xe3) 138.5MHz +HSync -VSync h: width 1920 start 1968 end 2000 total 2080 skew0 clock 66.6KHz v: height 1080 start 1083 end 1088 total clock 59.9Hz 1600x1200 (0xe4) 162.0MHz +HSync +VSync h: width 1600 start 1664 end 1856 total 2160 skew0 clock 75.0KHz v: height 1200 start 1201 end 1204 total 1250 clock 60.0Hz 1680x1050 (0xe5) 146.2MHz -HSync +VSync h: width 1680 start 1784 end 1960 total 2240 skew0 clock 65.3KHz v: height 1050 start 1053 end 1059 total 1089 clock 60.0Hz 1680x1050 (0xe6) 119.0MHz +HSync -VSync h: width 1680 start 1728 end 1760 total 1840 skew0 clock 64.7KHz v: height 1050 start 1053 end 1059 total 1080 clock 59.9Hz 1600x1024 (0xe7) 103.1MHz +HSync +VSync h: width 1600 start 1600 end 1656 total 1664 skew0 clock 62.0KHz v: height 1024 start 1024 end 1029 total 1030 clock 60.2Hz 1400x1050 (0xe8) 122.0MHz +HSync +VSync h: width 1400 start 1488 end 1640 total 1880 skew0 clock 64.9KHz v: height 1050 start 1052 end 1064 total 1082 clock 60.0Hz 1280x1024 (0xe9) 108.0MHz +HSync +VSync h: width 1280 start 1328 end 1440 total 1688 skew0 clock 64.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz 1440x900 (0xea) 106.5MHz -HSync +VSync h: width 1440 start 1520 end 1672 total 1904 skew0 clock 55.9KHz v: height 900 start 903 end 909 total 934 clock 59.9Hz 1280x960 (0xeb) 108.0MHz +HSync +VSync h: width 1280 start 1376 end 1488 total 1800 skew0 clock 60.0KHz v: height 960 start 961 end 964 total 1000 clock 60.0Hz 1360x768 (0xec) 84.8MHz -HSync +VSync h: width 1360 start 1432 end 1568 total 1776 skew0 clock 47.7KHz v: height 768 start 771 end 781 total 798 clock 59.8Hz 1360x768 (0xed) 72.0MHz +HSync -VSync h: width 1360 start 1408 end 1440 total 1520 skew0 clock 47.4KHz v: height 768 start 771 end 781 total 790 clock 60.0Hz 1152x864 (0xee) 81.6MHz -HSync +VSync h: width 1152 start 1216 end 1336 total 1520 skew0 clock 53.7KHz v: height 864 start 865 end 868 total
Re: [Intel-gfx] Intel Driver and 4K video output
On Mon, Apr 27, 2015 at 02:26:36PM +0100, Chris Wilson wrote: Hmm, you probably could... Try xrandr --newmode v4k 712.34 3840 4152 4576 5312 2160 2161 2164 2235 -HSync +Vsync xrandr --addmode VIRTUAL1 v4k xrandr --output VIRTUAL1 --mode v4k well, this is a half way through ;) xfce-panel recognizes a single whole screen. openbox does not. I.e., xfce-panel spans whole width, maximized windows span half screen size. Slightly wondering how is this even possible (different views with different apps). Maybe I should be satisfied with this :) Mainly because the DPMS thing is a bit worse than this and not wanting you to get exhausted because of crappy apps.. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel Driver and 4K video output
On Fri, Apr 24, 2015 at 01:24:56PM +0100, Chris Wilson wrote: iirc xrandr automatically chooses a fb size for your based on the remaining outputs. If you add --fb 3840x2160 to each of your invocations, it shouldn't touch the screen size. Hopefully. -Chris if you meant something like this: xrandr --output eDP1 --off --fb 3840x2160 then nope, logical screen size is shrunk to 1920x2160. The logical means, that maximizing windows results in a half wide windows and the same is for xfce panel. The display is 3840x2160 as expected. Moreover, if I unplug display port cable while eDP1 is off, I don't have any screen and it is hard to get at least some display. I thought that this is kind of hotplug, i.e., something happens on plug/unplung and that the result is different of all black screen. Also, plugging display port cable back does not restore display at least on the external monitor, so I have both of them black only.. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel Driver and 4K video output
Chris, On Thu, Apr 23, 2015 at 11:19:50AM +0100, Chris Wilson wrote: Anything is possible... Considering that the two halves are different sizes to the eDP, you can either scale the DP or scale the panel. You can try something like well, if anything is possible, can I keep virtual size 4k while display is turned off? What I do is: xrandr --output eDP1 --panning 3840x2160 xrandr --output DP1-9 --preferred --pos 0x0 --crtc 1 --output DP1-8 --preferred --pos 1920x0 --crtc 2 xrandr --output eDP1 --off if I do not turn eDP1 off, things work pretty well. However, as soon as I turn eDP1 off, window manager thinks I have two separate screens 1920x2160, e.g., xfce panel shrinks to a half of size. I do all this to switch desktop to external diplay while in office. So I would like to have eDP1 turned off and use only the external display while being able to switch them on the fly using xrandr. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel Driver and 4K video output
Chris, On Wed, Apr 22, 2015 at 03:27:51PM +0100, Chris Wilson wrote: Try $ xrandr \ --output eDP1 --primary --preferred \ --output DP1-8 --preferred --right-of eDP1 \ --output DP1-9 --preferred --right-of DP1-8 anubis: ~ $ xrandr \ Continue --output eDP1 --primary --preferred \ Continue --output DP1-8 --preferred --right-of eDP1 \ Continue --output DP1-9 --preferred --right-of DP1-8 xrandr: Configure crtc 1 failed I can turn on either DP1-8 *or* DP1-9. But not both. No matter which one I start, the other one fails with crtc 1 failed. below I provide driver version: intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20141121 intel(0): SNA compiled from 2.99.916-145-g6c2707d and this is from log while trying set the output: [116082.906] (II) intel(0): Enabled output DP2-1 [116082.906] (II) intel(0): Enabled output DP2-2 [116082.906] (II) intel(0): Enabled output DP2-3 [116082.906] (II) intel(0): Enabled output DP1-8 [116082.907] (II) intel(0): Enabled output DP1-9 [116082.995] (II) intel(0): resizing framebuffer to 6400x2160 [116083.043] (II) intel(0): switch to mode 1920x2160@60.0 on DP1-8, DP1-9 using pipe 1, position (2560, 0), rotation normal, reflection none [116083.047] (EE) intel(0): failed to set mode: Invalid argument [22] [116083.380] (II) intel(0): resizing framebuffer to 2560x1440 [116083.393] (II) intel(0): switch to mode 2560x1440@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none [116164.838] (II) intel(0): resizing framebuffer to 4480x2160 [116164.880] (II) intel(0): switch to mode 1920x2160@60.0 on DP1-8 using pipe 1, position (2560, 0), rotation normal, reflection none [116206.941] (II) intel(0): resizing framebuffer to 2560x1440 [116212.223] (II) intel(0): resizing framebuffer to 2560x2160 [116212.243] (II) intel(0): switch to mode 1920x2160@60.0 on DP1-9 using pipe 1, position (0, 0), rotation normal, reflection none [116241.928] (II) intel(0): switch to mode 1920x2160@60.0 on DP1-8, DP1-9 using pipe 1, position (0, 0), rotation normal, reflection none [116242.255] (EE) intel(0): failed to set mode: Invalid argument [22] [116242.577] (II) intel(0): switch to mode 2560x1440@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none [116243.364] (II) intel(0): switch to mode 1920x2160@60.0 on DP1-9 using pipe 1, position (0, 0), rotation normal, reflection none [116275.265] (II) intel(0): resizing framebuffer to 2560x1440 -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel Driver and 4K video output
On Thu, Apr 23, 2015 at 10:22:31AM +0100, Chris Wilson wrote: $ xrandr --output eDP1 --off --output DP1-8 --off --output DP1-9 --off ; \ xrandr \ --output eDP1 --primary --preferred --crtc 0 \ --output DP1-8 --preferred --right-of eDP1 --crtc 1 \ --output DP1-9 --preferred --right-of DP1-8 --crtc 2 well, this one works! Two caveats, have to switch DP1-8 and DP1-9, otherwise, I have switched sides. However, I would like to have a clone. But this seems to be a bit tricky, I can say same-as, bud not as a conjunction of both DP1-8 and DP1-9. Is there any possibility to mirror eDP to both DP1-8 and DP1-9? Or the best I can get is independent screens? On NVIDIA, I had to setup xinerama to have a big single screen. However, with xinerama, xrandr is inoperational. So no luck here? -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel Driver and 4K video output
On Thu, Apr 23, 2015 at 11:19:50AM +0100, Chris Wilson wrote: I probably have the scaling inverted. What should also work, but we may have to beat the kernel up to fix a few bugs... xrandr --addmode eDP1 3840x2160 \ --output eDP1 --primary --mode 3840x2160 --crtc 0 \ --output DP1-9 --preferred --position 0x0 -crtc 1 \ --output DP1-8 --preferred --position 1920x0 -crtc 1 \ That way we should be able to use the panel fitter for hardware downscaling. But there are all sorts of bandwidth caveats that I may have violated, as well as the code being untested! However, the mouse will be the wrong size. :| well, this one does not work, but I found this command working like a charm: xrandr --output eDP1 --panning 3840x2160 xrandr --output DP1-9 --preferred --pos 0x0 --crtc 1 --output DP1-8 --preferred --pos 1920x0 --crtc 2 than I have one big screen as desired and window manager is completely happy with it, i.e., window maximizing really maximizes the window to 3840x2160. So really happy with it. Maybe, one day someone proposes a window manager that rearrange windows on resolution change ;) -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Hangcheck does not work on SNB?
On Mon, Apr 02, 2012 at 08:32:50AM +0100, Chris Wilson wrote: Even after you stop the video? All it sounds like so far is that it is no longer rendering video frames. Also check your Xorg.log and video player for diagnostics. Xorg.log contains (however this may be consequence of SAK (sysrq-k)): [157714.584] [mi] EQ overflowing. Additional events will be discarded until existing events are processed. [157714.584] Backtrace: [157714.589] 0: /usr/bin/X (xorg_backtrace+0x26) [0x7f57d14622f6] [157714.589] 1: /usr/bin/X (mieqEnqueue+0x263) [0x7f57d14429d3] [157714.589] 2: /usr/bin/X (0x7f57d12da000+0x62814) [0x7f57d133c814] [157714.589] 3: /usr/bin/X (xf86PostMotionEvent+0xd8) [0x7f57d1379fb8] [157714.589] 4: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f57cb9f3000+0x3d28) [0x7f57cb9f6d28] [157714.589] 5: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f57cb9f3000+0x5f34) [0x7f57cb9f8f34] [157714.589] 6: /usr/bin/X (0x7f57d12da000+0x8ace7) [0x7f57d1364ce7] [157714.590] 7: /usr/bin/X (0x7f57d12da000+0xb0bda) [0x7f57d138abda] [157714.590] 8: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f57d060+0xfcb0) [0x7f57d060fcb0] [157714.590] 9: /lib/x86_64-linux-gnu/libc.so.6 (ioctl+0x7) [0x7f57cf55ed27] [157714.590] 10: /usr/lib/x86_64-linux-gnu/libdrm.so.2 (drmIoctl+0x28) [0x7f57cdaf11a8] [157714.590] 11: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f57cd5fa000+0x374ee) [0x7f57cd6314ee] [157714.590] 12: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f57cd5fa000+0x6789a) [0x7f57cd66189a] [157714.590] 13: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f57cd5fa000+0x42bca) [0x7f57cd63cbca] [157714.590] 14: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f57cd5fa000+0x55dee) [0x7f57cd64fdee] [157714.590] 15: /usr/bin/X (BlockHandler+0x4a) [0x7f57d132c51a] [157714.590] 16: /usr/bin/X (WaitForSomething+0x11d) [0x7f57d145f65d] [157714.590] 17: /usr/bin/X (0x7f57d12da000+0x4e4b2) [0x7f57d13284b2] [157714.590] 18: /usr/bin/X (0x7f57d12da000+0x3d68a) [0x7f57d131768a] [157714.590] 19: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xed) [0x7f57cf49576d] [157714.591] 20: /usr/bin/X (0x7f57d12da000+0x3d97d) [0x7f57d131797d] [157714.591] [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack. [157714.591] [mi] mieq is *NOT* the cause. It is a victim. And I am unable to stop the video, X session is completely dead so I don't even see if and what mplayer complains about. It seems that the video suddenly slows down and then stops completely but I am not 100% sure about this. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Hangcheck does not work on SNB?
Hello, should the hangcheck mechanism work on Sandy Bridge when XVideo causes GPU to hang? I can repeatedly hang GPU playing video for at least 1 hour continuously. Mouse cursor moves but nothing else. However, I got no message from kernel that GPU hung. The notebook is alive except graphics. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: re-enable rc6 by default
Hi, On Mon, Nov 14, 2011 at 06:39:15PM -0200, Eugeni Dodonov wrote: Most of the rc6-related hangs and major issues were addressed for the past months. which commits should I try to check whether rc6 issue is gone? As of 3.1 kernel, I'm still getting huge screen corruption. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: re-enable rc6 by default
On Mon, Nov 14, 2011 at 09:04:37PM -0200, Eugeni Dodonov wrote: The rc6 issue which are gone are the ones which was causing hard system hangs and gpu hangs. Corruptions are still out there, if they don't go away when using intel_iommu=off then we'll have to investigate them more in-depth. I disabled iommu in BIOS, so I guess it is not an issue here. I am unable to reproduce any rc6-related corruptions on my machine(s) though. So it looks like this is yet another case in which we'll need to use Sherlock Holmes methods to get to them... are you using SNA? I do on my SNB system. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: re-enable rc6 by default
On Mon, Nov 14, 2011 at 09:17:39PM -0200, Eugeni Dodonov wrote: Are the issues SNA-specific, or they happen with UXA as well? I do use both SNA and UXA actually (thanks to http://cgit.freedesktop.org/~eugeni/xf86-video-intel/ :)). I believe they happen with both but with SNA I got regular corruption while with UXA I got accidental corruption. I.e., with SNA I got corrupted window in few minutes, with UXA maybe one corruption per few hours. But I did not try those Eric's gating patches with UXA. I got also X server segfaults related to XV video (moving window, resing window with video crashes the X server randomly). Didn't investigate this (getting core file, e.g.) I have X server 1.10, I think there are some fixes around 1.12. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible wrong flushes on SNB
Chris, On Tue, Oct 11, 2011 at 09:01:20PM +0100, Chris Wilson wrote: If you are using SNA, the likely cause of the flash is the flush, read, modify, write of a fallback. That is we flush pending operations in the batchbuffer (likely a fill to the scanout), read back from the scanout the just modified region and perform the fallback with the CPU. That modification is then queued up to be written out sometime in the near future. That delay between the fill and the final write can cause flickering. By contrast UXA performs its fallbacks inplace and so such flicker should not be any more perceivable than any other drawing operation. File a bug. If you are using SNA, I'd like to prevent the fallback and so avoid the flicker. Or I may have misdiagnosed it entirely, so in any case I want sufficient information to reproduce. I did: #41718 -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Possible wrong flushes on SNB
Hi, I have SNB chip, with git driver 5913c90967091124e7c7b262782f0e99cf400eab, 3.1-rc9 kernel. I noticed that refresh of notification area or e.g., xosview refresh is linked with flashing. Looks like background exposing is synced with vertical refresh so it is visible and disturbing. This behaviour is more noticable at fresh start of system (after boot). If I run my desktop for several days, the problem disappears. Is it something new? Or something interesting so I should create a bug on fdo? -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) garbled window content when scrolling with SNA enabled
Chris, On Thu, Aug 04, 2011 at 09:12:13PM +0200, Lukas Hejtmanek wrote: Oh, I forgot to answer this one. XV is just fine with 2.6.39 and the same git head driver as tried with 3.0.0. well, it is not :( this is screenshot of XV corruption with 2.6.39 kernel. http://www.fi.muni.cz/~xhejtman/snb-bug9.png is there anything I can do in this issue? At least create bugzilla record? I'm capable of some debugging but not sure where should I start.. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) garbled window content when scrolling with SNA enabled
On Wed, Aug 03, 2011 at 08:44:30AM +0100, Chris Wilson wrote: I gave a try to 3.0 kernel but problems were even worse. Playing video using XV gave me random framents of video accross whole desktop :( This is to starting to sound quite serious. Is this just an excerbation of 2.6.39 behaviour or is it an entirely new failure mode? Oh, I forgot to answer this one. XV is just fine with 2.6.39 and the same git head driver as tried with 3.0.0. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) garbled window content when scrolling with SNA enabled
On Wed, Aug 03, 2011 at 08:44:30AM +0100, Chris Wilson wrote: I got screen corruption accross all the apps (xfce-terminal, im psi, xfce4 panel, firefox). Not all are text related, e.g., xfce4 panel gets corrupted in pager (workspace switcher where no text is). I know xfce4 has the choice of a compositor, do you have it enabled? Is it possible to capture the corruption in a screen shot? I got another observation. Videos played in firefox from youtube do not get refresh. Playback is only visible if I move another window on top of the firefox and its subwindow with video content. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) garbled window content when scrolling with SNA enabled
On Sat, Jul 09, 2011 at 12:59:50PM +0100, Chris Wilson wrote: On Sat, 9 Jul 2011 13:19:57 +0200 (CEST), Nicolas Kalkhof nkalk...@web.de wrote: Hi Chris, Applications: Oxygen XML Editor 12.2 using latest jdk 1.6.0 (get the trial here: http://www.oxygenxml.com/) Squirrel SQL Editor 3.2.1 (get it here: http://squirrel-sql.sourceforge.net/) Desktop: XFCE 4.8 or Trinity 3.5.12 Got a ScreenRegion dumped with xwd, see attachment. Given that I have to wait for a trial key, you're going to have to convince me that it is not simply the application mishandling a NoExpose. What are the steps to reproduce within Oxygen XML Editor? Can it be reproduced within the help system, which is all I can access at the moment? Can it be reproduced in any other application using a different toolkit? Chris, I'm getting similar render issues with XFCE and openbox. I use 2.6.39.3 kernel + git head driver (--enable-sna). I got screen corruption accross all the apps (xfce-terminal, im psi, xfce4 panel, firefox). Not all are text related, e.g., xfce4 panel gets corrupted in pager (workspace switcher where no text is). My HW is Lenovo T420. 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) I gave a try to 3.0 kernel but problems were even worse. Playing video using XV gave me random framents of video accross whole desktop :( Also, is it a bug that xrandr does not report eDP and DVI ports? (the first one is located on the NTB itself and dock, DVI is located on the dock only.) xrandr reports only VGA1 and LVDS1 ports. I have optimus variant but I switched to Intel only in BIOS. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Backlight bug
Hello, as of 2.6.37-rc kernels, backlight is dimmed to level 2 as soon as I close LID. After opening, backlight level is not restored to my level (4). However, /sys/class/backlight/acpi_video0/brightness still reports level 4 even if real level is 2. I have Lenovo ThinkPad T61 with 965GM. -- Lukáš Hejtmánek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
