Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758612AbbFCQpI (ORCPT ); Wed, 3 Jun 2015 12:45:08 -0400 Received: from mga09.intel.com ([134.134.136.24]:63828 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758553AbbFCQox (ORCPT ); Wed, 3 Jun 2015 12:44:53 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,547,1427785200"; d="scan'208";a="704733144" Message-ID: <556F2EFE.9030805@intel.com> Date: Wed, 03 Jun 2015 17:44:46 +0100 From: Dave Gordon Organization: Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jani Nikula , Shuah Khan , daniel.vetter@intel.com CC: intel-gfx@lists.freedesktop.org, "linux-kernel@vger.kernel.org" , dri-devel@lists.freedesktop.org Subject: Re: [Intel-gfx] intel_check_page_flip() - WARN_ON(!in_interrupt()) References: <5567A861.8080101@osg.samsung.com> <87vbfbgar9.fsf@intel.com> In-Reply-To: <87vbfbgar9.fsf@intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5161 Lines: 104 On 29/05/15 07:26, Jani Nikula wrote: > On Fri, 29 May 2015, Shuah Khan wrote: >> I am seeing the following in the dmesg on 4.0.4 with rt patch >> >> [ 5.720319] ------------[ cut here ]------------ >> [ 5.720347] WARNING: CPU: 6 PID: 466 at >> drivers/gpu/drm/i915/intel_display.c:9748 >> intel_check_page_flip+0xaa/0xf0 [i915]() >> [ 5.720349] WARN_ON(!in_interrupt()) >> [ 5.720350] Modules linked in: >> [ 5.720376] binfmt_misc rfcomm bnep arc4 eeepc_wmi hid_generic >> asus_wmi sparse_keymap iwlmvm intel_powerclamp coretemp kvm_intel kvm >> mac80211 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel >> aes_x86_64 lrw gf128mul dm_multipath glue_helper snd_hda_codec_hdmi >> scsi_dh ablk_helper cryptd microcode btusb iwlwifi bluetooth serio_raw >> cfg80211 i915 snd_hda_codec_realtek snd_hda_codec_generic lpc_ich >> snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm >> snd_seq_midi snd_seq_midi_event snd_rawmidi drm_kms_helper snd_seq drm >> video snd_seq_device mac_hid snd_timer snd mei_me wmi mei shpchp >> soundcore i2c_algo_bit usbhid hid parport_pc ppdev lp parport autofs4 >> btrfs xor raid6_pq psmouse dm_mirror r8169 ahci dm_region_hash libahci >> mii dm_log >> [ 5.720379] CPU: 6 PID: 466 Comm: irq/32-i915 Not tainted 4.0.4-rt1+ #8 >> [ 5.720380] Hardware name: System76, Inc. Wild Dog >> Performance/H87-PLUS, BIOS 0705 12/05/2013 >> [ 5.720382] 0000000000000009 ffff8803ea39bc98 ffffffff817c0694 >> 0000000000000002 >> [ 5.720383] ffff8803ea39bce8 ffff8803ea39bcd8 ffffffff81073d8a >> 0000000000000001 >> [ 5.720384] ffff8803eb184000 ffff8800d7804800 0000000000000000 >> 0000000000000000 >> [ 5.720385] Call Trace: >> [ 5.720390] [] dump_stack+0x4f/0x90 >> [ 5.720393] [] warn_slowpath_common+0x8a/0xe0 >> [ 5.720395] [] warn_slowpath_fmt+0x46/0x50 >> [ 5.720410] [] intel_check_page_flip+0xaa/0xf0 [i915] >> [ 5.720420] [] ironlake_irq_handler+0x2e8/0x1000 >> [i915] >> [ 5.720423] [] ? debug_smp_processor_id+0x17/0x20 >> [ 5.720424] [] ? pin_current_cpu+0x92/0x1d0 >> [ 5.720426] [] ? irq_thread_fn+0x50/0x50 >> [ 5.720428] [] irq_forced_thread_fn+0x27/0x80 >> [ 5.720429] [] irq_thread+0x10f/0x160 >> [ 5.720430] [] ? wake_threads_waitq+0x30/0x30 >> [ 5.720432] [] ? irq_thread_check_affinity+0x90/0x90 >> [ 5.720433] [] kthread+0xbb/0xe0 >> [ 5.720434] [] ? kthread_worker_fn+0x1a0/0x1a0 >> [ 5.720436] [] ret_from_fork+0x58/0x90 >> [ 5.720437] [] ? kthread_worker_fn+0x1a0/0x1a0 >> [ 5.720437] ---[ end trace 0000000000000002 ]--- >> >> There seem to be few past bug reports on this issue. Has this been >> fixed? Should I be concerned about this? > > One of the old bugs [1] was about using in_irq() which didn't work for > threaded irqs, hence the switch to in_interrupt(). The backtrace seems > to indicate intel_check_page_flip() is being called from irq context; I > do not know if the rt patchset has an impact on this. > > BR, > Jani. > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=89321 > >> thanks, >> -- Shuah >> Shuah Khan >> Sr. Linux Kernel Developer >> Open Source Innovation Group >> Samsung Research America (Silicon Valley) >> shuahkh@osg.samsung.com | (970) 217-8978 This is what the RT project page says: The RT-Preempt patch converts Linux into a fully preemptible kernel. The magic is done with: 1. Making in-kernel locking-primitives (using spinlocks) preemptible though reimplementation with rtmutexes: 2. Critical sections protected by i.e. spinlock_t and rwlock_t are now preemptible. The creation of non-preemptible sections (in kernel) is still possible with raw_spinlock_t (same APIs like spinlock_t) 3. Implementing priority inheritance for in-kernel mutexes, spinlocks and rw_semaphores. For more information on priority inversion and priority inheritance please consult "Introduction to Priority Inversion" 4. Converting interrupt handlers into preemptible kernel threads: The RT-Preempt patch treats soft interrupt handlers in kernel thread context, which is represented by a task_struct like a common userspace process. However it is also possible to register an IRQ in kernel context. 5. Converting the old Linux timer API into separate infrastructures for high resolution kernel timers plus one for timeouts, leading to userspace POSIX timers with high resolution. So my guess is that item (4) made the in_interrupt() and/or in_irq() macros unreliable; with interrupts handled as threads, there isn't really any notion of "being in interrupt context". .Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/