Re: [PATCH 0/8] drm/i915/pciids: PCI ID macro cleanups

[Dave Hansen]

On 5/15/24 07:25, Jani Nikula wrote:
> No reply from Bjorn, Cc: the x86 maintainers and list, could I get an
> ack from you please?

x86 is just a consumer of the drm/i915_pciids.h macros.  The name change
is perfectly fine with me.  No objections.  But I really don't think you
need our acks to move forward.

Either way:

Acked-by: Dave Hansen  # for x86

Re: [Intel-gfx] [PATCH v2] x86/mm: Fix PAT bit missing from page protection modify mask

[Dave Hansen]

On 6/7/23 08:23, Janusz Krzysztofik wrote:
> 
> Extend bitmask used by pgprot_modify() for selecting bits to be preserved
> with _PAGE_PAT bit.  However, since that bit can be reused as _PAGE_PSE,
> and the _PAGE_CHG_MASK symbol, primarly used by pte_modify(), is likely
> intentionally defined with that bit not set, keep that symbol unchanged.

I'm really having a hard time parsing what that last sentence is saying.

Could you try again, please?

Re: [Intel-gfx] [PATCH RFC v2] mm: Add f_ops->populate()

[Dave Hansen]

On 3/7/22 03:27, Jarkko Sakkinen wrote:
> But e.g. in __mm_populate() anything with (VM_IO | VM_PFNMAP) gets
> filtered out and never reach that function.
> 
> I don't know unorthodox that'd be but could we perhaps have a VM
> flag for SGX?

SGX only works on a subset of the chips from one vendor on one
architecture.  That doesn't seem worth burning a VM flag.

Re: [Intel-gfx] [PATCH RFC v2] mm: Add f_ops->populate()

[Dave Hansen]

On 3/6/22 15:24, Andrew Morton wrote:
> On Sun,  6 Mar 2022 05:26:55 +0200 Jarkko Sakkinen  wrote:
> 
>> Sometimes you might want to use MAP_POPULATE to ask a device driver to
>> initialize the device memory in some specific manner. SGX driver can use
>> this to request more memory by issuing ENCLS[EAUG] x86 opcode for each
>> page in the address range.
> Why is this useful?  Please fully describe the benefit to kernel users.
> Convince us that the benefit justifies the code churn, maintenance
> cost and larger kernel footprint.

In short: page faults stink.  The core kernel has lots of ways of
avoiding page faults like madvise(MADV_WILLNEED) or mmap(MAP_POPULATE).
 But, those only work on normal RAM that the core mm manages.

SGX is weird.  SGX memory is managed outside the core mm.  It doesn't
have a 'struct page' and get_user_pages() doesn't work on it.  Its VMAs
are marked with VM_IO.  So, none of the existing methods for avoiding
page faults work on SGX memory.

This essentially helps extend existing "normal RAM" kernel ABIs to work
for avoiding faults for SGX too.  SGX users want to enjoy all of the
benefits of a delayed allocation policy (better resource use,
overcommit, NUMA affinity) but without the cost of millions of faults.

That said, this isn't how I would have implemented it.  I probably would
have hooked in to populate_vma_page_range() or its callers.

Re: [Intel-gfx] [v3 1/3] drm/i915/rpl-s: Add PCI IDS for Raptor Lake S

[Dave Hansen]

On 12/2/21 10:35 PM, Anusha Srivatsa wrote:
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index 391a4e2b8604..fd2d3ab38ebb 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -554,6 +554,7 @@ static const struct pci_device_id intel_early_ids[] 
> __initconst = {
>   INTEL_RKL_IDS(_early_ops),
>   INTEL_ADLS_IDS(_early_ops),
>   INTEL_ADLP_IDS(_early_ops),
> + INTEL_RPLS_IDS(_early_ops),
>  };

For arch/x86 purposes:

Acked-by: Dave Hansen 

Re: [Intel-gfx] [PATCH 0/2] Nuke PAGE_KERNEL_IO

[Dave Hansen]

On 11/12/21 12:09 PM, Lucas De Marchi wrote:
> The intention was to merge this through the tip tree. Although now I'm
> not sure. Options:
> 
> 1) take the first patch through the drm-intel tree and apply the
>    second patch later
> 2) take everything through the drm tree
> 3) take everything through the tip tree
> 
> What's your preference here?

It's fine with me to take it through tip unless that causes a problem
for anyone.  I was planning on doing queuing it after -rc1.

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

[Dave Hansen]

On 10/12/20 9:19 AM, Eric Biggers wrote:
> On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
>>> And I still don't really understand.  After this patchset, there is still 
>>> code
>>> nearly identical to the above (doing a temporary mapping just for a memcpy) 
>>> that
>>> would still be using kmap_atomic().
>> I don't understand.  You mean there would be other call sites calling:
>>
>> kmap_atomic()
>> memcpy()
>> kunmap_atomic()
> Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
> and look for memcpy().
> 
> Hence why I'm asking what will be the "recommended" way to do this...
> kunmap_thread() or kmap_atomic()?

kmap_atomic() is always preferred over kmap()/kmap_thread().
kmap_atomic() is _much_ more lightweight since its TLB invalidation is
always CPU-local and never broadcast.

So, basically, unless you *must* sleep while the mapping is in place,
kmap_atomic() is preferred.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7] mm, drm/i915: mark pinned shmemfs pages as unevictable

[Dave Hansen]

On 11/6/18 5:23 AM, Chris Wilson wrote:
> + (3) By the i915 driver to mark pinned address space until it's unpinned. The
> + amount of unevictable memory marked by i915 driver is roughly the 
> bounded
> + object size in debugfs/dri/0/i915_gem_objects.

Thanks for adding this.  Feel free to add my:

Acked-by: Dave Hansen 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] mm, drm/i915: mark pinned shmemfs pages as unevictable

[Dave Hansen]

On 11/5/18 3:13 AM, Kuo-Hsin Yang wrote:
> -These are currently used in two places in the kernel:
> +These are currently used in three places in the kernel:
>  
>   (1) By ramfs to mark the address spaces of its inodes when they are created,
>   and this mark remains for the life of the inode.
> @@ -154,6 +154,8 @@ These are currently used in two places in the kernel:
>   swapped out; the application must touch the pages manually if it wants 
> to
>   ensure they're in memory.
>  
> + (3) By the i915 driver to mark pinned address space until it's unpinned.

At a minimum, I think we owe some documentation here of how to tell
approximately how much memory i915 is consuming with this mechanism.
The debugfs stuff sounds like a halfway reasonable way to approximate
it, although it's imperfect.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable

[Dave Hansen]

On 11/2/18 6:22 AM, Vovo Yang wrote:
> On Thu, Nov 1, 2018 at 10:30 PM Dave Hansen  wrote:
>> On 11/1/18 5:06 AM, Vovo Yang wrote:
>>>> mlock() and ramfs usage are pretty easy to track down.  /proc/$pid/smaps
>>>> or /proc/meminfo can show us mlock() and good ol' 'df' and friends can
>>>> show us ramfs the extent of pinned memory.
>>>>
>>>> With these, if we see "Unevictable" in meminfo bump up, we at least have
>>>> a starting point to find the cause.
>>>>
>>>> Do we have an equivalent for i915?
> Chris helped to answer this question:
> Though it includes a few non-shmemfs objects, see
> debugfs/dri/0/i915_gem_objects and the "bound objects".
> 
> Example i915_gem_object output:
>   591 objects, 95449088 bytes
>   55 unbound objects, 1880064 bytes
>   533 bound objects, 93040640 bytes

Do those non-shmemfs objects show up on the unevictable list?  How far
can the amount of memory on the unevictable list and the amount
displayed in this "bound objects" value diverge?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable

[Dave Hansen]

On 11/1/18 5:06 AM, Vovo Yang wrote:
>> mlock() and ramfs usage are pretty easy to track down.  /proc/$pid/smaps
>> or /proc/meminfo can show us mlock() and good ol' 'df' and friends can
>> show us ramfs the extent of pinned memory.
>>
>> With these, if we see "Unevictable" in meminfo bump up, we at least have
>> a starting point to find the cause.
>>
>> Do we have an equivalent for i915?
> AFAIK, there is no way to get i915 unevictable page count, some
> modification to i915 debugfs is required.

Is something like this feasible to add to this patch set before it gets
merged?  For now, it's probably easy to tell if i915 is at fault because
if the unevictable memory isn't from mlock or ramfs, it must be i915.

But, if we leave it as-is, it'll just defer the issue to the fourth user
of the unevictable list, who will have to come back and add some
debugging for this.

Seems prudent to just do it now.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable

[Dave Hansen]

On 10/31/18 7:24 AM, Michal Hocko wrote:
> I am also wondering whether unevictable pages culling can be
> really visible when we do the anon LRU reclaim because the swap path is
> quite expensinve on its own.

Didn't we create the unevictable lists in the first place because
scanning alone was observed to be so expensive in some scenarios?

Or am I misunderstanding your question.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable

[Dave Hansen]

On 10/31/18 1:19 AM, owner-linux...@kvack.org wrote:
> -These are currently used in two places in the kernel:
> +These are currently used in three places in the kernel:
>  
>   (1) By ramfs to mark the address spaces of its inodes when they are created,
>   and this mark remains for the life of the inode.
> @@ -154,6 +154,8 @@ These are currently used in two places in the kernel:
>   swapped out; the application must touch the pages manually if it wants 
> to
>   ensure they're in memory.
>  
> + (3) By the i915 driver to mark pinned address space until it's unpinned.

mlock() and ramfs usage are pretty easy to track down.  /proc/$pid/smaps
or /proc/meminfo can show us mlock() and good ol' 'df' and friends can
show us ramfs the extent of pinned memory.

With these, if we see "Unevictable" in meminfo bump up, we at least have
a starting point to find the cause.

Do we have an equivalent for i915?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] mm, drm/i915: Mark pinned shmemfs pages as unevictable

[Dave Hansen]

On 06/06/2017 05:34 AM, Chris Wilson wrote:
> With respect to i915, we may not be the sole owner of the page at the
> point where we call shmem_read_mapping_page_gfp() as it can mmapped or
> accessed directly via the mapping internally. It is just at this point
> we know that the page will not be returned to the system until we have
> finished using it with the GPU.
> 
> An API that didn't assume the page was locked or require exclusive
> ownership would be needed for random driver usage like i915.ko

Why do you think exclusive ownership is required, btw?  What does
exclusive ownership mean, anyway?  page_count()==1 and you old the old
reference?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] mm, drm/i915: Mark pinned shmemfs pages as unevictable

[Dave Hansen]

On 06/06/2017 05:14 AM, Michal Hocko wrote:
> On Tue 06-06-17 13:04:36, Chris Wilson wrote:
>> Similar in principle to the treatment of get_user_pages, pages that
>> i915.ko acquires from shmemfs are not immediately reclaimable and so
>> should be excluded from the mm accounting and vmscan until they have
>> been returned to the system via shrink_slab/i915_gem_shrink. By moving
>> the unreclaimable pages off the inactive anon lru, not only should
>> vmscan be improved by avoiding walking unreclaimable pages, but the
>> system should also have a better idea of how much memory it can reclaim
>> at that moment in time.
> That is certainly desirable. Peter has proposed a generic pin_page (or
> similar) API. What happened with it? I think it would be a better
> approach than (ab)using mlock API. I am also not familiar with the i915
> code to be sure that using lock_page is really safe here. I think that
> all we need is to simply move those pages in/out to/from unevictable LRU
> list on pin/unpining.

Yes, very true.  I just suggested mlock'ing them because it was the
simplest way to get page_evictable() to return true.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Don't race connector registration

[Dave Hansen]

On 02/01/2017 12:52 AM, Daniel Vetter wrote:
> On Tue, Jan 31, 2017 at 04:27:14PM -0800, Dave Hansen wrote:
>> I added some printk()s all over and gathered a bit more information
>> about what's going on.  It looks like the display doesn't work until the
>> drm connector code cleans up the *old* connector.  For some reason, it
>> isn't motivated to do that until I go to the console and back.
>>
>> In this case, the display was connected to DP-4.
>> intel_dp_destroy_mst_connector() got called on it when I switched away,
>> but drm_connector_cleanup() did not get called.  Upon switching back
>> DP-3/5/6 get created.  One of these *eventually* ends up being
>> "enabled", but is not now.  When I switch over to the console,
>> drm_connector_cleanup() finally gets called on the old connector: DP-4
>> and I can switch back to X and I see one of DP-3/5/6 enabled and working.
>>
>> Here are some snippets of dmesg interspersed with what I was doing:
> 
> Ok, so the delayed deleting seems to be involved in the bug (and we only
> do that since we recently introduced refcounting for hotplugged
> connectors). The question is who's getting confused, either kernel or X.
> To figure this out, next time things are out of sync, please compare the
> output of
> 
> $ xrandr
> 
> with what's reported in /sys/class/drm/*/status:
> 
> $ grep . /sys/class/drm/card0-DP-*/status

OK, I collected that 4 times:
1. When everything is OK
2. When the DVI is unplugged
3. When the DVI is re-plugged (no output)
4. After I press Ctrl-Alt-F2 (back to OK)

The good vs. bad diff looks like this:

--- xdebug.1485980540.start.log 2017-02-01 12:22:20.328242293 -0800
+++ xdebug.1485980621.dvi-replugged.log 2017-02-01 12:23:41.964241982 -0800
@@ -25,15 +25,6 @@
 DP2-1 disconnected (normal left inverted right x axis y axis)
 DP2-2 connected primary 1920x1200+0+0 (normal left inverted right x
axis y axis) 518mm x 324mm
1920x1200  60.0*+
-   1920x1080  60.0
-   1600x1200  60.0
-   1680x1050  59.9
-   1280x1024  60.0
-   1280x960   60.0
-   1024x768   60.0
-   800x60060.3
-   640x48059.9
-   720x40070.1
 DP2-3 disconnected (normal left inverted right x axis y axis)
 HDMI1 disconnected (normal left inverted right x axis y axis)
 HDMI2 disconnected (normal left inverted right x axis y axis)
@@ -41,5 +32,5 @@
 /sys/class/drm/card0-DP-1/status:disconnected
 /sys/class/drm/card0-DP-2/status:disconnected
 /sys/class/drm/card0-DP-3/status:disconnected
-/sys/class/drm/card0-DP-5/status:connected
+/sys/class/drm/card0-DP-4/status:connected
 /sys/class/drm/card0-DP-6/status:disconnected

But it's very interesting that when I unplug the DVI, the xrandr output
does not change.  Only the /sys/class/drm/.../status does.

> Another question: What desktop are you using, and if you unplug a screen,
> does that general reconfigure the desktop size to disable that output? The
> zombie connector only sticks around as long as someone is still using it
> in the screen configuration. As soon as the reconfiguration has happened,
> it should go away. You can test this by manually disabling the output when
> it's stuck as on:
> 
> $ xrandr --output DP-4 --off

Yep, it does the delayed cleanup.  The output still shows up in xrandr
(as an 8x8 display) at this point, but it can at least be turned back on.

xrandr snippet:

Screen 0: minimum 8 x 8, current 8 x 8, maximum 32767 x 32767

So, if I do a pair of these:

xrandr --output DP-4 --off
xrandr --output DP-4 --auto

it does bring the display back consistently.
Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767
eDP1 connected (normal left inverted right x axis y axis)
   1920x1080  60.0 +   59.9  
   1680x1050  60.0 59.9  
   1600x1024  60.2  
   1400x1050  60.0  
   1600x900   60.0  
   1280x1024  60.0  
   1440x900   59.9  
   1280x960   60.0  
   1368x768   60.0  
   1360x768   59.8 60.0  
   1152x864   60.0  
   1280x720   60.0  
   1024x768   60.0  
   1024x576   60.0  
   960x54060.0  
   800x60060.3 56.2  
   864x48660.0  
   640x48059.9  
   720x40560.0  
   640x36060.0  
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP2-1 disconnected (normal left inverted right x axis y axis)
DP2-2 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200  60.0*+
   1920x1080  60.0  
   1600x1200  60.0  
   1680x1050  59.9  
   1280x1024  60.0  
   1280x960   60.0  
   1024x768   60.0  
   800x60060.3  
   640x48059.9  
   720x40070.1  
DP2-3 disconnected (normal left inverted right x axis y axis)
H

Re: [Intel-gfx] [PATCH] drm: Don't race connector registration

[Dave Hansen]

I added some printk()s all over and gathered a bit more information
about what's going on.  It looks like the display doesn't work until the
drm connector code cleans up the *old* connector.  For some reason, it
isn't motivated to do that until I go to the console and back.

In this case, the display was connected to DP-4.
intel_dp_destroy_mst_connector() got called on it when I switched away,
but drm_connector_cleanup() did not get called.  Upon switching back
DP-3/5/6 get created.  One of these *eventually* ends up being
"enabled", but is not now.  When I switch over to the console,
drm_connector_cleanup() finally gets called on the old connector: DP-4
and I can switch back to X and I see one of DP-3/5/6 enabled and working.

Here are some snippets of dmesg interspersed with what I was doing:

Push DVI switch button to switch to other system:

> [ 6824.562838] drm_dp_destroy_port() kfree(8801ade46800)
> [ 6824.563164] drm_dp_destroy_connector_work() port: 8801ade42000 
> connector: 8801ade46000
> [ 6824.563178] intel_dp_destroy_mst_connector() connector: 8801ade46000 
> name: DP-3 : 8801ade46048 intel_connector: 8801ade46000
> [ 6824.563186] drm_sysfs_connector_remove() connector: 8801ade46000 kdev: 
> 8801a941b400
> [ 6824.571556] drm_connector_cleanup(8801ade46000)::329 
> connector->registered: 0 cpu: 3
> [ 6824.571570] drm_connector_cleanup() kfree() connector->name: 'DP-3' : 
> 8801ade46048
> [ 6824.571581] drm_dp_free_mst_port() kfree port: 8801ade42000
> [ 6824.571587] drm_dp_destroy_connector_work() port: 8801ade42800 
> connector: 8801ade47000
> [ 6824.571594] intel_dp_destroy_mst_connector() connector: 8801ade47000 
> name: DP-4 : 8801ade47048 intel_connector: 8801ade47000
> [ 6824.571601] drm_sysfs_connector_remove() connector: 8801ade47000 kdev: 
> 8801a941a000
> [ 6824.571915] drm_dp_free_mst_port() kfree port: 8801ade42800
> [ 6824.571925] drm_dp_destroy_connector_work() port: 8801ade40800 
> connector: 8801ade43000
> [ 6824.571934] intel_dp_destroy_mst_connector() connector: 8801ade43000 
> name: DP-6 : 8801ade43048 intel_connector: 8801ade43000
> [ 6824.571943] drm_sysfs_connector_remove() connector: 8801ade43000 kdev: 
> 8801a9419800
> [ 6824.572091] drm_connector_cleanup(8801ade43000)::329 
> connector->registered: 0 cpu: 3
> [ 6824.572101] drm_connector_cleanup() kfree() connector->name: 'DP-6' : 
> 8801ade43048
> [ 6824.572110] drm_dp_free_mst_branch_device() kfree mstb: 88030ac22600
> [ 6824.572117] drm_dp_free_mst_port() kfree port: 8801ade40800

Push button to switch back:

> [ 6837.349693] drm_connector_init() connector->name: 'DP-3' : 
> 88040231d848
> [ 6837.349894] drm_sysfs_connector_add() connector: 88040231d800 kdev: 
> 8801ae99f400
> [ 6837.352786] drm_connector_init() connector->name: 'DP-5' : 
> 880402318048
> [ 6837.352951] drm_sysfs_connector_add() connector: 880402318000 kdev: 
> 8801ae99c000
> [ 6837.353036] drm_connector_init() connector->name: 'DP-6' : 
> 88040d37f048
> [ 6837.353154] drm_sysfs_connector_add() connector: 88040d37f000 kdev: 
> 8801ae99ec00

I can type into the X session, but both screens are blank.  When I press
Ctrl-Alt-F2, I get:

> [ 6850.494310] drm_connector_cleanup(8801ade47000)::329 
> connector->registered: 0 cpu: 1
> [ 6850.494314] drm_connector_cleanup() kfree() connector->name: 'DP-4' : 
> 8801ade47048

Now I can switch back to X and everything is OK again.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Don't race connector registration

[Dave Hansen]

On 01/30/2017 01:12 AM, Daniel Vetter wrote:
> On Thu, Jan 26, 2017 at 12:34:29PM -0800, Dave Hansen wrote:
...
>> And, yeah, I think it just gets the connected status wrong.  The
>> connector is still there.
> 
> Hm, I thought I replied here but I didn't:
> - Is this just after boot (and then the connector is stuck forever), or
>   starts to happen after suspend/resume, or some other system change like
>   that? Or do they just crop up eventually?

The most consistent thing I do to screw it up is switch systems on my
DVI KVM switch.  When I switch back to the system in question, it
doesn't seem to notice the condition.  The connectors eventually show up
with random combinations of switching to the console (ctrl-alt-f1) and
back, running xrandr, or running gnome-control-panel and opening the
Displays applet.

I haven't been able to discern any pattern to it.  Sometimes just
running xrandr fixes it.  Sometimes just opening the control panel.
Others, I have to do it several times.

I don't think it shows up if I just leave it for a while.

> - Does this only happen once the connector is destroyed? Please trace
>   intel_dp_destroy_mst_connector with something like:

I'll see if I can gather that.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Don't race connector registration

[Dave Hansen]

On 01/25/2017 07:38 AM, Daniel Vetter wrote:
> On Wed, Jan 25, 2017 at 07:20:45AM -0800, Dave Hansen wrote:
>> On 01/24/2017 10:21 PM, Daniel Vetter wrote:
>>> Hi Dave,
>>>
>>> Still waiting for your testing results on this one here ...
>>
>> It's definitely stable with that patch applied.  No more crashes.
>>
>> But, it's also definitely having difficulty re-probing to find the
>> monitor that's attached to the dock in some cases.  Whatever is going on
>> isn't fixed by poking it with xrandr.
> 
> Is this new? When exactly does this happen? Does the mst sink connector no
> longer show up, or is the connected/disconnected status all wrong?

It's hard to say whether it's new or not.  I *think* it worked better
before, but it also crashed pretty often, so it's hard to say.

And, yeah, I think it just gets the connected status wrong.  The
connector is still there.




___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Don't race connector registration

[Dave Hansen]

On 01/24/2017 10:21 PM, Daniel Vetter wrote:
> Hi Dave,
> 
> Still waiting for your testing results on this one here ...

It's definitely stable with that patch applied.  No more crashes.

But, it's also definitely having difficulty re-probing to find the
monitor that's attached to the dock in some cases.  Whatever is going on
isn't fixed by poking it with xrandr.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

[Dave Hansen]

On 01/11/2017 07:39 AM, Daniel Vetter wrote:
> Hm, just cherry-picked it on top of Linus' latest 4.10 git, applies
> cleanly there. The substituation was for 4.9. I can send you the patch
> here, but seems all fine from what I can tell ...

All of the printk's that I added were making it fail to apply.

So, I took a 4.10-rc3 kernel with i915 compiled in (not as a module) and
applied e73ab00e9a0f17, which I grabbed from linux-next.

I'm seeing basically the same behavior that I did before applying
e73ab00e9a0f17.  sysfs_create_dir_ns() fails because of a NULL kobj->parent.

Have you guys tried testing this yourselves?  It seems really easy to
reproduce if you just compile the driver in.

> [1.400797] drm_dev_register(88040c73)::730 cpu: 2
> [1.400860] drm_connector_register(88040c76b000)::382 
> connector->registered: 0 cpu: 1
> [1.400870] sysfs_create_dir_ns()::53 error: -2
> [1.400874] create_dir()::75 error: -2 cpu: 1
> [1.400878] [ cut here ]
> [1.400884] WARNING: CPU: 1 PID: 91 at lib/kobject.c:249 
> kobject_add_internal+0x273/0x330
> [1.400888] kobject_add_internal failed for card0-DP-3 (error: -2 parent: 
> card0)
> [1.400892] Modules linked in:
> [1.400896] CPU: 1 PID: 91 Comm: kworker/1:2 Not tainted 
> 4.10.0-rc3-i915borked-dirty #67
> [1.400900] Hardware name: LENOVO 20F5S7V800/20F5S7V800, BIOS R02ET50W 
> (1.23 ) 09/20/2016
> [1.400906] Workqueue: events_long drm_dp_mst_link_probe_work
> [1.400909] Call Trace:
> [1.400914]  dump_stack+0x67/0x99
> [1.400918]  __warn+0xd1/0xf0
> [1.400922]  warn_slowpath_fmt+0x4f/0x60
> [1.400925]  kobject_add_internal+0x273/0x330
> [1.400927]  kobject_add+0x65/0xb0
> [1.400931]  ? klist_init+0x31/0x40
> [1.400936]  device_add+0x102/0x5d0
> [1.400940]  ? kfree_const+0x22/0x30
> [1.400944]  device_create_groups_vargs+0xd8/0x100
> [1.400947]  device_create_with_groups+0x36/0x40
> [1.400952]  ? vprintk_default+0x29/0x50
> [1.400957]  ? __might_sleep+0x4a/0x90
> [1.400962]  drm_sysfs_connector_add+0x60/0xe0
> [1.400967]  drm_connector_register+0x74/0xd0
> [1.400971]  intel_dp_register_mst_connector+0x41/0x50
> [1.400975]  drm_dp_add_port+0x350/0x450
> [1.400977] drm_connector_register(88040ee6f800)::382 
> connector->registered: 0 cpu: 2
> [1.400982]  ? rcu_early_boot_tests+0x1/0x10
> [1.400986]  ? schedule_timeout+0x1cd/0x390
> [1.400989]  ? __might_sleep+0x4a/0x90
> [1.400992]  ? mutex_lock+0x25/0x50
> [1.400995]  ? drm_dp_mst_wait_tx_reply+0x118/0x1e0
> [1.400996] drm_sysfs_connector_add() connector: 88040ee6f800 kdev: 
> 88040eef9c00
> [1.401002]  ? prepare_to_wait_event+0x120/0x120
> [1.401005]  ? drm_dp_check_mstb_guid+0x3d/0x120
> [1.401008]  drm_dp_send_link_address+0x185/0x1f0
> [1.401012]  drm_dp_check_and_send_link_address+0xad/0xc0
> [1.401015]  drm_dp_mst_link_probe_work+0x57/0xa0
> [1.401018]  process_one_work+0x14b/0x430
> [1.401021]  worker_thread+0x12b/0x4a0
> [1.401025]  kthread+0x10c/0x140
> [1.401027]  ? process_one_work+0x430/0x430
> [1.401030]  ? kthread_create_on_node+0x40/0x40
> [1.401034]  ret_from_fork+0x27/0x40
> [1.401038] ---[ end trace ba43fc250fbf282d ]---
> [1.401041] drm_sysfs_connector_add() connector: 88040c76b000 kdev: 
> fffe
> [1.401043] drm_connector_register(88040c768000)::382 
> connector->registered: 0 cpu: 2
> [1.401050] [drm:drm_sysfs_connector_add] *ERROR* failed to register 
> connector device: -2
> [1.401057] drm_sysfs_connector_add() connector: 88040c768000 kdev: 
> 88040eefa000
> [1.401093] drm_connector_register(88040c768800)::382 
> connector->registered: 0 cpu: 2
> [1.401113] drm_sysfs_connector_add() connector: 88040c768800 kdev: 
> 88040eefa400
> [1.401122] drm_connector_register(88040c769000)::382 
> connector->registered: 0 cpu: 2
> [1.401140] drm_sysfs_connector_add() connector: 88040c769000 kdev: 
> 88040eefa800
> [1.401167] drm_connector_register(88040c769800)::382 
> connector->registered: 0 cpu: 2
> [1.401186] drm_sysfs_connector_add() connector: 88040c769800 kdev: 
> 88040eefac00
> [1.401195] drm_connector_register(88040c76b000)::382 
> connector->registered: 0 cpu: 2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

[Dave Hansen]

On 01/10/2017 11:43 PM, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote:
>> On 01/10/2017 02:31 AM, Daniel Vetter wrote:
>>> commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e
>>> Author: Daniel Vetter <daniel.vet...@ffwll.ch>
>>> Date:   Sun Dec 18 14:35:45 2016 +0100
>>>
>>> drm: prevent double-(un)registration for connectors
>>>
>>> Lack of that would perfectly explain that oops ... Otherwise still no idea
>>> what's going wrong.
>> No...  That's not in mainline as far as I can see.  Should I test with
>> it applied?
> Hm, I guess failed to cc: stable that one properly, iirc we decided the
> race fix is too academic and can't be hit in reality ;-)
> 
> Testing would be great. Probably conflicts because we extracted
> drm_connector.c only recently, but running s/drm_connector\.c/drm_crtc.c/
> over the diff and then applying with some fudge should take care of that.

It doesn't apply to mainline, with or without the substitution you suggest.

Do you want that commit itself tested from -next?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

[Dave Hansen]

On 01/10/2017 02:31 AM, Daniel Vetter wrote:
> commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e
> Author: Daniel Vetter 
> Date:   Sun Dec 18 14:35:45 2016 +0100
> 
> drm: prevent double-(un)registration for connectors
> 
> Lack of that would perfectly explain that oops ... Otherwise still no idea
> what's going wrong.

No...  That's not in mainline as far as I can see.  Should I test with
it applied?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

[Dave Hansen]

On 01/09/2017 08:59 AM, Daniel Vetter wrote:
> On Mon, Jan 9, 2017 at 5:50 PM, Dave Hansen <dave.han...@intel.com> wrote:
>> On 01/09/2017 08:41 AM, Daniel Vetter wrote:
>>> On Mon, Jan 9, 2017 at 2:40 PM, Dave Hansen <dave.han...@intel.com> wrote:
>>>> Well, now I found where the -2 comes from.
>>>> intel_dp_register_mst_connector() calls drm_connector_register(), which
>>>> fails to add the kobject (warning below).  But, it does zero error
>>>> checking on the drm_connector_register() call and leaves the
>>>> partially-constructed connector in place.
>>>>
>>>> The next time some poor, hapless code goes and tries to do anything with
>>>> that kdev, they oops.  I'm perplexed by this, though.  The
>>>> drm_dp_mst_topology_cbs->register_connector just returns void.  It seems
>>>> a bit goofy that it can't even _return_ failure.
>>>>
>>>> Is there some stable code to go back to here?  Or, is there something
>>>> about my configuration that's unique?  I really wonder why nobody else
>>>> is running into this.
>>>>
>>>> There's probably some other race going on here.  This warning doesn't
>>>> happen on every boot.
>>> This smells more like the root-cause: Something goes wrong on boot
>>> that prevents connectors from properly registering, then we fall over
>>> later on. And the register callback is intentionally void, assuming
>>> that any prep work has been done earlier and that therefore the
>>> register step can't fail. Can you pls check whether the oops later on
>>> only happens together with this warning at boot, or whether they're
>>> not correlated?
>>
>> Looking through my logs, I can't find any instance of the oops without
>> the warning at boot.  So I do think the later oops is entirely caused by
>> the issue warned about in early boot.
> 
> Hm, I guess then we'd need to fix that boot-up warning. Can you try to
> figure out why it's unhappy? On a hunch it could be that we call
> drm_connector_register from the mst probe worker before the main
> driver load thread has reached the drm_dev_register call. A few printk
> to decide whether that's the case (plus a few boot-up tests to gather
> the statistics, sorry about that) would be real great.

I think your suspicion is correct.

The WARNING is getting printed from CPU0 (the
drm_dp_mst_link_probe_work() thread) and we can see the
drm_connector_register()s happening in parallel on CPU1 while the
WARNING is getting printed out.

This seems to happen very consistently when i915 is built into the kernel.

> [1.404237] drm_dev_register(02da)::209092608 cpu: 1
> [1.404284] drm_connector_register(88040ed3e800)::379 
> connector->registered: 0 cpu: 0
> [1.404293] sysfs_create_dir_ns()::53 error: -2
> [1.404295] create_dir()::75 error: -2 cpu: 0
> [1.404298] [ cut here ]
> [1.404304] WARNING: CPU: 0 PID: 3 at lib/kobject.c:249 
> kobject_add_internal+0x273/0x330
> [1.404308] kobject_add_internal failed for card0-DP-3 (error: -2 parent: 
> card0)
> [1.404311] Modules linked in:
> [1.404316] CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 
> 4.10.0-rc3-i915borked-dirty #66
> [1.404319] Hardware name: LENOVO 20F5S7V800/20F5S7V800, BIOS R02ET50W 
> (1.23 ) 09/20/2016
> [1.404325] Workqueue: events_long drm_dp_mst_link_probe_work
> [1.404328] Call Trace:
> [1.404334]  dump_stack+0x67/0x99
> [1.404338]  __warn+0xd1/0xf0
> [1.404342]  warn_slowpath_fmt+0x4f/0x60
> [1.404345]  kobject_add_internal+0x273/0x330
> [1.404347]  kobject_add+0x65/0xb0
> [1.404352]  ? klist_init+0x31/0x40
> [1.404356]  device_add+0x102/0x5d0
> [1.404360]  ? kfree_const+0x22/0x30
> [1.404364]  device_create_groups_vargs+0xd8/0x100
> [1.404367]  device_create_with_groups+0x36/0x40
> [1.404370] drm_connector_register(88040c779000)::379 
> connector->registered: 0 cpu: 1
> [1.404374]  ? vprintk_default+0x29/0x50
> [1.404375]  ? printk+0x4d/0x4f
> [1.404378]  drm_sysfs_connector_add+0x60/0xe0
> [1.404381]  drm_connector_register+0x4e/0x100
> [1.404383]  intel_dp_register_mst_connector+0x41/0x50
> [1.404385]  drm_dp_add_port+0x350/0x450
> [1.404388]  ? rcu_early_boot_tests+0x1/0x10
> [1.404390]  ? schedule_timeout+0x1cd/0x390
> [1.404392]  ? __might_sleep+0x4a/0x90
> [1.404394]  ? mutex_lock+0x25/0x50
> [1.404395]  ? drm_dp_mst_wait_tx_reply+0x118/0x1e0
> [1.404397]  ? prepare_to_wait_event+0x120/0x120
> [1.404399]  ? drm_dp_check_mstb_guid+0x3d/

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

[Dave Hansen]

On 01/09/2017 08:59 AM, Daniel Vetter wrote:
> On Mon, Jan 9, 2017 at 5:50 PM, Dave Hansen <dave.han...@intel.com> wrote:
>> On 01/09/2017 08:41 AM, Daniel Vetter wrote:
>>> On Mon, Jan 9, 2017 at 2:40 PM, Dave Hansen <dave.han...@intel.com> wrote:
>>>> Well, now I found where the -2 comes from.
>>>> intel_dp_register_mst_connector() calls drm_connector_register(), which
>>>> fails to add the kobject (warning below).  But, it does zero error
>>>> checking on the drm_connector_register() call and leaves the
>>>> partially-constructed connector in place.
>>>>
>>>> The next time some poor, hapless code goes and tries to do anything with
>>>> that kdev, they oops.  I'm perplexed by this, though.  The
>>>> drm_dp_mst_topology_cbs->register_connector just returns void.  It seems
>>>> a bit goofy that it can't even _return_ failure.
>>>>
>>>> Is there some stable code to go back to here?  Or, is there something
>>>> about my configuration that's unique?  I really wonder why nobody else
>>>> is running into this.
>>>>
>>>> There's probably some other race going on here.  This warning doesn't
>>>> happen on every boot.
>>> This smells more like the root-cause: Something goes wrong on boot
>>> that prevents connectors from properly registering, then we fall over
>>> later on. And the register callback is intentionally void, assuming
>>> that any prep work has been done earlier and that therefore the
>>> register step can't fail. Can you pls check whether the oops later on
>>> only happens together with this warning at boot, or whether they're
>>> not correlated?
>>
>> Looking through my logs, I can't find any instance of the oops without
>> the warning at boot.  So I do think the later oops is entirely caused by
>> the issue warned about in early boot.
> 
> Hm, I guess then we'd need to fix that boot-up warning. Can you try to
> figure out why it's unhappy? On a hunch it could be that we call
> drm_connector_register from the mst probe worker before the main
> driver load thread has reached the drm_dev_register call. A few printk
> to decide whether that's the case (plus a few boot-up tests to gather
> the statistics, sorry about that) would be real great.
> 
> If that's inconclusive I'm again a bit low on ideas ...

I'll do that shortly.  But, for now I can confirm that the failure is
precipitated by the !parent check in sysfs_create_dir_ns().

I also can't reproduce this if I build i915 as a module.  It only
happens when built in.

> Jan  9 09:07:34 ray kernel: [1.400547] sysfs_create_dir_ns()::53 error: -2
> Jan  9 09:07:34 ray kernel: [1.400554] create_dir()::75 error: -2
> Jan  9 09:07:34 ray kernel: [1.400558] [ cut here 
> ]
> Jan  9 09:07:34 ray kernel: [1.400565] WARNING: CPU: 1 PID: 90 at 
> lib/kobject.c:249 kobject_add_internal+0x273/0x320
> Jan  9 09:07:34 ray kernel: [1.400569] kobject_add_internal failed for 
> card0-DP-3 (error: -2 parent: card0)
> Jan  9 09:07:34 ray kernel: [1.400572] Modules linked in:
> Jan  9 09:07:34 ray kernel: [1.400577] CPU: 1 PID: 90 Comm: kworker/1:2 
> Not tainted 4.10.0-rc3-dirty #61
> Jan  9 09:07:34 ray kernel: [1.400579] Hardware name: LENOVO 
> 20F5S7V800/20F5S7V800, BIOS R02ET50W (1.23 ) 09/20/2016
> Jan  9 09:07:34 ray kernel: [1.400585] Workqueue: events_long 
> drm_dp_mst_link_probe_work
> Jan  9 09:07:34 ray kernel: [1.400588] Call Trace:
> Jan  9 09:07:34 ray kernel: [1.400593]  dump_stack+0x67/0x99
> Jan  9 09:07:34 ray kernel: [1.400598]  __warn+0xd1/0xf0
> Jan  9 09:07:34 ray kernel: [1.400601]  warn_slowpath_fmt+0x4f/0x60
> Jan  9 09:07:34 ray kernel: [1.400604]  kobject_add_internal+0x273/0x320
> Jan  9 09:07:34 ray kernel: [1.400607]  kobject_add+0x65/0xb0
> Jan  9 09:07:34 ray kernel: [1.400611]  ? klist_init+0x31/0x40
> Jan  9 09:07:34 ray kernel: [1.400615]  device_add+0x102/0x5d0
> Jan  9 09:07:34 ray kernel: [1.400619]  ? kfree_const+0x22/0x30
> Jan  9 09:07:34 ray kernel: [1.400623]  
> device_create_groups_vargs+0xd8/0x100
> Jan  9 09:07:34 ray kernel: [1.400626]  
> device_create_with_groups+0x36/0x40
> Jan  9 09:07:34 ray kernel: [1.400631]  ? 
> drm_fb_helper_add_one_connector+0x57/0xd0
> Jan  9 09:07:34 ray kernel: [1.400636]  ? 
> kmem_cache_alloc_trace+0x1d2/0x1f0
> Jan  9 09:07:34 ray kernel: [1.400641]  drm_sysfs_connector_add+0x60/0xe0
> Jan  9 09:07:34 ray kernel: [1.400645]  drm_connector_register+0x21/0xc0
> Jan  9 09:07:34 ray kernel: [1.400649]  
&

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

[Dave Hansen]

On 01/09/2017 08:41 AM, Daniel Vetter wrote:
> On Mon, Jan 9, 2017 at 2:40 PM, Dave Hansen <dave.han...@intel.com> wrote:
>> Well, now I found where the -2 comes from.
>> intel_dp_register_mst_connector() calls drm_connector_register(), which
>> fails to add the kobject (warning below).  But, it does zero error
>> checking on the drm_connector_register() call and leaves the
>> partially-constructed connector in place.
>>
>> The next time some poor, hapless code goes and tries to do anything with
>> that kdev, they oops.  I'm perplexed by this, though.  The
>> drm_dp_mst_topology_cbs->register_connector just returns void.  It seems
>> a bit goofy that it can't even _return_ failure.
>>
>> Is there some stable code to go back to here?  Or, is there something
>> about my configuration that's unique?  I really wonder why nobody else
>> is running into this.
>>
>> There's probably some other race going on here.  This warning doesn't
>> happen on every boot.
> This smells more like the root-cause: Something goes wrong on boot
> that prevents connectors from properly registering, then we fall over
> later on. And the register callback is intentionally void, assuming
> that any prep work has been done earlier and that therefore the
> register step can't fail. Can you pls check whether the oops later on
> only happens together with this warning at boot, or whether they're
> not correlated?

Looking through my logs, I can't find any instance of the oops without
the warning at boot.  So I do think the later oops is entirely caused by
the issue warned about in early boot.

My distro kernel (4.4.0-57-generic) is also unstable, but I haven't
managed to capture a good oops there.  It's hitting this, which I assume
is unrelated:

WARNING: CPU: 0 PID: 41 at /build/linux-lts-xenial-FdAdUy/linux-
lts-xenial-4.4.0/ubuntu/i915/intel_pm.c:3675
skl_update_other_pipe_wm+0x191/0x1a0 [i915_bpo]()

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

[Dave Hansen]

On 01/09/2017 05:40 AM, Dave Hansen wrote:
> Is there some stable code to go back to here?  Or, is there something
> about my configuration that's unique?  I really wonder why nobody else
> is running into this.

Here are a couple of similar-looking reports, if that helps:

https://bugzilla.redhat.com/attachment.cgi?id=1209947
https://bugzilla.redhat.com/show_bug.cgi?id=1382342
http://marc.info/?l=openbsd-bugs=147487082821348=2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

[Dave Hansen]

Well, now I found where the -2 comes from.
intel_dp_register_mst_connector() calls drm_connector_register(), which
fails to add the kobject (warning below).  But, it does zero error
checking on the drm_connector_register() call and leaves the
partially-constructed connector in place.

The next time some poor, hapless code goes and tries to do anything with
that kdev, they oops.  I'm perplexed by this, though.  The
drm_dp_mst_topology_cbs->register_connector just returns void.  It seems
a bit goofy that it can't even _return_ failure.

Is there some stable code to go back to here?  Or, is there something
about my configuration that's unique?  I really wonder why nobody else
is running into this.

There's probably some other race going on here.  This warning doesn't
happen on every boot.

> [1.396475] [ cut here ]
> [1.396486] WARNING: CPU: 0 PID: 91 at lib/kobject.c:244 
> kobject_add_internal+0x108/0x2d0
> [1.396492] kobject_add_internal failed for card0-DP-3 (error: -2 parent: 
> card0)
> [1.396496] Modules linked in:
> [1.396500] CPU: 0 PID: 91 Comm: kworker/0:2 Not tainted 4.10.0-rc2-dirty 
> #58
> [1.396503] Hardware name: LENOVO 20F5S7V800/20F5S7V800, BIOS R02ET50W 
> (1.23 ) 09/20/2016
> [1.396509] Workqueue: events_long drm_dp_mst_link_probe_work
> [1.396511] Call Trace:
> [1.396517]  dump_stack+0x67/0x99
> [1.396521]  __warn+0xd1/0xf0
> [1.396524]  warn_slowpath_fmt+0x4f/0x60
> [1.396527]  kobject_add_internal+0x108/0x2d0
> [1.396531]  ? vsnprintf+0x112/0x4b0
> [1.396533]  kobject_add+0x65/0xb0
> [1.396537]  ? klist_init+0x31/0x40
> [1.396542]  device_add+0x102/0x5d0
> [1.396546]  ? kfree_const+0x22/0x30
> [1.396549]  device_create_groups_vargs+0xd8/0x100
> [1.396553]  device_create_with_groups+0x36/0x40
> [1.396557]  ? drm_fb_helper_add_one_connector+0x57/0xd0
> [1.396561]  ? kmem_cache_alloc_trace+0x1d2/0x1f0
> [1.396566]  drm_sysfs_connector_add+0x60/0xe0
> [1.396570]  drm_connector_register+0x21/0xc0
> [1.396575]  intel_dp_register_mst_connector+0x41/0x50
> [1.396579]  drm_dp_add_port+0x350/0x450
> [1.396583]  ? rcu_early_boot_tests+0x1/0x10
> [1.396587]  ? schedule_timeout+0x1cd/0x390
> [1.396591]  ? __might_sleep+0x4a/0x90
> [1.396594]  ? mutex_lock+0x25/0x50
> [1.396597]  ? drm_dp_mst_wait_tx_reply+0x118/0x1e0
> [1.396600]  ? prepare_to_wait_event+0x120/0x120
> [1.396603]  ? drm_dp_check_mstb_guid+0x3d/0x120
> [1.396606] drm_sysfs_connector_add() connector: 88040ed3f000 kdev: 
> 88040c55dc00
> [1.396610]  drm_dp_send_link_address+0x185/0x1f0
> [1.396614]  drm_dp_check_and_send_link_address+0xad/0xc0
> [1.396617]  drm_dp_mst_link_probe_work+0x57/0xa0
> [1.396620]  process_one_work+0x14b/0x430
> [1.396623]  worker_thread+0x12b/0x4a0
> [1.396626]  kthread+0x10c/0x140
> [1.396629]  ? process_one_work+0x430/0x430
> [1.396632]  ? kthread_create_on_node+0x40/0x40
> [1.396635]  ret_from_fork+0x27/0x40
> [1.396639] ---[ end trace dd05bb2cd9ebd900 ]---
> [1.396643] drm_sysfs_connector_add() connector: 88040c75a000 kdev: 
> fffe
> [1.396648] [drm:drm_sysfs_connector_add] *ERROR* failed to register 
> connector device: -2
> [1.396651] drm_connector_register(88040ed3f000) 
> connector->registered: 1
> [1.39] drm_sysfs_connector_add() connector: 88040ed3f800 kdev: 
> 88040c55e400
> [1.396700] drm_connector_register(88040ed3f800) 
> connector->registered: 1
> [1.396717] drm_sysfs_connector_add() connector: 88040ed39800 kdev: 
> 88040c55e800
> [1.396726] drm_connector_register(88040ed39800) 
> connector->registered: 1
> [1.396743] drm_sysfs_connector_add() connector: 88040c758000 kdev: 
> 88040c55ec00
> [1.396769] drm_connector_register(88040c758000) 
> connector->registered: 1
> [1.396786] drm_sysfs_connector_add() connector: 88040c758800 kdev: 
> 88040c55f000
> [1.396799] drm_connector_register(88040c758800) 
> connector->registered: 1
> [1.396804] drm_connector_register(88040c75a000) 
> connector->registered: 1
> [1.398665] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
> [1.398893] drm_sysfs_connector_add() connector: 88040c75b000 kdev: 
> 88040c790400
> [1.398907] drm_connector_register(88040c75b000) 
> connector->registered: 1
> [1.398930] drm_sysfs_connector_add() connector: 88040c75c000 kdev: 
> 88040c790800
> [1.398939] drm_connector_register(88040c75c000) 
> connector->registered: 1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

[Dave Hansen]

On 01/09/2017 02:15 AM, Daniel Vetter wrote:
...
> Can you pls do some printk tracing to make sure that without your patch
> we're indeed releasing the same connector twice from this loop? I suspect
> you're just ever-so-slightly shifting the timing and things blow up
> somewhre else. But no idea where :(

Your suspicious appear correct.  I still get an oops even with my patch
applied.  I did add some printk's but they're weird.  I'm seeing a
'kdev' that looks to be -2, although it should never get set to that
unless device_create_with_groups() and th error checking failed somehow.

I'll take out the locking portion of the patch and add some more
printk's and see if anything else shows up.  Here's a copy of the
printk's and associated oops, with my locking modification patch
applied, if this helps at all:

> [ 7927.049763] drm_dp_destroy_port() kfree(88040c759000)
> [ 7927.050039] drm_dp_destroy_connector_work() port: 88040c759800 
> connector: 88040c75a000
> [ 7927.050061] drm_sysfs_connector_remove() connector: 88040c75a000 kdev: 
> fffe
> [ 7927.050106] BUG: unable to handle kernel NULL pointer dereference at 
> 009e
> [ 7927.050242] IP: device_del+0x19/0x330
> [ 7927.050300] PGD 0 
> [ 7927.050302] 
> [ 7927.050364] Oops:  [#1] SMP
> [ 7927.050414] Modules linked in: netconsole ctr ccm ipt_MASQUERADE 
> nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
> nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 
> xt_CHECKSUM iptable_mangle xt_tcpudp bridge stp llc iptable_filter ip_tables 
> ebtable_nat ebtables x_tables cmac rfcomm bnep dm_crypt arc4 iwlmvm mac80211 
> snd_hda_codec_hdmi iwlwifi snd_hda_codec_realtek snd_hda_codec_generic 
> snd_hda_intel snd_seq_midi snd_seq_midi_event snd_hda_codec cfg80211 
> snd_hwdep snd_rawmidi intel_rapl snd_hda_core iosf_mbi snd_pcm snd_seq btusb 
> x86_pkg_temp_thermal hid_logitech_hidpp btrtl btbcm btintel coretemp shpchp 
> snd_timer ghash_clmulni_intel bluetooth joydev thinkpad_acpi snd_seq_device 
> nvram wmi snd soundcore mac_hid aesni_intel aes_x86_64 crypto_simd cryptd 
> glue_helper
> [ 7927.051492]  kvm_intel kvm irqbypass hid_generic hid_logitech_dj usbhid 
> hid [last unloaded: netconsole]
> [ 7927.051642] CPU: 2 PID: 123 Comm: kworker/2:2 Tainted: GW   
> 4.10.0-rc2-dirty #53
> [ 7927.051763] Hardware name: LENOVO 20F5S7V800/20F5S7V800, BIOS R02ET50W 
> (1.23 ) 09/20/2016
> [ 7927.051887] Workqueue: events drm_dp_destroy_connector_work
> [ 7927.051971] task: 88040c21bc00 task.stack: c90002484000
> [ 7927.052065] RIP: 0010:device_del+0x19/0x330
> [ 7927.052129] RSP: 0018:c90002487d58 EFLAGS: 00010282
> [ 7927.052209] RAX:  RBX: fffe RCX: 
> 88040c72d1f8
> [ 7927.052310] RDX: 81cb69b2 RSI: 0001 RDI: 
> fffe
> [ 7927.052412] RBP: c90002487d90 R08:  R09: 
> 0392
> [ 7927.052517] R10: 0003e05de802 R11:  R12: 
> fffe
> [ 7927.052677] R13: 88040c516c18 R14:  R15: 
> 88040c516bd8
> [ 7927.052781] FS:  () GS:88042150() 
> knlGS:
> [ 7927.052897] CS:  0010 DS:  ES:  CR0: 80050033
> [ 7927.052981] CR2: 009e CR3: 01e0b000 CR4: 
> 003406e0
> [ 7927.053082] DR0:  DR1:  DR2: 
> 
> [ 7927.053186] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [ 7927.053288] Call Trace:
> [ 7927.053338]  ? printk+0x4d/0x4f
> [ 7927.053396]  device_unregister+0x12/0x30
> [ 7927.053464]  drm_sysfs_connector_remove+0x57/0x70
> [ 7927.053538]  drm_connector_unregister.part.8+0x27/0x40
> [ 7927.053616]  drm_connector_unregister+0x14/0x20
> [ 7927.053690]  intel_dp_destroy_mst_connector+0x1a/0x80
> [ 7927.053771]  drm_dp_destroy_connector_work+0xce/0x150
> [ 7927.053850]  process_one_work+0x14b/0x430
> [ 7927.053914]  worker_thread+0x12b/0x4a0
> [ 7927.053982]  kthread+0x10c/0x140
> [ 7927.054037]  ? process_one_work+0x430/0x430
> [ 7927.054104]  ? kthread_create_on_node+0x40/0x40
> [ 7927.054179]  ret_from_fork+0x27/0x40
> [ 7927.054237] Code: 00 00 00 00 00 00 00 5b 41 5c 41 5d 5d c3 0f 1f 40 00 0f 
> 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 fc 53 48 83 ec 10 <48> 
> 8b 87 a0 00 00 00 4c 8b 2f 48 85 c0 74 1b 48 8b b8 90 00 00 
> [ 7927.054462] RIP: device_del+0x19/0x330 RSP: c90002487d58
> [ 7927.054486] CR2: 009e
> [ 7927.065278] ---[ end trace 1a2a5ca2cf6c3a4f ]---

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] 4.10-rc2 oops in DRM connector code

[Dave Hansen]

My Thinkpad x260 doesn't like to be unplugged from its dock.  I don't
think this is a new bug.  It's happening on my distro's 4.4 kernel
as well.

The actual oops is in device_del().  It appears to have been passed a
null 'struct device *'.

There appears to have been a race _around_ here fixed in 1f7717552e.
I've looked for and tried to find the locking that prevents
drm_connector_unregister() from being called twice concurrently.  I'm
unable to find anything.

drm_dp_destroy_connector_work() has some locking that looks useful:

mutex_lock(>destroy_connector_lock)

but it's released before the offending call:

mgr->cbs->destroy_connector(mgr, port->connector);

which actually calls intel_dp_destroy_mst_connector().  I have no idea
if it's correct (and haven't even run it with lockdep), but the attached
patch does seem to fix my oopses.

Any ideas?

> Jan  5 10:22:32 ray kernel: [  537.087042] BUG: unable to handle kernel NULL 
> pointer dereference at 009e
> Jan  5 10:22:32 ray kernel: [  537.087954] IP: device_del+0x19/0x330
> Jan  5 10:22:32 ray kernel: [  537.088860] PGD 0
> Jan  5 10:22:32 ray kernel: [  537.088860]
> Jan  5 10:22:32 ray kernel: [  537.090578] Oops:  [#1] SMP
> Jan  5 10:22:32 ray kernel: [  537.091406] Modules linked in: ctr ccm 
> ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat 
> nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT 
> nf_reject_ipv4 xt_CHECKSUM iptable_mangle xt_tcpudp bridge stp llc 
> iptable_filter ip_tables ebtable_nat ebtables x_tables cmac rfcomm bnep 
> dm_crypt arc4 iwlmvm mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek 
> snd_hda_codec_generic iwlwifi intel_rapl snd_hda_intel iosf_mbi 
> hid_logitech_hidpp snd_seq_midi cfg80211 x86_pkg_temp_thermal snd_hda_codec 
> snd_seq_midi_event snd_hwdep btusb snd_rawmidi snd_hda_core btrtl coretemp 
> snd_seq snd_pcm btbcm btintel joydev bluetooth ghash_clmulni_intel snd_timer 
> shpchp thinkpad_acpi snd_seq_device nvram wmi snd soundcore mac_hid 
> aesni_intel aes_x86_64 crypto_simd cryptd glue_helper kvm_intel
> Jan  5 10:22:32 ray kernel: [  537.095222]  kvm irqbypass hid_generic 
> hid_logitech_dj usbhid hid
> Jan  5 10:22:32 ray kernel: [  537.096272] CPU: 2 PID: 23 Comm: kworker/2:0 
> Tainted: GW   4.10.0-rc2 #47
> Jan  5 10:22:32 ray kernel: [  537.097263] Hardware name: LENOVO 
> 20F5S7V800/20F5S7V800, BIOS R02ET50W (1.23 ) 09/20/2016
> Jan  5 10:22:32 ray kernel: [  537.098291] Workqueue: events 
> drm_dp_destroy_connector_work
> Jan  5 10:22:32 ray kernel: [  537.099328] task: 88040f2f1e00 task.stack: 
> c9000198c000
> Jan  5 10:22:32 ray kernel: [  537.100335] RIP: 0010:device_del+0x19/0x330
> Jan  5 10:22:32 ray kernel: [  537.101340] RSP: 0018:c9000198fd58 EFLAGS: 
> 00010282
> Jan  5 10:22:32 ray kernel: [  537.102361] RAX:  RBX: 
> fffe RCX: 88040c5191b0
> Jan  5 10:22:32 ray kernel: [  537.103418] RDX: 81cb6246 RSI: 
> 0001 RDI: fffe
> Jan  5 10:22:32 ray kernel: [  537.104473] RBP: c9000198fd90 R08: 
>  R09: 880421517780
> Jan  5 10:22:32 ray kernel: [  537.105574] R10: 007d0ce17c93 R11: 
> 0001 R12: fffe
> Jan  5 10:22:32 ray kernel: [  537.106636] R13: 88040ed36bd8 R14: 
> 88040ed36788 R15: 88040c728810
> Jan  5 10:22:32 ray kernel: [  537.107728] FS:  () 
> GS:88042150() knlGS:
> Jan  5 10:22:32 ray kernel: [  537.108812] CS:  0010 DS:  ES:  CR0: 
> 80050033
> Jan  5 10:22:32 ray kernel: [  537.109937] CR2: 009e CR3: 
> 000384894000 CR4: 003406e0
> Jan  5 10:22:32 ray kernel: [  537.111038] DR0:  DR1: 
>  DR2: 
> Jan  5 10:22:32 ray kernel: [  537.112142] DR3:  DR6: 
> fffe0ff0 DR7: 0400
> Jan  5 10:22:32 ray kernel: [  537.113223] Call Trace:
> Jan  5 10:22:32 ray kernel: [  537.114293]  device_unregister+0x12/0x30
> Jan  5 10:22:32 ray kernel: [  537.115354]  
> drm_sysfs_connector_remove+0x3b/0x50
> Jan  5 10:22:32 ray kernel: [  537.116391]  
> drm_connector_unregister.part.8+0x27/0x40
> Jan  5 10:22:32 ray kernel: [  537.117433]  drm_connector_unregister+0x14/0x20
> Jan  5 10:22:32 ray kernel: [  537.118478]  
> intel_dp_destroy_mst_connector+0x1a/0x80
> Jan  5 10:22:32 ray kernel: [  537.119513]  
> drm_dp_destroy_connector_work+0xa9/0x150
> Jan  5 10:22:32 ray kernel: [  537.120539]  process_one_work+0x14b/0x430
> Jan  5 10:22:32 ray kernel: [  537.121568]  worker_thread+0x12b/0x4a0
> Jan  5 10:22:32 ray kernel: [  537.122581]  kthread+0x10c/0x140
> Jan  5 10:22:32 ray kernel: [  537.123583]  ? process_one_work+0x430/0x430
> Jan  5 10:22:32 ray kernel: [  537.124584]  ? kthread_create_on_node+0x40/0x40
> Jan  5 10:22:32 ray kernel: [  537.125574]  ret_from_fork+0x27/0x40
> Jan  5 10:22:32 ray 

Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

[Dave Hansen]

On 10/19/2016 10:01 AM, Michal Hocko wrote:
> The question I had earlier was whether this has to be an explicit FOLL
> flag used by g-u-p users or we can just use it internally when mm !=
> current->mm

The reason I chose not to do that was that deferred work gets run under
a basically random 'current'.  If we just use 'mm != current->mm', then
the deferred work will sometimes have pkeys enforced and sometimes not,
basically randomly.

We want to be consistent with whether they are enforced or not, so we
explicitly indicate that by calling the remote variant vs. plain.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

[Dave Hansen]

On 10/19/2016 02:07 AM, Michal Hocko wrote:
> On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
>> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
>>> I am wondering whether we can go further. E.g. it is not really clear to
>>> me whether we need an explicit FOLL_REMOTE when we can in fact check
>>> mm != current->mm and imply that. Maybe there are some contexts which
>>> wouldn't work, I haven't checked.
>>
>> This flag is set even when /proc/self/mem is used. I've not looked deeply 
>> into
>> this flag but perhaps accessing your own memory this way can be considered
>> 'remote' since you're not accessing it directly. On the other hand, perhaps 
>> this
>> is just mistaken in this case?
> 
> My understanding of the flag is quite limited as well. All I know it is
> related to protection keys and it is needed to bypass protection check.
> See arch_vma_access_permitted. See also 1b2ee1266ea6 ("mm/core: Do not
> enforce PKEY permissions on remote mm access").

Yeah, we need the flag to tell us when PKEYs should be applied or not.
The current task's PKRU (pkey rights register) should really only be
used to impact access to the task's memory, but has no bearing on how a
given task should access remote memory.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] mm: Throttle shrinkers harder

[Dave Hansen]

On 04/26/2014 06:10 AM, Chris Wilson wrote:
   Thanks for the pointer to
   register_oom_notifier(), I can use that to make sure that we do purge
   everything from the GPU, and do a sanity check at the same time, before
   we start killing processes.
  
  Actually, that one doesn't get called until we're *SURE* we are going to
  OOM.  Any action taken in there won't be taken in to account.
 blocking_notifier_call_chain(oom_notify_list, 0, freed);
 if (freed  0)
   /* Got some memory back in the last second. */
   return;
 
 That looks like it should abort the oom and so repeat the allocation
 attempt? Or is that too hopeful?

You're correct.  I was reading the code utterly wrong.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] mm: Throttle shrinkers harder

[Dave Hansen]

On 04/25/2014 12:23 AM, Chris Wilson wrote:
 On Thu, Apr 24, 2014 at 03:35:47PM -0700, Dave Hansen wrote:
 On 04/24/2014 08:39 AM, Chris Wilson wrote:
 On Thu, Apr 24, 2014 at 08:21:58AM -0700, Dave Hansen wrote:
 Is it possible that there's still a get_page() reference that's holding
 those pages in place from the graphics code?

 Not from i915.ko. The last resort of our shrinker is to drop all page
 refs held by the GPU, which is invoked if we are asked to free memory
 and we have no inactive objects left.

 How sure are we that this was performed before the OOM?
 
 Only by virtue of how shrink_slabs() works.

Could we try to raise the level of assurance there, please? :)

So this last resort is i915_gem_shrink_all()?  It seems like we might
have some problems getting down to that part of the code if we have
problems getting the mutex.

We have tracepoints for the shrinkers in here (it says slab, but it's
all the shrinkers, I checked):

/sys/kernel/debug/tracing/events/vmscan/mm_shrink_slab_*/enable
and another for OOMs:
/sys/kernel/debug/tracing/events/oom/enable

Could you collect a trace during one of these OOM events and see what
the i915 shrinker is doing?  Just enable those two and then collect a
copy of:

/sys/kernel/debug/tracing/trace

That'll give us some insight about how well the shrinker is working.  If
the VM gave up on calling in to it, it might reveal why we didn't get
all the way down in to i915_gem_shrink_all().

 Thanks for the pointer to
 register_oom_notifier(), I can use that to make sure that we do purge
 everything from the GPU, and do a sanity check at the same time, before
 we start killing processes.

Actually, that one doesn't get called until we're *SURE* we are going to
OOM.  Any action taken in there won't be taken in to account.

 Also, forgive me for being an idiot wrt the way graphics work, but are
 there any good candidates that you can think of that could be holding a
 reference?  I've honestly never seen an OOM like this.
 
 Here the only place that we take a page reference is in
 i915_gem_object_get_pages(). We do this when we first bind the pages
 into the GPU's translation table, but we only release the pages once the
 object is destroyed or the system experiences memory pressure. (Once the
 GPU touches the pages, we no longer consider them to be cache coherent
 with the CPU and so migrating them between the GPU and CPU requires
 clflushing, which is expensive.)
 
 Aside from CPU mmaps of the shmemfs filp, all operations on our
 graphical objects should lead to i915_gem_object_get_pages(). However
 not all objects are recoverable as some may be pinned due to hardware
 access.

In that oom callback, could you dump out the aggregate number of
obj-pages_pin_count across all the objects?  That would be a very
interesting piece of information to have.  It would also be very
insightful for folks who see OOMs in practice with i915 in their systems.


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] mm: Throttle shrinkers harder

[Dave Hansen]

Poking around with those tracepoints, I don't see the i915 shrinker
getting run, only i915_gem_inactive_count() being called.  It must be
returning 0 because we're never even _getting_ to the tracepoints
themselves after calling i915_gem_inactive_count().

This is on my laptop, and I haven't been able to coax i915 in to
reclaiming a single page in 10 or 15 minutes.  That seems fishy to me.
Surely *SOMETHING* has become reclaimable in that time.

Here's /sys/kernel/debug/dri/0/i915_gem_objects:

 919 objects, 354914304 bytes
 874 [333] objects, 291004416 [93614080] bytes in gtt
   0 [0] active objects, 0 [0] bytes
   874 [333] inactive objects, 291004416 [93614080] bytes
 0 unbound objects, 0 bytes
 199 purgeable objects, 92844032 bytes
 30 pinned mappable objects, 18989056 bytes
 139 fault mappable objects, 17371136 bytes
 2145386496 [268435456] gtt total
 
 Xorg: 632 objects, 235450368 bytes (0 active, 180899840 inactive, 21262336 
 unbound)
 gnome-control-c: 11 objects, 110592 bytes (0 active, 0 inactive, 49152 
 unbound)
 chromium-browse: 266 objects, 101367808 bytes (0 active, 101330944 inactive, 
 0 unbound)
 Xorg: 0 objects, 0 bytes (0 active, 0 inactive, 0 unbound)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] mm: Throttle shrinkers harder

[Dave Hansen]

On 04/23/2014 10:58 PM, Chris Wilson wrote:
 [ 4756.750938] Node 0 DMA free:14664kB min:32kB low:40kB high:48kB 
 active_anon:0kB inactive_anon:1024kB active_file:0kB inactive_file:4kB 
 unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB 
 managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:412kB 
 slab_reclaimable:80kB slab_unreclaimable:24kB kernel_stack:0kB 
 pagetables:48kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB 
 pages_scanned:76 all_unreclaimable? yes
 [ 4756.751103] lowmem_reserve[]: 0 3337 3660 3660
 [ 4756.751133] Node 0 DMA32 free:7208kB min:7044kB low:8804kB high:10564kB 
 active_anon:36172kB inactive_anon:3351408kB active_file:92kB 
 inactive_file:72kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
 present:3518336kB managed:3440548kB mlocked:0kB dirty:0kB writeback:0kB 
 mapped:12kB shmem:1661420kB slab_reclaimable:17624kB 
 slab_unreclaimable:14400kB kernel_stack:696kB pagetables:4324kB unstable:0kB 
 bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:327 
 all_unreclaimable? yes
 [ 4756.751341] lowmem_reserve[]: 0 0 322 322
 [ 4756.752889] Node 0 Normal free:328kB min:680kB low:848kB high:1020kB 
 active_anon:61372kB inactive_anon:250740kB active_file:0kB inactive_file:4kB 
 unevictable:0kB isolated(anon):0kB isolated(file):0kB present:393216kB 
 managed:330360kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB 
 shmem:227740kB slab_reclaimable:3032kB slab_unreclaimable:5128kB 
 kernel_stack:400kB pagetables:624kB unstable:0kB bounce:0kB free_cma:0kB 
 writeback_tmp:0kB pages_scanned:6 all_unreclaimable? yes
 [ 4756.757635] lowmem_reserve[]: 0 0 0 0
 [ 4756.759294] Node 0 DMA: 2*4kB (UM) 2*8kB (UM) 3*16kB (UEM) 4*32kB (UEM) 
 2*64kB (UM) 4*128kB (UEM) 2*256kB (EM) 2*512kB (EM) 2*1024kB (UM) 3*2048kB 
 (EMR) 1*4096kB (M) = 14664kB
 [ 4756.762776] Node 0 DMA32: 424*4kB (UEM) 171*8kB (UEM) 21*16kB (UEM) 1*32kB 
 (R) 1*64kB (R) 1*128kB (R) 0*256kB 1*512kB (R) 1*1024kB (R) 1*2048kB (R) 
 0*4096kB = 7208kB
 [ 4756.766284] Node 0 Normal: 26*4kB (UER) 18*8kB (UER) 3*16kB (E) 1*32kB (R) 
 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 328kB
 [ 4756.768198] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
 hugepages_size=2048kB
 [ 4756.770026] 916139 total pagecache pages
 [ 4756.771857] 443703 pages in swap cache
 [ 4756.773695] Swap cache stats: add 15363874, delete 14920171, find 
 6533699/7512215
 [ 4756.775592] Free swap  = 0kB
 [ 4756.777505] Total swap = 2047996kB

OK, so here's my theory as to what happens:

1. The graphics pages got put on the LRU
2. System is low on memory, they get on (and *STAY* on) the inactive
   LRU.
3. VM adds graphics pages to the swap cache, and writes them out, and
   we see the writeout from the vmstat, and lots of adds/removes from
   the swap cache.
4. But, despite all the swap writeout, we don't get helped by seeing
   much memory get freed.  Why?

I _suspect_ that the graphics drivers here are holding a reference to
the page.  During reclaim, we're mostly concerned with the pages being
mapped.  If we manage to get them unmapped, we'll go ahead and swap
them, which I _think_ is what we're seeing.  But, when it comes time to
_actually_ free them, that last reference on the page keeps them from
being freed.

Is it possible that there's still a get_page() reference that's holding
those pages in place from the graphics code?

 Also, the vmstat output from the bug:

 https://bugs.freedesktop.org/show_bug.cgi?id=72742

 shows there being an *AWFUL* lot of swap I/O going on here.  From the
 looks of it, we stuck ~2GB in swap and evicted another 1.5GB of page
 cache (although I guess that could be double-counting tmpfs getting
 swapped out too).  Hmmm, was this one of the cases where you actually
 ran _out_ of swap?
 
 Yes. This bug is a little odd because they always run out of swap. We
 have another category of bug (which appears to be fixed, touch wood)
 where we trigger oom without even touching swap. The test case is
 designed to only just swap (use at most 1/4 of the available swap space)
 and checks that its working set should fit into available memory + swap.
 However, when QA run the test, their systems run completely out of
 virtual memory. There is a discrepancy on their machines where
 anon_inactive is reported as being 2x shmem, but we only expect
 anon_inactive to be our own shmem allocations. I don't know how to track
 what else is using anon_inactive. Suggestions?

Let's tackle one bug at a time.  They might be the same thing.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] mm: Throttle shrinkers harder

[Dave Hansen]

On 04/24/2014 08:39 AM, Chris Wilson wrote:
 On Thu, Apr 24, 2014 at 08:21:58AM -0700, Dave Hansen wrote:
 Is it possible that there's still a get_page() reference that's holding
 those pages in place from the graphics code?
 
 Not from i915.ko. The last resort of our shrinker is to drop all page
 refs held by the GPU, which is invoked if we are asked to free memory
 and we have no inactive objects left.

How sure are we that this was performed before the OOM?

Also, forgive me for being an idiot wrt the way graphics work, but are
there any good candidates that you can think of that could be holding a
reference?  I've honestly never seen an OOM like this.

Somewhat rhetorical question for the mm folks on cc: should we be
sticking the pages on which you're holding a reference on our
unreclaimable list?

 If we could get a callback for the oom report, I could dump some details
 about what the GPU is holding onto. That seems like a useful extension to
 add to the shrinkers.

There's a register_oom_notifier().  Is that sufficient for your use, or
is there something additional that would help?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] mm: Throttle shrinkers harder

[Dave Hansen]

On 04/22/2014 12:30 PM, Daniel Vetter wrote:
   During testing of i915.ko with working texture sets larger than RAM, we
   encounter OOM with plenty of memory still trapped within writeback, e.g:
   
   [   42.386039] active_anon:10134 inactive_anon:1900781 isolated_anon:32
active_file:33 inactive_file:39 isolated_file:0
unevictable:0 dirty:0 writeback:337627 unstable:0
free:11985 slab_reclaimable:9458 slab_unreclaimable:23614
mapped:41 shmem:1560769 pagetables:1276 bounce:0
   
   If we throttle for writeback following shrink_slab, this gives us time
   to wait upon the writeback generated by the i915.ko shinker:
   
   [ 4756.750808] active_anon:24386 inactive_anon:900793 isolated_anon:0
active_file:23 inactive_file:20 isolated_file:0
unevictable:0 dirty:0 writeback:0 unstable:0
free:5550 slab_reclaimable:5184 slab_unreclaimable:4888
mapped:3 shmem:472393 pagetables:1249 bounce:0

Could you get some dumps of the entire set of OOM information?  These
are only tiny snippets.

Also, the vmstat output from the bug:

 https://bugs.freedesktop.org/show_bug.cgi?id=72742

shows there being an *AWFUL* lot of swap I/O going on here.  From the
looks of it, we stuck ~2GB in swap and evicted another 1.5GB of page
cache (although I guess that could be double-counting tmpfs getting
swapped out too).  Hmmm, was this one of the cases where you actually
ran _out_ of swap?

  2  0  19472  33952296 36103240 19472 0 19472 1474  151  3 27 71   0
  4  0 484964  66468296 31758640 465492 0 465516 2597 1395  0 32 
 66  2
  0  2 751940  23692980 30228840 266976   688 266976 3681  636  0 27 
 66  6
 procs ---memory-- ---swap-- -io -system-- cpu
  r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa
  2  1 1244580 295336988 26069840 492896 0 492908 1237  311  1  9 
 50 41
  0  2 2047996  28760988 20371440 803160 0 803160 1221 1291  1 15 
 69 14


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] i915 hang and large allocation (~3.7-rc4)

[Dave Hansen]

I've been seeing a little goofiness with i915 video under the 3.7-rc's.
It looks like I'm seeing two separate issues.  One, that the video
hardware hangs, spits some errors in dmesg, and then video acceleration
seems to stop working.  Two, when it does this, apport goes digging in
debugfs for information about the hang.  When it does this, something
does an order-9 (2MB) kmalloc() which fails.

While debugfs is expected to be a _bit_ rickety, I do think order-9
is a bit excessive for an in-kernel allocation, even a temporary
one.  I'm not quite sure if it has done this for a long time, and I'm
only hitting it now since I'm seeing a _separate_ i915 hang.

Relevant parts of dmesg, lspci, and kernel config are here:

http://sr71.net/~dave/linux/i915-wonky/

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx