| Summary: | [ILK] system stalls with vaapi rendering | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Tobias Jakobi <liquid.acid> | ||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | ||||||||
| Version: | DRI git | ||||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
|
Description
Tobias Jakobi
2013-02-17 17:33:50 UTC
Please attach dmesg and Xorg.log, thanks. Created attachment 75378 [details]
Xorg log
I had to downgrade xf86-video-intel to 2.20.19, since git is unstable for me and X randomly crashing is not nice at all.
Created attachment 75379 [details]
dmesg after boot
@Daniel: Logs added! (In reply to comment #2) > I had to downgrade xf86-video-intel to 2.20.19, since git is unstable for me > and X randomly crashing is not nice at all. WHAT? Please do report critical bugs... I'm not even sure when the crash was introduced. Currently it looks like that 2.21.0 is already not working for me. However I don't have time to triage this (and the 3.7 kernel also introduces ACPI bugs for me). Forgot to mention: I had iommu disabled since some other report mentioned stalls on 3.2 with ILK (but accompanied by output from the kernel). It turned out that this doesn't seem the issue here -- read: iommu enabled or not, it doesn't change the stalls. (In reply to comment #6) > I'm not even sure when the crash was introduced. Currently it looks like > that 2.21.0 is already not working for me. However I don't have time to > triage this (and the 3.7 kernel also introduces ACPI bugs for me). Just the Xorg.0.log with the crash would be sufficient (ok, I may prefer a symbolic stacktrace) but any information about a crash is better than none. Even just a heads up is useful. Please retest without 'i915.i915_enable_rc6=1 i915.lvds_downclock=1'. If you do have a downclocking mode available, then you need a bug fix to prevent one frequent stall. liquid@leena ~ $ cat /proc/cmdline BOOT_IMAGE=/kernel-3.7.10-vanilla root=/dev/sda4 ro rootfstype=ext4 usbhid.mousepoll=4 i915.i915_enable_rc6=0 i915.lvds_downclock=0 video.brightness_switch_enabled=0 No change at all. I checked for the issue with the kernel versions inbetween: 3.5.7: GOOD 3.6.11: BAD So looks like it was introduced from 3.5 to 3.6 Can you please attempt to bisect down to a commit with git? My favourite howto is http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ Pretty please? Sorry for the late reply, I tried to bisect this twice in the last weeks but due to the nature of bug without any success. I didn't try again because it was already very time consuming (not the compiling, but the verification if the stalling is actually there). With the numerous bugs (ACPI, etc.) that seem to creep into recent kernel versions, and the fact that Arrandale/Ironlake doesn't really profit from them anyway, I decided to stay on the 3.4.x branch until this system goes out of service. Since 3.4 will get fixes until mid (?) of 2014, this seems like a good solution for me. Feel free to set this bug to abandoned. Please do reopen if you are able to characterise the lag or find the specific commit introducing the stall. |
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.