Bug 75144 - [SNB Regression]igt/gem_render_linear_blits causes OOM killer
Summary: [SNB Regression]igt/gem_render_linear_blits causes OOM killer
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: high major
Assignee: Rodrigo Vivi
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on: 72742
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-18 08:21 UTC by lu hua
Modified: 2017-10-06 14:39 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg (96.22 KB, text/plain)
2014-02-18 08:21 UTC, lu hua
no flags Details

Description lu hua 2014-02-18 08:21:00 UTC
Created attachment 94269 [details]
dmesg

System Environment:
--------------------------
Platform: Sandybridge
kernel:   (drm-intel-nightly)1be8f2b4dd6d3db00af24d4891c82d2650bd282d

Bug detailed description:
---------------------------
run ./gem_render_linear_blits, It causes OOM killer. It happens on Sandybridge with -queued and -nightly kernel.

TThe latest known good commit: c461562e84d180fb691af57f93a42bd9cc7eb69c
The latest known bad commit:  4c0e552882114d1edb588242d45035246ab078a0

output:
IGT-Version: 1.5-g9597836 (i686) (Linux: 3.13.0_drm-intel-next-queued_4c0e55_20140218+ i686)
Using 3072 1MiB buffers
Verifying initialisation...
Cyclic blits, forward...
Killed

[  305.969567] Call Trace:
[  305.969584]  [<c08910a9>] ? dump_stack+0x3e/0x4e
[  305.969609]  [<c088dc1c>] ? dump_header.isra.10+0x53/0x15e
[  305.969637]  [<c028e60f>] ? oom_kill_process+0x6e/0x299
[  305.969663]  [<c0290e1e>] ? get_page_from_freelist+0x3a5/0x3d6
[  305.969692]  [<c045b6a8>] ? security_capable_noaudit+0xc/0xf
[  305.969720]  [<c028eb3b>] ? out_of_memory+0x1c3/0x1f0
[  305.969746]  [<c029137b>] ? __alloc_pages_nodemask+0x52c/0x620
[  305.969775]  [<c02ac3a1>] ? read_swap_cache_async+0x50/0xe6
[  305.969802]  [<c02ac497>] ? swapin_readahead+0x60/0x95
[  305.969830]  [<c0299741>] ? shmem_getpage_gfp+0x17e/0x563
[  305.969858]  [<c0486f8d>] ? __sg_free_table+0x45/0x5c
[  305.969883]  [<c0299bcf>] ? shmem_read_mapping_page_gfp+0x1f/0x39
[  305.969922]  [<f818d097>] ? i915_gem_object_get_pages_gtt+0x10c/0x2a4 [i915]
[  305.969961]  [<f8189e3d>] ? i915_gem_object_get_pages+0x53/0x79 [i915]
[  305.969997]  [<f818ca26>] ? i915_gem_object_pin+0x20b/0x4aa [i915]
[  305.970031]  [<f81907ba>] ? i915_gem_execbuffer_reserve_vma.isra.13+0x6a/0x11d [i915]
[  305.970072]  [<f8190a4d>] ? i915_gem_execbuffer_reserve+0x1e0/0x24f [i915]
[  305.970109]  [<f8191002>] ? i915_gem_do_execbuffer.isra.15+0x546/0xe83 [i915]
[  305.970143]  [<c02b4421>] ? __kmalloc+0x82/0xda
[  305.970170]  [<f8191e83>] ? i915_gem_execbuffer2+0x119/0x1aa [i915]
[  305.970204]  [<f8191d6a>] ? i915_gem_execbuffer+0x42b/0x42b [i915]
[  305.970236]  [<f80847ce>] ? drm_ioctl+0x222/0x30c [drm]
[  305.970266]  [<f8191d6a>] ? i915_gem_execbuffer+0x42b/0x42b [i915]
[  305.970298]  [<c02403dc>] ? hrtimer_forward+0xfe/0x125
[  305.970326]  [<f80845ac>] ? drm_core_reclaim_buffers+0x52/0x52 [drm]
[  305.970357]  [<c02c3cb1>] ? do_vfs_ioctl+0x3f6/0x43d
[  305.970381]  [<c0265cff>] ? clockevents_program_event+0xe6/0x107
[  305.970410]  [<c0266d58>] ? tick_program_event+0x1c/0x1f
[  305.970436]  [<c02408db>] ? hrtimer_interrupt+0x12d/0x1e7
[  305.970463]  [<c02c3d41>] ? SyS_ioctl+0x49/0x74
[  305.970489]  [<c0899cfa>] ? sysenter_do_call+0x12/0x22
[  305.970515] Mem-Info:
[  305.970526] DMA per-cpu:
[  305.970540] CPU    0: hi:    0, btch:   1 usd:   0
[  305.970563] CPU    1: hi:    0, btch:   1 usd:   0
[  305.970587] CPU    2: hi:    0, btch:   1 usd:   0
[  305.970609] CPU    3: hi:    0, btch:   1 usd:   0
[  305.970632] CPU    4: hi:    0, btch:   1 usd:   0
[  305.970655] CPU    5: hi:    0, btch:   1 usd:   0
[  305.970677] CPU    6: hi:    0, btch:   1 usd:   0
[  305.970700] CPU    7: hi:    0, btch:   1 usd:   0

Reproduce steps:
---------------------------- 
1. ./gem_render_linear_blits
Comment 1 Guang Yang 2014-05-17 01:17:37 UTC
Rodrigo, any update on this issue? 
Hua, can you help to retest this issue.
Comment 2 Daniel Vetter 2014-05-19 09:04:59 UTC
Sounds like a dupe of the filp leak ... Please retest and reopen if it still
happens.

Also we'd need the bisect result here ...
Comment 3 Daniel Vetter 2014-05-19 09:09:39 UTC
Nevermind, got lost. But we need the bisect here.
Comment 4 Chris Wilson 2014-05-20 08:58:04 UTC
commit ceabbba524fb43989875f66a6c06d7ce0410fe5c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Mar 25 13:23:04 2014 +0000

    drm/i915: Include bound and active pages in the count of shrinkable objects
    
    When the machine is under a lot of memory pressure and being stressed by
    multiple GPU threads, we quite often report fewer than shrinker->batch
    (i.e. SHRINK_BATCH) pages to be freed. This causes the shrink_control to
    skip calling into i915.ko to release pages, despite the GPU holding onto
    most of the physical pages in its active lists.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=72742
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Robert Beckett <robert.beckett@intel.com>
    Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 5 lu hua 2014-05-21 08:23:21 UTC
Test on latest -nightly kernel. It works well.
Comment 6 Elizabeth 2017-10-06 14:39:52 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.