Bug 35781 - [bisected] EDID lost when reprobing VGA
Summary: [bisected] EDID lost when reprobing VGA
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-29 19:31 UTC by meng
Modified: 2017-09-04 10:05 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
The bad_xarndr_verbose with the commit f0c860246 (4.03 KB, text/plain)
2011-03-29 19:32 UTC, meng
no flags Details
The good_xarndr_verbose (6.59 KB, text/plain)
2011-03-29 19:35 UTC, meng
no flags Details
The dmesg when add "drm.debug=0xe" in grub with commit f0c86 (66.61 KB, text/plain)
2011-03-30 00:17 UTC, meng
no flags Details
Reset GMBUS after NAK (2.38 KB, patch)
2011-03-30 09:06 UTC, Chris Wilson
no flags Details | Splinter Review

Description meng 2011-03-29 19:31:03 UTC
System Environment:
--------------------------
Platform:        Piketon
Libdrm:		(master)2.4.24-7-gfd3ed34a2070fca3804baf54ece40d0bc2666226
Mesa:		(master)5d7c27f5ec2f30c264dc2d53c4980970b3a13ee5
Xserver:		
(master)xorg-server-1.10.0-142-ga095a6d4e8f5090907e8d3d66018636216300846
Xf86_video_intel:		
(master)2.14.901-22-g79e7f4ca3b5f035af6f473b5a53c3fe7d1361089
Cairo:		(master)90156f6ab7b94e9e576e34f6a2d8cb809242f8d0
Libva:		(master)a259f9ef76d5719d19e273b17478ffedeff01ddc
Kernel:(drm-intel-next) f0c860246472248a534656d6cdbed5a36d1feb2e

Bug detailed description:
--------------------------------------
The numbers of VGA resolution mode isn't enough when xrandr on Piketon.The numbers of resolution mode is 9 normally, but it's only 4 with bad commit f0c8602. Please see attachments about [good|bad]xrandr--verbose.
Especially,
1.It exist on Piketon.It works fine on Surgarbay.
2.It's kernel regression.Bisect shows 8f9a3f9b63b8cd3f03be9dc53533f90bd4120e5f is the first bad commit.

commit 8f9a3f9b63b8cd3f03be9dc53533f90bd4120e5f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Feb 1 09:01:13 2011 +0000

    drm/i915: Enable GMBUS for post-gen2 chipsets

    With the recent SDVO fix, this is working on all the machines I have to
    hand - except for an 845G.

    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Reproduce steps:
--------------------------------------
1. xinit&
2. xrandr
Comment 1 meng 2011-03-29 19:32:52 UTC
Created attachment 45017 [details]
The bad_xarndr_verbose with the commit f0c860246
Comment 2 meng 2011-03-29 19:35:03 UTC
Created attachment 45018 [details]
The good_xarndr_verbose  

The good_xarndr_verbose with the cmmit f0c860246 which gits revert commit 8f9a3f
Comment 3 Chris Wilson 2011-03-29 23:29:35 UTC
You need to attach the full drm.debug=0xe dmesg. Despite the VGA connection appearing to have a EDID, it has not added the modelines.
Comment 4 meng 2011-03-30 00:17:02 UTC
Created attachment 45021 [details]
The dmesg when add "drm.debug=0xe" in grub with commit f0c86
Comment 5 Chris Wilson 2011-03-30 00:47:19 UTC
Ok, upon the second probe we lost the modes from the EDID:

[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1]
[drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0x83f40018, result 1
[drm:intel_crt_detect], CRT detected via hotplug
[drm:drm_mode_debug_printmodeline], Modeline 27:"1680x1050" 60 146250 1680 1784 1960 2240 1050 1053 1059 1089 0x48 0x5
[drm:drm_mode_prune_invalid], Not using 1680x1050 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 38:"1280x1024" 75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
[drm:drm_mode_prune_invalid], Not using 1280x1024 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 28:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5
[drm:drm_mode_prune_invalid], Not using 1280x1024 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 29:"1280x960" 60 108000 1280 1376 1488 1800 960 961 964 1000 0x40 0x5
[drm:drm_mode_prune_invalid], Not using 1280x960 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 45:"1152x864" 75 108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5
[drm:drm_mode_prune_invalid], Not using 1152x864 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 39:"1024x768" 75 78800 1024 1040 1136 1312 768 769 772 800 0x40 0x5
[drm:drm_mode_prune_invalid], Not using 1024x768 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 40:"1024x768" 70 75000 1024 1048 1184 1328 768 771 777 806 0x40 0xa
[drm:drm_mode_prune_invalid], Not using 1024x768 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 42:"832x624" 75 57284 832 864 928 1152 624 625 628 667 0x40 0xa
[drm:drm_mode_prune_invalid], Not using 832x624 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 44:"800x600" 72 50000 800 856 976 1040 600 637 643 666 0x40 0x5
[drm:drm_mode_prune_invalid], Not using 800x600 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 43:"800x600" 75 49500 800 816 896 1056 600 601 604 625 0x40 0x5
[drm:drm_mode_prune_invalid], Not using 800x600 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 34:"640x480" 73 31500 640 664 704 832 480 489 491 520 0x40 0xa
[drm:drm_mode_prune_invalid], Not using 640x480 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 33:"640x480" 75 31500 640 656 720 840 480 481 484 500 0x40 0xa
[drm:drm_mode_prune_invalid], Not using 640x480 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 35:"640x480" 67 30240 640 704 768 864 480 483 486 525 0x40 0xa
[drm:drm_mode_prune_invalid], Not using 640x480 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 36:"640x480" 60 25200 640 656 752 800 480 490 492 525 0x40 0xa
[drm:drm_mode_prune_invalid], Not using 640x480 mode -3
[drm:drm_mode_debug_printmodeline], Modeline 37:"720x400" 70 28320 720 738 846 900 400 412 414 449 0x40 0x6
[drm:drm_mode_prune_invalid], Not using 720x400 mode -3
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1] probed modes :
[drm:drm_mode_debug_printmodeline], Modeline 41:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 31:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 32:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 50:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 47:"640x480" 60 25175 640 656 752 800 480 489 492 525 0x40 0xa
Comment 6 Chris Wilson 2011-03-30 08:20:33 UTC
Reproduced on my HuronRiver box.
Comment 7 Chris Wilson 2011-03-30 09:06:34 UTC
Created attachment 45052 [details] [review]
Reset GMBUS after NAK
Comment 8 meng 2011-03-30 18:51:21 UTC
(In reply to comment #7)
> Created an attachment (id=45052) [details]
> Reset GMBUS after NAK

It works fine,when testing in the commit f0c8602 with the patch(45052).
Comment 9 Chris Wilson 2011-03-31 00:09:59 UTC
Applied to -fixes:

commit 0ee1418d4b66d5f644a7b752329d37ccb0e20c23
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Mar 30 16:20:43 2011 +0100

    drm/i915: Reset GMBUS controller after NAK
    
    Once a NAK has been asserted by the slave, we need to reset the GMBUS
    controller in order to continue. This is done by asserting the Software
    Clear Interrupt bit and then clearing it again to restore operations.
    
    If we don't clear the NAK, then all future GMBUS xfers will fail,
    including DDC probes and EDID retrieval.
    
    v2: Add some comments as suggested by Keith Packard.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35781
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Keith Packard <keithp@keithp.com>
    Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Tested-by: mengmeng.meng@intel.com
Comment 10 Chris Wilson 2011-03-31 00:43:10 UTC
Meng, what credit line should I use for you in the changelogs? (Similar question to all the QA team.)

If I can encourage you to add your Tested-bys once your happy with the patch, that would be perfect. (Cut'n'paste ftw!)

e.g.

  It works fine,when testing in the commit f0c8602 with the patch(45052).

  Tested-by: "Mengmeng Meng" <meng.mengmeng@intel.com>

I would not like to dishonour anybody by getting their name wrong.
Comment 11 meng 2011-03-31 01:34:26 UTC
(In reply to comment #10)
Thanks for that.I think the credit line that "Mengmeng Meng" is good.
Comment 12 meng 2011-03-31 01:35:38 UTC
Verified with the commit 0ee1418d4b66d5f644a7b752329d37ccb0e20c23,it works fine.
Comment 13 Jari Tahvanainen 2017-09-04 10:05:57 UTC
Closing old verified+fixed.


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.