search for: __fget_light

https://bugs.freedesktop.org/show_bug.cgi?id=90482 Bug ID: 90482 Summary: Xorg take 100% CPU when using multiple independent screen configuration Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

...ffffff811e7042>] __generic_file_write_iter+0x1a2/0x1e0 [<ffffffff81310a12>] ext4_file_write_iter+0x102/0x480 [<ffffffff810268b9>] ? sched_clock+0x9/0x10 [<ffffffff812760dc>] __vfs_write+0xcc/0x110 [<ffffffff8127677c>] vfs_write+0xac/0x1a0 [<ffffffff81297a56>] ? __fget_light+0x66/0x90 [<ffffffff81277478>] SyS_write+0x58/0xd0 [<ffffffff818800b2>] entry_SYSCALL_64_fastpath+0x12/0x76 SLUB: Unable to allocate memory on node -1 (gfp=0x2000000) cache: radix_tree_node, object size: 576, buffer size: 584, default order: 2, min order: 0 node 0: slabs: 766, obj...

...ad+0x1f/0x30 [ 46.168289] ? kvm_sched_clock_read+0x5/0x10 [ 46.168303] ? __do_page_fault+0x549/0xd00 [ 46.168308] ? kvm_clock_read+0x1f/0x30 [ 46.168313] ? kvm_sched_clock_read+0x5/0x10 [ 46.168318] ? sched_clock+0x5/0x10 [ 46.168324] ? sched_clock_cpu+0x18/0x2b0 [ 46.168336] ? __fget_light+0x5c/0x280 [ 46.168357] ? __sys_sendmsg+0xd2/0x170 [ 46.168362] __sys_sendmsg+0xd2/0x170 [ 46.168371] ? __ia32_sys_shutdown+0x90/0x90 [ 46.168382] ? handle_mm_fault+0x363/0xa70 [ 46.168397] ? up_read+0x1c/0x130 [ 46.168403] ? __do_page_fault+0x549/0xd00 [ 46.168443] ? do_syscal...

...ad+0x1f/0x30 [ 46.168289] ? kvm_sched_clock_read+0x5/0x10 [ 46.168303] ? __do_page_fault+0x549/0xd00 [ 46.168308] ? kvm_clock_read+0x1f/0x30 [ 46.168313] ? kvm_sched_clock_read+0x5/0x10 [ 46.168318] ? sched_clock+0x5/0x10 [ 46.168324] ? sched_clock_cpu+0x18/0x2b0 [ 46.168336] ? __fget_light+0x5c/0x280 [ 46.168357] ? __sys_sendmsg+0xd2/0x170 [ 46.168362] __sys_sendmsg+0xd2/0x170 [ 46.168371] ? __ia32_sys_shutdown+0x90/0x90 [ 46.168382] ? handle_mm_fault+0x363/0xa70 [ 46.168397] ? up_read+0x1c/0x130 [ 46.168403] ? __do_page_fault+0x549/0xd00 [ 46.168443] ? do_syscal...

..._runtime_resume+0x4d/0x60 [<ffffffff8110848d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff81743392>] ? _raw_spin_unlock_irqrestore+0x42/0x70 [<ffffffffa0354777>] nouveau_drm_ioctl+0x67/0xc0 [nouveau] [<ffffffff8124aa11>] do_vfs_ioctl+0x301/0x550 [<ffffffff812566aa>] ? __fget_light+0x2a/0x90 [<ffffffff8124acd9>] SyS_ioctl+0x79/0x90 [<ffffffff81743c5b>] entry_SYSCALL_64_fastpath+0x16/0x73 Code: fe ff ff 48 c7 c2 18 f1 a2 81 be 92 03 00 00 48 c7 c7 f5 eb a2 81 c6 05 50 65 7f 00 01 e8 ec 30 bd ff e9 2a fe ff ff 48 8b 43 08 <48> 8b 40 18 48 85 c0 0f 84 03 fe f...

...? __switch_to_asm+0x34/0x70 > ? __switch_to_asm+0x34/0x70 > drm_ioctl+0x445/0x950 [drm] > ? drm_mode_getcrtc+0x790/0x790 [drm] > ? drm_getunique+0x220/0x220 [drm] > ? expand_files.part.10+0x920/0x920 > do_vfs_ioctl+0x1a1/0x13d0 > ? ioctl_preallocate+0x2b0/0x2b0 > ? __fget_light+0x2d6/0x390 > ? schedule+0xd7/0x2e0 > ? fget_raw+0x10/0x10 > ? apic_timer_interrupt+0xa/0x20 > ? apic_timer_interrupt+0xa/0x20 > ? rcu_cleanup_dead_rnp+0x2c0/0x2c0 > ksys_ioctl+0x60/0x90 > __x64_sys_ioctl+0x6f/0xb0 > do_syscall_64+0x136/0x440 > ? syscall_return_s...

...kvm_sched_clock_read+0x5/0x10 > [?? 46.168303]? ? __do_page_fault+0x549/0xd00 > [?? 46.168308]? ? kvm_clock_read+0x1f/0x30 > [?? 46.168313]? ? kvm_sched_clock_read+0x5/0x10 > [?? 46.168318]? ? sched_clock+0x5/0x10 > [?? 46.168324]? ? sched_clock_cpu+0x18/0x2b0 > [?? 46.168336]? ? __fget_light+0x5c/0x280 > [?? 46.168357]? ? __sys_sendmsg+0xd2/0x170 > [?? 46.168362]? __sys_sendmsg+0xd2/0x170 > [?? 46.168371]? ? __ia32_sys_shutdown+0x90/0x90 > [?? 46.168382]? ? handle_mm_fault+0x363/0xa70 > [?? 46.168397]? ? up_read+0x1c/0x130 > [?? 46.168403]? ? __do_page_fault+0x549/0xd...

...b/0x45 [ 243.143861] nouveau_drm_ioctl+0x53/0x9a [nouveau] [ 243.143861] ? nouveau_pmops_thaw+0xf/0xf [nouveau] [ 243.143861] do_vfs_ioctl+0x85/0x635 [ 243.143861] ? _raw_spin_unlock+0x10/0x23 [ 243.143861] ? handle_mm_fault+0x67d/0x859 [ 243.143861] ? __fget+0x5c/0x93 [ 243.143861] ? __fget_light+0x43/0x4d [ 243.143861] ksys_ioctl+0x33/0x52 [ 243.143861] sys_ioctl+0x11/0x13 [ 243.143861] do_fast_syscall_32+0x8f/0x1c2 [ 243.143861] entry_SYSENTER_32+0x6b/0xbe [ 243.143861] EIP: 0xb7fb9af5 [ 243.143861] Code: 82 f8 ff ff 8b 55 08 8b 80 5c cd ff ff 85 d2 74 02 89 02 5d c3 8b 04 24 c3...

On Mon, Jul 23, 2018 at 11:36:03PM +0900, Toshiaki Makita wrote: > From: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp> > > Add some ethtool stat items useful for performance analysis. > > Signed-off-by: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp> Series: Acked-by: Michael S. Tsirkin <mst at redhat.com> Patch 1 seems appropriate for stable, even

On Mon, Jul 23, 2018 at 11:36:03PM +0900, Toshiaki Makita wrote: > From: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp> > > Add some ethtool stat items useful for performance analysis. > > Signed-off-by: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp> Series: Acked-by: Michael S. Tsirkin <mst at redhat.com> Patch 1 seems appropriate for stable, even

...grade+0x5e0/0x5e0 > [ 7.276439] ? mem_cgroup_commit_charge+0xb4/0xf80 > [ 7.276453] ? _raw_spin_unlock+0x24/0x30 > [ 7.276458] ? __handle_mm_fault+0xc85/0x3140 > [ 7.276467] ? __pmd_alloc+0x430/0x430 > [ 7.276473] ? find_held_lock+0x32/0x1c0 > [ 7.276485] ? __fget_light+0x55/0x1f0 > [ 7.276497] ? __sys_sendmsg+0xd2/0x170 > [ 7.276502] __sys_sendmsg+0xd2/0x170 > [ 7.276508] ? __ia32_sys_shutdown+0x70/0x70 > [ 7.276516] ? handle_mm_fault+0x1f9/0x6a0 > [ 7.276528] ? up_read+0x1c/0x110 > [ 7.276534] ? __do_page_fault+0x4a6/0xa...

...drm] ? drm_setversion+0x7f0/0x7f0 [drm] ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x34/0x70 drm_ioctl+0x445/0x950 [drm] ? drm_mode_getcrtc+0x790/0x790 [drm] ? drm_getunique+0x220/0x220 [drm] ? expand_files.part.10+0x920/0x920 do_vfs_ioctl+0x1a1/0x13d0 ? ioctl_preallocate+0x2b0/0x2b0 ? __fget_light+0x2d6/0x390 ? schedule+0xd7/0x2e0 ? fget_raw+0x10/0x10 ? apic_timer_interrupt+0xa/0x20 ? apic_timer_interrupt+0xa/0x20 ? rcu_cleanup_dead_rnp+0x2c0/0x2c0 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x6f/0xb0 do_syscall_64+0x136/0x440 ? syscall_return_slowpath+0x2d0/0x2d0 ? do_page_fault+0x89/0x3...

...c04b514a>] handle_irq_event+0x2a/0x50 [<c04b7dd2>] handle_fasteoi_irq+0x72/0x120 [<c04060c3>] handle_irq+0xa3/0xd0 <IRQ> [<c040589c>] do_IRQ+0x3c/0xc0 [<c072adad>] ? __copy_to_user_ll+0xd/0x10 [<c0ac3a73>] common_interrupt+0x33/0x38 [<c05cf255>] ? __fget_light+0x35/0x50 [<c05cf282>] __fdget+0x12/0x20 [<c05c825d>] do_sys_poll+0x2bd/0x570 [<c072b07c>] ? _copy_from_user+0x3c/0x50 [<c05b5408>] ? rw_copy_check_uvector+0x58/0x110 [<c0a69076>] ? unix_stream_recvmsg+0x46/0x60 [<c0a66f40>] ? unix_set_peek_off+0x50/0x50 [...

...drm] ? drm_setversion+0x7f0/0x7f0 [drm] ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x34/0x70 drm_ioctl+0x445/0x950 [drm] ? drm_mode_getcrtc+0x790/0x790 [drm] ? drm_getunique+0x220/0x220 [drm] ? expand_files.part.10+0x920/0x920 do_vfs_ioctl+0x1a1/0x13d0 ? ioctl_preallocate+0x2b0/0x2b0 ? __fget_light+0x2d6/0x390 ? schedule+0xd7/0x2e0 ? fget_raw+0x10/0x10 ? apic_timer_interrupt+0xa/0x20 ? apic_timer_interrupt+0xa/0x20 ? rcu_cleanup_dead_rnp+0x2c0/0x2c0 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x6f/0xb0 do_syscall_64+0x136/0x440 ? syscall_return_slowpath+0x2d0/0x2d0 ? do_page_fault+0x89/0x3...

...? __switch_to_asm+0x34/0x70 > > drm_ioctl+0x445/0x950 [drm] > > ? drm_mode_getcrtc+0x790/0x790 [drm] > > ? drm_getunique+0x220/0x220 [drm] > > ? expand_files.part.10+0x920/0x920 > > do_vfs_ioctl+0x1a1/0x13d0 > > ? ioctl_preallocate+0x2b0/0x2b0 > > ? __fget_light+0x2d6/0x390 > > ? schedule+0xd7/0x2e0 > > ? fget_raw+0x10/0x10 > > ? apic_timer_interrupt+0xa/0x20 > > ? apic_timer_interrupt+0xa/0x20 > > ? rcu_cleanup_dead_rnp+0x2c0/0x2c0 > > ksys_ioctl+0x60/0x90 > > __x64_sys_ioctl+0x6f/0xb0 > > do_syscall...

This fixes the extra issues I discovered upstream after the introduction of my rework of the atomic VCPI helpers that occur during suspend/resume. This time around, we use a slightly different but much less complicated approach for fixing said issues. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (4): drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

This fixes the extra issues I discovered upstream after the introduction of my rework of the atomic VCPI helpers that occur during suspend/resume. This time around, we use a slightly different but much less complicated approach for fixing said issues. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (4): drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

Hello I recently switched from Nvidia binary driver to Nouveau. I have encountered a possible bug in the kernel module. Before I file a bug report I would like to know if this is a known issue or not. I believe it is related to sleep state and power management of the driver. The Bug: When the computer is left on it's own to go to a power save mode X takes 100% CPU-time in its thread. A

The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called while nouveau was runtime suspended, a deadlock would occur due to nouveau_fbcon_set_suspend also trying to obtain console_lock(). Fix this by delaying the drm_fb_helper_set_suspend call. Based on the i915 code (which was done for performance reasons though). Cc: Chris Wilson <chris at chris-wilson.co.uk> Cc: Daniel