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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Comment # 6 on bug 106533 from
(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=""
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:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux