Kernel BUG with i915 in intel_sdvo_ddc_proxy_func

Hi,

I'm having trouble with an integrated i915 card, KMS and Linux >2.6.36.

The bug has been introduced somewhere between 2.6.36.1 (working) and 2.6.37 (bad) and is still happening on 2.6.38.6.

Kernel output (Images only, sorry):

http://ionic.de/gfx/Screenshots/Kernel/i915-BUG/Part1.jpg
http://ionic.de/gfx/Screenshots/Kernel/i915-BUG/Part2.jpg
http://ionic.de/gfx/Screenshots/Kernel/i915-BUG/Part3.jpg
http://ionic.de/gfx/Screenshots/Kernel/i915-BUG/Part4.jpg

lspci:

00:00.0 Host bridge: Intel Corporation 4 Series Chipset DRAM Controller (rev 03)
Subsystem: Intel Corporation Device 1003
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?> Kernel driver in use: agpgart-intel

00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
Subsystem: Intel Corporation Device 1003
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-

        Latency: 0
        Interrupt: pin A routed to IRQ 50
        Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=4M]
        Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at f220 [size=8]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
                Address: fee0f00c  Data: 41c1
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 

PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

00:02.1 Display controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)
Subsystem: Intel Corporation Device 1003
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Region 0: Memory at e0400000 (64-bit, non-prefetchable) [size=1M]
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

PCI:IDs for those devices:
00:00.0 0600: 8086:2e10 (rev 03)

        Subsystem: 8086:1003

00:02.0 0300: 8086:2e12 (rev 03) (prog-if 00 [VGA controller])

        Subsystem: 8086:1003

00:02.1 0380: 8086:2e13 (rev 03)

        Subsystem: 8086:1003

It only happens when I enable CONFIG_DRM_I915_KMS.

Also, as of 2.6.37, the video= Kernel parameter doesn't have any effect anymore (set to video=1280x1024-24@75). It's working fine on 2.6.36.1.

Do you need anything else? Feel free to request additional information.

I'm looking forward to hearing from you.

Best regards,

Mihai

I forgot to add: this is the integrated GPU on an Intel DQ45CB board.

Also, I'm CCing the Intel DRM maintainer, I hope that's OK?

Best regards,

Mihai

The ddc proxy depends upon the underlying i2c bus being selected. Under certain configurations, the i2c-adapter functionality is queried during initialisation and so may trigger an OOPS during boot. Hence, we need to reorder the initialisation of the ddc proxy until after we hook up the i2c adapter for the SDVO device.

---
 drivers/gpu/drm/i915/intel_sdvo.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

index 4324f33..754086f 100644
@@ -2544,21 +2544,19 @@ bool intel_sdvo_init(struct drm_device *dev, int sdvo_reg)
 	if (!intel_sdvo)
 		return false;
 
+	intel_sdvo->sdvo_reg = sdvo_reg;
+	intel_sdvo->slave_addr = intel_sdvo_get_slave_addr(dev, sdvo_reg) >> 1;
+	intel_sdvo_select_i2c_bus(dev_priv, intel_sdvo, sdvo_reg);
 	if (!intel_sdvo_init_ddc_proxy(intel_sdvo, dev)) {
 		kfree(intel_sdvo);
 		return false;
 	}
 
-	intel_sdvo->sdvo_reg = sdvo_reg;
-
+	/* encoder type will be decided later */
 	intel_encoder = &intel_sdvo->base;
 	intel_encoder->type = INTEL_OUTPUT_SDVO;
-	/* encoder type will be decided later */
 	drm_encoder_init(dev, &intel_encoder->base, &intel_sdvo_enc_funcs, 0);
 
-	intel_sdvo->slave_addr = intel_sdvo_get_slave_addr(dev, sdvo_reg) >> 1;
-	intel_sdvo_select_i2c_bus(dev_priv, intel_sdvo, sdvo_reg);
-
 	/* Read the regs to test if we can talk to the device */
 	for (i = 0; i < 0x40; i++) {
 		u8 byte;

1.7.5.1

Wow, my machine is booting fine again, thanks!

Hope to see it included in 2.6.39. :)

Best regards,

Mihai

I'd love more explanation here about how this code ever worked -- what are these 'certain configurations' of which you speak?

(on the surface, this patch seems sane, but I'd love to review with specific knowledge about what configurations would have worked and which would have triggered this bug).

[email protected]

The condition under which it fails is when the i2c_add_adapter calls into i2c_detect which will attempt to probe all valid addresses on the adapter iff there is a pre-existing i2c_driver with the same class as the freshly added i2c_adapter.

So it appears to depend upon having compiled in (or loaded such a module before i915.ko) an i2c-driver that likes to futz over the i2c_adapters claiming DDC support.
-Chris

Chris Wilson, Intel Open Source Technology Centre

Lovely.

Thanks for your additional explanation, as I said, the patch looks sane on the face of it (always nice to initialize values before use).

I've marked this as reviewed, added your additional explanation and merged it to drm-intel-next. Seems like it might like a cc to stable?

[email protected]

At the very least it works for me.

So far those special conditions seem to be rare, as the only other reference I found was this bug report against the Ubuntu kernel: https://bugs.launchpad.net/ubuntu/+bug/783039

(I'm using vanilla, besides the Reiser4 patch.)

I guess it'll hit more i915 users once distros ship 3.6.37 and up.

Thanks again!

As a side note, I'm also seeing those GMBUS and MTRR allocation failures, although I think that's pretty harmless.

Cleaned up kernel log ring buffer output:
http://ionic.de/dmesg-gmbus-fail.txt

I admit that I have no idea what GMBUS is and how critical it is, any information on this? It seems to be linked to I2C as well, so I suspect yet another hidden bug (though so far with no manifestation).

MTRR allocation may also fail due to BIOS settings, given a similar report on http://intellinuxgraphics.org/user.html (Gigabyte GA-965G-DS3 board). I've got an Intel DQ45CB board (w/ Intel ICH10 chipset), but Fan control is set to automatic, too. Sounds familiar and may explain this issue. I'll give it a try tomorrow and see whether I still have allocation failures or they are gone when switching the fan control mode.

Best regards,

Mihai