Kernel BUG with i915 in intel_sdvo_ddc_proxy_func

Kernel BUG with i915 in intel_sdvo_ddc_proxy_func

[Mihai Moldovan]

[-- Attachment #1: Type: text/plain, Size: 3384 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 6111 bytes --]

Re: Kernel BUG with i915 in intel_sdvo_ddc_proxy_func

[Mihai Moldovan]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

* On 17.05.2011 02:05 PM, Mihai Moldovan wrote:
> 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

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 6111 bytes --]

[PATCH] drm/i915/sdvo: Reorder i2c initialisation before ddc proxy

[Chris Wilson]

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.

Reported-by: Mihai Moldovan <ionic@ionic.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/intel_sdvo.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c
index 4324f33..754086f 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -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

Re: [PATCH] drm/i915/sdvo: Reorder i2c initialisation before ddc proxy

[Mihai Moldovan]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

* On 17.05.2011 03:03 PM, Chris Wilson wrote:
> 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.
>
> Reported-by: Mihai Moldovan<ionic@ionic.de>
> Signed-off-by: Chris Wilson<chris@chris-wilson.co.uk>

Wow, my machine is booting fine again, thanks!

Hope to see it included in 2.6.39. :)

Best regards,


Mihai



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 6111 bytes --]

Re: [PATCH] drm/i915/sdvo: Reorder i2c initialisation before ddc proxy

[Keith Packard]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Tue, 17 May 2011 14:03:50 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> 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.

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).

-- 
keith.packard@intel.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] drm/i915/sdvo: Reorder i2c initialisation before ddc proxy

[Chris Wilson]

On Tue, 17 May 2011 18:22:52 -0700, Keith Packard <keithp@keithp.com> wrote:
> On Tue, 17 May 2011 14:03:50 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > 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.
> 
> I'd love more explanation here about how this code ever worked -- what
> are these 'certain configurations' of which you speak?

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

Re: [PATCH] drm/i915/sdvo: Reorder i2c initialisation before ddc proxy

[Keith Packard]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

On Wed, 18 May 2011 09:04:11 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Tue, 17 May 2011 18:22:52 -0700, Keith Packard <keithp@keithp.com> wrote:
> > On Tue, 17 May 2011 14:03:50 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > > 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.
> > 
> > I'd love more explanation here about how this code ever worked -- what
> > are these 'certain configurations' of which you speak?
> 
> 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.

Lovely.

> 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.

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?

-- 
keith.packard@intel.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] drm/i915/sdvo: Reorder i2c initialisation before ddc proxy

[Mihai Moldovan]

[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]

* On 18.05.2011 04:40 PM, Keith Packard wrote:
> 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?

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 6111 bytes --]