Created attachment 92153 [details] Kernel 3.11.10 / 3.12.1 / 3.12.7 Logs I use Ubuntu 13.10 x64. I run XBMC Alpha Git 10 using HDMI output. I use Ubuntu kernels from mainline (http://kernel.ubuntu.com/~kernel-ppa/mainline) Kernel 3.8.x / 3.11.10 (and some others kernels) work fine and every frame is rendered properly. Problem: Using kernel 3.12.1 / 3.12.7 (I tested only these two) video playback skips several frames per second. Mainboard: Intel DH61AG BIOS: AGH6110H.86A.0106.2013.0509.1441 CPU: Intel i3-3240 Memory: 4 Gb One SSD is being used I am attaching logs from dmesg for a 3.11.10 and 3.12.1/3.12.7 kernel. Regards, Bjoern
Created attachment 92154 [details] Kernel 3.11.10 Log
Created attachment 92155 [details] Kernel 3.12.1 Log
Created attachment 92156 [details] Kernel 3.12.7 Log
I'm assuming XBMC is using libva to decode video on your platform? Those dmesg captures show absolutely nothing, as you may have guessed. Could you recapture one of those (say a 3.12.7 one) with the addition of drm.debug=6 on the command line so we can have a few more details. Next step is to try to understand what's happening when frames are being skipped, do you have new messages in dmesg? it could be a bug triggering a GPU reset for instance. Trying 3.13.0-rc8 would also be interesting.
Given that it seems to be a regression and that it seems quite easy to figure if a given kernel version works, the ideal would be to bisect between 3.11 and 3.12.1 (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/ has the history/tags for that, it should be possible to bisect between the v3.11 and v3.12.1 tags) http://landley.net/writing/git-bisect-howto.html
Created attachment 92245 [details] Kernel 3.12.7 Log drm.debug=6
I've not done any bisecting till date - so will have to read on it and stuff, will take some time. So for now I've added the request log file, maybe that helps already. Will try 3.13.0-rc8 soon and update here.
We now know XBMC is using GL here and that the ffmpeg used is built with vaapi support. Have you done any other update on the system before noticing that change (libva, mesa ?) Was XBMC skipping frames in that last trace captured (showing an XMBC run)?
> We now know XBMC is using GL here and that the ffmpeg used is built with vaapi support. I am however using software decoding and not vaapi in XBMC. My experience has shown that the hardware decoders too often cause screen corruption, software on the other hand never (unless the material is broken). > Have you done any other update on the system before noticing that change (libva, mesa ?) Nope, just the usual. I have installed this Ubuntu around 3-4 weeks ago. Since then I have basically installed only XBMC and the updates coming from Ubuntu (no clue what they were though). To get Audio working properly with 7.1 I did have to make some changes in one file (something with PulseAudio or so iirc) otherwise Ubuntu would not show me 7.1. > Was XBMC skipping frames in that last trace captured (showing an XMBC run)? I believe so, yes - I did want to give you exactly such a trace. However I'll redo it again later. Additionally, I'll do the bisecting today to nail down the issue.
If you're redoing the trace, can you add buf_log_len=8M to the kernel command line? we're missing the start of it because the buffer was too small.
After doing a bisect, the issue was fixed by David Hermann with commit 498f6d3660e8c3343b26a5f8e2707b642bcf3fc8 ; "simplefb: fix unmapping fb during destruction" in v3.13-rc1 The code in question was introduced with v3.10-rc3 ("drivers/video: implement a simple framebuffer driver"). However, I didn't face the issue in 3.11. On a side note - the bug did not occur with every video material in XBMC. The one in question was H264 1280x720p @ 50 fps (german "Das Erste" DVB-S2 channel). Mpeg2 video did not experience the issue.
That is quite a weird result, this has nothing to do with the i915 driver. So I'm guessing something went wrong in the bisect :) In any case, if you're seeing it fixed in later kernels, let's assume something fixed it and close this bug. Please reopen if needed.
I never said it was solely related to the i915 driver - I just wrote everything I knew into this report so that you guys can maybe better figure out what is going on. I just know that the bug appeared at some point on my Intel HTPC system and I wanted to assist in nailing it down. And the guys from the linux kernel mailing list said I should seek help here. And my bisect is correct Daniel ;) I manually changed the code to how it was before this commit and voila, the issue reoccurs. So David's commit definitely is the one that resolved it. But in any case, yes, this is resolved and fixed.
Ah, very useful detail to know (that reverting the fix brings back the bug to confirm that's the active ingredient). git bisect wins again! Thanks for your investigation work.
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.