Bug 28812

Created attachment 47182 [details]
kernel log from a linux 2.6.38-rc4 boot

I have attached the boot log of a linux 2.6.38-rc4 kernel.

Created attachment 47192 [details]
Hardware configuration

I have attached the output of "lspci -vvv" on my system.

Created attachment 50102 [details]
kernel log from booting linux 2.6.38-rc7

Update: When booting linux 2.6.38-rc7 the monitor is no longer turned off. But the framebuffer text consoles and the X server do not come up in the right resolution. It seems they come up in 1024x768 instead of 1680x1050. The xdm login box is partly off screen. And the framebuffer text consoles are filled with endless messages about the EDID checksum error.

The release kernel linux-2.6.38 behaves no different than the version 2.6.38-rc7. See previous comment.

Can you tell us which commit between 2.6.36-rc4 and 2.6.37 broke the EDID retrieval? I can guess it is SDVO port related... drm.debug=0xe would help, but not as much as that and the bisection.

I have bisected the kernel between v2.6.36 and v2.6.37. The result is:

44834a67c0082e2cf74b16be91e49108b1432d65 is the first bad commit
commit 44834a67c0082e2cf74b16be91e49108b1432d65
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Aug 19 16:09:23 2010 +0100

    drm/i915: Use the VBT from OpRegion when available (v3)
    
    It is recommended that we use the Video BIOS tables that were copied
    into the OpRegion during POST when initialising the driver. This saves
    us from having to furtle around inside the ROM ourselves and possibly
    allows the vBIOS to adjust the tables prior to initialisation.
    
    On some systems, such as the Samsung N210, there is no accessible VBIOS
    and the only means of finding the VBT is through the OpRegion.
    
    v2: Rearrange the code so that ASLE is enabled along with ACPI
    v3: Enable OpRegion parsing even without ACPI
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Matthew Garrett <mjg@redhat.com>

:040000 040000 9e9d888e698bcee28fbbf040f0b0a68450fe2d57 669037950f60b494886259b930dedcd92c318f03 M      drivers

Created attachment 52082 [details]
linux kernel from first bad revision

I have attached the kernel log from booting the kernel with the first bad revision from bisecting between v2.6.36 and v2.6.37 with extended debug output.

First-Bad-Commit: 44834a67c0082e2cf74b16be91e49108b1432d65

That would only make sense if the VBT differed between the ROM and the copy in OpRegion memory, for example if you had a machine which had no ROM. A debug dmesg for 44834a67^ would confirm that.

If there is a ROM, then we need to dump both to see what differed and suggest a course of action. intel_bios_read (part of intel-gpu-tools) and /sys/kernel/debug/dri/0/i915_opregion. Otherwise, it is just our use of some information from the VBT that conflicts with reality. More information on that front is found in later kernels debug dmesg.

To verify the bisection, you can simply do:

diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c
index fb5b4d4..fac32cf 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -612,7 +612,7 @@ intel_parse_bios(struct drm_device *dev)
        init_vbt_defaults(dev_priv);
 
        /* XXX Should this validation be moved to intel_opregion.c? */
-       if (dev_priv->opregion.vbt) {
+       if (0 && dev_priv->opregion.vbt) {
                struct vbt_header *vbt = dev_priv->opregion.vbt;
                if (memcmp(vbt->signature, "$VBT", 4) == 0) {
                        DRM_DEBUG_DRIVER("Using VBT from OpRegion: %20s\n",

I have patched a linux 2.6.38.1 kernel with the patch from comment #9 and have successfully booted it. The monitor is not turned off and the resulting screen resolution is fine, too.

Created attachment 52142 [details]
dmesg from a patched linux 2.6.38.1 kernel

I have attached the dmesg output from the patched linux 2.6.38.1 kernel from the previous comment.

Thanks, we get an interesting message:

[drm:parse_sdvo_device_mapping], the SDVO device with slave addr 70 is found on SDVOB port
[drm:parse_sdvo_device_mapping], SDVO device: dvo=1, addr=70, wiring=1, ddc_pin=29, i2c_pin=5, i2c_speed=67
[drm:parse_sdvo_device_mapping], the SDVO device with slave addr 70 is found on SDVOB port
[drm:parse_sdvo_device_mapping], Maybe one SDVO port is shared by two SDVO device.

Can you please also attach the debug dmesg for the unpatched 2.6.38?

Created attachment 52152 [details]
dmesg from unpatched linux 2.6.38.1 kernel

I have attached the dmesg output from an unpatched linux 2.6.38.1 kernel.

And so to compare the unpatched kernel:

[drm:intel_parse_bios], Using VBT from OpRegion: $VBT BEARLAKE-B     d
[drm:parse_general_definitions], crt_ddc_bus_pin: 2
[drm:parse_sdvo_device_mapping], No SDVO device info is found in VBT
[drm:parse_device_mapping], no child dev is parsed from VBT

Yay for out-of-spec BIOSes.

Can you please attach /sys/kernel/debug/dri/0/i915_opregion?

I do not have a file named "/sys/kernel/debug/dri/0/i915_opregion". How can I create it?

Do you have debugfs mounted at /sys/kernel/debug ? (mount -t debugfs debugfs /sys/kernel/debug will do the trick, if you have it activated in your kernel .config)

Created attachment 52662 [details]
i915_opregion file from patched 2.6.38.1 kernel

I have attached the file i915_opregion from debug fs running on a patched linux 2.6.38.1 kernel.

Linux 3.0.1 is still affected by this regression.

I am using kernel 3.1.6, opensource radeon driver(gallium) on a Radeon Turks [Radeon HD 6670].

I had a very strange issue, that can be connected with this drm issue, i leave the story:

1) both drm and Xorg was giving bad EDID checksum.
After a deep investigation, using also other tools like get-edid, i found 1 byte of the fixed EDID header damaged, from 0xFF to 0x80. Setting it to 0xFF was giving the correct checksum. So i opened the monitor, de-soldered the i2c eeprom. and once dumped the wrong byte was really there. I reprogrammed that byte only and solved, no more EDID checksum error.
But my question is, since the monitor have about 3 years, who can be responsible to have damaged this byte ? Radeon driver ? Some kernel module could also be able to write a wrong byte in the monitor i2c eeprom ?
2) after many days, drm(kernel) started again to give some checksum error. It shows a wrong byte in the EDID block (since i have the original dump). This message disappear if i power off for some seconds and back on the monitor.

My mb seems not having i915:
lspci shows:
PCI bridge: Intel Corporation 82801I (ICH9 Family)

Is it possible that on newer kernel this EDID bad-checksum issue has been fixed ?

many thanks
regards

Linux version 3.1, 3.2 and 3.3 are affected, too.

Ok, sounds like we just need to quirk away the opregion vbt for this machine. Can you please attach the output of dmidecode so I can prep the corresponding patch?

Created attachment 72699 [details]
Output of dmidecode

I have attached the output of dmidecode.

Created attachment 72700 [details]
dmi quirk-away broken vbt

Please test this patch and if it works, supply your tested-by.

I have successfully tested the patch from comment #23 against a vanilla 3.3 kernel. The screen resolution in the console and under X11 is as expected. 

I have found this log message:

[drm:intel_no_opregion_vbt_callback], Falling back to manually reading VBT fromVBIOS ROM for ThinkCentre A57

Thanks a lot. Will this patch be included in the next kernel release (3.3.1)?

I've submitted it for inclusion into 3.4-rc, as soon as it lands there, it will get applied to older kernels by the stable team.

A patch referencing this bug report has been merged in Linux v3.4-rc2:

commit 25e341cfc33d94435472983825163e97fe370a6c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Mar 24 23:51:30 2012 +0100

    drm/i915: quirk away broken OpRegion VBT