..snip..
> > > I think the main question I have is how would you like to see patches for
> > > 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else?
> >
> > Yes that would be perfect. If there are any dependencies on the rc1, I
> > can rebase it on top of that.
>
> Yes, please,
On Tue, Jul 06, 2021 at 05:57:21PM +0100, Will Deacon wrote:
> On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wro
On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > FWIW I was pondering the question of whether to do something along those
> > lines or just scrap the default assignment entirely, so since I hadn't got
> > round
On Thu, Jun 24, 2021 at 11:58:57PM +0800, Claire Chang wrote:
> On Thu, Jun 24, 2021 at 11:56 PM Konrad Rzeszutek Wilk
> wrote:
> >
> > On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
> > >
> > >
> > > On 6/24/2021 7:48 AM, Will Deacon
On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or unexpected addresses, possibly
> leading to data
On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
>
>
> On 6/24/2021 7:48 AM, Will Deacon wrote:
> > Ok, diff below which attempts to tackle the offset issue I mentioned as
> > well. Qian Cai -- please can you try with these changes?
>
> This works fine.
Cool. Let me squash this patch
On Sat, Jun 19, 2021 at 11:40:31AM +0800, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or unexpected addresses, possibly
> leading to data
On Tue, Jun 15, 2021 at 09:27:02PM +0800, Claire Chang wrote:
> Always have the pointer to the swiotlb pool used in struct device. This
> could help simplify the code for other pools.
Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
error: patch failed: kernel/dma/swiotlb.c:339
> > do the set_memory_decrypted()+memset(). Is this okay or should
> > swiotlb_init_io_tlb_mem() add an additional argument to do this
> > conditionally?
>
> I'm actually not sure if this it okay. If not, will add an additional
> argument for it.
Any observations discovered? (Want to make sure
On Tue, May 18, 2021 at 02:51:52PM +0800, Claire Chang wrote:
> Still keep this function because directly using dev->dma_io_tlb_mem
> will cause issues for memory allocation for existing devices. The pool
> can't support atomic coherent allocation so we need to distinguish the
> per device pool
On Tue, May 18, 2021 at 02:48:35PM +0800, Claire Chang wrote:
> I didn't move this to a separate file because I feel it might be
> confusing for swiotlb_alloc/free (and need more functions to be
> non-static).
> Maybe instead of moving to a separate file, we can try to come up with
> a better
On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
> Hi all,
>
> swiotlb_max_segment is a rather strange "API" export by swiotlb.c,
> and i915 is the only (remaining) user.
>
> swiotlb_max_segment returns 0 if swiotlb is not in use, 1 if
> SWIOTLB_FORCE is set or swiotlb-zen is
On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote:
> On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote:
> > So one thing that has been on my mind for a while: I'd really like
> > to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb
> > to swiotlb
On Thu, Feb 04, 2021 at 11:49:23AM +, Robin Murphy wrote:
> On 2021-02-04 07:29, Christoph Hellwig wrote:
> > On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
> > > This patch converts several swiotlb related variables to arrays, in
> > > order to maintain stat/status for
On Thu, Aug 06, 2020 at 03:46:23AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:47ec5303 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16fe1dea90
>
.snip..
> > -u64 drm_get_max_iomem(void)
> > +bool drm_need_swiotlb(int dma_bits)
> > {
> > struct resource *tmp;
> > resource_size_t max_iomem = 0;
> >
> > + /*
> > +* Xen paravirtual hosts require swiotlb regardless of requested dma
> > +* transfer size.
> > +*
> > +*
On Fri, Feb 15, 2019 at 11:07:22AM -0500, Michael Labriola wrote:
> On Fri, Feb 15, 2019 at 12:57 AM Juergen Gross wrote:
> >
> > On 14/02/2019 18:57, Christoph Hellwig wrote:
> > > On Thu, Feb 14, 2019 at 07:03:38AM +0100, Juergen Gross wrote:
> > >>> The thing which is different between Xen PV
On Thu, Jan 10, 2019 at 04:26:43PM +0100, Sibren Vasse wrote:
> On Thu, 10 Jan 2019 at 14:57, Christoph Hellwig wrote:
> >
> > On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
> > >
> > > Hi Christoph,
> > >
> > >
> > > https://bugs.freedesktop.org/109234 (please ignore comments
On Thu, Jun 08, 2017 at 03:25:33PM +0200, Christoph Hellwig wrote:
> DMA_ERROR_CODE is going to go away, so don't rely on it.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
___
dri-devel mailing list
dri-devel@lists.freedesktop.
-xen.c | 14 ---
> drivers/xen/swiotlb-xen.c | 93
> ++
> include/xen/swiotlb-xen.h | 62 +---
> 4 files changed, 49 insertions(+), 137 deletions(-)
Yeeey!
Revi
On Tue, Apr 18, 2017 at 09:42:20AM -0600, Logan Gunthorpe wrote:
>
>
> On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote:
> > Interesting that you didn't CC any of the maintainers. Could you
> > do that in the future please?
>
> Please read the cover le
On Tue, Apr 18, 2017 at 02:13:59PM +, David Laight wrote:
> From: Logan Gunthorpe
> > Sent: 13 April 2017 23:05
> > Straightforward conversion to the new helper, except due to
> > the lack of error path, we have to warn if unmapable memory
> > is ever present in the sgl.
Interesting that you
On Tue, Dec 20, 2016 at 09:42:46AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 19, 2016 at 03:16:44PM +0100, Juergen Gross wrote:
> > On 19/12/16 13:29, Chris Wilson wrote:
> > > On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote:
> > >> With recent
On Mon, Dec 19, 2016 at 03:16:44PM +0100, Juergen Gross wrote:
> On 19/12/16 13:29, Chris Wilson wrote:
> > On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote:
> >> With recent 4.10 kernel the graphics isn't coming up under Xen. First
> >> failure message is:
> >>
> >> [ 46.656649]
On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote:
> The dma-mapping core and the implementations do not change the
> DMA attributes passed by pointer. Thus the pointer can point to const
> data. However the attributes do not have to be a bitfield. Instead
> unsigned long will
On Wed, Aug 26, 2015 at 04:31:50PM -0400, Jerome Glisse wrote:
> On Wed, Aug 26, 2015 at 03:44:52PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Aug 26, 2015 at 03:26:42PM -0400, Jerome Glisse wrote:
> > > On Wed, Aug 26, 2015 at 03:02:31PM -0400, Konrad Rzeszutek Wilk wro
On Wed, Aug 26, 2015 at 03:26:42PM -0400, Jerome Glisse wrote:
> On Wed, Aug 26, 2015 at 03:02:31PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Aug 26, 2015 at 02:52:02PM -0400, jglisse at redhat.com wrote:
> > > From: Jérôme Glisse
> > >
> > > Some d
simple helpers to check if any of
Why is it unreliable?
> the dma_ops associated with a device points to the swiotlb functions,
> making swiotlb check reliable for a device.
>
> Signed-off-by: Jérôme Glisse
> Cc: Konrad Rzeszutek Wilk
> Cc: Alex Deucher
> Cc: Ben S
gned-off-by: Jérôme Glisse
> Reviewed-by: Mario Kleiner
> Tested-by: Michel Dänzer
> Cc: Thomas Hellstrom
> Cc: Konrad Rzeszutek Wilk
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 8 +---
> 1 file changed, 1 insertion(+), 7
me Glisse
> Reviewed-by: Mario Kleiner
> Cc: Michel Dänzer
> Cc: Thomas Hellstrom
> Cc: Konrad Rzeszutek Wilk
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletio
On Tue, May 19, 2015 at 08:33:59PM +0900, Alexandre Courbot wrote:
> On 05/16/2015 04:55 AM, Konrad Rzeszutek Wilk wrote:
> >On Fri, May 15, 2015 at 04:09:54PM +0900, Alexandre Courbot wrote:
> >>dma_alloc_coherent() can return memory in the vmalloc range.
> >>v
On Fri, May 15, 2015 at 04:09:54PM +0900, Alexandre Courbot wrote:
> dma_alloc_coherent() can return memory in the vmalloc range.
> virt_to_page() cannot handle such addresses and crashes. This
> patch detects such cases and obtains the struct page * using
> vmalloc_to_page() instead.
>
>
nd deallocation.
>
> Signed-off-by: Jérôme Glisse
> Reviewed-by: Mario Kleiner
> Tested-by: Michel Dänzer
> Cc: Thomas Hellstrom
> Cc: Konrad Rzeszutek Wilk
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 9 ++---
> 1
On Wed, Nov 12, 2014 at 06:03:49PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 November 2014 09:18:59 Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 12, 2014 at 01:39:05PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > dma_alloc_coheren
On Wed, Nov 12, 2014 at 01:39:05PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> dma_alloc_coherent() returns a kernel virtual address that is part of
> the linear range. Passing such an address to virt_to_page() is illegal
> on non-coherent architectures. This causes the kernel to
ellstrom wrote:
> >>>>On 08/10/2014 05:11 AM, Mario Kleiner wrote:
> >>>>>Resent this time without HTML formatting which lkml doesn't like.
> >>>>>Sorry.
> >>>>>
> >>>>>On 08/09/2014 03:58 PM, Thomas Hellstrom
On August 9, 2014 1:39:39 AM EDT, Thomas Hellstrom
wrote:
>Hi.
>
Hey Thomas!
>IIRC I don't think the TTM DMA pool allocates coherent pages more than
>one page at a time, and _if that's true_ it's pretty unnecessary for
>the
>dma subsystem to route those allocations to CMA. Maybe Konrad could
On Fri, Jul 11, 2014 at 08:29:56AM +0200, Daniel Vetter wrote:
> On Thu, Jul 10, 2014 at 09:08:24PM +, Tian, Kevin wrote:
> > actually I'm curious whether it's still necessary to __detect__ PCH. Could
> > we assume a 1:1 mapping between GPU and PCH, e.g. BDW already hard
> > code the
On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> > At some level, maybe Paolo is right. Ignore existing drivers and ask
> > intel developers to update their drivers to do something sane on
> > hypervisors, even if they do ugly
On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > &
On Sat, May 31, 2014 at 12:00:45PM +0900, Tetsuo Handa wrote:
> >From 4e8d1a83629c5966bfd401c5f2187355624194f2 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Sat, 31 May 2014 09:59:44 +0900
> Subject: [PATCH 3/5] gpu/drm/ttm: Use mutex_trylock() to avoid deadlock
> inside shrinker
On Thu, May 29, 2014 at 11:34:59PM +0900, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > Konrad Rzeszutek Wilk wrote:
> > > On Sat, May 24, 2014 at 11:22:09PM +0900, Tetsuo Handa wrote:
> > > > Hello.
> > > >
> > > > I tried to
On Thu, May 29, 2014 at 06:47:49AM +0900, Tetsuo Handa wrote:
> Konrad Rzeszutek Wilk wrote:
> > On Sat, May 24, 2014 at 11:22:09PM +0900, Tetsuo Handa wrote:
> > > Hello.
> > >
> > > I tried to test whether it is OK (from point of view o
On Sat, May 24, 2014 at 11:22:09PM +0900, Tetsuo Handa wrote:
> Hello.
>
> I tried to test whether it is OK (from point of view of reentrant) to use
> mutex_lock() or mutex_lock_killable() inside shrinker functions when shrinker
> functions do memory allocation, for
On Tue, May 20, 2014 at 01:40:40AM +0100, Dave Airlie wrote:
>
> cc'ing dri-devel.
It looks pretty simple and correct . I can test it tomorrow and make sure it
works
right.
>
> > >From d0d57745ba23faf605b0f249b57d283fe1a8ee60 Mon Sep 17 00:00:00 2001
> > From: Tetsuo Handa
> > Date: Mon, 19
Hey,
I should know this but I am bit behind on the latest of the drm-debug
tools. Is there a way to figure out which applications are using
GEM/TTM buffers? Or just even a simpler - which application is using
which DRM pages?
Michael (CC-ed here) is finding that TTM is hitting the memory ceiling
Yijing Wang wrote:
>Fix acpi_evaluate_object() return value check,
>shoud acpi_status not int.
Should be?
Your mailer also ate the word 'to' .
>
>Signed-off-by: Yijing Wang
>---
>
>v1->v2: Add CC to the related subsystem MAINTAINERS.
>
>---
> drivers/gpu/drm/i915/intel_acpi.c |
I keep on getting this:
Any thoughts? I hadn't tried to do a bisection or such.
[ 1784.126124] Console: switching to colour VGA+ 80x25
[ 1784.128286] drm_kms_helper: drm: unregistered panic notifier
[ 1784.133601] [drm] radeon: finishing device.
[ 1784.135934] BUG: unable to handle kernel NULL
On Mon, Nov 04, 2013 at 05:57:39AM -0800, Thomas Hellstrom wrote:
> The code handles three different cases:
> 1) physical page addresses. The ttm page array is used.
> 2) DMA subsystem addresses. A scatter-gather list is used.
> 3) Coherent pages. The ttm dma pool is used, together with the
On Mon, Nov 04, 2013 at 05:57:38AM -0800, Thomas Hellstrom wrote:
> Used by the vmwgfx driver
That looks OK to me. And baremetal should not be
affected as the Intel VT-d driver turns of the SWIOTLB
driver - so it will still use the classic ttm pool code.
Reviewed-by: Konrad Rzeszutek W
On Mon, Nov 04, 2013 at 05:57:37AM -0800, Thomas Hellstrom wrote:
> These patches makes the vmwgfx driver use the DMA API to obtain valid
> device addresses rather than blindly using physical addresses.
>
> The main motivation is to be able to use a virtual IOMMU in the future.
Ooooh. Neat! Are
On Tue, Oct 01, 2013 at 12:16:16PM +0200, Thomas Hellstrom wrote:
Jerome, Konrad
Forgive an ignorant question, but it appears like both Nouveau and
Radeon may use pci_map_page() when populating TTMs on
pages obtained using the ordinary (not DMA pool). These pages will,
if I understand
On Sat, Sep 21, 2013 at 07:39:10AM +0400, Alex Ivanov wrote:
21.09.2013, в 1:27, Alex Deucher alexdeuc...@gmail.com написал(а):
On Tue, Sep 17, 2013 at 3:33 PM, Alex Ivanov gnido...@p0n4ik.tk wrote:
17.09.2013, в 18:24, Alex Deucher alexdeuc...@gmail.com написал(а):
On Tue, Sep 17,
On Tue, Sep 10, 2013 at 01:20:57PM +0400, Alex Ivanov wrote:
Alex,
09.09.2013, в 21:43, Alex Deucher alexdeuc...@gmail.com написал(а):
On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov gnido...@p0n4ik.tk wrote:
Folks,
We (people at linux-parisc @ vger.kernel.org mail list) are trying to
On Sun, Sep 08, 2013 at 02:10:58PM +0200, Markus Trippelsdorf wrote:
Currently radeon devices are not properbly shutdown during kexec. This
properly
cases a varity of issues, e.g. dpm initialization failures.
Fix this by implementing a radeon_pci_shutdown function, that unloads
the driver
airl...@redhat.com
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
drivers/gpu/drm/ttm/ttm_agp_backend.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers
On Wed, Aug 28, 2013 at 06:58:37PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 28.08.2013, 12:43 -0400 schrieb Konrad Rzeszutek Wilk:
> > On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote:
> > > Signed-off-by: Lucas Stach
> > > ---
> > > drive
On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote:
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 4
> drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>
On Wed, Aug 28, 2013 at 09:28:57AM +0200, Lucas Stach wrote:
> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
> > On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
> > > MSIs were only problematic on some old, broken chipsets. But now that we
> > > already see systems where PCI
On Wed, Aug 28, 2013 at 09:28:57AM +0200, Lucas Stach wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where
On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote:
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
On Wed, Aug 28, 2013 at 06:58:37PM +0200, Lucas Stach wrote:
Am Mittwoch, den 28.08.2013, 12:43 -0400 schrieb Konrad Rzeszutek Wilk:
On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote:
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4
> > > +EXPORT_SYMBOL(is_dmabuf_sync_supported);
> >
> > _GPL ?
> >
> > I would also prefix it with 'dmabuf_is_sync_supported' just to make
> > all of the libraries call start with 'dmabuf'
> >
>
> Seems better. Will change it to dmabuf_is_sync_supported, and use
> EXPORT_SYMBOL_GPL.
One thing
+EXPORT_SYMBOL(is_dmabuf_sync_supported);
_GPL ?
I would also prefix it with 'dmabuf_is_sync_supported' just to make
all of the libraries call start with 'dmabuf'
Seems better. Will change it to dmabuf_is_sync_supported, and use
EXPORT_SYMBOL_GPL.
One thing thought - while I
On Tue, Aug 13, 2013 at 06:19:35PM +0900, Inki Dae wrote:
> This patch adds a buffer synchronization framework based on DMA BUF[1]
> and and based on ww-mutexes[2] for lock mechanism.
>
> The purpose of this framework is to provide not only buffer access control
> to CPU and DMA but also
On Tue, Aug 13, 2013 at 06:19:35PM +0900, Inki Dae wrote:
This patch adds a buffer synchronization framework based on DMA BUF[1]
and and based on ww-mutexes[2] for lock mechanism.
The purpose of this framework is to provide not only buffer access control
to CPU and DMA but also easy-to-use
On Wed, Aug 07, 2013 at 12:09:32PM +0200, Daniel Vetter wrote:
> This fixes a WARN in i915_gem_free_object when the
> obj->pages_pin_count isn't 0.
>
> v2: Add locking to unmap, noticed by Chris Wilson. Note that even
> though we call unmap with our own dev->struct_mutex held that won't
> result
On Wed, Aug 07, 2013 at 12:09:32PM +0200, Daniel Vetter wrote:
This fixes a WARN in i915_gem_free_object when the
obj-pages_pin_count isn't 0.
v2: Add locking to unmap, noticed by Chris Wilson. Note that even
though we call unmap with our own dev-struct_mutex held that won't
result in an
Hey Alex,
Your recent patch "31f731a drm/radeon/dpm: fix calculations in
si_calculate_leakage_for_v_and_t_formula" causes a build regression:
drivers/built-in.o: In function `si_calculate_leakage_for_v_and_t_formula':
/home/build/linux-linus/drivers/gpu/drm/radeon/si_dpm.c:1770: undefined
Hey Alex,
Your recent patch 31f731a drm/radeon/dpm: fix calculations in
si_calculate_leakage_for_v_and_t_formula causes a build regression:
drivers/built-in.o: In function `si_calculate_leakage_for_v_and_t_formula':
/home/build/linux-linus/drivers/gpu/drm/radeon/si_dpm.c:1770: undefined
On Fri, Jul 26, 2013 at 04:37:32PM -0400, Ilia Mirkin wrote:
> On Fri, Jul 26, 2013 at 2:28 PM, konrad wilk
> wrote:
> > I just saw this on a box of mine (rc1 worked) I hadn't done yet a bisection.
> > Any suggestions?
> >
> > ring 0 polarity 1
> > [6.023776] Already setup the GSI :22
> >
On Fri, Jul 26, 2013 at 04:37:32PM -0400, Ilia Mirkin wrote:
On Fri, Jul 26, 2013 at 2:28 PM, konrad wilk konrad.w...@oracle.com wrote:
I just saw this on a box of mine (rc1 worked) I hadn't done yet a bisection.
Any suggestions?
ring 0 polarity 1
[6.023776] Already setup the GSI
the backport, including the original git commit
> id to .
>
> thanks,
>
> greg k-h
>
> -- original commit in Linus's tree --
>
> >From 1625e7e549c50fb57a1e1ab1cb0f5735c84c9029 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk
>
the original git commit
id to sta...@vger.kernel.org.
thanks,
greg k-h
-- original commit in Linus's tree --
From 1625e7e549c50fb57a1e1ab1cb0f5735c84c9029 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Mon, 24 Jun 2013 11:47
> So after a bit of irc chatting with Maarten this seems to be more
> involved. The above check is to cache the dma mapping, but the
> implementation is bogus in tons of ways:
> - If direction changes we don't bother with unmaping and freeing the
> mapping, but simply leak it.
> - This will break
So after a bit of irc chatting with Maarten this seems to be more
involved. The above check is to cache the dma mapping, but the
implementation is bogus in tons of ways:
- If direction changes we don't bother with unmaping and freeing the
mapping, but simply leak it.
- This will break if the
James Simmons wrote:
>
>> Am Freitag, 28. Juni 2013, 13:31:50 schrieb Dave Airlie:
>> > Okay drm-next is pretty big, possibly the biggest ever.
>> >
>> > Outstanding things I know about, and will merge, if they arrive
>soon:
>> > exynos -next
>> > nouveau -next
>> >
>> > Big things I've
James Simmons jsimm...@infradead.org wrote:
Am Freitag, 28. Juni 2013, 13:31:50 schrieb Dave Airlie:
Okay drm-next is pretty big, possibly the biggest ever.
Outstanding things I know about, and will merge, if they arrive
soon:
exynos -next
nouveau -next
Big things I've merged:
> >>Dave.
> >
> > Hey Dave
> > Of course I will investigate.
> >
> > The SWIOTLB is unfortunately used because it is a fallback (and I am the
> > maintainer of it) and if a real IOMMU is activated it can be mitigated
> > differently. When you say 'passed through' you mean in terms of an IOMMU
Dave.
Hey Dave
Of course I will investigate.
The SWIOTLB is unfortunately used because it is a fallback (and I am the
maintainer of it) and if a real IOMMU is activated it can be mitigated
differently. When you say 'passed through' you mean in terms of an IOMMU
in a guest?
On Tue, Jun 25, 2013 at 11:03:01AM -0400, Jerome Glisse wrote:
> On Fri, Jun 21, 2013 at 3:28 PM, Konrad Rzeszutek Wilk
> wrote:
> > Hey,
> >
> > I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18
> > (3.9.6) I can get it to boot and work just
On Tue, Jun 25, 2013 at 11:03:01AM -0400, Jerome Glisse wrote:
On Fri, Jun 21, 2013 at 3:28 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
Hey,
I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18
(3.9.6) I can get it to boot and work just fine with Xen
Dave Airlie wrote:
>On Tue, Jun 25, 2013 at 4:34 AM, Konrad Rzeszutek Wilk
> wrote:
>> On Mon, Jun 24, 2013 at 08:26:18PM +0200, Daniel Vetter wrote:
>>> On Mon, Jun 24, 2013 at 7:32 PM, Konrad Rzeszutek Wilk
>>> wrote:
>>> > On Mon, Jun 24, 201
On Mon, Jun 24, 2013 at 08:26:18PM +0200, Daniel Vetter wrote:
> On Mon, Jun 24, 2013 at 7:32 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Mon, Jun 24, 2013 at 07:09:12PM +0200, Daniel Vetter wrote:
> >> On Mon, Jun 24, 2013 at 11:47:48AM -0400, Konrad Rzeszutek Wilk wro
On Mon, Jun 24, 2013 at 07:09:12PM +0200, Daniel Vetter wrote:
> On Mon, Jun 24, 2013 at 11:47:48AM -0400, Konrad Rzeszutek Wilk wrote:
> > Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
> > ("drm/i915: create compact dma scatter lists for gem objects") makes
>
he '.get_pages' and the
i915_gem_gtt_prepare_object to retry with smaller max gap of the
amount of PFNs that can be combined together - but with this issue
discovered during rc7 that might be too risky.
Reported-and-Tested-by: Konrad Rzeszutek Wilk
CC: Chris Wilson
CC: Imre Deak
CC: Daniel Vetter
CC: Da
Hey Dave, Chris, Imre,
Attached is a fix that makes v3.10-rc6 boot on Intel HD 4000 when SWIOTLB
bounce buffer is in usage. The SWIOTLB can only handle up to 512KB swath
of memory to create bounce buffers for and Imre's patch made it possible
to provide more than to the DMA API which caused it
On Sat, Jun 22, 2013 at 03:22:59PM +0100, Chris Wilson wrote:
> On Fri, Jun 21, 2013 at 10:03:43PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jun 21, 2013 at 03:28:28PM -0400, Konrad Rzeszutek Wilk wrote:
> > > Hey,
> >
> > CC-ing I
On Sat, Jun 22, 2013 at 03:22:59PM +0100, Chris Wilson wrote:
On Fri, Jun 21, 2013 at 10:03:43PM -0400, Konrad Rzeszutek Wilk wrote:
On Fri, Jun 21, 2013 at 03:28:28PM -0400, Konrad Rzeszutek Wilk wrote:
Hey,
CC-ing Imre,
Imre, your patch 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
' and the
i915_gem_gtt_prepare_object to retry with smaller max gap of the
amount of PFNs that can be combined together - but with this issue
discovered during rc7 that might be too risky.
Reported-and-Tested-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
CC: Chris Wilson ch...@chris-wilson.co.uk
CC: Imre Deak
Hey Dave, Chris, Imre,
Attached is a fix that makes v3.10-rc6 boot on Intel HD 4000 when SWIOTLB
bounce buffer is in usage. The SWIOTLB can only handle up to 512KB swath
of memory to create bounce buffers for and Imre's patch made it possible
to provide more than to the DMA API which caused it
On Mon, Jun 24, 2013 at 07:09:12PM +0200, Daniel Vetter wrote:
On Mon, Jun 24, 2013 at 11:47:48AM -0400, Konrad Rzeszutek Wilk wrote:
Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
(drm/i915: create compact dma scatter lists for gem objects) makes
certain assumptions about the under
On Mon, Jun 24, 2013 at 08:26:18PM +0200, Daniel Vetter wrote:
On Mon, Jun 24, 2013 at 7:32 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Mon, Jun 24, 2013 at 07:09:12PM +0200, Daniel Vetter wrote:
On Mon, Jun 24, 2013 at 11:47:48AM -0400, Konrad Rzeszutek Wilk wrote:
Git
Dave Airlie airl...@gmail.com wrote:
On Tue, Jun 25, 2013 at 4:34 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Mon, Jun 24, 2013 at 08:26:18PM +0200, Daniel Vetter wrote:
On Mon, Jun 24, 2013 at 7:32 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Mon, Jun 24, 2013
On Fri, Jun 21, 2013 at 03:28:28PM -0400, Konrad Rzeszutek Wilk wrote:
> Hey,
CC-ing Imre,
Imre, your patch 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
("drm/i915: create compact dma scatter lists for gem objects") is the cause
of the regression.
If I revert your patch it boots fin
I am wondering is if there are some fallbacks when the
underlaying IOMMU can't deal with a request for contingous regions
that are more than 2MB?
Thanks.
>From a681a4adb4738c32cb1acdf6f5161bf877816b01 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Date: Fri
wondering is if there are some fallbacks when the
underlaying IOMMU can't deal with a request for contingous regions
that are more than 2MB?
Thanks.
From a681a4adb4738c32cb1acdf6f5161bf877816b01 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Fri, 21 Jun 2013 11
On Fri, Jun 21, 2013 at 03:28:28PM -0400, Konrad Rzeszutek Wilk wrote:
Hey,
CC-ing Imre,
Imre, your patch 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
(drm/i915: create compact dma scatter lists for gem objects) is the cause
of the regression.
If I revert your patch it boots fine without any
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote:
> Hi all,
>
> So I've taken a look again at the locking mess in our fbdev support and cried.
> Fixing up the console_lock mess around the fbdev notifier will be real work,
> semanatically the fbdev layer does lots of stupid things
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote:
Hi all,
So I've taken a look again at the locking mess in our fbdev support and cried.
Fixing up the console_lock mess around the fbdev notifier will be real work,
semanatically the fbdev layer does lots of stupid things (like
1 - 100 of 474 matches
Mail list logo
