As of Linux 2.6.39 (Debian linux-image-2.6.39-1-amd64 version 2.6.39-1), loading the eeprom I2C module hangs, both on a desktop with a Q35 and on a laptop with a GM45. The system is otherwise responsive, though that makes no practical difference if it's configured to load eeprom at boot (as my desktop was until now per sensors-detect's suggestion). On my laptop (a Thinkpad R500), the relevant kernel messages were [ 2904.484147] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.540156] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.596159] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.652153] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.708158] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.764159] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.820147] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.876159] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2905.584162] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [ 2905.640162] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [ 2905.696046] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [ 2905.752155] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [ 2905.808119] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [ 2905.864110] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [ 2905.920157] [drm] GMBUS timed out, falling back to bit banging on pin 7 [i915 gmbus dpd] [ 3120.492233] INFO: task modprobe:8678 blocked for more than 120 seconds. [ 3120.492242] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 3120.492248] modprobe D ffff8800a32b27a0 0 8678 8677 0x00000004 [ 3120.492259] ffff8800a32b27a0 0000000000000082 ffff8800a32b27a0 ffff8800a32a6e40 [ 3120.492271] 0000000000013b40 ffff880086ef7fd8 ffff880086ef7fd8 0000000000013b40 [ 3120.492282] ffff8800a32b27a0 ffff880086ef6010 ffff8800a32b27a0 ffff880086ef6000 [ 3120.492293] Call Trace: [ 3120.492352] [<ffffffff81331cb5>] ? __mutex_lock_common+0x127/0x193 [ 3120.492383] [<ffffffffa024fecc>] ? i2c_add_numbered_adapter+0xad/0xad [i2c_core] [ 3120.492391] [<ffffffff81331ded>] ? mutex_lock+0x1a/0x33 [ 3120.492406] [<ffffffffa024ff02>] ? i2c_add_adapter+0x36/0x86 [i2c_core] [ 3120.492416] [<ffffffff811a95a9>] ? snprintf+0x36/0x3b [ 3120.492430] [<ffffffffa02c585c>] ? __i2c_bit_add_bus+0x1e9/0x22c [i2c_algo_bit] [ 3120.492459] [<ffffffffa03f227b>] ? intel_gpio_create+0x124/0x13d [i915] [ 3120.492486] [<ffffffffa03f29da>] ? gmbus_xfer+0x3ef/0x46d [i915] [ 3120.492503] [<ffffffffa024ed26>] ? i2c_transfer+0xa1/0xdd [i2c_core] [ 3120.492520] [<ffffffffa024f055>] ? i2c_smbus_xfer_emulated+0x2f3/0x3fd [i2c_core] [ 3120.492529] [<ffffffff811a338e>] ? kobject_get+0x12/0x17 [ 3120.492539] [<ffffffff81241c84>] ? get_device+0x14/0x1b [ 3120.492548] [<ffffffff8131c187>] ? klist_add_tail+0x1f/0x41 [ 3120.492556] [<ffffffff81243129>] ? device_add+0x4de/0x5d7 [ 3120.492572] [<ffffffffa024f7cc>] ? i2c_default_probe+0x99/0xfd [i2c_core] [ 3120.492589] [<ffffffffa025007a>] ? i2c_do_add_adapter+0xcf/0x22b [i2c_core] [ 3120.492605] [<ffffffffa02501d6>] ? i2c_do_add_adapter+0x22b/0x22b [i2c_core] [ 3120.492615] [<ffffffff81244264>] ? bus_for_each_dev+0x44/0x78 [ 3120.492631] [<ffffffffa02501d6>] ? i2c_do_add_adapter+0x22b/0x22b [i2c_core] [ 3120.492647] [<ffffffffa024e6a3>] ? i2c_for_each_dev+0x2c/0x47 [i2c_core] [ 3120.492668] [<ffffffffa0045000>] ? 0xffffffffa0044fff [ 3120.492684] [<ffffffffa024e774>] ? i2c_register_driver+0x9c/0xa2 [i2c_core] [ 3120.492695] [<ffffffffa0045000>] ? 0xffffffffa0044fff [ 3120.492704] [<ffffffff81002078>] ? do_one_initcall+0x78/0x131 [ 3120.492714] [<ffffffff810757b6>] ? sys_init_module+0xd3/0x221 [ 3120.492722] [<ffffffff81338c12>] ? system_call_fastpath+0x16/0x1b On my desktop, the details were only slightly different: when pin 0 didn't pan out, the kernel moved on to pin 1 ("i915 gmbus ssc"), which led to the same failure mode on the first try. In contrast, 2.6.38 on my desktop reported eight attempts on each of pin 0 and pin 6, after which it moved on with no further messages from the DRM subsystem. (I haven't tested with older kernel versions on my laptop; should I?) See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627575.
Turn on lockdep. Looks like we try to acquire an i2c mutex to create the fallback adapter, but that mutex is being already held.
Created attachment 47169 [details] log messages with lockdep enabled Good call. Enabling lockdep indeed detected recursive locking, per the attachment; although the lock in question is private to i2c-core.c, AFAICT that has seen only formal changes between 2.6.38.5 and 2.6.39, so I'd suggest reviewing your usage of its API. (See http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.39.y.git;a=blobdiff;f=drivers/i2c/i2c-core.c;h=9a58994ff7ea54bd46cf6b576e9e43b10e736b79;hp=f0bd5bcdf56329294b5cab85a0fe41ce06600dd6;hb=HEAD;hpb=f4e8db31a83ad019e9ae06edb9c2f89de66bc7b7 .) Thanks for the quick response; please let me know if you need any further details.
The revert to disable GMBUS has finally gone upstream.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.