[Nouveau] [Bug 87819] [NVAC] EQ overflowing

2015-02-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=87819

--- Comment #19 from Oleg Kravchenko  ---
Created attachment 113652
  --> https://bugs.freedesktop.org/attachment.cgi?id=113652&action=edit
Xorg.0.log for X-1.15.2-r1 freeze with nouveau from linux-3.14.31

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 87819] [NVAC] EQ overflowing

2015-02-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=87819

--- Comment #18 from Oleg Kravchenko  ---
Hello! I have the same issue, after restoring from memory suspend ("echo mem >
/sys/power/state")

(EE) [mi] EQ overflowing.  Additional events will be discarded until existing
events are processed.
(EE) 
(EE) Backtrace:
(EE) 0: /usr/bin/X (xorg_backtrace+0x42) [0x57bfe2]
(EE) 1: /usr/bin/X (mieqEnqueue+0x213) [0x55e83b]
(EE) 2: /usr/bin/X (QueuePointerEvents+0x5a) [0x44bf4a]
(EE) 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f227fb18000+0x5704)
[0x7f227fb1d704]
(EE) 4: /usr/bin/X (0x40+0x71558) [0x471558]
(EE) 5: /usr/bin/X (0x40+0x98bd6) [0x498bd6]
(EE) 6: /lib64/libpthread.so.0 (0x7f2286ee8000+0x116b0) [0x7f2286ef96b0]
(EE) 7: /lib64/libc.so.6 (ioctl+0x7) [0x7f2285c15907]
(EE) 8: /usr/lib64/libdrm.so.2 (drmIoctl+0x34) [0x7f2286cdb984]
(EE) 9: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1e) [0x7f2286cddb36]
(EE) 10: /usr/lib64/libdrm_nouveau.so.2 (nouveau_bo_wait+0x89) [0x7f22827025c9]
(EE) 11: /usr/lib64/xorg/modules/drivers/nouveau_drv.so (0x7f2282908000+0x6a93)
[0x7f228290ea93]
(EE) 12: /usr/lib64/xorg/modules/libexa.so (0x7f2281a78000+0xac47)
[0x7f2281a82c47]
(EE) 13: /usr/bin/X (0x40+0x16d363) [0x56d363]
(EE) 14: /usr/bin/X (0x40+0xbcce5) [0x4bcce5]
(EE) 15: /usr/bin/X (0x40+0x32bae) [0x432bae]
(EE) 16: /usr/bin/X (0x40+0x3561e) [0x43561e]
(EE) 17: /usr/bin/X (0x40+0x3937a) [0x43937a]
(EE) 18: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f2285b54df5]
(EE) 19: /usr/bin/X (0x40+0x24de1) [0x424de1]
(EE) 
(EE) [mi] These backtraces from mieqEnqueue may point to a culprit higher up
the stack.
(EE) [mi] mieq is *NOT* the cause.  It is a victim.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


Re: [Nouveau] [PATCH v3 1/6] make RAM device optional

2015-02-18 Thread Ben Skeggs
On 18 Feb 2015 17:08, "Alexandre Courbot"  wrote:
>
> On Wed, Feb 18, 2015 at 8:01 AM, Ben Skeggs  wrote:
> > On Tue, Feb 17, 2015 at 5:47 PM, Alexandre Courbot 
wrote:
> >> Having a RAM device does not make sense for chips like GK20A which have
> >> no dedicated video memory. The dummy RAM device that we used so far
> >> works as a temporary band-aid, but in the long-term it is desirable for
> >> the driver to be able to work without any kind of VRAM.
> >>
> >> This patch adds a few conditionals in places where a RAM device was
> >> assumed to be present and allows some more objects to be allocated from
> >> the TT domain, allowing Nouveau to handle GPUs for which
> >> pfb->ram == NULL.
> >>
> >> Signed-off-by: Alexandre Courbot 
> >> ---
> >>  drm/nouveau/nouveau_display.c |  8 +++-
> >>  drm/nouveau/nouveau_ttm.c |  3 +++
> >>  drm/nouveau/nv84_fence.c  | 14 +++---
> >>  drm/nouveau/nvkm/engine/device/base.c |  9 ++---
> >>  drm/nouveau/nvkm/subdev/clk/base.c|  2 +-
> >>  drm/nouveau/nvkm/subdev/fb/base.c | 26 ++
> >>  drm/nouveau/nvkm/subdev/ltc/gf100.c   | 10 +-
> >>  7 files changed, 55 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/drm/nouveau/nouveau_display.c
b/drm/nouveau/nouveau_display.c
> >> index 860b0e2d4181..68ee0af22eea 100644
> >> --- a/drm/nouveau/nouveau_display.c
> >> +++ b/drm/nouveau/nouveau_display.c
> >> @@ -869,13 +869,19 @@ nouveau_display_dumb_create(struct drm_file
*file_priv, struct drm_device *dev,
> >> struct drm_mode_create_dumb *args)
> >>  {
> >> struct nouveau_bo *bo;
> >> +   uint32_t domain;
> >> int ret;
> >>
> >> args->pitch = roundup(args->width * (args->bpp / 8), 256);
> >> args->size = args->pitch * args->height;
> >> args->size = roundup(args->size, PAGE_SIZE);
> >>
> >> -   ret = nouveau_gem_new(dev, args->size, 0,
NOUVEAU_GEM_DOMAIN_VRAM, 0, 0, &bo);
> >> +   if (nvxx_fb(&nouveau_drm(dev)->device)->ram)
> > For these checks in the drm, it's probably better to use
> > nouveau_drm(dev)->device.info.ram_size.
>
> I wonder - in other places (e.g. clock, ltc) we don't have access to
> nouveau_drm, so IIUC we need to rely on pfb->ram there.
Correct.

>Wouldn't it be
> more confusing to use two different ways to check the presence of VRAM
> when we could stick to a single one?
It's best to think of nvkm/ as a separate entity, and it will be at some
point (drm load on its own, inside a vm), and drm might not be able to
access it's internal structures.

That's not the case now, so the code is fine as-is for the moment. But it's
worth keeping in mind.

Thanks,
Ben.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 87244] [NV94] X hangs, logs show kernel: nouveau E[ PFIFO][0000:01:00.0] still angry after 101 spins, halt followed by an X trace

2015-02-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=87244

--- Comment #14 from Aleksander Morgado  ---
Just for reference, I cherry-picked that fix for my 3.18.6 and I no longer get
the X stuck. Hoping it hits the stables soon...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 87244] [NV94] X hangs, logs show kernel: nouveau E[ PFIFO][0000:01:00.0] still angry after 101 spins, halt followed by an X trace

2015-02-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=87244

--- Comment #13 from Aleksander Morgado  ---
(In reply to Adam Williamson from comment #12)
> So Ben told me on IRC he'd committed a change that should address this, but
> I guess it didn't make it in time for 3.19 because I just hit it with 3.19
> stable :( Ben, any chance it could be backported for 3.19 updates? It's a
> pretty icky bug.

If it's not yet pulled by Linus, what's the kernel git tree where that was
submitted?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau