Created attachment 37821 [details] dmesg (including 0xc for drm.ko debug parameter) System is Acer TM660 laptop with i855 chipset: 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:02.1 Display controller [0380]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) Software (Gentoo distribution): linux-2.6.35 (with a few patches, all unrelated to GPU except for Daniel Vetter's cache-coherancy patch) x11-drivers/xf86-video-intel-2.12.0 x11-libs/libdrm-2.4.21 x11-base/xorg-server-1.7.7-r1 media-libs/mesa-7.8.2 Debugging on IRC with ickle produced following insight: latencytop hit: drm_mode_cursor_ioctl drm_icoctl vfs_ioctl do_vfs_i (rest clipped) perf top: intel_crt_load_detect gets high-score quoting ickle: hotplug storm! that explains what's holding the mode lock what's happening is that every 10s the non-hotplug capable outputs are polled, and for VGA this involves reading back the border colour [which is quite laborious]
Created attachment 37822 [details] [review] Workaround, disable polling
Created attachment 37823 [details] [review] Workaround, disable polling
I suspect this is related to https://bugzilla.kernel.org/show_bug.cgi?id=16265
*** Bug 29433 has been marked as a duplicate of this bug. ***
Created attachment 38582 [details] [review] Second, automatic workaround. Sweep the issue under the carpet by simpler not polling if it requires load-detection.
I see that the patch is in 2.6.36. However, for me on 965g, it only fixes the bug if the kernel is compiled as fully preemptible. If the kernel is compiled with voluntary preemption, there is still a 30-100 ms latency introduced every 10 seconds. drm_mms_helper.poll=0 does help. shining on #intel-gfx asked me to play with latencytrace. Unfortunately, this isn't useful: irqsoff and sched_switch yield no smoking guns, and preemptoff is only available with the fully preemptible kernel.
If I thought I had resolved the bug, I would have closed the report. This is still open because we hold the mode mutex around the output polling and cursor manipulation, causing the stalls. The two workarounds (a) optionally disable the output polling and (b) remove the worst offender. The locking design remains less than optimal.
Hi Chris, does your "automatic workaround" patch address this issue for ATI cards, or only Intel?
after switching from the proprietary nvidia driver to nouveau, i experience the same issue. latencytop reports latencies of 100 to 200 ms in drm_mode_cursor_ioctl.
I started using a radeon card on my desktop a few days ago and started experiencing this problem again but I wasn't able to get any of the workarounds to work this time. I tried to deactivate polling with the drm_kms_helper.poll=0 trick but it didn't work. I even went as far as removing all calls to queue_delayed_work() from drivers/gpu/drm/drm_crtc_helper.c but it didn't work. After digging a while I noticed that a daemon called upowerd reads from /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-VGA-1/status every 30sec and that cause the stall. upowerd is a dependency on kde but I can't find any setting in kde to disable this polling. Killing the upowerd process works but I assume that has some negative consequence.
*** Bug 47059 has been marked as a duplicate of this bug. ***
The patch for 2.6.36 does not seem to be in 3.1 anymore.
I tested 3.2.1. While xrandr is much faster (and I get less blocks during starting of wine applications which request that a lot) I now get intermittent blocks of X every 10-30 seconds. The blocks last several seconds and make working completely impossible. I switched back to a 3.1 kernel and the problem is gone, with xrandr being slow again. xf86-video-intel-2.17.0 libdrm-2.4.27 mesa-7.11.2 not blocking: linux 3.1.10 blocking: linux 3.2.1
Could you test the 3.4-rc1 kernel please? it included a patch which speeds-up the EDID retrievals, so it could help here I think..
timeout, but I think this is either fixed or will be shortly by Daniel's hotplug handling fixes.
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.