On 29/05/15 07:26, Jani Nikula wrote:
On Fri, 29 May 2015, Shuah Khan shuahkh@osg.samsung.com 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] [<ffffffff817c0694>] dump_stack+0x4f/0x90 [ 5.720393] [<ffffffff81073d8a>] warn_slowpath_common+0x8a/0xe0 [ 5.720395] [<ffffffff81073e26>] warn_slowpath_fmt+0x46/0x50 [ 5.720410] [<ffffffffa040bdba>] intel_check_page_flip+0xaa/0xf0 [i915] [ 5.720420] [<ffffffffa03d7888>] ironlake_irq_handler+0x2e8/0x1000 [i915] [ 5.720423] [<ffffffff813e7787>] ? debug_smp_processor_id+0x17/0x20 [ 5.720424] [<ffffffff81074512>] ? pin_current_cpu+0x92/0x1d0 [ 5.720426] [<ffffffff810d0690>] ? irq_thread_fn+0x50/0x50 [ 5.720428] [<ffffffff810d06b7>] irq_forced_thread_fn+0x27/0x80 [ 5.720429] [<ffffffff810d0c4f>] irq_thread+0x10f/0x160 [ 5.720430] [<ffffffff810d0740>] ? wake_threads_waitq+0x30/0x30 [ 5.720432] [<ffffffff810d0b40>] ? irq_thread_check_affinity+0x90/0x90 [ 5.720433] [<ffffffff81093d7b>] kthread+0xbb/0xe0 [ 5.720434] [<ffffffff81093cc0>] ? kthread_worker_fn+0x1a0/0x1a0 [ 5.720436] [<ffffffff817c6bd8>] ret_from_fork+0x58/0x90 [ 5.720437] [<ffffffff81093cc0>] ? 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.