Re: [Intel-gfx] intel_check_page_flip() - WARN_ON(!in_interrupt())

[Dave Gordon]

On 29/05/15 07:26, Jani Nikula wrote:
> On Fri, 29 May 2015, Shuah Khan <shuahkh@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx | (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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/