our acks to move forward.
Either way:
Acked-by: Dave Hansen # for x86
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
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 o
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
t pci_device_id intel_early_ids[]
> __initconst = {
> INTEL_RKL_IDS(&gen11_early_ops),
> INTEL_ADLS_IDS(&gen11_early_ops),
> INTEL_ADLP_IDS(&gen11_early_ops),
> + INTEL_RPLS_IDS(&gen11_early_ops),
> };
For arch/x86 purposes:
Acked-by: 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) tak
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
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
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.
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&#
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 a
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 obse
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
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 r
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 th
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 co
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 displ
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
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&
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
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 ap
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
>>> Date: Sun Dec 18
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 id
On 01/09/2017 08:59 AM, Daniel Vetter wrote:
> On Mon, Jan 9, 2017 at 5:50 PM, Dave Hansen wrote:
>> On 01/09/2017 08:41 AM, Daniel Vetter wrote:
>>> On Mon, Jan 9, 2017 at 2:40 PM, Dave Hansen wrote:
>>>> Well, now I found where the -2 comes from.
>>>&g
On 01/09/2017 08:59 AM, Daniel Vetter wrote:
> On Mon, Jan 9, 2017 at 5:50 PM, Dave Hansen wrote:
>> On 01/09/2017 08:41 AM, Daniel Vetter wrote:
>>> On Mon, Jan 9, 2017 at 2:40 PM, Dave Hansen wrote:
>>>> Well, now I found where the -2 comes from.
>>>&g
On 01/09/2017 08:41 AM, Daniel Vetter wrote:
> On Mon, Jan 9, 2017 at 2:40 PM, Dave Hansen 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). Bu
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
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
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 w
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
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 'curr
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
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 o
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 a
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
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 re
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:0k
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
>> > >
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 infor
39 matches
Mail list logo
