Bug 48248

Your bug report is a bit thin:
- please attach lspci -nn, so we know which machine this is.
- please boot with drm.debug=0xe and attach the entire dmesg
- do you notice any bad side effects? gmbus is used to read the edid information from monitors and display panels, so it would be good if you can test this.

xrandr -q --verbose is a easy way to trigger reading edids.

Sorry, I forgot to link the previous bug report: https://bugs.freedesktop.org/show_bug.cgi?id=27168
It's the same machine.

~ # lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07)
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03)
00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03)
00:1a.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03)
00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03)
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03)
00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 [8086:2944] (rev 03)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 [8086:2946] (rev 03)
00:1d.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03)
00:1d.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03)
00:1d.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03)
00:1d.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93)
00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03)
00:1f.2 SATA controller [0106]: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] [8086:2929] (rev 03)
00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 03)
02:00.0 Network controller [0280]: Intel Corporation WiFi Link 5100 [8086:4232]
06:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8055 PCI-E Gigabit Ethernet Controller [11ab:4363] (rev 13)

drm.debug=0xe is in #27168

> do you notice any bad side effects?

I used 3.4-rc1 just to test your patch on #27168

Created attachment 59426 [details] [review]
print gmbus name

Can you please try the attached patch and grab dmesg with it? It's just to figure out whether it's always the same gmbus adpater timing out.

Sorry but it takes 2 hours to compile a kernel :(

niko@laptop ~ $ dmesg | grep drm
[    0.367660] [drm] Initialized drm 1.1.0 20060810
[    0.462708] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    0.462777] [drm] Driver supports precise vblank timestamp query.
[    0.974023] [drm] GMBUS [i915 gmbus dpc] timed out waiting for idle
[    1.020024] [drm] GMBUS [i915 gmbus dpc] timed out waiting for idle
[    1.195255] fbcon: inteldrmfb (fb0) is primary device
[    1.571598] fb0: inteldrmfb frame buffer device
[    1.571636] drm: registered panic notifier
[    1.573036] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[   11.604011] [drm] GMBUS [i915 gmbus dpc] timed out waiting for idle
[   11.653010] [drm] GMBUS [i915 gmbus dpc] timed out waiting for idle
[   11.702010] [drm] GMBUS [i915 gmbus dpc] timed out waiting for idle
[...]

Two quick things to check:
- is it always "gmbus dpc"?
- does it ever stop and what's the reoccurence? If you can, please attach the dmesg with loads of these messages.

Created attachment 59440 [details]
full dmesg

Created attachment 59441 [details]
dmesg | grep drm

1) is it always "gmbus dpc"?
Yes

2) does it ever stop and what's the reoccurence?
No it doesn't. It seems I get one every 10 seconds, but it seems there are other occurrences too.

> --- Comment #8 from darkbasic <darkbasic@linuxsystems.it> s it ever stop and what's the reoccurence?
> No it doesn't. It seems I get one every 10 seconds, but it seems there are
> other occurrences too.

Hotplug detection then. For easy reference, can you attach full dmesg
with drm.debug=0xe from 3.4-rc1 please?

Created attachment 59442 [details]
dmesg with drm.debug=0xe

Here it is.

A whole slew of GMBUS patches are heading into -next, so keep your eyes peeled for new issues (or checkout http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next-queued for a sneak peek). In the meantime, GMBUS is being disabled for 3.4:

commit 6a562e3daee217ce99fe0e31150acd89a5b22606
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Apr 9 21:10:38 2012 +0200

    Revert "drm/i915: reenable gmbus on gen3+ again"
    
    This reverts commit c3dfefa0a6d235bd465309e12f4c56ea16e71111.
    
    gmbus in 3.4 has simply too many known issues:
    - gmbus is too noisy, we need to rework the logging:
      https://bugs.freedesktop.org/show_bug.cgi?id=48248
    - zero-length writes cause an OOPS, and they are
      userspace-triggerable:
      https://lkml.org/lkml/2012/3/30/176
    - same for zero-length reads:
      https://bugs.freedesktop.org/show_bug.cgi?id=48269
    
    We can try again for 3.5.
    
    Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

We've tuned down the gmbus dmesg messages for 3.5 (too noisy and not really an error condition but expected under some circumstances):

commit 56fa6d6ff76c7700f8dd131bee9ffa6c3c06dcd4
Author: Daniel Kurtz <djkurtz@chromium.org>
Date:   Fri Apr 13 19:47:54 2012 +0800

    drm/i915/intel_i2c: reduce verbosity of some messages

... and gmbus is disabled in 3.4 for the time being:


commit 6a562e3daee217ce99fe0e31150acd89a5b22606
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Apr 9 21:10:38 2012 +0200

    Revert "drm/i915: reenable gmbus on gen3+ again"