On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes wrote:
> TL;DR: these patches save 250 KB of memory, with more low-hanging
> fruit ready to pick.
>
> While browsing through the lib/idr.c code, I noticed that the code at
> the end of ida_get_new_above() probably doesn't work as intended: Most
On Thu, 8 Dec 2016 10:34:12 +0200 Tomi Valkeinen
wrote:
> Remove Tomi Valkeinen from fbdev maintainer and mark fbdev as orphan.
>
> ...
>
> I just don't have time to even pretend I maintain fbdev, so mark it as Orphan.
>
> Anyone want to pick fbdev maintainership?
I'll keep an eye on the mail
On Mon, 19 Dec 2016 14:34:12 +0100 Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Thursday, December 15, 2016 12:12:52 PM Andrew Morton wrote:
> > On Thu, 8 Dec 2016 10:34:12 +0200 Tomi Valkeinen
> > wrote:
> >
> > > Remove Tomi Valkeinen from fb
On Tue, 20 Nov 2018 15:12:49 -0800 Dan Williams
wrote:
> Changes since v7 [1]:
> At Maintainer Summit, Greg brought up a topic I proposed around
> EXPORT_SYMBOL_GPL usage. The motivation was considerations for when
> EXPORT_SYMBOL_GPL is warranted and the criteria for taking the
> exceptional st
On Fri, 23 Nov 2018 15:24:16 +0530 Anshuman Khandual
wrote:
> At present there are multiple places where invalid node number is encoded
> as -1. Even though implicitly understood it is always better to have macros
> in there. Replace these open encodings for an invalid node number with the
> glo
On Mon, 9 Jul 2018 18:25:09 +0200 Daniel Vetter wrote:
> To avoid compilers complainig about ambigious else blocks when putting
> an if condition into a for_each macro one needs to invert the
> condition and add a dummy else. We have a nice little convenience
> macro for that in drm headers, let
On Wed, 11 Jul 2018 13:51:08 +0200 Daniel Vetter wrote:
> But I still have the situation that a bunch of maintainers acked this
> and Andrew Morton defacto nacked it, which I guess means I'll keep the
> macro in drm? The common way to go about this seems to be to just push
>
On Mon, 3 Dec 2018 15:18:17 -0500 jgli...@redhat.com wrote:
> CPU page table update can happens for many reasons, not only as a result
> of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
> as a result of kernel activities (memory compression, reclaim, migration,
> ...).
>
>
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko wrote:
> > Any suggestions regarding how the driver developers can test this code
> > path? I don't think we presently have a way to fake an oom-killing
> > event? Perhaps we should add such a thing, given the problems we're
> > having with that f
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
On Tue, 24 Jul 2018 16:17:47 +0200 Michal Hocko wrote:
> On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> [...]
> > - Undocumented return value.
> >
> > - comment "failed to reap part..." is misleading - sounds like it's
> > referring to som
On Mon, 26 Aug 2024 10:30:54 +0800 Yafang Shao wrote:
> Hello Andrew,
>
> Could you please apply this series to the mm tree ?
Your comment in
https://lkml.kernel.org/r/CALOAHbA5VDjRYcoMOMKcLMVR0=zwtz5fbtvqzexi6w8we9j...@mail.gmail.com
led me to believe that a v8 is to be sent?
On Fri, 5 Jul 2024 13:48:25 -0700 SeongJae Park wrote:
> > + * memfd_pin_folios() - pin folios associated with a memfd
> [...]
> > + for (i = 0; i < nr_found; i++) {
> > + /*
> > +* As there can be multiple entries for a
> >
On Fri, 5 Jul 2024 22:11:14 + "Kasireddy, Vivek"
wrote:
> Hi Andrew and SJ,
>
> >
> > >
> > > I didn't look deep into the patch, so unsure if that's a valid fix,
> > > though.
> > > May I ask your thoughts?
> >
> > Perhaps we should propagate the errno which was returned by
> > try_grab
On Fri, 5 Jul 2024 15:55:23 -0700 Andrew Morton
wrote:
> On Fri, 5 Jul 2024 22:11:14 + "Kasireddy, Vivek"
> wrote:
>
> > Hi Andrew and SJ,
> >
> > >
> > > >
> > > > I didn't look deep into the patch, so unsure if
On Mon, 29 Jul 2024 10:37:08 +0800 Yafang Shao wrote:
> Is it appropriate for you to apply this to the mm tree?
There are a couple of minor conflicts against current 6.11-rc1 which
you'd best check. So please redo this against current mainline?
On Tue, 13 Aug 2024 15:12:35 +0300 Jani Nikula wrote:
> The fault-inject.h users across the kernel need to add a lot of #ifdef
> CONFIG_FAULT_INJECTION to cater for shortcomings in the header. Make
> fault-inject.h self-contained for CONFIG_FAULT_INJECTION=n, and add
> stubs for DECLARE_FAULT_ATT
On Wed, 14 Aug 2024 09:57:31 +0300 Jani Nikula wrote:
> > Removing a nested include exposes all those sites which were
> > erroneously depending upon that nested include. Here's what I have
> > found so far, there will be more.
>
> Right. I didn't hit them with the configs I tried... though I w
On Tue, 6 Feb 2024 09:45:18 +0530 Anshuman Khandual
wrote:
> cma_get_name() just returns cma->name without any additional transformation
> unlike other helpers such as cma_get_base() and cma_get_size(). This helper
> is not worth the additional indirection, and can be dropped after replacing
>
On Thu, 11 Jan 2024 18:22:50 -0800 "Darrick J. Wong" wrote:
> On Thu, Jan 11, 2024 at 10:45:53PM +, Matthew Wilcox wrote:
> > On Thu, Jan 11, 2024 at 02:00:53PM -0800, Andrew Morton wrote:
> > > On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong"
On Tue, 2 Jul 2024 09:13:35 +0200 Christian König
wrote:
> yes that is
> intentionally a define and not an inline function.
>
> See this patch here which changed that:
>
> commit 2c321f3f70bc284510598f712b702ce8d60c4d14
> Author: Suren Baghdasaryan
> Date: Sun Apr 14 19:07:31 2024 -0700
>
On Thu, 08 Mar 2018 12:06:46 +0200 Jani Nikula
wrote:
> On Wed, 07 Mar 2018, a...@linux-foundation.org wrote:
> > From: Andrew Morton
> > Subject: drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union
> > initializer issue
> >
> > gcc-4.4.4 has
On Tue, 20 Feb 2018 10:03:56 +0200 Jani Nikula
wrote:
> On Mon, 19 Feb 2018, Pavel Machek wrote:
> > On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
> >> Yeah, pls split this into one patch per area, with a suitable patch
> >> subject prefix. Look at git log of each file to get a feeling for w
On Thu, 18 Jan 2018 11:47:48 -0500 Andrey Grodzovsky
wrote:
> Hi, this series is a revised version of an RFC sent by Christian König
> a few years ago. The original RFC can be found at
> https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html
>
> This is the same idea and I
On Wed, 10 Jan 2024 10:21:07 +0100 Christoph Hellwig wrote:
> Hi all,
>
> Darrick reported that the fairly new XFS xfile code blows up when force
> enabling large folio for shmem. This series fixes this quickly by disabling
> large folios for this particular shmem file for now until it can be f
On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong" wrote:
> > > Fixing this will require a bit of an API change, and prefeably sorting out
> > > the hwpoison story for pages vs folio and where it is placed in the shmem
> > > API. For now use this one liner to disable large folios.
> > >
> > >
On Thu, 13 Jun 2024 10:30:39 +0800 Yafang Shao wrote:
> In kstrdup(), it is critical to ensure that the dest string is always
> NUL-terminated. However, potential race condidtion can occur between a
> writer and a reader.
>
> Consider the following scenario involving task->comm:
>
> reader
On Wed, 14 Nov 2012 11:41:49 -0800
Randy Dunlap wrote:
> On 11/13/2012 09:30 PM, Stephen Rothwell wrote:
>
> > Hi all,
> >
> > News: next-20121115 (i.e. tomorrow) will be the last release until
> > next-20121126 (which should be just be after -rc7, I guess - assuming
> > that Linus does not rel
On Fri, 25 Jan 2013 00:42:37 + (GMT)
Dave Airlie wrote:
> These patches have been sailing around long enough, waiting for a maintainer
> to reappear, so I've decided enough is enough, lockdep is kinda useful to
> have.
>
> Thanks to Daniel for annoying me enough :-)
Me too, but the patches
ed commit message and modified to short-circuit panic_timeout < 0
> > > > instead of testing panic_timeout >= 0. -Mandeep ]
> > > > Signed-off-by: Mandeep Singh Baines
> > > > Cc: Dave Airlie
> > > > Cc: Andrew Morton
> > > > Cc: dri-
> References : https://lkml.org/lkml/2011/11/12/11
> >
>
> Andrea's patch already fixes this issue, which was reported first by
> Jiri Slaby. https://lkml.org/lkml/2011/11/11/93
> I remember Andrew Morton taking this patch in his -mm tree. But it is
> not in mainline
On Thu, 16 Feb 2012 13:01:36 +0100
Daniel Vetter wrote:
> drm/i915 wants to read/write more than one page in its fastpath
> and hence needs to prefault more than PAGE_SIZE bytes.
>
> I've checked the callsites and they all already clamp size when
> calling fault_in_pages_* to the same as for the
On Fri, 24 Feb 2012 14:34:31 +0100
Daniel Vetter wrote:
> > > --- a/include/linux/pagemap.h
> > > +++ b/include/linux/pagemap.h
> > > @@ -408,6 +408,7 @@ extern void add_page_wait_queue(struct page *page,
> > > wait_queue_t *waiter);
> > > static inline int fault_in_pages_writeable(char __user
* to the same as for the subsequent
> __copy_to|from_user and hence don't rely on the implicit clamping
> to PAGE_SIZE.
>
> Also kill a copy&pasted spurious space in both functions while at it.
>
> v2: As suggested by Andrew Morton, add a multipage parameter to both
>
On Thu, 1 Mar 2012 00:14:53 +0100
Daniel Vetter wrote:
> I'll redo this patch by adding _multipage versions of these 2 functions
> for i915.
OK, but I hope "for i915" doesn't mean "private to"! Put 'em in
pagemap.h, for maintenance reasons and because they are generic.
Making them inline is a
On Thu, 1 Mar 2012 20:22:59 +0100
Daniel Vetter wrote:
> drm/i915 wants to read/write more than one page in its fastpath
> and hence needs to prefault more than PAGE_SIZE bytes.
>
> Add new functions in filemap.h to make that possible.
>
> Also kill a copy&pasted spurious space in both functio
On Tue, 08 May 2012 11:50:33 +0200
Tomasz Stanislawski wrote:
> This patch adds a new constructor for an sg table. The table is constructed
> from an array of struct pages. All contiguous chunks of the pages are merged
> into a single sg nodes. A user may provide an offset and a size of a buffer
On Mon, 21 May 2012 16:01:50 +0200
Tomasz Stanislawski wrote:
> >> +int sg_alloc_table_from_pages(struct sg_table *sgt,
> >> + struct page **pages, unsigned int n_pages,
> >> + unsigned long offset, unsigned long size,
> >> + gfp_t gfp_mask)
> >
> > I guess a 32-bit n_pages is OK. A 16TB IO
On Mon, 21 May 2012 09:24:35 +0200
Corentin Chary wrote:
> In all these files, the .power field was never correctly initialized.
>
> ...
>
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -342,6 +342,7 @@ int intel_panel_setup_backlight(struct drm_device
On Thu, 19 May 2011 08:21:36 +0200 Uwe Kleine-König
wrote:
> I'm not sure that the things that radeon_cp_init does are sane.
Some more details here might help someone fix it.
> Maybe
> add a comment that it is the only known stopper to make
> platform_device_register_resndata __init_or_module
On Fri, 22 Oct 2010 10:13:19 -0300
Davidlohr Bueso wrote:
> drm: include missing types header to drm_mode.h
>
> Signed-off-by: Davidlohr Bueso
> ---
> include/drm/drm_mode.h |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/include/drm/drm_mode.h b/include/drm/drm
On Fri, 19 Nov 2010 10:53:52 -0500
Matthew Garrett wrote:
> There may be multiple ways of controlling the backlight on a given machine.
> Allow drivers to expose the type of interface they are providing, making
> it possible for userspace to make appropriate policy decisions.
>
> ...
>
> 60 fil
On Fri, 19 Nov 2010 20:25:59 +
Matthew Garrett wrote:
> On Fri, Nov 19, 2010 at 12:05:23PM -0800, Andrew Morton wrote:
> > On Fri, 19 Nov 2010 10:53:52 -0500
> > Matthew Garrett wrote:
> >
> > > There may be multiple ways of controlling the backlight on a giv
On Wed, 1 Dec 2010 17:54:18 +0100
Julien Cristau wrote:
> On Wed, Dec 1, 2010 at 17:10:42 +0200, Alexander Shishkin wrote:
>
> > For headers that get exported to userland and make use of u32 style
> > type names, it is advised to include linux/types.h.
> >
> > This fixes 5 headers_check warnin
(cc dri-devel)
On Mon, 20 Dec 2010 23:58:21 +0300 Michael Tokarev wrote:
> Hello.
>
> A weird problem here, and I'm looking for help in
> an attempt to solve it.
>
> Ever since KMS went into kernel and I tried turning
> it on, the scrolling speed on the resulting "text"
> console (with kms it
On Fri, 14 Jan 2011 14:24:23 -0500
Matthew Garrett wrote:
> From: Michel D__nzer
>
> Allows e.g. power management daemons to control the backlight level. Inspired
> by the corresponding code in radeonfb.
>
> (Updated to add backlight type and make the connector the parent device - mjg)
>
x86
On Thu, 20 Jan 2011 17:55:02 +0100
torbenh wrote:
> On Thu, Jan 20, 2011 at 08:34:48AM -0800, Greg KH wrote:
> > On Thu, Jan 20, 2011 at 04:58:13PM +0100, Torben Hohn wrote:
> > > the -rt patches change the console_semaphore to console_mutex.
> > > so a quite large chunk of the patches changes al
On Fri, 21 Jan 2011 00:43:46 +0330
Ali Gholami Rudi wrote:
> Ali Gholami Rudi wrote:
> > I tried to apply this patch but I get:
> >
> > drivers/gpu/drm/i915/intel_panel.c: In function
> > 'intel_panel_setup_backlight':
> > drivers/gpu/drm/i915/intel_panel.c:319: error: 'struct
> > bac
On Fri, 21 Jan 2011 00:43:59 +
Matthew Garrett wrote:
> On Thu, Jan 20, 2011 at 03:13:49PM -0800, Andrew Morton wrote:
> > On Fri, 21 Jan 2011 00:43:46 +0330
> > Ali Gholami Rudi wrote:
> >
> > > Ali Gholami Rudi wrote:
> > >
On Fri, 21 Jan 2011 06:36:54 +0100 Sedat Dilek
wrote:
> ( Original posting from [1] )
>
> I have the backlight-type patchset for months in my patch-series (and
> maintained them if necessary against daily linux-next).
> Also the last series from 14-Jan-2011 (see 1-5 patch from [2] and the
> fol
On Fri, 21 Jan 2011 09:10:06 +0100 Geert Uytterhoeven
wrote:
> include/linux/mutex.h:
>
> /*
> * NOTE: mutex_trylock() follows the spin_trylock() convention,
> * not the down_trylock() convention!
> *
> * Returns 1 if the mutex has been acquired successfully, and 0 on contention.
> *
(cc dri-devel)
A post-2.6.37 regression.
On Sun, 27 Feb 2011 10:10:41 +0100
Paolo Ornati wrote:
> Today I got this while starting a video in SMplayer (MPlayer) with
> 2.6.38-rc6-00113-g4662db4:
>
> [ 830.880014] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
> elapsed... GPU hung
> [
(cc dri-devel)
On Mon, 28 Feb 2011 12:26:08 +0100 Paul Rolland wrote:
> Hello,
>
> I'm using 2.6.37.2 and I'm getting loads of this error in my messages,
> while at the same time I can observe font display corruption in a GTK
> application (Claws-Mail) while running X, compiz and this app.
>
(cc dri-devel)
On Wed, 5 May 2010 00:22:16 +0200
Nils Radtke wrote:
> Hi,
>
> It happens quite often that X crashes for unknown reasons but this time
> there it's left us a note, this BUG:
>
> BUG: unable to handle kernel NULL pointer dereference at 01e4
> IP: [] i915_gem_object_move_to
On Tue, 11 May 2010 17:10:53 +0100 Chris Wilson
wrote:
> On Tue, 11 May 2010 20:30:07 +0530, Jaswinder Singh Rajput
> wrote:
> > Hello,
> >
> > With latest git kernel, I am getting following DRM error and not
> > getting XWindows :
>
> [snip]
>
> Hmm, there are still patches for capturing e
On Tue, 11 May 2010 19:19:26 +0100 Chris Wilson
wrote:
> On Tue, 11 May 2010 10:48:18 -0400, Andrew Morton
> wrote:
> >
> > On Tue, 11 May 2010 17:10:53 +0100 Chris Wilson
> > wrote:
> >
> > > On Tue, 11 May 2010 20:30:07 +0530, Jaswinder Si
On Tue, 11 May 2010 19:22:14 +0100 Chris Wilson
wrote:
> + reloc_offset = src_priv->gtt_offset;
> for (page = 0; page < page_count; page++) {
> - void *s, *d = kmalloc(PAGE_SIZE, GFP_ATOMIC);
> + void __iomem *s;
> + void *d;
> +
> + d =
On Tue, 11 May 2010 19:52:31 +0100
Chris Wilson wrote:
> On Tue, 11 May 2010 11:35:55 -0400, Andrew Morton
> wrote:
> > No, io_mapping_map_atomic_wc() cannot be used from [soft]irq context:
> > it hardwires use of KM_USER0. I suggest that io_mapping_create_wc(),
> >
On Wed, 12 May 2010 08:22:49 +1000
Dave Airlie wrote:
> On Wed, May 12, 2010 at 5:57 AM, Chris Wilson
> wrote:
> > On Tue, 11 May 2010 12:10:01 -0700, Andrew Morton
> > wrote:
> >> On Tue, 11 May 2010 19:52:31 +0100
> >> Chris Wilson wrote:
> >&
On Wed, 12 May 2010 08:51:05 +1000
Dave Airlie wrote:
> On Wed, May 12, 2010 at 8:32 AM, Andrew Morton
> wrote:
> > On Wed, 12 May 2010 08:22:49 +1000
> > Dave Airlie wrote:
> >
> >> On Wed, May 12, 2010 at 5:57 AM, Chris Wilson
> >> wrote:
> &g
On Wed, 12 May 2010 09:17:09 +1000
Dave Airlie wrote:
> >> >> and
> >> >> this codepath is called from non-irq contexts just as much as irq
> >> >> contexts.
> >> >
> >> > That's fine. __As long as we do a local_irq_disable(), KM_IRQ0 can be
> >> > used from both irq- and non-irq contexts. __All
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 7 Jun 2010 17:32:04 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=16148
>
>Summary: page allocation failure. order:1, mode:0x50d0
On Fri, 11 Jun 2010 10:46:07 +0200 Thomas Hellstrom
wrote:
> >>>
> >>>
> >> David, I have a vague feeling that we've been round this loop before..
> >>
> >> Why does agp_alloc_page_array() use __GFP_NORETRY? It's pretty unusual
> >> and it's what caused this spew.
> >>
> >> There's noth
On Fri, 11 Jun 2010 22:22:28 +0200
Thomas Hellstrom wrote:
> >>> cc'ing Thomas, who added this, I expect we could drop the NORETRY or
> >>> just add NOWARN. Though an order 1 page alloc failure isn't a pretty
> >>> sight, not sure how a vmalloc fallback could save us.
> >>>
> >>>
> >>>
>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
(switching back to email, actually)
On Sun, 13 Jun 2010 13:01:57 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=16148
>
>
> Mikko C. changed:
>
>
On Thu, 1 Jul 2010 09:40:52 +0200 Nico Schottelius
wrote:
> Good morning!
>
> A short report on what's broken in 2.6.35-rc3-00262-g984bc96 with
> the Lenovo X201:
So you see two post-2.6.34 regressions?
> == xrandr ==
>
> After using xrandr several times in xorg, the screen gets
> "fancy": b
(Rafael, Maciej: two probably-separate post-2.6.34 regressions here)
On Tue, 06 Jul 2010 22:22:17 +1000
Andrew Hendry wrote:
>
> Some extra messages when booting with -rc4. Didn't get them in -rc3.
> [1.387013] swapper:1 freeing invalid memtype bf788000-bf789000
> [1.387409] swapper:1 f
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sun, 1 Aug 2010 08:55:49 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=16488
Innocuous-looking one-liner is said to have made Milan's X server eve
On Mon, 30 Aug 2010 10:02:36 +0200
Karsten Mehrhoff wrote:
> Using the same .config from 2.6.35.3 to compile 2.5.36.4 results in a
> heavy load with 2.6.35.4.
A regression within -stable is rather bad.
> Example:
>
> Difference between 2.6.35.1/2/3 and 2.6.35.4 while watching some videos:
>
On Wed, 22 Sep 2010 23:10:10 +0200 Alessandro Guido
wrote:
> I have this traces in my logs (full dmesg attached).
>
> idr_remove called for id=0 which is not allocated.
> Pid: 1136, comm: Xorg Not tainted 2.6.36-rc5-49-gc79bd89 #1
> Call Trace:
> [] ? printk+0x18/0x1a
> [] idr_remove+0x73/0
On Wed, 25 Aug 2010 15:59:09 -0500
Matt Mackall wrote:
> On Tue, 2010-08-24 at 10:37 -0500, Christoph Lameter wrote:
> > On Tue, 24 Aug 2010, Matt Mackall wrote:
> >
> > > kmalloc-321113344 1113344 32 1281 : tunables00
> > > 0 : slabdata 8698 8698 0
> > >
> > >
That was quick, thanks.
On Mon, 27 Sep 2010 21:08:36 +0100
Chris Wilson wrote:
> Hook the GEM vm open/close ops into the generic drm vm open/close so
> that the vma entries are created and destroy appropriately.
Please update the changelog to indicate that it fixes a memory leak.
> Reported-by
On Thu, 16 Feb 2012 13:01:36 +0100
Daniel Vetter wrote:
> drm/i915 wants to read/write more than one page in its fastpath
> and hence needs to prefault more than PAGE_SIZE bytes.
>
> I've checked the callsites and they all already clamp size when
> calling fault_in_pages_* to the same as for the
On Fri, 24 Feb 2012 14:34:31 +0100
Daniel Vetter wrote:
> > > --- a/include/linux/pagemap.h
> > > +++ b/include/linux/pagemap.h
> > > @@ -408,6 +408,7 @@ extern void add_page_wait_queue(struct page *page,
> > > wait_queue_t *waiter);
> > > static inline int fault_in_pages_writeable(char __user
* to the same as for the subsequent
> __copy_to|from_user and hence don't rely on the implicit clamping
> to PAGE_SIZE.
>
> Also kill a copy&pasted spurious space in both functions while at it.
>
> v2: As suggested by Andrew Morton, add a multipage parameter to both
>
On Thu, 1 Mar 2012 00:14:53 +0100
Daniel Vetter wrote:
> I'll redo this patch by adding _multipage versions of these 2 functions
> for i915.
OK, but I hope "for i915" doesn't mean "private to"! Put 'em in
pagemap.h, for maintenance reasons and because they are generic.
Making them inline is a
On Mon, 30 Aug 2010 10:02:36 +0200
Karsten Mehrhoff wrote:
> Using the same .config from 2.6.35.3 to compile 2.5.36.4 results in a
> heavy load with 2.6.35.4.
A regression within -stable is rather bad.
> Example:
>
> Difference between 2.6.35.1/2/3 and 2.6.35.4 while watching some videos:
>
On Wed, 22 Sep 2010 23:10:10 +0200 Alessandro Guido wrote:
> I have this traces in my logs (full dmesg attached).
>
> idr_remove called for id=0 which is not allocated.
> Pid: 1136, comm: Xorg Not tainted 2.6.36-rc5-49-gc79bd89 #1
> Call Trace:
> [] ? printk+0x18/0x1a
> [] idr_remove+0x73/0x
On Wed, 25 Aug 2010 15:59:09 -0500
Matt Mackall wrote:
> On Tue, 2010-08-24 at 10:37 -0500, Christoph Lameter wrote:
> > On Tue, 24 Aug 2010, Matt Mackall wrote:
> >
> > > kmalloc-321113344 1113344 32 1281 : tunables00
> > > 0 : slabdata 8698 8698 0
> > >
> > >
That was quick, thanks.
On Mon, 27 Sep 2010 21:08:36 +0100
Chris Wilson wrote:
> Hook the GEM vm open/close ops into the generic drm vm open/close so
> that the vma entries are created and destroy appropriately.
Please update the changelog to indicate that it fixes a memory leak.
> Reported-by
On Thu, 19 May 2011 08:21:36 +0200 Uwe Kleine-K?nig wrote:
> I'm not sure that the things that radeon_cp_init does are sane.
Some more details here might help someone fix it.
> Maybe
> add a comment that it is the only known stopper to make
> platform_device_register_resndata __init_or_module a
ed commit message and modified to short-circuit panic_timeout < 0
> > > > instead of testing panic_timeout >= 0. -Mandeep ]
> > > > Signed-off-by: Mandeep Singh Baines
> > > > Cc: Dave Airlie
> > > > Cc: Andrew Morton
> > > > Cc: dr
> References : https://lkml.org/lkml/2011/11/12/11
> >
>
> Andrea's patch already fixes this issue, which was reported first by
> Jiri Slaby. https://lkml.org/lkml/2011/11/11/93
> I remember Andrew Morton taking this patch in his -mm tree. But it is
> not in mainline
(cc dri-devel)
On Mon, 20 Dec 2010 23:58:21 +0300 Michael Tokarev wrote:
> Hello.
>
> A weird problem here, and I'm looking for help in
> an attempt to solve it.
>
> Ever since KMS went into kernel and I tried turning
> it on, the scrolling speed on the resulting "text"
> console (with kms it
On Thu, 1 Jul 2010 09:40:52 +0200 Nico Schottelius wrote:
> Good morning!
>
> A short report on what's broken in 2.6.35-rc3-00262-g984bc96 with
> the Lenovo X201:
So you see two post-2.6.34 regressions?
> == xrandr ==
>
> After using xrandr several times in xorg, the screen gets
> "fancy": bl
(Rafael, Maciej: two probably-separate post-2.6.34 regressions here)
On Tue, 06 Jul 2010 22:22:17 +1000
Andrew Hendry wrote:
>
> Some extra messages when booting with -rc4. Didn't get them in -rc3.
> [1.387013] swapper:1 freeing invalid memtype bf788000-bf789000
> [1.387409] swapper:1 f
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 7 Jun 2010 17:32:04 GMT
bugzilla-daemon at bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=16148
>
>Summary: page allocation failure. order:1, mode:0x5
On Fri, 11 Jun 2010 10:46:07 +0200 Thomas Hellstrom
wrote:
> >>>
> >>>
> >> David, I have a vague feeling that we've been round this loop before..
> >>
> >> Why does agp_alloc_page_array() use __GFP_NORETRY? It's pretty unusual
> >> and it's what caused this spew.
> >>
> >> There's noth
On Fri, 11 Jun 2010 22:22:28 +0200
Thomas Hellstrom wrote:
> >>> cc'ing Thomas, who added this, I expect we could drop the NORETRY or
> >>> just add NOWARN. Though an order 1 page alloc failure isn't a pretty
> >>> sight, not sure how a vmalloc fallback could save us.
> >>>
> >>>
> >>>
>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
(switching back to email, actually)
On Sun, 13 Jun 2010 13:01:57 GMT
bugzilla-daemon at bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=16148
>
>
> Mikko C. changed:
>
>
(cc dri-devel)
On Wed, 5 May 2010 00:22:16 +0200
Nils Radtke wrote:
> Hi,
>
> It happens quite often that X crashes for unknown reasons but this time
> there it's left us a note, this BUG:
>
> BUG: unable to handle kernel NULL pointer dereference at 01e4
> IP: [] i915_gem_object_move_to
(cc dri-devel)
On Wed, 5 May 2010 00:51:38 +0200
Nils Radtke wrote:
> Hi,
>
> Some more kernel NULL ptr deref, a lot of scheduling while atomic
> (probably due to first bug occurred) and again this "last sysfs file"
> from wireless. ath5k is a real source of trouble here:
>
> - resume f
On Tue, 11 May 2010 17:10:53 +0100 Chris Wilson
wrote:
> On Tue, 11 May 2010 20:30:07 +0530, Jaswinder Singh Rajput gmail.com> wrote:
> > Hello,
> >
> > With latest git kernel, I am getting following DRM error and not
> > getting XWindows :
>
> [snip]
>
> Hmm, there are still patches for cap
On Tue, 11 May 2010 19:19:26 +0100 Chris Wilson
wrote:
> On Tue, 11 May 2010 10:48:18 -0400, Andrew Morton linux-foundation.org> wrote:
> >
> > On Tue, 11 May 2010 17:10:53 +0100 Chris Wilson > chris-wilson.co.uk> wrote:
> >
> > > On Tue, 11 May 2010
On Tue, 11 May 2010 19:22:14 +0100 Chris Wilson
wrote:
> + reloc_offset = src_priv->gtt_offset;
> for (page = 0; page < page_count; page++) {
> - void *s, *d = kmalloc(PAGE_SIZE, GFP_ATOMIC);
> + void __iomem *s;
> + void *d;
> +
> + d =
On Tue, 11 May 2010 19:52:31 +0100
Chris Wilson wrote:
> On Tue, 11 May 2010 11:35:55 -0400, Andrew Morton linux-foundation.org> wrote:
> > No, io_mapping_map_atomic_wc() cannot be used from [soft]irq context:
> > it hardwires use of KM_USER0. I suggest that io
On Wed, 12 May 2010 08:22:49 +1000
Dave Airlie wrote:
> On Wed, May 12, 2010 at 5:57 AM, Chris Wilson
> wrote:
> > On Tue, 11 May 2010 12:10:01 -0700, Andrew Morton > linux-foundation.org> wrote:
> >> On Tue, 11 May 2010 19:52:31 +0100
> >> Chris Wilson wr
On Wed, 12 May 2010 08:51:05 +1000
Dave Airlie wrote:
> On Wed, May 12, 2010 at 8:32 AM, Andrew Morton
> wrote:
> > On Wed, 12 May 2010 08:22:49 +1000
> > Dave Airlie wrote:
> >
> >> On Wed, May 12, 2010 at 5:57 AM, Chris Wilson >> chris-wilson.co.uk&g
On Wed, 12 May 2010 09:17:09 +1000
Dave Airlie wrote:
> >> >> and
> >> >> this codepath is called from non-irq contexts just as much as irq
> >> >> contexts.
> >> >
> >> > That's fine. __As long as we do a local_irq_disable(), KM_IRQ0 can be
> >> > used from both irq- and non-irq contexts. __All
101 - 200 of 222 matches
Mail list logo
