Bug 522907 - possible recursive locking detected
Summary: possible recursive locking detected
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-12 04:25 UTC by John Reiser
Modified: 2018-04-11 11:29 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-08 04:44:29 UTC


Attachments (Terms of Use)

Description John Reiser 2009-09-12 04:25:15 UTC
Description of problem: Booting testday-20090909-i686.iso CD-ROM on Apple Macintosh Mini gives a complaint in /var/log/messages about possible recursive locking detected.


Version-Release number of selected component (if applicable):
kernel-2.6.31-0.219.rc9.git2.fc12.i686

How reproducible: every time


Steps to Reproduce:
1. boot testday-20090909-i686.iso on Apple Macintosh Mini (Core Duo i686 only)
2. switch to VT2 and inspect /var/log/messages
3.
  
Actual results:  [Prefix of "Sep 12 03:57:24 localhost kernel: " has been removed from each line]
-----
 [drm] Initialized drm 1.1.0 20060810
 i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 usb 4-2: New USB device found, idVendor=05ac, idProduct=1003
 usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
 usb 4-2: Product: Hub in Apple Extended USB Keyboard
 usb 4-2: Manufacturer: Mitsumi Electric
 usb 4-2: configuration #1 chosen from 1 choice
 hub 4-2:1.0: USB hub found
 hub 4-2:1.0: 3 ports detected
 usb 5-1: new full speed USB device using uhci_hcd and address 2

 =============================================
 [ INFO: possible recursive locking detected ]
 2.6.31-0.219.rc9.git2.fc12.i686 #1
 ---------------------------------------------
 modprobe/99 is trying to acquire lock:
 (&adap->bus_lock){+.+...}, at: [<f7cc26ee>] i2c_transfer+0x63/0x103 [i2c_core]

 but task is already holding lock:
 (&adap->bus_lock){+.+...}, at: [<f7cc26ee>] i2c_transfer+0x63/0x103 [i2c_core]

 other info that might help us debug this: 
 1 lock held by modprobe/99:
 #0:  (&adap->bus_lock){+.+...}, at: [<f7cc26ee>] i2c_transfer+0x63/0x103 [i2c_core]

 stack backtrace:
 Pid: 99, comm: modprobe Not tainted 2.6.31-0.219.rc9.git2.fc12.i686 #1
 Call Trace:
 [<c0823a86>] ? printk+0x22/0x3c
 [<c0470f55>] __lock_acquire+0x7e9/0xb25
 [<c0471348>] lock_acquire+0xb7/0xeb
 [<f7cc26ee>] ? i2c_transfer+0x63/0x103 [i2c_core]
 [<f7cc26ee>] ? i2c_transfer+0x63/0x103 [i2c_core]
 [<c0824ef4>] __mutex_lock_common+0x43/0x32b
 [<f7cc26ee>] ? i2c_transfer+0x63/0x103 [i2c_core]
 [<f7cc26ee>] ? i2c_transfer+0x63/0x103 [i2c_core]
 [<c046f899>] ? mark_lock+0x29/0x1f6
 [<c08252cf>] mutex_lock_nested+0x41/0x5a
 [<f7cc26ee>] ? i2c_transfer+0x63/0x103 [i2c_core]
 [<f7cc26ee>] i2c_transfer+0x63/0x103 [i2c_core]
 [<f7e19b5d>] intel_sdvo_write_cmd+0x63/0xc1 [i915]
 [<f7e19c53>] intel_sdvo_master_xfer+0x98/0xc4 [i915]
 [<f7cc270a>] i2c_transfer+0x7f/0x103 [i2c_core]
 [<f7ce3d2a>] drm_do_probe_ddc_edid+0x54/0x75 [drm]
 [<c0460080>] ? __remove_hrtimer+0xd/0x83
 [<f7ce3d75>] drm_ddc_read_edid+0x2a/0x85 [drm]
 [<f7ce44e6>] drm_get_edid+0xa9/0x137 [drm]
 [<f7e1b994>] intel_sdvo_hdmi_sink_detect+0x32/0xcd [i915]
 [<f7e1ba94>] ? intel_sdvo_detect+0x65/0x13d [i915]
 [<f7e1bb4b>] intel_sdvo_detect+0x11c/0x13d [i915]
 [<f7dbd438>] drm_helper_probe_single_connector_modes+0x7d/0x220 [drm_kms_helper]
 [<f7dbd61e>] drm_helper_probe_connector_modes+0x43/0x81 [drm_kms_helper]
 [<f7dbda1b>] drm_helper_initial_config+0x2c/0x71 [drm_kms_helper]
 [<f7e028a0>] i915_driver_load+0xabb/0xb52 [i915]
 [<f7cdb5f7>] drm_get_dev+0x325/0x40f [drm]
 [<f7e21064>] i915_pci_probe+0x21/0xb5 [i915]
 [<c0613ce8>] local_pci_probe+0x22/0x35
 [<c0614b71>] pci_device_probe+0x54/0x8a
 [<c06b0d34>] driver_probe_device+0xca/0x1d9
 [<c06b0e99>] __driver_attach+0x56/0x84
 [<c06b015b>] bus_for_each_dev+0x53/0x8e
 [<c06b0e43>] ? __driver_attach+0x0/0x84
 [<c06b0ab1>] driver_attach+0x27/0x3a
 [<c06b0e43>] ? __driver_attach+0x0/0x84
 [<c06b0749>] bus_add_driver+0xde/0x235
 [<c06b11e8>] driver_register+0x89/0x101
 [<c06059ed>] ? __spin_lock_init+0x35/0x6c
 [<c0614dad>] __pci_register_driver+0x5c/0xcd
 [<f7cd6ab4>] drm_init+0x6d/0xd6 [drm]
 [<f7cfa000>] ? i915_init+0x0/0x67 [i915]
 [<f7cfa054>] i915_init+0x54/0x67 [i915]
 [<c040117e>] do_one_initcall+0x6d/0x18c
 [<c047b9a7>] sys_init_module+0xc8/0x1f1
 [<c0403a50>] syscall_call+0x7/0xb


Expected results: no complaints


Additional info:  lspci shows:
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.0 0300: 8086:27a2 (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
        Subsystem: Intel Corporation Device 7270
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at 90380000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at 20f0 [size=8]
        Memory at 80000000 (32-bit, prefetchable) [size=256M]
        Memory at 90400000 (32-bit, non-prefetchable) [size=256K]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Kernel driver in use: i915
        Kernel modules: i915

Comment 1 Matěj Cepl 2009-11-05 17:16:15 UTC
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

Comment 2 John Reiser 2009-11-05 20:32:18 UTC
The problem persists in F12-Beta-i686-Live (log appears below.)  "Beta" is two weeks old by now.  The problem does _not_ appear in today's boot.iso for i686, but I don't know whether it would.

/var/log/messages for F12-Beta-i686-Live:
=============================================
[ INFO: possible recursive locking detected ]
2.6.31.1-56.fc12.i686 #1
---------------------------------------------
modprobe/97 is trying to acquire lock:
(&adap->bus_lock){+.+...}, at: [<f7cc26ee>] i2c_transfer+0x63/0x103 [i2c_core]
Nov  5 20:08:17 localhost kernel:
but task is already holding lock: 
(&adap->bus_lock){+.+...}, at: [<f7cc26ee>] i2c_transfer+0x63/0x103 [i2c_core]
Nov  5 20:08:17 localhost kernel:
other info that might help us debug this:
1 lock held by modprobe/97:
#0:  (&adap->bus_lock){+.+...}, at: [<f7cc26ee>] i2c_transfer+0x63/0x103 [i2c_core]
Nov  5 20:08:17 localhost kernel:
stack backtrace:
Pid: 97, comm: modprobe Not tainted 2.6.31.1-56.fc12.i686 #1
Call Trace:
[<c0823fc6>] ? printk+0x22/0x3c
[<c0470fe9>] __lock_acquire+0x7e9/0xb25
[<c04713dc>] lock_acquire+0xb7/0xeb
[<f7cc26ee>] ? i2c_transfer+0x63/0x103 [i2c_core]
[<f7cc26ee>] ? i2c_transfer+0x63/0x103 [i2c_core]
[<c0825434>] __mutex_lock_common+0x43/0x32b
[<f7cc26ee>] ? i2c_transfer+0x63/0x103 [i2c_core]
[<f7cc26ee>] ? i2c_transfer+0x63/0x103 [i2c_core]
[<c046f92d>] ? mark_lock+0x29/0x1f6
[<c082580f>] mutex_lock_nested+0x41/0x5a
[<f7cc26ee>] ? i2c_transfer+0x63/0x103 [i2c_core]
[<f7cc26ee>] i2c_transfer+0x63/0x103 [i2c_core]
[<f7e11b51>] intel_sdvo_write_cmd+0x63/0xc1 [i915]
[<f7e11c47>] intel_sdvo_master_xfer+0x98/0xc4 [i915]
[<f7cc270a>] i2c_transfer+0x7f/0x103 [i2c_core]
[<f7ce36a6>] drm_do_probe_ddc_edid+0x54/0x75 [drm]
[<c0460080>] ? hrtimer_force_reprogram+0x54/0xdb 
[<f7ce36f1>] drm_ddc_read_edid+0x2a/0x85 [drm] 
[<f7ce3ed4>] drm_get_edid+0xa9/0x139 [drm]
[<f7e1398f>] intel_sdvo_hdmi_sink_detect+0x32/0xcd [i915]
[<f7e13a8f>] ? intel_sdvo_detect+0x65/0x13e [i915]
[<f7e13b46>] intel_sdvo_detect+0x11c/0x13e [i915]
[<f7cfb990>] drm_helper_probe_single_connector_modes+0xaa/0x251 [drm_kms_helper]
[<f7cfbb7a>] drm_helper_probe_connector_modes+0x43/0x81 [drm_kms_helper]
[<f7cfc086>] drm_helper_initial_config+0x33/0x78 [drm_kms_helper]
[<f7dfa8a0>] i915_driver_load+0xabb/0xb52 [i915]
[<f7cdb281>] drm_get_dev+0x313/0x3fd [drm]
[<f7e19064>] i915_pci_probe+0x21/0xb5 [i915]
[<c0613f78>] local_pci_probe+0x22/0x35
[<c0614e01>] pci_device_probe+0x54/0x8a
[<c06b0fb8>] driver_probe_device+0xca/0x1d9
[<c06b111d>] __driver_attach+0x56/0x84
[<c06b03df>] bus_for_each_dev+0x53/0x8e
[<c06b10c7>] ? __driver_attach+0x0/0x84
[<c06b0d35>] driver_attach+0x27/0x3a
[<c06b10c7>] ? __driver_attach+0x0/0x84
[<c06b09cd>] bus_add_driver+0xde/0x235
[<c06b146c>] driver_register+0x89/0x101
[<c0605c7d>] ? __spin_lock_init+0x35/0x6c
[<c061503d>] __pci_register_driver+0x5c/0xcd
[<f7cd6b0c>] drm_init+0x6d/0xd6 [drm]
[<f7e2d000>] ? i915_init+0x0/0x67 [i915]
[<f7e2d054>] i915_init+0x54/0x67 [i915]
[<c040117e>] do_one_initcall+0x6d/0x18c
[<c047ba3b>] sys_init_module+0xc8/0x1f1
[<c0403a50>] syscall_call+0x7/0xb

Comment 3 Matěj Cepl 2009-11-08 02:00:09 UTC
(In reply to comment #2)
> The problem persists in F12-Beta-i686-Live (log appears below.)  "Beta" is two
> weeks old by now.  The problem does _not_ appear in today's boot.iso for i686,
> but I don't know whether it would.

You mean, it has been fixed in the latest ISO, not in Beta? So we should close it as a post-Beta fix?

Thank you very much for the reply

Comment 4 John Reiser 2009-11-08 04:44:29 UTC
Yes, the problem does not appear in desktop-i386-20091104.16.iso (a LiveCD), nor in boot.iso (netinst.iso), but was still present in Beta.


Note You need to log in before you can comment on or make changes to this bug.