Bug 69397

Summary: [Baytrail-M] No lockdep key for rps work?
Product: DRI Reporter: shui yangwei <yangweix.shui>
Component: DRM/IntelAssignee: Imre Deak <imre.deak>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: major    
Priority: medium CC: intel-gfx-bugs
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg: boot up with call trace
none
dmesg: call trace also exists with the patch applied
none
fix vlv work init none

Description shui yangwei 2013-09-16 02:02:02 UTC 
Created attachment 85887 [details]
dmesg: boot up with call trace

Environment:
--------------------
Kernel: (drm-intel-next-queued)6c4a8962a4a078cacfc8eb5d4bd79f6343b8cd7a
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Sep 10 14:54:42 2013 -0700
    drm/i915/vlv: re-enable hotplug detect based probing on VLV/BYT


lspci:
--------------------
00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0a)


Description:
--------------------
Test with latest -next-queued kernel, there's call trace in dmesg when machine boot up. I tested other IVB platform, there's not this issue. Older kernels also reproduceable. We are testing Baytrail machine recently, and it might not be a regression. 


Call Trace:
--------------------
[    2.672633] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing gene
ric driver
[    2.672973] Console: switching to colour dummy device 80x25
[    2.691967] i915 0000:00:02.0: setting latency timer to 64
[    2.760073] [drm:intel_detect_pch], No PCH found?
[    2.760338] INFO: trying to register non-static key.
[    2.760351] the code is fine but needs lockdep annotation.
[    2.760358] turning off the locking correctness validator.
[    2.760369] CPU: 0 PID: 1191 Comm: systemd-udevd Not tainted 3.11.0-rc7_drm-i
ntel-next-queued_e14c68_20130912+ #1
[    2.760381] Hardware name: Intel Corp. VALLEYVIEW B2 PLATFORM/NOTEBOOK, BIOS
BBAYCRB1.X64.0055.R31.1308081542 BBAY_X64_R_V0055_31 08/08/2013
[    2.760394]  0000000000000000 ffff88003f9f16a8 ffffffff817d020f 0000000000000
006
[    2.760409]  ffffffff82859810 ffff88003f9f1778 ffffffff81089328 0000000000000006
[    2.760422]  0000000700046e00 ffffffff828a7470 0000000000000000 ffffffff00000000
[    2.760436] Call Trace:
[    2.760449]  [<ffffffff817d020f>] dump_stack+0x46/0x58
[    2.760465]  [<ffffffff81089328>] __lock_acquire+0x8b4/0x183b
[    2.760477]  [<ffffffff8108b004>] ? trace_hardirqs_on_caller+0x142/0x19e
[    2.760490]  [<ffffffff8108b06d>] ? trace_hardirqs_on+0xd/0xf
[    2.760501]  [<ffffffff8104fb0d>] ? __flush_work+0x3a/0x1cc
[    2.760513]  [<ffffffff8107b4ea>] ? vprintk_emit+0x453/0x47f
[    2.760524]  [<ffffffff8108a7b3>] lock_acquire+0xcc/0x106
[    2.760534]  [<ffffffff8104fd30>] ? flush_work+0x5/0x5a
[    2.760545]  [<ffffffff8108ae96>] ? mark_held_locks+0xce/0xfa
[    2.760556]  [<ffffffff8104fd61>] flush_work+0x36/0x5a
...............
...............
Comment 1 Daniel Vetter 2013-09-25 15:57:09 UTC 
Relevant lines from dmesg:

[    2.760338] INFO: trying to register non-static key.
[    2.760351] the code is fine but needs lockdep annotation.

I suspect the rps work ordering that we currently miss. Please test the below patch:

https://patchwork.kernel.org/patch/2899631/
Comment 2 shui yangwei 2013-09-26 02:32:42 UTC 
(In reply to comment #1)
> Relevant lines from dmesg:
> 
> [    2.760338] INFO: trying to register non-static key.
> [    2.760351] the code is fine but needs lockdep annotation.
> 
> I suspect the rps work ordering that we currently miss. Please test the
> below patch:
> 
> https://patchwork.kernel.org/patch/2899631/

Apply this patch on latest -next-queued, after booting up, this "Call Trace" also reproduceable.
Comment 3 shui yangwei 2013-09-26 02:36:41 UTC 
Created attachment 86604 [details]
dmesg: call trace also exists with the patch applied

For comment 2.
Comment 4 shui yangwei 2013-09-26 03:04:06 UTC 
When both VGA and eDP plugged in, run testdisplay, this call trace will come up while switching panel. Then testdisplay stick at the first mode of the second panel.
Comment 5 Imre Deak 2013-09-27 09:05:41 UTC 
Created attachment 86711 [details] [review]
fix vlv work init

Attached is a fix for an issue I had with the same error message.
Comment 6 Jesse Barnes 2013-09-27 17:38:45 UTC 
Looks like Imre has a fix.
Comment 7 shui yangwei 2013-09-29 01:52:08 UTC 
(In reply to comment #5)
> Created attachment 86711 [details] [review] [review]
> fix vlv work init
> 
> Attached is a fix for an issue I had with the same error message.

This patch worked, When machine boot up, the call trace disappeared.
Comment 8 Jesse Barnes 2013-10-04 16:46:34 UTC 
commit 671952a2a290a90017c64e75b7dd0343b0d005b4
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue Oct 1 18:11:26 2013 +0300

    drm/i915: fix rps.vlv_work initialization
Comment 9 shui yangwei 2013-10-08 03:39:52 UTC 
(In reply to comment #8)
> commit 671952a2a290a90017c64e75b7dd0343b0d005b4
> Author: Imre Deak <imre.deak@intel.com>
> Date:   Tue Oct 1 18:11:26 2013 +0300
> 
>     drm/i915: fix rps.vlv_work initialization


I tried latest -next-queued kernel, this issue is gone. Verified here.
Comment 10 Elizabeth 2017-10-06 14:43:05 UTC 
Closing old verified.

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.