[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 6980 bytes --]

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

            Bug ID: 106533
           Summary: r300_dri.so SIGSEGV in llvm_pipeline_generic under
                    Cinnamon
           Product: Mesa
           Version: 18.0
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: major
          Priority: medium
         Component: Drivers/Gallium/r300
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: anthonyjciani@gmail.com
        QA Contact: dri-devel@lists.freedesktop.org

Cinnamon issues SIGSEGV in (unknown function after) llvm_pipeline_generic.

Stack trace of thread 1400:
#0  0x00007f5442209333 n/a (n/a)
#1  0x00007f54554f7ed3 llvm_pipeline_generic (r300_dri.so)
#2  0x00007f54554f83af llvm_middle_end_linear_run (r300_dri.so)
#3  0x00007f5455415a54 vsplit_segment_simple_linear (r300_dri.so)
#4  0x00007f545540e858 draw_pt_arrays (r300_dri.so)
#5  0x00007f545540eca5 draw_vbo (r300_dri.so)
#6  0x00007f5455636569 r300_swtcl_draw_vbo (r300_dri.so)
#7  0x00007f54553fd6b7 cso_draw_arrays (r300_dri.so)
#8  0x00007f5455268c31 st_draw_quad (r300_dri.so)
#9  0x00007f5455252ff5 clear_with_quad (r300_dri.so)
#10 0x00007f547287d224 _cogl_framebuffer_gl_clear (libcogl.so.20)
#11 0x00007f54728c28da cogl_framebuffer_clear4f (libcogl.so.20)
#12 0x00007f5472fe283c _clutter_stage_do_pick (libclutter-1.0.so.0)
#13 0x00007f5472fbf3b9 _clutter_input_device_update (libclutter-1.0.so.0)
#14 0x00007f5472fc801c _clutter_process_event (libclutter-1.0.so.0)
#15 0x00007f5472fde940 _clutter_stage_process_queued_events
(libclutter-1.0.so.0)
#16 0x00007f5472fca439 clutter_clock_dispatch (libclutter-1.0.so.0)
#17 0x00007f546d9bab77 g_main_context_dispatch (libglib-2.0.so.0)
#18 0x00007f546d9baf20 g_main_context_iterate.isra.23 (libglib-2.0.so.0)
#19 0x00007f546d9bb232 g_main_loop_run (libglib-2.0.so.0)
#20 0x00007f547539fe2c meta_run (libmuffin.so.0)
#21 0x000055640d5edce0 main (cinnamon)
#22 0x00007f546d3bcf2a __libc_start_main (libc.so.6)
#23 0x000055640d5eddda _start (cinnamon)

Stack trace of thread 1405:
#0  0x00007f546d486c6b __poll (libc.so.6)
#1  0x00007f546d9bae99 g_main_context_iterate.isra.23 (libglib-2.0.so.0)
#2  0x00007f546d9bafac g_main_context_iteration (libglib-2.0.so.0)
#3  0x00007f546d9baff1 glib_worker_main (libglib-2.0.so.0)
#4  0x00007f546d9e2486 g_thread_proxy (libglib-2.0.so.0)
#5  0x00007f546d75950b start_thread (libpthread.so.0)
#6  0x00007f546d49116f __clone (libc.so.6)

Stack trace of thread 1406:
#0  0x00007f546d486c6b __poll (libc.so.6)
#1  0x00007f546d9bae99 g_main_context_iterate.isra.23 (libglib-2.0.so.0)
#2  0x00007f546d9bb232 g_main_loop_run (libglib-2.0.so.0)
#3  0x00007f546dfa3b56 gdbus_shared_thread_func (libgio-2.0.so.0)
#4  0x00007f546d9e2486 g_thread_proxy (libglib-2.0.so.0)
#5  0x00007f546d75950b start_thread (libpthread.so.0)
#6  0x00007f546d49116f __clone (libc.so.6)

Stack trace of thread 1407:
#0  0x00007f546d486c6b __poll (libc.so.6)
#1  0x00007f546d9bae99 g_main_context_iterate.isra.23 (libglib-2.0.so.0)
#2  0x00007f546d9bafac g_main_context_iteration (libglib-2.0.so.0)
#3  0x00007f545417042d dconf_gdbus_worker_thread (libdconfsettings.so)
#4  0x00007f546d9e2486 g_thread_proxy (libglib-2.0.so.0)
#5  0x00007f546d75950b start_thread (libpthread.so.0)
#6  0x00007f546d49116f __clone (libc.so.6)

Stack trace of thread 1408:
#0  0x00007f546d75f82d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x00007f54689284f0 PR_WaitCondVar (libnspr4.so)
#2  0x00007f546b96ae41 _ZN2js12HelperThread10threadLoopEv (libmozjs-38.so)
#3  0x00007f546892e06b _pt_root (libnspr4.so)
#4  0x00007f546d75950b start_thread (libpthread.so.0)
#5  0x00007f546d49116f __clone (libc.so.6)

Stack trace of thread 1409:
#0  0x00007f546d75f82d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x00007f54689284f0 PR_WaitCondVar (libnspr4.so)
#2  0x00007f546b96ae41 _ZN2js12HelperThread10threadLoopEv (libmozjs-38.so)
#3  0x00007f546892e06b _pt_root (libnspr4.so)
#4  0x00007f546d75950b start_thread (libpthread.so.0)
#5  0x00007f546d49116f __clone (libc.so.6)

Stack trace of thread 1410:
#0  0x00007f546d75f82d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x00007f54689284f0 PR_WaitCondVar (libnspr4.so)
#2  0x00007f546b96ae41 _ZN2js12HelperThread10threadLoopEv (libmozjs-38.so)
#3  0x00007f546892e06b _pt_root (libnspr4.so)
#4  0x00007f546d75950b start_thread (libpthread.so.0)
#5  0x00007f546d49116f __clone (libc.so.6)

Stack trace of thread 1411:
#0  0x00007f546d75f82d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x00007f54689284f0 PR_WaitCondVar (libnspr4.so)
#2  0x00007f546b96ae41 _ZN2js12HelperThread10threadLoopEv (libmozjs-38.so)
#3  0x00007f546892e06b _pt_root (libnspr4.so)
#4  0x00007f546d75950b start_thread (libpthread.so.0)
#5  0x00007f546d49116f __clone (libc.so.6)

Stack trace of thread 1412:
#0  0x00007f546d75f82d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x00007f54689284f0 PR_WaitCondVar (libnspr4.so)
#2  0x00007f546b96ae41 _ZN2js12HelperThread10threadLoopEv (libmozjs-38.so)
#3  0x00007f546892e06b _pt_root (libnspr4.so)
#4  0x00007f546d75950b start_thread (libpthread.so.0)
#5  0x00007f546d49116f __clone (libc.so.6)

Stack trace of thread 1653:
#0  0x00007f546d48bb99 syscall (libc.so.6)
#1  0x00007f546da0062a g_cond_wait_until (libglib-2.0.so.0)
#2  0x00007f546d98f381 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0)
#3  0x00007f546d9e2e24 g_thread_pool_thread_proxy (libglib-2.0.so.0)
#4  0x00007f546d9e2486 g_thread_proxy (libglib-2.0.so.0)
#5  0x00007f546d75950b start_thread (libpthread.so.0)
#6  0x00007f546d49116f __clone (libc.so.6)

Stack trace of thread 1701:
#0  0x00007f546d48bb99 syscall (libc.so.6)
#1  0x00007f546da0062a g_cond_wait_until (libglib-2.0.so.0)
#2  0x00007f546d98f381 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0)
#3  0x00007f546d9e2e24 g_thread_pool_thread_proxy (libglib-2.0.so.0)
#4  0x00007f546d9e2486 g_thread_proxy (libglib-2.0.so.0)
#5  0x00007f546d75950b start_thread (libpthread.so.0)
#6  0x00007f546d49116f __clone (libc.so.6)

Stack trace of thread 1702:
#0  0x00007f546d48bb99 syscall (libc.so.6)
#1  0x00007f546da0062a g_cond_wait_until (libglib-2.0.so.0)
#2  0x00007f546d98f381 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0)
#3  0x00007f546d9e2e24 g_thread_pool_thread_proxy (libglib-2.0.so.0)
#4  0x00007f546d9e2486 g_thread_proxy (libglib-2.0.so.0)
#5  0x00007f546d75950b start_thread (libpthread.so.0)
#6  0x00007f546d49116f __clone (libc.so.6)


Notes: this bug exists in 17.2, 17.3 and 18.0 branches (17.1 untested, 17.0 not
compilable with llvm/clang 5.0.  Compiled from 18.0.3 source tarball via
rpmbuild based on Fedora 29 mesa-18.0.0-3 SRPM.  17.2 and 17.3 tested with
Fedora 27 binary packages.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 8383 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 3022 bytes --]

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

--- Comment #1 from Anthony Ciani <anthonyjciani@gmail.com> ---
Error occurs on two identical Dell Inspiron 1501's, one with 3GB of memory and
the other with 4GB.

00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD/ATI]
RS480/RS482/RS485 Host Bridge [1002:5950] (rev 10)
00:01.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RC4xx/RS4xx
PCI Bridge [int gfx] [1002:5a3f]
00:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RC4xx/RS4xx
PCI Express Port 2 [1002:5a37]
00:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RC4xx/RS4xx
PCI Express Port 3 [1002:5a38]
00:12.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] SB600
Non-Raid-5 SATA [1002:4380]
00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI0) [1002:4387]
00:13.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI1) [1002:4388]
00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI2) [1002:4389]
00:13.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI3) [1002:438a]
00:13.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI4) [1002:438b]
00:13.5 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
Controller (EHCI) [1002:4386]
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus
Controller [1002:4385] (rev 14)
00:14.1 IDE interface [0101]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 IDE
[1002:438c]
00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00
Azalia (Intel HDA) [1002:4383]
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD/ATI] SB600 PCI to
LPC Bridge [1002:438d]
00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to
PCI Bridge [1002:4384]
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] K8
[Athlon64/Opteron] Address Map [1022:1101]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] K8
[Athlon64/Opteron] DRAM Controller [1022:1102]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] K8
[Athlon64/Opteron] Miscellaneous Control [1022:1103]
01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] RS482M [Mobility Radeon Xpress 200] [1002:5975]
05:00.0 Network controller [0280]: Broadcom Limited BCM4311 802.11b/g WLAN
[14e4:4311] (rev 01)
08:00.0 Ethernet controller [0200]: Broadcom Limited BCM4401-B0 100Base-TX
[14e4:170c] (rev 02)
08:01.0 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro
Host Adapter [1180:0822] (rev 19)
08:01.1 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller
[1180:0843] (rev 01)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 3830 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 529 bytes --]

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

--- Comment #2 from Roland Scheidegger <sroland@vmware.com> ---
I suppose it crashes in the jit-compiled code (debug symbols should help with
identifying that, but not help any further if that's the case).
Can you print out the faulting instruction (gdb x/i address or so)?
Also, if that would be some SSE instruction, try to see if the memory operand
is aligned (or just not addressable).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1337 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 3694 bytes --]

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

michael.panzlaff@fau.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michael.panzlaff@fau.de

--- Comment #3 from michael.panzlaff@fau.de ---
Created attachment 139995
  --> https://bugs.freedesktop.org/attachment.cgi?id=139995&action=edit
registers, stack and jit function disassembly

(In reply to Roland Scheidegger from comment #2)
> I suppose it crashes in the jit-compiled code (debug symbols should help
> with identifying that, but not help any further if that's the case).
> Can you print out the faulting instruction (gdb x/i address or so)?
> Also, if that would be some SSE instruction, try to see if the memory
> operand is aligned (or just not addressable).

I've tried to get the game "Thimbleweed Park" to run and it seems like it's
crashing for a very similar reason. This is the stack trace:

#0  0x00007ffff7fdc000 in ?? ()
#1  0x00007ffff27288d8 in llvm_pipeline_generic (middle=middle@entry=0x2bc9110,
fetch_info=fetch_info@entry=0x7fffffffdf80, 
    in_prim_info=in_prim_info@entry=0x7fffffffdfa0) at
draw/draw_pt_fetch_shade_pipeline_llvm.c:408
#2  0x00007ffff2728f86 in llvm_middle_end_linear_run (middle=0x2bc9110,
start=0, count=<optimized out>, prim_flags=0)
    at draw/draw_pt_fetch_shade_pipeline_llvm.c:588
#3  0x00007ffff2635d56 in vsplit_segment_simple_linear (vsplit=0x2bc6340,
vsplit=0x2bc6340, icount=4, istart=0, flags=0) at draw/draw_pt_vsplit_tmp.h:226
#4  vsplit_run_linear (frontend=0x2bc6340, start=0, count=4) at
draw/draw_split_tmp.h:70
#5  0x00007ffff262d71a in draw_pt_arrays (draw=draw@entry=0x2ba3b20, prim=6,
start=0, count=count@entry=4) at draw/draw_pt.c:175
#6  0x00007ffff262df50 in draw_vbo (draw=0x2ba3b20, info=0x7fffffffe0d0,
info@entry=0x7fffffffe1a0) at draw/draw_pt.c:609
#7  0x00007ffff273b319 in r300_swtcl_draw_vbo (pipe=0x2b7ac80,
info=0x7fffffffe1a0) at r300_render.c:862
#8  0x00007ffff273d9e6 in r300_stencilref_draw_vbo (pipe=0x2b7ac80,
info=0x7fffffffe1a0) at r300_render_stencilref.c:113
#9  0x00007ffff261cce7 in cso_draw_arrays (cso=<optimized out>,
mode=mode@entry=6, start=start@entry=0, count=count@entry=4) at
cso_cache/cso_context.c:1724
#10 0x00007ffff2413ee4 in st_draw_quad (st=st@entry=0x2cbddb0, x0=x0@entry=-1,
y0=y0@entry=-0.899999976, x1=x1@entry=1, y1=y1@entry=0.899999976, z=1, 
    s0=s0@entry=0, t0=t0@entry=0, s1=s1@entry=0, t1=0,
color=color@entry=0x2c9a44c, num_instances=num_instances@entry=1) at
state_tracker/st_draw.c:435
#11 0x00007ffff23f8df1 in clear_with_quad (clear_buffers=<optimized out>,
ctx=0x2c987c0) at state_tracker/st_cb_clear.c:300
#12 st_Clear (ctx=0x2c987c0, mask=2) at state_tracker/st_cb_clear.c:454
#13 0x00007ffff2244dc5 in clear (no_error=false, mask=<optimized out>,
ctx=0x2c987c0) at main/clear.c:221
#14 _mesa_Clear (mask=<optimized out>) at main/clear.c:244
#15 0x000000000049e364 in ?? ()
#16 0x0000000000481fd3 in ?? ()
#17 0x000000000048359f in ?? ()
#18 0x00007ffff6c9aa87 in __libc_start_main (main=0x40e130, argc=1,
argv=0x7fffffffe5f8, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffffffe5e8) at
../csu/libc-start.c:310
#19 0x000000000040f04a in ?? ()

To answer your original question I've provided information (stack, registers,
assembly of jit function) in the attached text file.

PS: Hope I did everything correct. First time for me posting something on the
bugzilla.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 5428 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 2315 bytes --]

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

Roland Scheidegger <sroland@vmware.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maraeo@gmail.com

--- Comment #4 from Roland Scheidegger <sroland@vmware.com> ---
You have the same tcl-less chipset?
So the assembly shows the segfault isn't due to alignment, but simply because
it's a null pointer.
This is also mesa 18.0? I'm just asking because according to the line numbers
(r300_render_stencilref.c:113) it's doing two-sided stencil emulation, which I
can't see how it could happen with the emulated clear (which definitely doesn't
enable two-sided stencil), so that looks a little bit suspect. Although maybe
the line numbers aren't quite accurate due to optimization...

You could try setting (with a debug build) DRAW_USE_LLVM="0" and see if this
fixes the crash - and if it still crashes it should be easier to figure out
what pointer is zero.

You could print out the shader (with a debug build) with
GALLIVM_DEBUG=tgsi,ir,asm to see what the assembly really might do. I think
though this is trying to read a vertex buffer (for position probably) which
just isn't there.

Or you could try setting (with a debug build) DRAW_USE_LLVM="0" and see if this
fixes the crash - and if it still crashes it should be easier to figure out
what pointer is zero.

I think I have an idea why it might fail, but someone more familiar with the
u_upload stuff and r300 would have to look at it:
r300_set_vertex_buffers_swtcl() would provide the vertex buffers to draw, and I
suspect it's always setting NULL buffer, because I think it's going to be not a
user buffer, but there won't be a malloced_buffer neither - the u_upload code
will call r300_buffer_create() but it won't alloc the malloced_buffer because
the PIPE_BIND_CUSTOM bit will always be set (because r300->stream_uploader is
the same as r300->uploader which will set that by default).

I'm not quite sure actually how it's supposed to work, maybe the logic in
r300_buffer_create should always use the malloced_buffer path when !has_tcl?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 3710 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 351 bytes --]

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

--- Comment #5 from Marek Olšák <maraeo@gmail.com> ---
Created attachment 140026
  --> https://bugs.freedesktop.org/attachment.cgi?id=140026&action=edit
patch

Would you please test the attached patch? Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1340 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 6642 bytes --]

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

--- Comment #6 from Michael Panzlaff <michael.panzlaff@fau.de> ---
(In reply to Roland Scheidegger from comment #4)
> You have the same tcl-less chipset?

I'm sorry to say, but I don't really know what a tcl-less chipset is. I'm using
a Dell Latitude D531. Perhaps an lspci output helps?

00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD/ATI] RS690 Host Bridge
00:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RS690 PCI to PCI
Bridge (Internal gfx)
00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RS690 PCI to PCI
Bridge (PCI Express Port 1)
00:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RS690 PCI to PCI
Bridge (PCI Express Port 2)
00:12.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600
Non-Raid-5 SATA
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI0)
00:13.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI1)
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI2)
00:13.3 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI3)
00:13.4 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
(OHCI4)
00:13.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB
Controller (EHCI)
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller
(rev 14)
00:14.1 IDE interface: Advanced Micro Devices, Inc. [AMD/ATI] SB600 IDE
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia
(Intel HDA)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB600 PCI to LPC
Bridge
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI
Bridge
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron]
Address Map
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron]
DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RS690M [Radeon Xpress 1200/1250/1270]
03:01.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 21)
03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02)
09:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5755M Gigabit
Ethernet PCI Express (rev 02)
0b:00.0 Network controller: Broadcom Limited BCM4311 802.11a/b/g (rev 01)

> This is also mesa 18.0? I'm just asking because according to the line
> numbers (r300_render_stencilref.c:113) it's doing two-sided stencil
> emulation, which I can't see how it could happen with the emulated clear
> (which definitely doesn't enable two-sided stencil), so that looks a little
> bit suspect. Although maybe the line numbers aren't quite accurate due to
> optimization...

I initially used mesa 18.0.? from Debian Unstable but my latest tests with the
stacktrace we're made using mesa from the git repository (master). I sadly
can't really help with the stencil stuff. I know a bit of OpenGL but I
literally have no idea about the implementation behind it.

> You could try setting (with a debug build) DRAW_USE_LLVM="0" and see if this
> fixes the crash - and if it still crashes it should be easier to figure out
> what pointer is zero.

Still segfaults. Here is a stacktrace:
#0  util_format_r32g32b32_float_fetch_rgba_float (dst=0x7fffffffde70, src=0x0,
i=0, j=0) at util/u_format_table.c:10080
#1  0x00007ffff24a9032 in generic_run_one (vert=0x4521aa0, instance_id=0,
start_instance=0, elt=0, tg=<optimized out>) at
translate/translate_generic.c:629
#2  generic_run (translate=0x49c8bc0, start=<optimized out>, count=<optimized
out>, start_instance=0, instance_id=0, output_buffer=<optimized out>)
    at translate/translate_generic.c:723
#3  0x00007ffff244e040 in fetch (output=<optimized out>, fetch_info=<optimized
out>, fetch=
    {void (char *, const struct draw_fetch_info *, struct pt_fetch *)}
0x7ffff244dec3 <fetch_pipeline_generic+131>) at
draw/draw_pt_fetch_shade_pipeline.c:161
#4  fetch_pipeline_generic (middle=0x2bb8f60,
fetch_info=fetch_info@entry=0x7fffffffe010,
in_prim_info=in_prim_info@entry=0x7fffffffe030)
    at draw/draw_pt_fetch_shade_pipeline.c:268
#5  0x00007ffff244e48d in fetch_pipeline_linear_run (middle=<optimized out>,
start=<optimized out>, count=<optimized out>, prim_flags=<optimized out>)
    at draw/draw_pt_fetch_shade_pipeline.c:426
#6  0x00007ffff245368a in vsplit_segment_simple_linear (vsplit=0x2bb63a0,
vsplit=0x2bb63a0, icount=4, istart=0, flags=0) at draw/draw_pt_vsplit_tmp.h:226
#7  vsplit_run_linear (frontend=0x2bb63a0, start=0, count=4) at
draw/draw_split_tmp.h:60
#8  0x00007ffff244b4a8 in draw_pt_arrays (draw=draw@entry=0x2ba3980, prim=6,
start=0, count=count@entry=4) at draw/draw_pt.c:149
#9  0x00007ffff244b9c4 in draw_vbo (draw=0x2ba3980, info=0x7fffffffe150,
info@entry=0x7fffffffe1f0) at draw/draw_pt.c:564
#10 0x00007ffff257a5c9 in r300_swtcl_draw_vbo (pipe=0x2b7aae0,
info=0x7fffffffe1f0) at r300_render.c:862
#11 0x00007ffff2439de7 in cso_draw_arrays (cso=<optimized out>,
mode=mode@entry=6, start=start@entry=0, count=count@entry=4) at
cso_cache/cso_context.c:1724
#12 0x00007ffff222ec59 in st_draw_quad (st=st@entry=0x2d3a290, x0=x0@entry=-1,
y0=y0@entry=-0.899999976, x1=x1@entry=1, y1=y1@entry=0.899999976, z=1, 
    s0=s0@entry=0, t0=t0@entry=0, s1=s1@entry=0, t1=0,
color=color@entry=0x2d1692c, num_instances=num_instances@entry=1) at
state_tracker/st_draw.c:428
#13 0x00007ffff2213c39 in clear_with_quad (clear_buffers=<optimized out>,
ctx=0x2d14ca0) at state_tracker/st_cb_clear.c:293
#14 st_Clear (ctx=0x2d14ca0, mask=2) at state_tracker/st_cb_clear.c:445
#15 0x000000000049e364 in ?? ()
#16 0x0000000000481fd3 in ?? ()
#17 0x000000000048359f in ?? ()
#18 0x00007ffff6c9aa87 in __libc_start_main (main=0x40e130, argc=1,
argv=0x7fffffffe5f8, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffffffe5e8) at
../csu/libc-start.c:310
#19 0x000000000040f04a in ?? ()

> You could print out the shader (with a debug build) with
> GALLIVM_DEBUG=tgsi,ir,asm to see what the assembly really might do. I think
> though this is trying to read a vertex buffer (for position probably) which
> just isn't there.

I'll provide a new attachment with the output of that.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 7825 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 391 bytes --]

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

--- Comment #7 from Michael Panzlaff <michael.panzlaff@fau.de> ---
Created attachment 140027
  --> https://bugs.freedesktop.org/attachment.cgi?id=140027&action=edit
Crash with GALLIVM_DEBUG=tgsi,ir,asm

To provide the attachment for my previous reply.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1366 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 485 bytes --]

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

--- Comment #8 from Michael Panzlaff <michael.panzlaff@fau.de> ---
(In reply to Marek Olšák from comment #5)
> Created attachment 140026 [details] [review]
> patch
> 
> Would you please test the attached patch? Thanks.

Yay! It seems to have fixed it. It also fixed a crash I got in Cube 2
Sauerbraten (probably because of the same reason).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1627 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1022 bytes --]

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

--- Comment #9 from Roland Scheidegger <sroland@vmware.com> ---
(In reply to Michael Panzlaff from comment #6)
> (In reply to Roland Scheidegger from comment #4)
> > You have the same tcl-less chipset?
> 
> I'm sorry to say, but I don't really know what a tcl-less chipset is. I'm
> using a Dell Latitude D531. Perhaps an lspci output helps?
Sorry it's not actually really "tcl-less" by this generation. That was the term
used by ATI for "transform, clippling, lighting". But of course for r300
generation it's really just vertex shader hw. Which neither the rs480 nor rs690
have (but all discrete r300 based chips do), it's all done in software. So,
it's not quite the same chipset than what the OP got but they behave pretty
much the same (I think rs690 would be somewhat faster though than rs480, but
not sure anymore...).
Glad Marek has a patch to get it working again!

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1976 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 583 bytes --]

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

Marek Olšák <maraeo@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #10 from Marek Olšák <maraeo@gmail.com> ---
Thanks for testing. I pushed the patch as
17a42062ccdb3bf5624435db9598e4353756771f. Closing.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2110 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 859 bytes --]

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

--- Comment #11 from Anthony Ciani <anthonyjciani@gmail.com> ---
Thanks.  That patch resolved the issue with clear_with_quad and Cinnamon as
well.  

While I was looking at the source, I did notice that many of the functions
assumed that their inputs were valid.  I was speculating that clear_with_quad
may have calculated a zero or even negative number of elements and passed that
along to draw_pt_arrays, which would have passed a NULL array or negative index
to llvm.

You might want to apply that patch to the 17.1, 17.2 and 17.3 branches as well.
 While researching this bug I saw several posts from people having llvm
problems on Radeon hardware with Fedora and Ubuntu versions based on the 17.x
branches.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1720 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 351 bytes --]

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

--- Comment #12 from Marek Olšák <maraeo@gmail.com> ---
17.x branches are no longer supported (and 18.0 is uncertain). Users and
distros are encouraged to switch to Mesa 18.1 if they want to obtain future
fixes.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1205 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel