[Nouveau] [Bug 102135] WARN_ON hit when loading G71 with v4.13-rc4

https://bugs.freedesktop.org/show_bug.cgi?id=102135 --- Comment #3 from Ilia Mirkin --- Should be fixed by: https://github.com/skeggsb/nouveau/commit/33d8409a5cd51f347ab3f5b848b82b331ac7e279 -- You are receiving this mail because: You are the assignee for the

[Nouveau] [Bug 71900] [NV40] GPU lockup and segmentation fault of Nouveau-1.0.10 on PowerMac G5 with acceleration

https://bugs.freedesktop.org/show_bug.cgi?id=71900 --- Comment #13 from Ilia Mirkin --- Alex, which issue are you talking about? Like almost every issue where someone says "me too", they actually have a totally different issue. Here's a list of problems: - MSI is broken -

[Nouveau] [Bug 71900] [NV40] GPU lockup and segmentation fault of Nouveau-1.0.10 on PowerMac G5 with acceleration

https://bugs.freedesktop.org/show_bug.cgi?id=71900 --- Comment #12 from Alex Perez --- Ping, this bug is zombified. It's been open for nearly five years now, and hasn't had a comment in over two years. Ben, two years ago, you wrote "I plan on attempting to untangle the vm

[Nouveau] [PATCH 00/29] DRM API conversions

This patch set replaces the occurrences of drm_*_reference() and drm_*_unreference() with the new drm_*_get() and drm_*_put() functions. All patches in the series do the same thing, converting to the new APIs. I created patches per DRM driver as suggested by Daniel Vetter. Background: In the

Re: [Nouveau] [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property

On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_plane_set_property. > > Signed-off-by: Daniel Vetter [...] > drivers/gpu/drm/sti/sti_cursor.c|

Re: [Nouveau] [PATCH 3/3] drm/etnaviv: add thermal dependency

Hi Arnd, Am Mittwoch, den 26.07.2017, 15:53 +0200 schrieb Arnd Bergmann: > When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is > built-in, we get a link error: > > drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind': >

Re: [Nouveau] [PATCH] Add drm ioctl DRM_IOCTL_MODE_GETFB2 & associated helpers.

Hi Joe, On Tuesday 01 Aug 2017 10:24:25 Joe Kniss wrote: > On Tue, Aug 1, 2017 at 5:09 AM, Laurent Pinchart wrote: > > On Monday 31 Jul 2017 11:29:13 Joe Kniss wrote: > >> New getfb2 functionality uses drm_mode_fb_cmd2 struct to be symmetric > >> with addfb2. > > > > What's the use case for this

Re: [Nouveau] [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. > > The only special case is nouveau and tda988x which used one function > for both legacy modeset code and -nv50 atomic world instead of 2 > vtables. But amounts to exactly the same. > > v2:

Re: [Nouveau] [Intel-gfx] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

On 9 August 2017 at 09:42, Joe Kniss wrote: > Because all drivers currently use gem objects for framebuffer planes, > the virtual create_handle() is not required. This change adds a > struct drm_gem_object *gems[4] field to drm_framebuffer and removes > create_handle()

[Nouveau] [PATCH 17/29] drm/nouveau: switch to drm_*{get, put} helpers

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 functions to use the new APIs. Signed-off-by: Cihangir Akturk ---

Re: [Nouveau] [PATCH] Add drm ioctl DRM_IOCTL_MODE_GETFB2 & associated helpers.

Hi Joe, Thank you for the patch. On Monday 31 Jul 2017 11:29:13 Joe Kniss wrote: > New getfb2 functionality uses drm_mode_fb_cmd2 struct to be symmetric > with addfb2. What's the use case for this ? We haven't needed such an ioctl for so long that it seemed to me that userspace doesn't really

Re: [Nouveau] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

Den 09.08.2017 01.42, skrev Joe Kniss: Because all drivers currently use gem objects for framebuffer planes, the virtual create_handle() is not required. This change adds a struct drm_gem_object *gems[4] field to drm_framebuffer and removes create_handle() function pointer from

[Nouveau] [Bug 102135] WARN_ON hit when loading G71 with v4.13-rc4

https://bugs.freedesktop.org/show_bug.cgi?id=102135 --- Comment #2 from Ilia Mirkin --- The issue at hand being the multiple WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c:180 .nvkm_outp_init+0x170/0x2d0 which happen inside nvkm_disp_init.

[Nouveau] [Bug 102135] WARN_ON hit when loading G71 with v4.13-rc4

https://bugs.freedesktop.org/show_bug.cgi?id=102135 Alex Perez changed: What|Removed |Added Summary|WARN_ON hit when loading|WARN_ON hit when

[Nouveau] [Bug 102135] New: WARN_ON hit when loading G71 with v4.13-rc3

https://bugs.freedesktop.org/show_bug.cgi?id=102135 Bug ID: 102135 Summary: WARN_ON hit when loading G71 with v4.13-rc3 Product: xorg Version: unspecified Hardware: PowerPC OS: Linux (All) Status: NEW

[Nouveau] [Bug 102135] WARN_ON hit when loading G71 with v4.13-rc4

https://bugs.freedesktop.org/show_bug.cgi?id=102135 --- Comment #1 from Alex Perez --- Created attachment 133418 --> https://bugs.freedesktop.org/attachment.cgi?id=133418=edit attached G71 vbios from this board. -- You are receiving this mail because: You are the

Re: [Nouveau] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes wrote: > > Den 09.08.2017 01.42, skrev Joe Kniss: >> >> Because all drivers currently use gem objects for framebuffer planes, >> the virtual create_handle() is not required. This change adds a >> struct drm_gem_object *gems[4]

[Nouveau] [Bug 102106] xorg crashes when running gscan2pdf (libgtk2-perl) test case

https://bugs.freedesktop.org/show_bug.cgi?id=102106 --- Comment #4 from Ilia Mirkin --- Works for me... $ DISPLAY=:1 PERL5LIB="blib:lib:$PERL5LIB" perl t/114_cancel_save_pdf.t 1..1 test.jpg JPEG 70x46 70x46+0+0 8-bit sRGB 2649B 0.000u 0:00.000 ok 1 - can create a valid

[Nouveau] [Bug 100423] MMIO read of 00000000 FAULT at 022554 [ IBUS ]

https://bugs.freedesktop.org/show_bug.cgi?id=100423 --- Comment #5 from ros...@gmail.com --- I've bisected the issue. It happens with this commit: fb/gf100-: modify constructors to allow more customisation -- You are receiving this mail because: You are the assignee for the