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
* 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
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 <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
---
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
* 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<[email protected]>
> Signed-off-by: Chris Wilson<[email protected]>
Wow, my machine is booting fine again, thanks!
Hope to see it included in 2.6.39. :)
Best regards,
Mihai
On Tue, 17 May 2011 18:22:52 -0700, Keith Packard <[email protected]> wrote:
> On Tue, 17 May 2011 14:03:50 +0100, Chris Wilson <[email protected]> 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
* 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
