:00.0: DRM: ttm_dma: Zero Alloc: 0
nouveau :01:00.0: DRM: ttm_dma: Swapped: 0
Signed-off-by: Tobias Klausmann
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
-functioning state.
Signed-off-by: Tobias Klausmann
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 5020265bfbd9..56a107f3a0e1 100644
hwmon.
On Fri, Jan 26, 2018 at 2:40 PM, Tobias Klausmann
wrote:
Not sure if i understand completely what you intend to say here, with this
we prevent hwmon from reporting utterly wrong temperature values returning
an error (we could return -EBUSY or somehting instead, granted), yet if the
device is
obias Klausmann
wrote:
This fixes wrong temperature outputs e.g. 511°C if the card is asleep.
Signed-off-by: Tobias Klausmann
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100
This fixes wrong temperature outputs e.g. 511°C if the card is asleep.
Signed-off-by: Tobias Klausmann
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
b/drivers/gpu
On 12/18/17 7:06 PM, Mike Galbraith wrote:
Greetings,
Kernel bound workloads seem to trigger the below for whatever reason.
I only see this when beating up NFS. There was a kworker wakeup
latency issue, but with a bandaid applied to fix that up, I can still
trigger this.
Hi,
i have seen
On 11/24/17 4:35 PM, Christian König wrote:
Am 24.11.2017 um 16:17 schrieb Tobias Klausmann:
On 11/24/17 3:54 PM, Daniel Vetter wrote:
On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote:
On 11/23/17 2:58 AM, Dave Airlie wrote:
On 23 November 2017 at 11:17, Laura Abbott
wrote
On 11/24/17 3:54 PM, Daniel Vetter wrote:
On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote:
On 11/23/17 2:58 AM, Dave Airlie wrote:
On 23 November 2017 at 11:17, Laura Abbott wrote:
Hi,
Fedora QA testing reported a panic when booting up VMs
using qmeu vga drivers
(https
On 11/23/17 2:58 AM, Dave Airlie wrote:
On 23 November 2017 at 11:17, Laura Abbott wrote:
Hi,
Fedora QA testing reported a panic when booting up VMs
using qmeu vga drivers
(https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)
[ 30.108507] [ cut here ]
[ 3
Hi,
Lgtm!
Reviewed-by: Tobias Klausmann
On 8/6/17 4:19 AM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
>
> This was helpful when debugging our earlier mpeg woes. May as well have it
> upstream.
>
> drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.c | 7 +
Looks good to me!
Reviewed-by: Tobias Klausmann
On 8/3/17 1:58 PM, Cihangir Akturk wrote:
> drm_*_reference() and drm_*_unreference() functions are just
> compatibility alias for drm_*_get() and drm_*_put() adn should not be
> used by new code. So convert all users of compatibility
b0 e8 38 fa ed c6 44 0f b6
[ 12.768508] ---[ end trace d9bb853af3659bd5 ]---
Signed-off-by: Tobias Klausmann
---
drivers/gpu/drm/drm_vblank.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index a233a6
fix it up.
> Otherwise we're back to the old style vblank horror show.
>
> Thanks, Daniel
>
>> On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann
>> wrote:
>>> mimic the behavior of vblank_disable_fn(), another caller of
>>> drm_vblank_disable_and_
The conversion is a nice catch, but i'd like to have a bit more context,
see below!
With a better description:
Tobias Klausmann
On 7/14/17 5:10 PM, Karol Herbst wrote:
Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
usage we could convert to WARN_ONCE?
R
On 7/14/17 3:41 PM, Mike Galbraith wrote:
On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:
All DRM did was to slip a
WARN_ON_ONCE() that nouveau triggers into a kernel module where such
things no longer warn, they blow the box out of the water.
BTW, turn that irksome WARN_ON_ONCE() in
On 7/12/17 7:19 PM, Mike Galbraith wrote:
On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote:
On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith wrote:
On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote:
On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote:
Some display stuff did change
Any idea on how to solve the problem. other than just reporting it?
But for now this adds a helpful error message... you may add my R-b.
On 20.05.2015 22:01, Ilia Mirkin wrote:
> Some newer chips have trouble coming up, and we get bad MMIO reads from
> them, like 0xbadf100. This ends up translati
On 26.11.2014 21:29, Michael Marineau wrote:
> On Mon, Nov 24, 2014 at 11:43 PM, Maarten Lankhorst
> wrote:
>> Hey,
>>
>> Op 22-11-14 om 21:16 schreef Michael Marineau:
>>> On Nov 22, 2014 11:45 AM, "Michael Marineau" wrote:
On Nov 22, 2014 8:56 AM, "Maarten Lankhorst" <
>>> maarten.lankho
On 19.11.2014 09:10, Maarten Lankhorst wrote:
> ...
> On the EDITED patch from fixed-fences-for-bisect, can you do the following:
>
> In nouveau/nv84_fence.c function nv84_fence_context_new, remove
>
> fctx->base.sequence = nv84_fence_read(chan);
>
> and add back
>
> nouveau_bo_wr32(priv->bo, chan-
On 19.11.2014 09:10, Maarten Lankhorst wrote:
> Hey,
>
> On 19-11-14 07:43, Michael Marineau wrote:
>> On 3.18-rc kernel's I have been intermittently experiencing GPU
>> lockups shortly after startup, accompanied with one or both of the
>> following errors:
>>
>> nouveau E[ PFIFO][:01:00.0] r
0x90 [i915]
[] ? dma_buf_release+0x23/0x80
[] ? __fput+0xcd/0x230
[] ? task_work_run+0x97/0xd0
[] ? do_notify_resume+0x79/0xa0
[] ? int_signal+0x12/0x17
---[ end trace 99a0c147e69ddcd1 ]---
Thanks,
Tobias Klausmann
___
dri-devel mailing list
dri-devel@lists.freed
0x90 [i915]
[] ? dma_buf_release+0x23/0x80
[] ? __fput+0xcd/0x230
[] ? task_work_run+0x97/0xd0
[] ? do_notify_resume+0x79/0xa0
[] ? int_signal+0x12/0x17
---[ end trace 99a0c147e69ddcd1 ]---
Thanks,
Tobias Klausmann
22 matches
Mail list logo
