Bug 513404 - [KMS] EDID stack trace during boot
[KMS] EDID stack trace during boot
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-23 10:23 EDT by Robert de Rooy
Modified: 2009-11-06 02:29 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-06 02:29:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Robert de Rooy 2009-07-23 10:23:51 EDT
Description of problem:
ThinkPad T60 with Intel 945GM
External Samsung LCD monitor, DVI-D attached

When booting with the external display attached, it becomes the primary display and I get an exception being thrown. This does not occur when booting with only the LVDS.

Version-Release number of selected component (if applicable):
kernel-2.6.31-0.86.rc3.git5.fc12.x86_64

How reproducible:
every time

Steps to Reproduce:
1. attach external display
2. boot
3.
  
Actual results:
stack trace

Expected results:
no stack trace

Additional info:
input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/input/input6
ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
[drm] Initialized drm 1.1.0 20060810
i915 0000:00:02.0: power state changed by ACPI to D0
i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 0000:00:02.0: setting latency timer to 64

=============================================
[ INFO: possible recursive locking detected ]
2.6.31-0.86.rc3.git5.fc12.x86_64 #1
---------------------------------------------
work_for_cpu/84 is trying to acquire lock:
(&adap->bus_lock){+.+...}, at: [<ffffffffa0012880>] i2c_transfer+0x83/0x146 [i2c_core]

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

other info that might help us debug this:
1 lock held by work_for_cpu/84:
#0: (&adap->bus_lock){+.+...}, at: [<ffffffffa0012880>] i2c_transfer+0x83/0x146 [i2c_core]

stack backtrace:
Pid: 84, comm: work_for_cpu Not tainted 2.6.31-0.86.rc3.git5.fc12.x86_64 #1
Call Trace:
[<ffffffff810955bf>] __lock_acquire+0xb84/0xc0e
[<ffffffff81095737>] lock_acquire+0xee/0x12e
[<ffffffffa0012880>] ? i2c_transfer+0x83/0x146 [i2c_core]
[<ffffffff81013a90>] ? restore_args+0x0/0x30
[<ffffffffa0012880>] ? i2c_transfer+0x83/0x146 [i2c_core]
[<ffffffffa0012880>] ? i2c_transfer+0x83/0x146 [i2c_core]
[<ffffffff814f16ab>] __mutex_lock_common+0x5b/0x3bf
[<ffffffffa0012880>] ? i2c_transfer+0x83/0x146 [i2c_core]
[<ffffffff8109387f>] ? mark_lock+0x3c/0x253
[<ffffffff814f1b32>] mutex_lock_nested+0x4f/0x6b
[<ffffffffa0012880>] ? i2c_transfer+0x83/0x146 [i2c_core]
[<ffffffffa0012880>] i2c_transfer+0x83/0x146 [i2c_core]
[<ffffffffa006de65>] intel_sdvo_write_cmd+0x82/0xf7 [i915]
[<ffffffffa006f610>] intel_sdvo_master_xfer+0xa9/0xdc [i915]
[<ffffffffa001289d>] i2c_transfer+0xa0/0x146 [i2c_core]
[<ffffffffa0037d77>] drm_do_probe_ddc_edid+0x62/0xb2 [drm]
[<ffffffffa0037dfb>] drm_ddc_read_edid+0x34/0xed [drm]
[<ffffffffa0037f87>] drm_get_edid+0xd3/0x190 [drm]
[<ffffffffa006f802>] intel_sdvo_detect+0x9f/0xf0 [i915]
[<ffffffffa00360de>] drm_helper_probe_single_connector_modes+0x97/0x253 [drm]
[<ffffffffa00362ed>] drm_helper_probe_connector_modes+0x53/0xa0 [drm]
[<ffffffffa00367b0>] drm_helper_initial_config+0x39/0x1b0 [drm]
[<ffffffffa0056ab8>] i915_driver_load+0xa84/0xb0e [i915]
[<ffffffffa002c948>] drm_get_dev+0x3b9/0x4d0 [drm]
[<ffffffff814f09ff>] ? thread_return+0x4e/0xd3
[<ffffffff8107a025>] ? do_work_for_cpu+0x0/0x50
[<ffffffffa00775a2>] i915_pci_probe+0x28/0xfc [i915]
[<ffffffff812897af>] local_pci_probe+0x2a/0x42
[<ffffffff8107a04c>] do_work_for_cpu+0x27/0x50
[<ffffffff8107f339>] kthread+0xa5/0xad
[<ffffffff8101412a>] child_rip+0xa/0x20
[<ffffffff81013a90>] ? restore_args+0x0/0x30
[<ffffffff8107f294>] ? kthread+0x0/0xad
[<ffffffff81014120>] ? child_rip+0x0/0x20
async/0 used greatest stack depth: 3744 bytes left
Console: switching to colour frame buffer device 175x65
[drm] TMDS-15: set mode 1600x1200 21
[drm] LVDS-8: set mode 1400x1050 23
[drm] fb0: inteldrmfb frame buffer device
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Comment 1 Robert de Rooy 2009-11-06 02:29:10 EST
I just tried the 2.6.31.5-122 kernel build and can no longer reproduce this stack trace. So somewhere along the line this got fixed.

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