[Nouveau] [Bug 92438] Segfault in pushbuf_kref when running the android emulator (qemu) on nv50

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92438

--- Comment #23 from Ilia Mirkin  ---
(In reply to Jim Blandy from comment #21)
> I have no idea what this code is supposed to be doing, but here's what I can
> infer:
> 
> The call to pushbuf_kref crashes because the `struct nouveau_bo *bo`
> argument is NULL, and cli_push_get tries to use it. The caller of
> pushbuf_kref, pushbuf_validate, is iterating over a list of brefs; the
> current bref's bo field is NULL.
> 
> This bref was created by nouveau_bufctx_refn, which was passed a NULL `bo`
> argument. Its caller is nvc0_add_resident, which was passed a `struct
> nv04_resource *` whose `bo` field is NULL.
> 
> This nv04_resource was created by a call to nouveau_buffer_create in which
> buffer->domain is never set to anything other than 0. Looking at
> nouveau_buffer_allocate, it seems like a domain of zero is a legitimate
> value; the last branch of the if-else chain asserts that this is the case.
> Since that path doesn't set buf->bo, it seems it's legitimate for buf->bo to
> be NULL.
> 
> pushbuf_kref seems adamant that bo should be non-NULL; both cli_push_get and
> cli_kref_get require it. At this point I'm lost: should nouveau_bufctx_refn
> never be passed a NULL bo? Should such a bufref never make it onto the list
> that pushbuf_validate sees? I'm not sure.
> 
> Here's the stack trace at the call to nouveau_bufctx_refn:
> 
> #0  nouveau_bufctx_refn (bctx=0x55b3eea0, bin=bin@entry=1, bo=0x0,
> flags=256) at bufctx.c:126
> #1  0x70c33154 in nvc0_add_resident (flags=256, res=0x55bf4800,
> bin=1, bufctx=) at nvc0/nvc0_winsys.h:29
> #2  nvc0_validate_vertex_buffers_shared (nvc0=0x55b3cf30) at
> nvc0/nvc0_vbo.c:407

Whoa, great analysis! And makes a *ton* more sense than my thought, which was
that the GPU hung and we ran out of GEM handles making pushbufs.

So this is one of those idiotic bo-less resources. Ugh. Will check if your
repro makes it happen for me too.

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

[Nouveau] [Bug 91557] [NVE4] freezes: HUB_INIT timed out

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91557

--- Comment #16 from Ilia Mirkin  ---
Update from OP on IRC: War00C800_0=1 makes it work

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104M [GeForce
GTX 870M] [10de:1199] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:1106]

-- 
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 92438] Segfault in pushbuf_kref when running the android emulator (qemu) on nv50

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92438

--- Comment #21 from Jim Blandy  ---
I have no idea what this code is supposed to be doing, but here's what I can
infer:

The call to pushbuf_kref crashes because the `struct nouveau_bo *bo` argument
is NULL, and cli_push_get tries to use it. The caller of pushbuf_kref,
pushbuf_validate, is iterating over a list of brefs; the current bref's bo
field is NULL.

This bref was created by nouveau_bufctx_refn, which was passed a NULL `bo`
argument. Its caller is nvc0_add_resident, which was passed a `struct
nv04_resource *` whose `bo` field is NULL.

This nv04_resource was created by a call to nouveau_buffer_create in which
buffer->domain is never set to anything other than 0. Looking at
nouveau_buffer_allocate, it seems like a domain of zero is a legitimate value;
the last branch of the if-else chain asserts that this is the case. Since that
path doesn't set buf->bo, it seems it's legitimate for buf->bo to be NULL.

pushbuf_kref seems adamant that bo should be non-NULL; both cli_push_get and
cli_kref_get require it. At this point I'm lost: should nouveau_bufctx_refn
never be passed a NULL bo? Should such a bufref never make it onto the list
that pushbuf_validate sees? I'm not sure.

Here's the stack trace at the call to nouveau_bufctx_refn:

#0  nouveau_bufctx_refn (bctx=0x55b3eea0, bin=bin@entry=1, bo=0x0,
flags=256) at bufctx.c:126
#1  0x70c33154 in nvc0_add_resident (flags=256, res=0x55bf4800,
bin=1, bufctx=) at nvc0/nvc0_winsys.h:29
#2  nvc0_validate_vertex_buffers_shared (nvc0=0x55b3cf30) at
nvc0/nvc0_vbo.c:407
#3  nvc0_vertex_arrays_validate (nvc0=0x55b3cf30) at nvc0/nvc0_vbo.c:504
#4  0x70c28e8e in nvc0_state_validate (nvc0=nvc0@entry=0x55b3cf30,
mask=mask@entry=4294967295, words=words@entry=8) at
nvc0/nvc0_state_validate.c:651
#5  0x70c33670 in nvc0_draw_vbo (pipe=0x55b3cf30,
info=0x7fffb9f0) at nvc0/nvc0_vbo.c:893
#6  0x708ec867 in st_draw_vbo (ctx=,
prims=0x7fffbab0, nr_prims=1, ib=0x0, index_bounds_valid=,
min_index=0, max_index=2, tfb_vertcount=0x0, indirect=0x0) at
state_tracker/st_draw.c:286
#7  0x708be81c in vbo_draw_arrays (ctx=0x77f22010, mode=4, start=0,
count=3, numInstances=1, baseInstance=0) at vbo/vbo_exec_array.c:645
#8  0x555b21b7 in tutorial_02::gl::Gl::DrawArrays (self=0x76868010,
mode=4, first=0, count=3) at
target/debug/build/glium-e8f4c0a69cec8d2d/out/gl_bindings.rs:11032
#9  0x555acee9 in
tutorial_02::ops::draw::draw
(context=0x76868010, framebuffer=..., vertex_buffers=0x7fffdc08,
indices=..., program=0x7fffd6f8, uniforms=0x557fc297 ,
draw_parameters=0x7fffd370, dimensions=...) at src/ops/draw.rs:320
#10 0x555aa751 in
tutorial_02::Frame.Surface::draw<::vertex::buffer::VertexBuffer,::index::NoIndices,glium::uniforms::uniforms::EmptyUniforms>
(self=0x7fffd508, vertex_buffer=0x7fffdc08,
index_buffer=0x7fffd8d0, program=0x7fffd6f8, uniforms=0x557fc297
, draw_parameters=0x7fffd370) at src/lib.rs:1083
#11 0x55576f84 in tutorial_02::main () at examples/tutorial-02.rs:48
#12 0x557ccf85 in
sys_common::unwind::try::try_fn::h13449604025847140769 ()
#13 0x557ca969 in __rust_try ()
#14 0x557ccc20 in rt::lang_start::h426b3aba4736785fsbx ()
#15 0x555b31da in main ()
(gdb)

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

[Nouveau] [Bug 92438] Segfault in pushbuf_kref when running the android emulator (qemu) on nv50

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92438

--- Comment #22 from Jim Blandy  ---
Steps to reproduce:

1) Install Rust from www.rust-lang.org, which provides the 'cargo' command.
2) git clone g...@github.com:tomaka/glium.git
3) cd glium
4) cargo build
5) cargo build --example tutorial-02
6) ./target/debug/examples/tutorial-02

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

[Nouveau] [PATCH] pci: enable c800 magic for Medion Erazer X7827

[Ilia Mirkin]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91557
Signed-off-by: Ilia Mirkin 
---
 drm/nouveau/nvkm/engine/device/pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drm/nouveau/nvkm/engine/device/pci.c 
b/drm/nouveau/nvkm/engine/device/pci.c
index e8eb14e..20318f4 100644
--- a/drm/nouveau/nvkm/engine/device/pci.c
+++ b/drm/nouveau/nvkm/engine/device/pci.c
@@ -678,6 +678,7 @@ nvkm_device_pci_10de_1189[] = {
 static const struct nvkm_device_pci_vendor
 nvkm_device_pci_10de_1199[] = {
{ 0x1458, 0xd001, "GeForce GTX 760" },
+   { 0x1462, 0x1106, "GeForce GTX 780M", { .War00C800_0 = true } }, /* 
Medion Erazer X7827 */
{}
 };
 
-- 
2.4.10

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

[Nouveau] [Bug 92438] Segfault in pushbuf_kref when running the android emulator (qemu) on nv50

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92438

--- Comment #20 from Jim Blandy  ---
I'm able to reproduce a crash with a very similar stack on Fedora 22, using the
glium Rust OpenGL bindings: https://github.com/tomaka/glium

Here's the stack trace I get:

Program received signal SIGSEGV, Segmentation fault.
0x702f66fc in pushbuf_kref () from /lib64/libdrm_nouveau.so.2
Missing separate debuginfos, use: dnf debuginfo-install
bzip2-libs-1.0.6-14.fc22.x86_64 elfutils-libelf-0.163-4.fc22.x86_64
elfutils-libs-0.163-4.fc22.x86_64 expat-2.1.0-10.fc22.x86_64
libattr-2.4.47-10.fc22.x86_64 libcap-2.24-7.fc22.x86_64
libdrm-2.4.61-3.fc22.x86_64 libedit-3.1-12.20150325cvs.fc22.x86_64
libffi-3.1-7.fc22.x86_64 libgcc-5.1.1-4.fc22.x86_64
libpciaccess-0.13.3-0.3.fc22.x86_64 libselinux-2.3-10.fc22.x86_64
libstdc++-5.1.1-4.fc22.x86_64 libwayland-client-1.7.0-1.fc22.x86_64
libwayland-server-1.7.0-1.fc22.x86_64 libX11-1.6.3-1.fc22.x86_64
libX11-devel-1.6.3-1.fc22.x86_64 libXau-1.0.8-4.fc22.x86_64
libxcb-1.11-8.fc22.x86_64 libXcursor-devel-1.1.14-4.fc22.x86_64
libXdamage-1.1.4-6.fc22.x86_64 libXext-1.3.3-2.fc22.x86_64
libXfixes-5.0.1-4.fc22.x86_64 libXi-devel-1.7.4-2.fc22.x86_64
libXrender-0.9.9-1.fc22.x86_64 libxshmfence-1.2-1.fc22.x86_64
libXxf86vm-devel-1.1.4-1.fc22.x86_64 llvm-libs-3.5.0-9.fc22.x86_64
mesa-dri-drivers-10.6.9-1.20151008.fc22.x86_64
mesa-libEGL-10.6.9-1.20151008.fc22.x86_64
mesa-libgbm-10.6.9-1.20151008.fc22.x86_64
mesa-libGL-10.6.9-1.20151008.fc22.x86_64
mesa-libglapi-10.6.9-1.20151008.fc22.x86_64
ncurses-libs-5.9-18.20150214.fc22.x86_64 pcre-8.37-5.fc22.x86_64
systemd-libs-219-25.fc22.x86_64 xz-libs-5.2.0-2.fc22.x86_64
zlib-1.2.8-7.fc22.x86_64
(gdb) where
#0  0x702f66fc in pushbuf_kref () from /lib64/libdrm_nouveau.so.2
#1  0x702f6db9 in pushbuf_validate () from /lib64/libdrm_nouveau.so.2
#2  0x70c28ecd in nvc0_state_validate () from
/usr/lib64/dri/nouveau_dri.so
#3  0x70c33670 in nvc0_draw_vbo () from /usr/lib64/dri/nouveau_dri.so
#4  0x708ec867 in st_draw_vbo () from /usr/lib64/dri/nouveau_dri.so
#5  0x708be81c in vbo_draw_arrays () from /usr/lib64/dri/nouveau_dri.so
#6  0x555b21b7 in tutorial_02::gl::Gl::DrawArrays (self=0x76868010,
mode=4, first=0, count=3) at
target/debug/build/glium-e8f4c0a69cec8d2d/out/gl_bindings.rs:11032
#7  0x555acee9 in
tutorial_02::ops::draw::draw
(context=0x76868010, framebuffer=..., vertex_buffers=0x7fffd548,
indices=..., program=0x7fffd038, uniforms=0x557fc297 ,
draw_parameters=0x7fffccb0, dimensions=...) at src/ops/draw.rs:320
#8  0x555aa751 in
tutorial_02::Frame.Surface::draw<::vertex::buffer::VertexBuffer,::index::NoIndices,glium::uniforms::uniforms::EmptyUniforms>
(self=0x7fffce48, vertex_buffer=0x7fffd548,
index_buffer=0x7fffd210, program=0x7fffd038, uniforms=0x557fc297
, draw_parameters=0x7fffccb0) at src/lib.rs:1083
#9  0x55576f84 in tutorial_02::main () at examples/tutorial-02.rs:48
#10 0x557ccf85 in
sys_common::unwind::try::try_fn::h13449604025847140769 ()
#11 0x557ca969 in __rust_try ()
#12 0x557ccc20 in rt::lang_start::h426b3aba4736785fsbx ()
#13 0x555b31da in main ()
(gdb)

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

[Nouveau] [Bug 92438] Segfault in pushbuf_kref when running the android emulator (qemu) on nv50

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92438

--- Comment #24 from Ilia Mirkin  ---
Hmmm... looks like rust isn't quite ready for prime-time -- there is no 'cargo'
gentoo ebuild. (Apparently cargo can't be built hermetically?) So I can't
repro.

I'm a little worried about how that buffer object came to be. It suggests we're
missing some PIPE_BIND_* flags somewhere, or something is creating a buffer
without any bind flags set. Can you look at the resource's "bind" property and
see what it is?

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

[Nouveau] [Bug 92438] Segfault in pushbuf_kref when running the android emulator (qemu) on nv50

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92438

--- Comment #25 from Ilia Mirkin  ---
I believe this is now possible with ARB_direct_state_access. While I add
support for this and add some asserts so that this doesn't happen in the
future, would either of you mind retesting with

MESA_EXTENSION_OVERRIDE=-GL_ARB_direct_state_access

which should prevent those endpoints from appearing? I somewhat doubt that this
is the b2g issue though, that seems to be using GLES2 which doesn't have
anything like this.

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

[Nouveau] [Bug 92761] New: dmesg full of nouveau E[ PIBUS][0000:01:00.0] GPC4: 0x5233e4 0xbadf1301 (0x01024215)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92761

Bug ID: 92761
   Summary: dmesg full of nouveau E[   PIBUS][:01:00.0] GPC4:
0x5233e4 0xbadf1301 (0x01024215)
   Product: xorg
   Version: unspecified
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: ascanio.al...@gmail.com
QA Contact: xorg-t...@lists.x.org

Created attachment 119321
  --> https://bugs.freedesktop.org/attachment.cgi?id=119321=edit
dmesg output

1. nouveau on Fedora 23
2. dmesg is full of 
[68759.141891] nouveau E[   PIBUS][:01:00.0] GPC4: 0x5233e4 0xbadf1301
(0x01024215)
[68759.161134] nouveau E[   PIBUS][:01:00.0] GPC4: 0x5233e4 0xbadf1301
(0x01024215)
[68759.172614] nouveau E[   PIBUS][:01:00.0] GPC4: 0x5233e4 0xbadf1301
(0x01024215)
[68759.172695] nouveau E[   PIBUS][:01:00.0] GPC4: 0x5233e4 0xbadf1301
(0x01024215)
[68759.279172] nouveau E[   PIBUS][:01:00.0] GPC4: 0x5233e4 0xbadf1301
(0x01024215)
[68759.293372] nouveau E[   PIBUS][:01:00.0] GPC4: 0x5233e4 0xbadf1301
(0x01024215)
[68759.305836] nouveau E[   PIBUS][:01:00.0] GPC4: 0x5233e4 0xbadf1301
(0x01024215)
[68759.305903] nouveau E[   PIBUS][:01:00.0] GPC4: 0x5233e4 0xbadf1301
(0x01024215)
[68759.470585] nouveau E[   PIBUS][:01:00.0] GPC4: 0x5233e4 0xbadf1301
(0x01024215)
[68759.474667] nouveau E[   PIBUS][:01:00.0] GPC4: 0x5233e4 0xbadf1301
(0x01024215)
3. kernel 4.2.3-300.fc23.x86_64
4. xorg-x11-drv-nouveau-1.0.12-0.3.fc23.x86_64
5. 01:00.0 VGA compatible controller: NVIDIA Corporation GK110 [GeForce GTX
780] (rev a1)

-- 
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