Summary: | [ilk Regression] Generalized slowness after upgrade to kernel 3.10 | ||
---|---|---|---|
Product: | xorg | Reporter: | Jonathan Protzenko <jonathan.protzenko+fdo> |
Component: | Driver/intel | Assignee: | Chris Wilson <chris> |
Status: | RESOLVED MOVED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Description
Jonathan Protzenko
2013-12-27 12:16:58 UTC
Your complete Xorg.0.log and glxinfo will contain some essential information. Created attachment 91217 [details]
glxinfo with the working kernel
Created attachment 91218 [details]
glxinfo with a kernal that exhibits the issue
Created attachment 91219 [details]
xorg with a working kernel
Created attachment 91220 [details]
xorg log with a kernel that exhibits the issue
Here's the requested information. I'm afraid both the logs and the glxinfo outputs are similar across kernel versions.
Hope that helps,
~ jonathan
Hmm, Ironlake. Not likely to be directly related to i915.ko. The first thing I would suggest checking is that intel_ips is running (CONFIG_INTEL_IPS). Yes, the module is loaded. Unloading it / reloading it has no effect. Did you enable vtd or iommu? Does intel_iommu=off make any difference? i.e. does this log anything? diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 998f9a0b322a..2adfef0fa6ac 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -1727,6 +1727,9 @@ static int i915_gmch_probe(struct drm_device *dev, dev_priv->gtt.do_idle_maps = needs_idle_maps(dev_priv->dev); dev_priv->gtt.base.clear_range = i915_ggtt_clear_range; + if (unlikely(dev_priv->gtt.do_idle_maps)) + DRM_INFO("applying Ironlake quirks for intel_iommu\n"); + return 0; } Hi, and first of all thanks for the quick feedback and help :-). (In reply to comment #8) > Did you enable vtd or iommu? I, unfortunately, have no idea what this even means. I'm just following Debian's default setup. If you can tell me how to determine this, I'd be happy to provide you with the information. > Does intel_iommu=off make any difference? Yes, booting with 3.11 and intel_iommu=off _does_ fix the problem. Fantastic! > > i.e. does this log anything? > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > b/drivers/gpu/drm/i915/i915_gem_gtt.c > index 998f9a0b322a..2adfef0fa6ac 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -1727,6 +1727,9 @@ static int i915_gmch_probe(struct drm_device *dev, > dev_priv->gtt.do_idle_maps = needs_idle_maps(dev_priv->dev); > dev_priv->gtt.base.clear_range = i915_ggtt_clear_range; > > + if (unlikely(dev_priv->gtt.do_idle_maps)) > + DRM_INFO("applying Ironlake quirks for intel_iommu\n"); > + > return 0; > } Booting 3.11 with intel_iommu=off, I do not see the message above in the output of dmesg. Let me know if I can help you further! Cheers and a happy new year, ~ jonathan It turns out that the bug re-surfaced with intel_iommu=off. The absence of the bug may have been correlated with my using my external screen and not the internal screen of the laptop, I'll investigate more. Hmm. Any news or fresh ideas? Also see if x11perf (perhaps -aa10text, -putimage10, -shmput500, -copywinwin500) detects any discrepancies. I've done some more testing, and I can confirm that the issue: - does NOT occur when booting 3.12 with the external screen attached; - occurs on 3.12 without the external screen attached. I'm running the benchmarks you suggested on 3.12 (faulty kernel) and soon on 3.9 (working kernel) to compare the figures. Created attachment 92985 [details]
Series of x11perf tests with the (working) 3.9 kernel
Created attachment 92986 [details]
Series of x11perf tests with the (faulty) 3.12 kernel
Here's the requested series of tests. 3.9 seems to behave better for aatext and _much_ better for copy window to window.
FWIW, the "slowness" occurs mainly when switching desktops in my window manager. Whenever I do that, the x11perf tests are slowed down almost to a halt, and then after about a second, start running at full speed again.
I feel fairly confident that the x11perf differences are an artifact of IPS. (The image tests were for a reference point to check that CPU/memory performance was the same between kernels. But you can notice that the tests gradually got quicker in 3.12, which is a sign of IPS - if you keep on running -copywinwin500 does it plateau at the 3.9 levels?) I don't think those measurements give me the explanation I was looking for though - I had hoped that the GPU copy performance would mirror the dramatic performance difference in workspace switching between 3.9 and 3.12. There is one other thing to quickly test, add Section "Device" Identifier "Device0" Driver "intel" Option "AccelMethod" "sna" EndSection to your /etc/X11/xorg.conf That also won't explain what changed in the kernel, but I am curious to know how it performs on your upset machine. Any recent updates? Sorry for the delay. I tried using sna, my /var/log/Xorg.0.log now shows: [ 55982.994] (**) intel(0): Option "AccelMethod" "sna" but this does not solve the problem. The slowdown only happens when switching desktops with my window manager (e17), so I guess there's some special x11 call that happens there and that is responsible for the slowdown. If only I could figure out which X11 call... probably one that redraws the entire screen? I can also confirm that today I was using 3.12 with my external screen plugged in, with no issues. When I woke up the computer after unplugging the screen, the problem surfaced immediately. If you've found a more reliable way to reproduce this it might be interesting to attempt a bisect. Otherwise I don't really see a handle for tackling this bug here. It's a long shot, but if you compile SNA with ./configure --enable-debug=full and reproduce the slowdown I might be able to see what causes it in the humongous haystack of a logfile. Oh, in the meantime try SNA with the latest kernel, and redo the x11perf testing before/after slowdown. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/26. |
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.