Created attachment 73890 [details] dmesg.log after X has come up using drm.debug=0x7 The screen is blank before and after X is started when using KMS. The display comes up by disabling KMS with the "nomodeset" option. System environment: Intel 845G 3.3.4-5.fc17.i686 I installed intel-gpu-tools-2.20.16-1.fc17.i686 but was unable to run intel_reg_dumper. # intel_reg_dumper Gen2/3 Ranges are not supported. Please use unsafe access.Aborted (core dumped)
Created attachment 73891 [details] Xorg.0.log
Created attachment 73892 [details] xrandr.verbose xrandr --verbose
What's the actual display hardware you are using? It detects both an LVDS and VGA connection. As the 845g can only show on one pipe, it can only show on either LVDS or VGA (if we ignore the rather unhelpful and fragile clone mode). Currently it is using the LVDS, which I guess is a phantom output. Perhaps xrandr --output LVDS1 --off --output VGA1 --preferred To make that permanent you can add video=LVDS-1:d to you kernel parameters.
Btw, neither of those versions of the kernel or ddx are stable on 845g. You need either a brand spanking new 3.8 or to enable SNA.
Btw, latst intel-gpu-tools git from http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ should work for your platform ...
There are two displays, one is a integrated display LVDS-1 and the other is external, VGA-1. Clone mode would be ideal if we can get that to work. I didn't have any luck with disabling LVDS1 using xrandr # xrandr --output LVDS1 --off --output VGA1 --preferred xrandr: cannot find crtc for output VGA1 # xrandr --output LVDS1 --preferred --output VGA1 --off Had no effect I was able to get Fedora to come up on external display VGA-1 by disabling LVDS-1 in the kernel command line. The integrated display acted strange though with pixels being illuminated to look like a white fog on the screen. video=LVDS-1:d Disabling VGA-1 in the kernel command line had no effect.
Enabling SNA in the xorg.conf file resulted in a GPU hang. I'll compile and install the 3.8-rc5 kernel to see if that helps.
Let's see the hang (i915_error_state), 2.20.16 is meant to be stable.
Created attachment 73937 [details] i915_error_state after GPU hang with SNA enabled
(In reply to comment #9) > Created attachment 73937 [details] > i915_error_state after GPU hang with SNA enabled Ok, that's one of Daniel's KMS hangs, not due to SNA itself. :-p
Thanks for the help! Looks like the problem is fixed in the v3.8-rc5! I'll work on doing a bisect of the code to narrow down the patch that fixes this problem. :)
Looks like the reason it is working on 3.8-rc5 is because the drm indicated that there was no driver support for vblank timestamp query. So it doesn't appear to be using KMS in 3.8-rc5. 3.8-rc5 [ 1.234348] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 1.241052] [drm] No driver support for vblank timestamp query. [ 1.247000] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 3.3.4-5.fc17 [ 3.301722] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 3.308365] [drm] Driver supports precise vblank timestamp query. [ 3.354705] [drm:init_vbt_defaults], Set default to SSC at 66MHz [ 3.354752] [drm:parse_general_features], BDB_GENERAL_FEATURES int_tv_support 1 int_crt_support 0 lvds_use_ssc 0 lvds_ssc_freq 48 display_clock_mode 0 [ 3.354762] [drm:parse_general_definitions], crt_ddc_bus_pin: 2 [ 3.354769] [drm:parse_sdvo_device_mapping], different child size is found. I nvalid. [ 3.354774] [drm:parse_device_mapping], different child size is found. Invali d. [ 3.354805] [drm:quirk_pipea_force], applying pipe a force quirk [ 3.354814] [drm:intel_modeset_init], 1 display pipe available. [ 3.354828] [drm:intel_modeset_init], plane 0 init failed: -19 [ 3.354846] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+me m,decodes=io+mem:owns=io+mem [ 3.364761] [drm:drm_sysfs_connector_add], adding "VGA-1" to sysfs
Precise vblank query support is optional, so kms seems to be still loading I think. If you're in doubt, please add the complete debug dmesg.
Created attachment 73998 [details] dmesg-3.8-rc5
Your driver loads fine, though with kernel modesetting disabled. Do you have a lingering setting somewhere for that?
doh! Thanks! My .config was missing CONFIG_DRM_I915_KMS CONFIG_DRM_I915=y # CONFIG_DRM_I915_KMS is not set I'll give 3.8-rc5 another try.
Please disregard comment 11 and comment 12. With KMS enabled on 3.8-rc5 in the kernel config, I got similar results to comment 6 when LVDS-1 was disabled on the kernel command line. It came up on external display VGA-1 and the integrated display acted strange with pixels being illuminated with a white fog coming and going on the screen.
Created attachment 74008 [details] dmesg-3.8-rc5_before_X This is the dmesg output after the system is up and running and before X is started.
Ok, it sounds like we have a bit a sync issue on your LVDS output still. Can you please test http://cgit.freedesktop.org/~danvet/drm/commit/?h=pll-limits-mess&id=c2965c7fae71ac7a06dc6fe1b4c2e9b93dc28ed0
I don't have the failing system anymore but I'll see if I can have someone test the change. Thanks!
The change in Comment 19 did not fix the problem.
Sounds like we are not disabling the LVDS and its backlight entirely when switching the pipe over to VGA. Can you please grab intel_reg_dumper with LVDS on and LVDS off (but with the spooky glow effect).
Sorry Chris, I don't have access to the system anymore. I'll see if someone can get the information you need. Thanks, Trey
Created attachment 86486 [details] dmesg output from kernel v3.11 Sorry for the delay, I'll be picking up from here. I've recreated with drm.debug=14 on kernel 3.11. On boot, the screen alternates between a few minutes of blackness and an animated plasma/lava lamp effect. Something new in the dmesg output that may be helpful: [ 1.737127] WARNING: CPU: 0 PID: 66 at drivers/gpu/drm/i915/intel_display.c:1074 assert_pipe+0x82/0xe0 [i915]() [ 1.737129] pipe A assertion failure (expected on, current off) Please let me know what else I could do to help.
Created attachment 86487 [details] output from intel_reg_dumper on kernel v3.11 I ran it while the screen was doing the spooky glow/fade to black dance.
We've just fixed a bug in the drm-intel-fixes branch which applies for this situation. Can you please retest with that? git tree is at http://cgit.freedesktop.org/~danvet/drm-intel/
Created attachment 86578 [details] dmesg output from kernel e4c64bc No problem. I recreated using the drm-intel-fixes branch. git says I'm at v3.12-rc2-4-ge4c64bc. The assertion failure is gone, but the bug behavior is still there. The screen goes to black and periodically does the spooky glow/plasma/lava lamp thing.
Created attachment 92468 [details] dmesg output from kernel 3.13 Still having this problem. Can't tell from the dmesg exactly where things go bad. Is there anything else I can try or do to help?
Eeek 845. Daniel got his info. Reassigning to him.
Is this still happening on latest drm-intel-nightly?
Created attachment 106862 [details] dmesg output from kernel 0f7cc12 Yes, it does. I just verified using drm-intel-next-2014-09-19-379-g0f7cc12. Same behavior.
Trying to contact Devs in order to see if there is any solution or if we need to close it since it was a long time without answer.
(In reply to Elio from comment #32) > Trying to contact Devs in order to see if there is any solution or if we > need to close it since it was a long time without answer. Timeout, closing. Please reopen if the problem persists with latest kernels.
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.