| Summary: | [ilk] missed irq | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | pierre_aussaguel | ||||||
| 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: | major | ||||||||
| Priority: | medium | CC: | pierre_aussaguel | ||||||
| Version: | unspecified | ||||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
|
Description
pierre_aussaguel
2013-01-24 09:32:06 UTC
Can you please attach the dmesg when this happens? Also, on recent kernels (3.7 should be good enough) we should dump a gpu error state into i915_error_state in debugfs when this happens. Please attach the contents of that file. Last one: Which is the exact 2.6 kernel you've been using? Created attachment 73588 [details]
dmesg
I attached the dmesg outbut while the system suffered the bug. Both debugfs i915_error_state files contains "no error state collected" (there is one in dri/0/ and another in dri/64/ The kernel that works is the stable kernel supplied with debian squeeze : 2.6.32-5-amd64 Would it be usefull that I provide the same files, but using 3.2.0-4-amd64 where at least dmesg show some error messages ? Hm, I don't see any missed IRQ line in your dmesg. If you still have the 2.6.32 kernel around, booting with drm.debug=0xe and attaching the dmesg would be interesting. Afaict ilk gem/kms support was merged for kernel 2.6.31. Created attachment 73596 [details]
dmesg_kernel_3.2
Dmesg of kernel 3.2 output, with drm.debug=0xe option
I attached the dmesg output for kernel 3.2 I noticed a curious coincidence : I used the computer about 40 min without problem, and the bug showed up just when a backup script started. I believe this is not the first time this happen, could this be related ? My script for information : #!/bin/sh # Script de sauvegarde automatique if test -e /dev/disk/by-uuid/ea43e9e6-4251-4358-b6cd-3643f5a0ebda; then mount /mnt/sauvegarde nice rsync -a --delete /home /mnt/sauvegarde/ umount /mnt/sauvegarde fi The performance issue on 3.7 is not due to the missed irq, but a combination of using UXA and VT-d. In order to workaround an erratum on Ironlake, every time we touch the GPU's page tables, we have to idle the GPU before doing so. This causes extremely noticeable display lag. Try appending intel_iommu=off to you kernel commandline. Appending intel_iommu=off seems to fix the problem (I tested a few days befor posting). Thank you for giving me the workaround. Shouldn't the Ironlake GPU be detected and this fix automatically applied ? Well we presume that if you enable the iommu, you actually want it for something. In general we only disable stuff automatically if it doesn't have any functional impact (which disabling the iommu has). Hence just workarounds to make it work, not to make it fast ... Since we can't fix the hw, closing this as wontfix. Thanks for reporting this issue anyway. |
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.