Bug 41334 - [SNB] Screen Corruption with VAAPI (G620T)
Summary: [SNB] Screen Corruption with VAAPI (G620T)
Alias: None
Product: libva
Classification: Unclassified
Component: intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: haihao
QA Contact:
Depends on:
Reported: 2011-09-29 06:04 UTC by mus.svz
Modified: 2012-02-02 03:28 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

output of "lspci -n" (397 bytes, text/plain)
2011-10-17 07:34 UTC, mus.svz
output of "lspci -vvnn" (7.78 KB, text/plain)
2011-10-19 03:14 UTC, mus.svz
output of "sudo lspci -vvnn" (17.31 KB, text/plain)
2011-10-19 03:20 UTC, mus.svz
XBMC GUI "Corruption" (2.06 MB, image/jpeg)
2011-11-01 10:52 UTC, mus.svz

Description mus.svz 2011-09-29 06:04:56 UTC
I have random screen corruption in XBMC when watching videos with VAAPI. Sometimes it starts after a few minutes, sometimes as soon as I start the video, it is completely random. It was working fine before I reinstalled the machine recently, so I guess this must have been caused by some update.

I have another Sandy Bridge machine with the exact same software configuration which does not have any problems (Core i5 2500, Intel DH67GD).

I doubt that this is a XBMC problem because I have seen no other reports of this problem and it is working fine on the other machine.

I've seen this in multiple videos (all x264 afaik).

See video here:



Output of vainfo:

libva: libva version 0.32.0
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/dri/i965_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA API version: 0.32
vainfo: Driver version: i965 Driver 0.1
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileH264Baseline           :	VAEntrypointVLD
      VAProfileH264Baseline           :	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD



Arch Linux
Kernel 3.0
libva 1.0.14
XBMC Git 2011-09-28
Intel Pentium G620T
MSI H61I-E35
Comment 1 mus.svz 2011-10-12 13:34:27 UTC
I just tested mplayer with -vo vaapi -va vaapi. It has the exact same problem, so it is definitively not an XBMC bug.

Additionally the video is stuttering in mplayer although the CPU usage stays below 10% (no stuttering in XBMC). Not sure if this is related...
Comment 2 haihao 2011-10-12 22:32:07 UTC
You mentioned it works fine with another machine, what is the difference between your two machines?
Comment 3 mus.svz 2011-10-13 03:14:30 UTC
(In reply to comment #2)
> You mentioned it works fine with another machine, what is the difference
> between your two machines?

Machine with the problem:

Intel Pentium G620T
MSI H61I-E35 (B3)

Machine which is working fine:

Intel DH67GD (B3)
Intel Core i5 2500

Both of them are running Arch Linux with Kernel 3.0 and libva 1.0.14. The software configuration is basically the same, so the only difference is the hardware.

Is it possible that is a hardware problem (GPU defect)?
Comment 4 Hai 2011-10-13 20:05:09 UTC
In fact the GPU of G620T is different with the GPU of i5 2500. Please see the following link to get the detailed information.
Maybe it is a bug about chip ID.
It should not support VC-1 hardware decoding and H.264 hardware encoding for G620T, while vainfo showes it support.
Comment 5 mus.svz 2011-10-16 12:10:23 UTC
so what does this mean? that this is a bug in the graphics driver itself? 

anything I can do to narrow down the problem, debugging, logs etc.?
Comment 6 haihao 2011-10-16 20:28:49 UTC
Could you attach the output  of 'lspci -n' ?
Comment 7 mus.svz 2011-10-17 07:34:46 UTC
Created attachment 52425 [details]
output of "lspci -n"
Comment 8 Hai 2011-10-17 18:41:41 UTC
So the kernel gets 0x0102 as the device ID of G620T which is same as sandy bridge. But I am afraid it is wrong.
Comment 9 mus.svz 2011-10-18 09:56:29 UTC
I already noticed that the GPU of the Core i5 2500 has the exact same id. So does this mean the kernel thinks the G620T is a "Intel HD Graphics 2000" GPU while it actually is a "Intel HD Graphics" GPU?!

So is this a kernel bug? A BIOS bug? Is there a workaround?
Comment 10 haihao 2011-10-18 20:08:52 UTC
Is there any issue when running a 3D application on this machine? BTW could you attach the detail output of 'lspci -nnvv'?
Comment 11 mus.svz 2011-10-19 03:14:23 UTC
Created attachment 52523 [details]
output of "lspci -vvnn"
Comment 12 mus.svz 2011-10-19 03:16:18 UTC
All I can tell you is that XBMC and Mupen64plus (n64 emulator) are both working fine without any graphic glitches.
Comment 13 mus.svz 2011-10-19 03:20:23 UTC
Created attachment 52524 [details]
output of "sudo lspci -vvnn"

Just realized that lspci shows more info as root.
Comment 14 haihao 2011-10-19 17:51:38 UTC
Could you test mplayer with the following options?
  1. -vo vaapi   (without -va vaapi)
  2. -vo xv
  3. -vo x11
Comment 15 mus.svz 2011-10-20 06:06:06 UTC
I saw something very interesting. When I was testing the -vo x11 option in XFCE and I switched back from mplayer to a terminal window, I saw some of the "VAAPI screen corruption" within the terminal window(!), while there was none in the video. It was still there when I quit mplayer and it even scrolled together with the content in the terminal window. It disappeared when I tried to take a screenshot of it.

This doesn't really make sense to me. To me this looks like a GPU defect, but XBMC and mupen64plus are working fine. I'm really confused... 
I'm gonna try to get my hand on another Sandy Bridge CPU, maybe this really is a hardware problem!? Or could this also be caused by the chip id problem?!

Although this doesn't seem to be VAAPI specific problem after all, here are my testing results:

-vo vaapi -va vaapi - Screen corruption begins after a few minutes
-vo vaapi - Screen corruption begins after a few minutes 
-vo xv - tearing, random video/audio hangs, but no screen corruption after 20 minutes of watching
-vo x11 - the same as xv, but less hangs

btw, the stuttering with -vo vaapi -va vaapi I mentioned earlier was happening because I started mplayer directly from my login manager because I was too lazy to install a desktop environment (I use this machine for XBMC only and XBMC has a standalone mode to run without a desktop environment).
I installed XFCE and there is no stuttering if I run mplayer -vo vaapi -va vaapi from a XFCE session.
Comment 16 haihao 2011-10-24 01:07:58 UTC
It sounds this is a rendering issue instead of decoding issue.
Comment 17 Hai 2011-10-24 01:08:52 UTC
I am OOP on vacation today. E-mail response might be late.

Hai Lan
Comment 18 mus.svz 2011-10-26 12:51:12 UTC
As if the confusion wasn't big enough already, I can now suddenly not reproduce the problem anymore. I just watched a whole movie with VAAPI without any problems and tested several other videos that showed screen corruption within minutes before.

I made a system upgrade a few days ago, part of the update was the linux kernel (3.0.6 -> 3.0.7), so I thought this was responsible. Out of curiousity, I downgraded back to 3.0.6 - still couldn't reproduce it. All other updated package imho wouldn't fix such an issue, so I've actually no idea what's going on. But feel free to correct me, these packages were updated:


I'm starting to think the system just wants to mess with me or something, maybe the problem is going to return tomorrow, who knows...
Comment 19 Eugeni Dodonov 2011-10-26 18:50:27 UTC
(In reply to comment #18)
> mplayer-vaapi

This one certainly looks like as a possible suspect. But perhaps it is one of those random issues which go away by themselves :/..
Comment 20 mus.svz 2011-10-27 12:50:28 UTC
nevermind, it's back again...

I'm gonna replace the CPU/GPU and see if it helps...
Comment 21 mus.svz 2011-10-29 10:52:34 UTC
Replaced the CPU with a G630T - didn't fix it
Replaced the mainboard with a ASUS P8H61-I - didn't fix it
Replaced the memory - didn't fix it

So I guess this rules out a hardware problem...
Comment 22 mus.svz 2011-11-01 10:50:32 UTC
Now I noticed some problems in the XBMC GUI as well. Not sure if this happened for the first time or if I just didn't notice it before. If you look closely in the attached picture, you can see that the bars in the images are not "corrupted" but actually transparent.

btw, since this is not a VAAPI problem after all, shouldn't this bug be assigned to someone else? Just asking...
Comment 23 mus.svz 2011-11-01 10:52:29 UTC
Created attachment 53009 [details]
XBMC GUI "Corruption"
Comment 24 haihao 2011-11-01 18:32:52 UTC
I will close this bug as notourbug.  Please file a new bug to track the new issue you found and assign it the owner of 2D/3D driver.  If you still experience screen corruption issue with vaapi after fix the new bug, please feel free to reopen this bug.
Comment 25 mus.svz 2011-11-02 05:03:58 UTC
created new bug #42506
Comment 26 mus.svz 2012-01-25 04:11:27 UTC
It seems like this has all been fixed in kernel 3.3-rc1, running for 3 days without any problems. :)
However, vainfo still shows the wrong information. I personally don't really have a problem with this, but if one of the developers would like to find out why this is happening, I'd be happy to provide more information.
Comment 27 haihao 2012-02-01 22:06:17 UTC
(In reply to comment #26)
> It seems like this has all been fixed in kernel 3.3-rc1, running for 3 days
> without any problems. :)
> However, vainfo still shows the wrong information. 

What is the wrong information?
Comment 28 mus.svz 2012-02-02 03:28:02 UTC
(In reply to comment #27)
> (In reply to comment #26)
> > It seems like this has all been fixed in kernel 3.3-rc1, running for 3 days
> > without any problems. :)
> > However, vainfo still shows the wrong information. 
> What is the wrong information?

See comment #4 by Hai, vainfo shows the GPU supports VC1 decoding/H264 encoding although it actually doesn't.
The vainfo output is still the same as in my original bug description.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.