Created attachment 72557 [details] xrandr --verbose (before mode switching) Bug description: Since installing openSUSE 12.1, I've problems when switching to another mode (again, see #24748). System environment: -- chipset: G965 -- system architecture: x86_64 -- xf86-video-intel: 2.20.3 -- xserver: 1.12.3 -- mesa: 8.0.4 -- libdrm: 2.4.33 -- kernel: 3.4.11 -- Linux distribution: openSUSE 12.1 -- Machine or mobo model: Intel mainboard with i965G chipset -- Display connector: DVI (via ADD2 card) Reproducing steps: - Power up, boot system and login to KDE desktop (resolution is now 1600x1200@60) - Open konsole xrandr --output DVI1 --mode 0x4b # (1024x768@60) sleep 5 xrandr --output DVI1 --mode 0x43 # (1600x768@60) - I've everything is ok, repeat mode switching Additional info: -- Previous bug report for openSUSE 11.4 (has been solved): https://bugs.freedesktop.org/show_bug.cgi?id=24748 -- Photo: https://bugs.freedesktop.org/attachment.cgi?id=30732 Upgrading to kernel 3.7.1 didn't help.
Created attachment 72558 [details] Output of intel_reg_dump (before mode switching)
Created attachment 72559 [details] vbios.dump (before mode switching)
Created attachment 72560 [details] Output of intel_reg_dumper (after switching to 1024x768)
Created attachment 72561 [details] vbios.dump (after switching to 1024x768)
Created attachment 72562 [details] Output of intel_reg_dumper (after switching back to 1600x1200)
Created attachment 72563 [details] vbios.dump (after switching back to 1600x1200)
Created attachment 72564 [details] Output of dmesg (after switching back to 1600x1200)
Created attachment 72565 [details] Xorg.0.log (after switching back to 1600x1200)
Typo: xrandr --output DVI1 --mode 0x43 # (1600x768@60) Correct: xrandr --output DVI1 --mode 0x43 # (1600x1200@60)
Can you please boot with drm.debug=0xe added to your kernel cmdline and attach the complete dmesg after boot. Then try to reproduce the issue until the modeset has failed, and then again grab a new dmesg (there's tons of debug stuff, so usually after a few modeset cycles the important boot message are lost, hence 2 dmesgs required). Please don't do any other modeset changes in between, so that we can correlate the dmesg noise with the failed modeset.
Created attachment 72645 [details] Output of dmesg (after login, before modesetting)
Created attachment 72646 [details] Output of dmesg (after failure)
ping?
I didn't see anything in the logs which would point towards a modeset failure. So dunno what to do here ...
Can you please retest with latest drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel I've just merged two patches to adjust the pll limits for sdvo/lvds on gen3/4.
Tested three different testcases several times which _all_ didn't work reliable before: - Mode settings from shell script in a loop: over 500 loops --> fine - X11 login as a 2nd user (VT-8) with a different mode (calling xrandr in .xinitrc) --> fine - Connect 2nd monitor to VGA1 --> fine Can this be applied to mainline and stable series? I would like to switch back to openSUSE 12.2 distribution kernel (3.4.x) after this has been applied. Thank you very much. Christian
Wohooo, nice that this works! Patch is on the way to get merged to 3.9, with a cc: stable tag. So should show up in a stable kernel near you eventually. commit 0568d08790bff87652aabed3b0f534fbc0a6f651 Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Date: Wed Feb 13 22:20:22 2013 +0100 drm/i915: Set i9xx sdvo clock limits according to specifications
Unfortunately only one of the two patches ("drm/i915: Set i9xx sdvo clock limits according to specifications") has been applied to linux-stable. The other one ("drm/i915: Set i9xx lvds clock limits according to specifications") doesn't have the "Cc: stable@vger.kernel.org" tag.
Hm, I've thought you only need the sdvo patch to make your machine work. Do you need the lvds one, too?
I downloaded and tested the whole http://cgit.freedesktop.org/~danvet/drm-intel tree which included both patches. Is there any reason not to send both patches to linux-stable? If really required I can test again with the current 3.8.1 kernel which only includes the first patch.
Yeah, testing with 3.8.1 would be appreciated to make sure we've backported the right patches.
Retested with kernel-3.8.2 from openSUSE build service. Everything looks fine.
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.