Bug 90012

Summary: [ BSW regression] Call trace when starting the system
Product: DRI Reporter: ye.tian <yex.tian>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: major    
Priority: high CC: imre.deak, intel-gfx-bugs
Version: unspecified   
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg info none

Description ye.tian 2015-04-13 10:01:16 UTC
Created attachment 115053 [details]
dmesg info

System Environment:       
-----------------------------------------------------
Regression:  Yes
Non-working platforms: BSW

==Kernel==
--------------------------------------------------
commit 631c2f8cb69ecbd7dd0494c37dd3c7fbd04de928
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Apr 11 00:21:05 2015 +0200

    drm-intel-nightly: 2015y-04m-10d-22h-20m-20s UTC integration manifest
==Bug detailed description==
Call trace when starting the system on bsw with latest nightly kernel,  The latest drm-intel-next-queued and drm-intel-fixes are good, it unstable on the latest for-next branch(for-next_cfd311_20150410+), Fail rate: 3/5 on for-next, 5/5 on nightly kernel.
Fail rate: 0/5 on 4.0.0-rc5_for-next_473846_20150326+.
I checkout the for-next branch is fail.


Reproduce steps:
----------------------------

1, start machine
Comment 1 Jeff Zheng 2015-04-14 01:10:32 UTC
Yes, this issue also exists on drm-intel-testing-2015-04-10

[    4.528751] WARNING: CPU: 3 PID: 741 at drivers/gpu/drm/i915/intel_audio.c:484 i915_audio_component_get_cdclk_freq+0x37/0x72 [i915]()
[    4.528759] WARN_ON_ONCE(!HAS_DDI(dev_priv))
[    4.528780] Modules linked in: iTCO_wdt iTCO_vendor_support serio_raw pcspkr i2c_i801 lpc_ich mfd_core snd_hda_intel snd_hda_controller snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore battery ac acpi_cpufreq joydev i915 button video drm_kms_helper drm
[    4.528784] CPU: 3 PID: 741 Comm: kworker/3:1 Not tainted 4.0.0-rc7_drm-intel-testing-2015-04-10+ #1074
[    4.528791] Workqueue: events azx_probe_work [snd_hda_intel]
[    4.528796]  0000000000000000 0000000000000009 ffffffff817958c7 ffff880179d4fd28
[    4.528799]  ffffffff8103bd5a 0000000000000046 ffffffffa00c12bd ffff88017a2a5000
[    4.528802]  ffff880002c90000 ffff880179c2a800 0000000000000004 ffff880002e03800
[    4.528803] Call Trace:
[    4.528813]  [<ffffffff817958c7>] ? dump_stack+0x40/0x50
[    4.528819]  [<ffffffff8103bd5a>] ? warn_slowpath_common+0x98/0xb0
[    4.528852]  [<ffffffffa00c12bd>] ? i915_audio_component_get_cdclk_freq+0x37/0x72 [i915]
[    4.528856]  [<ffffffff8103bdb7>] ? warn_slowpath_fmt+0x45/0x4a
[    4.528863]  [<ffffffff81357973>] ? pci_bus_read_config_word+0x70/0x7b
[    4.528896]  [<ffffffffa00c12bd>] ? i915_audio_component_get_cdclk_freq+0x37/0x72 [i915]
[    4.528901]  [<ffffffffa01f4974>] ? haswell_set_bclk+0x1c/0x91 [snd_hda_intel]
[    4.528906]  [<ffffffffa01f3f33>] ? azx_probe_work+0x391/0x544 [snd_hda_intel]
[    4.528912]  [<ffffffff8104ca7f>] ? process_one_work+0x1b2/0x31d
[    4.528916]  [<ffffffff8104d278>] ? worker_thread+0x24d/0x339
[    4.528920]  [<ffffffff8104d02b>] ? cancel_delayed_work_sync+0xa/0xa
[    4.528924]  [<ffffffff81050b25>] ? kthread+0xce/0xd6
[    4.528928]  [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162
[    4.528931]  [<ffffffff8179b0c8>] ? ret_from_fork+0x58/0x90
[    4.528935]  [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162
[    4.528937] ---[ end trace 1ecd514f87a6026c ]---
[
Comment 2 Jani Nikula 2015-04-14 07:41:54 UTC
i915_audio_component_get_cdclk_freq is not implemented for hsw.

I am not sure if haswell_set_bclk in the hda driver is the right thing to call on a bsw either.

Imre?
Comment 3 Imre Deak 2015-04-14 10:42:26 UTC
(In reply to Jani Nikula from comment #2)
> i915_audio_component_get_cdclk_freq is not implemented for hsw.

On hsw it is but not on bsw. There is the corresponding get_display_clock_speed hook defined for all platforms, so in theory this would work everywhere. Ville suggested to Mika Kahola that he removes this WARN after the CDCLK patchset is merged, I think that's the way to fix this.

> I am not sure if haswell_set_bclk in the hda driver is the right thing to
> call on a bsw either.

Yes, that looks incorrect. haswell_set_bclk() in practice only updates the EM4/EM5 registers which - based on Bspec - only exist on hsw and bdw.

> Imre?
Comment 4 ye.tian 2015-04-23 07:48:46 UTC
Test on the latest nightly kernel(b9fe35), This problem does not exists.
So verified it.
Comment 5 Elizabeth 2017-10-06 14:30:36 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.