[Nouveau] [Bug 87819] [NVAC] EQ overflowing
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
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
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
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
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