Summary: | [SNB+]Ogles3conform ES3-CTS.shaders.struct.uniform.sampler_array_vertex crash | ||
---|---|---|---|
Product: | Mesa | Reporter: | lu hua <huax.lu> |
Component: | Drivers/DRI/i965 | Assignee: | Kenneth Graunke <kenneth> |
Status: | VERIFIED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | idr |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
lu hua
2014-08-29 02:46:27 UTC
I didn't know this test ever passed. Was there ever a bisect? There was a patch for this on the gles3conform-v5 branch. Should we just land it? commit 4be2eb8bf6402bbe8aa640628464f00f992f53ff Author: Anuj Phogat <anuj.phogat@gmail.com> Date: Fri Aug 8 20:50:45 2014 -0700 i965: Make type_size()'s handling of samplers on vec4 and FS backends match Made following CTS tests to pass: ES3-CTS.shaders.struct.uniform.sampler_nested_vertex (crash) ES3-CTS.shaders.struct.uniform.sampler_array_vertex (crash) This is what Ken said about it: I noticed type_size() handles samplers differently between the vec4 and FS backends: brw_vec4_visitor.cpp: --------------------- case GLSL_TYPE_SAMPLER: /* Samplers take up one slot in UNIFORMS[], but they're baked in * at link time. */ return 1; brw_fs.cpp: ----------- case GLSL_TYPE_SAMPLER: /* Samplers take up no register space, since they're baked in at * link time. */ return 0; Changing the vec4 backend to "return 0" makes that test pass. It sure doesn't make sense to waste space for samplers. But, I've seen similar trouble in the FS backend: it doesn't count them in uniforms, but still tries to access arrays as if they took up space. The only reason it works out is because we reserve space for another 2 * MaxSamplerImageUnits uniforms for texture rectangle rescaling (in the FS backend only - texrect scaling is just broken in the vec4 backend, and always has been.) I think changing it to 0 is the right thing to do, but then we start calling virtual_grf_alloc(0) in some places, and that seems bad too. I'm not sure how the dynamic sampler stuff from ARB_gpu_shader5 affects this, if at all. Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Test on earlier commit, I don't catch a pass commit. On commit f043971097f2c707c3104845066ad2cc72f65708, It's fail but no crash. dEQP Core GL-CTS-2.0 (0x0052484b) starting.. target implementation = 'X11' Test case 'ES3-CTS.shaders.struct.uniform.sampler_array_vertex'.. Vertex compile time = 2.352000 ms Fragment compile time = 0.131000 ms Link time = 0.457000 ms Fail (Fail) DONE! Test run totals: Passed: 0/1 (0.00%) Failed: 1/1 (100.00%) Not supported: 0/1 (0.00%) Warnings: 0/1 (0.00%) Do you need the bisect for crash? If so, I will bisect it. Bisected it. The crash caused by commit c019105f3742b39ba6913235f85ddfb327a39d12. commit c019105f3742b39ba6913235f85ddfb327a39d12 Author: Matt Turner <mattst88@gmail.com> Date: Sun Jun 29 15:27:07 2014 -0700 i965: Make a common backend_reg class. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com> I don't think that bisect is correct. Assertion fails on c019105f3742b39ba6913235f85ddfb327a39d12 (bisect commit). Assertion fails on (c019105f3742b39ba6913235f85ddfb327a39d12~1 - previous commit). Fails but doesn't assert for me on origin/10.2 (e4752221679c4fd67d8b5688b5735d2a4d45275a). Oh, it's using an undefined value, so you hit it intermittently. I wouldn't worry about trying to bisect it. I did a little more digging. Valgrind produces the output below. All of the use-after-free problems are in memory freed by vec4_live_variables::~vec4_live_variables. This felt like a little bit of a red herring, so I added assert((src->reg * 4 + 0) < (virtual_grf_count * 4)); assert((src->reg * 4 + 1) < (virtual_grf_count * 4)); assert((src->reg * 4 + 2) < (virtual_grf_count * 4)); assert((src->reg * 4 + 3) < (virtual_grf_count * 4)); at line 227 of vec4_visitor::opt_cse_local. This got hit! src->reg was 18 and virtual_grf_count was 7. entry->generator has some information. Notice that src[1].reg is 18, but file is ATTR. Should this loop even process that? Looking at vec4_visitor::virtual_grf_alloc, it appears that virtual_grf_count is only incremented when a register with file == GRF is allocated. { <backend_instruction> = { <exec_node> = {next = 0x17dcc60, prev = 0x17df150}, ir = 0x144b770, annotation = 0x0, texture_offset = 0, offset = 0, mlen = 0 '\000', base_mrf = 0 '\000', target = 0 '\000', opcode = BRW_OPCODE_MAD, conditional_mod = BRW_CONDITIONAL_NONE, predicate = BRW_PREDICATE_NONE, predicate_inverse = false, writes_accumulator = false, force_writemask_all = false, no_dd_clear = false, no_dd_check = false, saturate = false }, dst = { <backend_reg> = { file = GRF, type = BRW_REGISTER_TYPE_F, reg = 4, reg_offset = 0, fixed_hw_reg = { type = BRW_REGISTER_TYPE_UD, file = 0, nr = 0, subnr = 0, negate = 0, abs = 0, vstride = 0, width = 0, hstride = 0, address_mode = 0, pad0 = 0, dw1 = { bits = { swizzle = 0, writemask = 0, indirect_offset = 0, pad1 = 0 }, f = 0, d = 0, ud = 0 } }, negate = false, abs = false }, writemask = 3, reladdr = 0x0 }, src = { { <backend_reg> = { file = UNIFORM, type = BRW_REGISTER_TYPE_F, reg = 1, reg_offset = 0, fixed_hw_reg = { type = BRW_REGISTER_TYPE_UD, file = 0, nr = 0, subnr = 0, negate = 0, abs = 0, vstride = 0, width = 0, hstride = 0, address_mode = 0, pad0 = 0, dw1 = { bits = { swizzle = 0, writemask = 0, indirect_offset = 0, pad1 = 0 }, f = 0, d = 0, ud = 0 } }, negate = false, abs = false }, swizzle = 170, reladdr = 0x0 }, { <backend_reg> = { file = ATTR, type = BRW_REGISTER_TYPE_F, reg = 18, reg_offset = 0, fixed_hw_reg = { type = BRW_REGISTER_TYPE_UD, file = 0, nr = 0, subnr = 0, negate = 0, abs = 0, vstride = 0, width = 0, hstride = 0, address_mode = 0, pad0 = 0, dw1 = { bits = { swizzle = 0, writemask = 0, indirect_offset = 0, pad1 = 0 }, f = 0, d = 0, ud = 0 } }, negate = false, abs = false }, swizzle = 84, reladdr = 0x0 }, { <backend_reg> = { file = GRF, type = BRW_REGISTER_TYPE_F, reg = 3, reg_offset = 0, fixed_hw_reg = { type = BRW_REGISTER_TYPE_UD, file = 0, nr = 0, subnr = 0, negate = 0, abs = 0, vstride = 0, width = 0, hstride = 0, address_mode = 0, pad0 = 0, dw1 = { bits = { swizzle = 0, writemask = 0, indirect_offset = 0, pad1 = 0 }, f = 0, d = 0, ud = 0 } }, negate = false, abs = false }, swizzle = 228, reladdr = 0x0 } }, shadow_compare = false, urb_write_flags = BRW_URB_WRITE_NO_FLAGS, header_present = false } ==30600== Invalid read of size 4 ==30600== at 0x7C5641A: brw::vec4_visitor::opt_cse_local(bblock_t*) (brw_vec4_cse.cpp:228) ==30600== by 0x7C565C4: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:256) ==30600== by 0x7C54F45: brw::vec4_visitor::run() (brw_vec4.cpp:1787) ==30600== by 0x7C551AC: brw_vs_emit (brw_vec4.cpp:1865) ==30600== by 0x7C716C9: do_vs_prog (brw_vs.c:295) ==30600== by 0x7C71F12: brw_vs_precompile (brw_vs.c:545) ==30600== by 0x7C4D103: brw_link_shader (brw_shader.cpp:79) ==30600== by 0x7B0B553: _mesa_glsl_link_shader (ir_to_mesa.cpp:3038) ==30600== by 0x7A174E0: link_program (shaderapi.c:915) ==30600== by 0x7A18C7E: _mesa_LinkProgram (shaderapi.c:1383) ==30600== by 0xBD6F01: glu::Program::linkProgram(unsigned int, unsigned int, unsigned int, std::string&, unsigned long&) (in /home/idr/devel/graphics/ESCTS-3.0.3.0-20140530.build/cts/glcts) ==30600== by 0xBD63F5: glu::Program::Program(glu::RenderContext const&, char const*, char const*) (in /home/idr/devel/graphics/ESCTS-3.0.3.0-20140530.build/cts/glcts) ==30600== Address 0x87f2a00 is 0 bytes inside a block of size 80 free'd ==30600== at 0x4A077E6: free (vg_replace_malloc.c:446) ==30600== by 0x7B98FFD: unsafe_free (ralloc.c:255) ==30600== by 0x7B98FDD: unsafe_free (ralloc.c:248) ==30600== by 0x7B99126: ralloc_free (ralloc.c:218) ==30600== by 0x7C5C5A2: brw::vec4_live_variables::~vec4_live_variables() (brw_vec4_live_variables.cpp:173) ==30600== by 0x7C5C810: brw::vec4_visitor::calculate_live_intervals() (brw_vec4_live_variables.cpp:267) ==30600== by 0x7C5659F: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:253) ==30600== by 0x7C54F45: brw::vec4_visitor::run() (brw_vec4.cpp:1787) ==30600== by 0x7C551AC: brw_vs_emit (brw_vec4.cpp:1865) ==30600== by 0x7C716C9: do_vs_prog (brw_vs.c:295) ==30600== by 0x7C71F12: brw_vs_precompile (brw_vs.c:545) ==30600== by 0x7C4D103: brw_link_shader (brw_shader.cpp:79) ==30600== ==30600== Invalid read of size 4 ==30600== at 0x7C5641E: brw::vec4_visitor::opt_cse_local(bblock_t*) (brw_vec4_cse.cpp:228) ==30600== by 0x7C565C4: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:256) ==30600== by 0x7C54F45: brw::vec4_visitor::run() (brw_vec4.cpp:1787) ==30600== by 0x7C551AC: brw_vs_emit (brw_vec4.cpp:1865) ==30600== by 0x7C716C9: do_vs_prog (brw_vs.c:295) ==30600== by 0x7C71F12: brw_vs_precompile (brw_vs.c:545) ==30600== by 0x7C4D103: brw_link_shader (brw_shader.cpp:79) ==30600== by 0x7B0B553: _mesa_glsl_link_shader (ir_to_mesa.cpp:3038) ==30600== by 0x7A174E0: link_program (shaderapi.c:915) ==30600== by 0x7A18C7E: _mesa_LinkProgram (shaderapi.c:1383) ==30600== by 0xBD6F01: glu::Program::linkProgram(unsigned int, unsigned int, unsigned int, std::string&, unsigned long&) (in /home/idr/devel/graphics/ESCTS-3.0.3.0-20140530.build/cts/glcts) ==30600== by 0xBD63F5: glu::Program::Program(glu::RenderContext const&, char const*, char const*) (in /home/idr/devel/graphics/ESCTS-3.0.3.0-20140530.build/cts/glcts) ==30600== Address 0x87f2a04 is 4 bytes inside a block of size 80 free'd ==30600== at 0x4A077E6: free (vg_replace_malloc.c:446) ==30600== by 0x7B98FFD: unsafe_free (ralloc.c:255) ==30600== by 0x7B98FDD: unsafe_free (ralloc.c:248) ==30600== by 0x7B99126: ralloc_free (ralloc.c:218) ==30600== by 0x7C5C5A2: brw::vec4_live_variables::~vec4_live_variables() (brw_vec4_live_variables.cpp:173) ==30600== by 0x7C5C810: brw::vec4_visitor::calculate_live_intervals() (brw_vec4_live_variables.cpp:267) ==30600== by 0x7C5659F: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:253) ==30600== by 0x7C54F45: brw::vec4_visitor::run() (brw_vec4.cpp:1787) ==30600== by 0x7C551AC: brw_vs_emit (brw_vec4.cpp:1865) ==30600== by 0x7C716C9: do_vs_prog (brw_vs.c:295) ==30600== by 0x7C71F12: brw_vs_precompile (brw_vs.c:545) ==30600== by 0x7C4D103: brw_link_shader (brw_shader.cpp:79) ==30600== ==30600== Invalid read of size 4 ==30600== at 0x7C56423: brw::vec4_visitor::opt_cse_local(bblock_t*) (brw_vec4_cse.cpp:228) ==30600== by 0x7C565C4: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:256) ==30600== by 0x7C54F45: brw::vec4_visitor::run() (brw_vec4.cpp:1787) ==30600== by 0x7C551AC: brw_vs_emit (brw_vec4.cpp:1865) ==30600== by 0x7C716C9: do_vs_prog (brw_vs.c:295) ==30600== by 0x7C71F12: brw_vs_precompile (brw_vs.c:545) ==30600== by 0x7C4D103: brw_link_shader (brw_shader.cpp:79) ==30600== by 0x7B0B553: _mesa_glsl_link_shader (ir_to_mesa.cpp:3038) ==30600== by 0x7A174E0: link_program (shaderapi.c:915) ==30600== by 0x7A18C7E: _mesa_LinkProgram (shaderapi.c:1383) ==30600== by 0xBD6F01: glu::Program::linkProgram(unsigned int, unsigned int, unsigned int, std::string&, unsigned long&) (in /home/idr/devel/graphics/ESCTS-3.0.3.0-20140530.build/cts/glcts) ==30600== by 0xBD63F5: glu::Program::Program(glu::RenderContext const&, char const*, char const*) (in /home/idr/devel/graphics/ESCTS-3.0.3.0-20140530.build/cts/glcts) ==30600== Address 0x87f2a08 is 8 bytes inside a block of size 80 free'd ==30600== at 0x4A077E6: free (vg_replace_malloc.c:446) ==30600== by 0x7B98FFD: unsafe_free (ralloc.c:255) ==30600== by 0x7B98FDD: unsafe_free (ralloc.c:248) ==30600== by 0x7B99126: ralloc_free (ralloc.c:218) ==30600== by 0x7C5C5A2: brw::vec4_live_variables::~vec4_live_variables() (brw_vec4_live_variables.cpp:173) ==30600== by 0x7C5C810: brw::vec4_visitor::calculate_live_intervals() (brw_vec4_live_variables.cpp:267) ==30600== by 0x7C5659F: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:253) ==30600== by 0x7C54F45: brw::vec4_visitor::run() (brw_vec4.cpp:1787) ==30600== by 0x7C551AC: brw_vs_emit (brw_vec4.cpp:1865) ==30600== by 0x7C716C9: do_vs_prog (brw_vs.c:295) ==30600== by 0x7C71F12: brw_vs_precompile (brw_vs.c:545) ==30600== by 0x7C4D103: brw_link_shader (brw_shader.cpp:79) ==30600== ==30600== Invalid read of size 4 ==30600== at 0x7C56428: brw::vec4_visitor::opt_cse_local(bblock_t*) (brw_vec4_cse.cpp:228) ==30600== by 0x7C565C4: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:256) ==30600== by 0x7C54F45: brw::vec4_visitor::run() (brw_vec4.cpp:1787) ==30600== by 0x7C551AC: brw_vs_emit (brw_vec4.cpp:1865) ==30600== by 0x7C716C9: do_vs_prog (brw_vs.c:295) ==30600== by 0x7C71F12: brw_vs_precompile (brw_vs.c:545) ==30600== by 0x7C4D103: brw_link_shader (brw_shader.cpp:79) ==30600== by 0x7B0B553: _mesa_glsl_link_shader (ir_to_mesa.cpp:3038) ==30600== by 0x7A174E0: link_program (shaderapi.c:915) ==30600== by 0x7A18C7E: _mesa_LinkProgram (shaderapi.c:1383) ==30600== by 0xBD6F01: glu::Program::linkProgram(unsigned int, unsigned int, unsigned int, std::string&, unsigned long&) (in /home/idr/devel/graphics/ESCTS-3.0.3.0-20140530.build/cts/glcts) ==30600== by 0xBD63F5: glu::Program::Program(glu::RenderContext const&, char const*, char const*) (in /home/idr/devel/graphics/ESCTS-3.0.3.0-20140530.build/cts/glcts) ==30600== Address 0x87f2a0c is 12 bytes inside a block of size 80 free'd ==30600== at 0x4A077E6: free (vg_replace_malloc.c:446) ==30600== by 0x7B98FFD: unsafe_free (ralloc.c:255) ==30600== by 0x7B98FDD: unsafe_free (ralloc.c:248) ==30600== by 0x7B99126: ralloc_free (ralloc.c:218) ==30600== by 0x7C5C5A2: brw::vec4_live_variables::~vec4_live_variables() (brw_vec4_live_variables.cpp:173) ==30600== by 0x7C5C810: brw::vec4_visitor::calculate_live_intervals() (brw_vec4_live_variables.cpp:267) ==30600== by 0x7C5659F: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:253) ==30600== by 0x7C54F45: brw::vec4_visitor::run() (brw_vec4.cpp:1787) ==30600== by 0x7C551AC: brw_vs_emit (brw_vec4.cpp:1865) ==30600== by 0x7C716C9: do_vs_prog (brw_vs.c:295) ==30600== by 0x7C71F12: brw_vs_precompile (brw_vs.c:545) ==30600== by 0x7C4D103: brw_link_shader (brw_shader.cpp:79) ==30600== Patch sent to mesa-dev: http://lists.freedesktop.org/archives/mesa-dev/2014-September/067605.html My previous information was for a branch that included Anuj's "i965: Make type_size()'s handling of samplers on vec4 and FS backends match" patch. http://cgit.freedesktop.org/~idr/mesa/commit/?h=gles3conform-v5&id=10020e7b43db8c6e633774c0757030d25c404704 With just my patch, we get these additional Valgrind complaints: ==1920== Conditional jump or move depends on uninitialised value(s) ==1920== at 0x7C523B2: brw::vec4_visitor::opt_reduce_swizzle() (brw_vec4.cpp:398) ==1920== by 0x7C54D31: brw::vec4_visitor::run() (brw_vec4.cpp:1782) ==1920== by 0x7C551AC: brw_vs_emit (brw_vec4.cpp:1865) ==1920== by 0x7C71729: do_vs_prog (brw_vs.c:295) ==1920== by 0x7C71F72: brw_vs_precompile (brw_vs.c:545) ==1920== by 0x7C4D103: brw_link_shader (brw_shader.cpp:79) ==1920== by 0x7B0B553: _mesa_glsl_link_shader (ir_to_mesa.cpp:3038) ==1920== by 0x7A174E0: link_program (shaderapi.c:915) ==1920== by 0x7A18C7E: _mesa_LinkProgram (shaderapi.c:1383) ==1920== by 0xBD6F01: glu::Program::linkProgram(unsigned int, unsigned int, unsigned int, std::string&, unsigned long&) (in /home/idr/devel/graphics/ESCTS-3.0.3.0-20140530.build/cts/glcts) ==1920== by 0xBD63F5: glu::Program::Program(glu::RenderContext const&, char const*, char const*) (in /home/idr/devel/graphics/ESCTS-3.0.3.0-20140530.build/cts/glcts) ==1920== by 0x4ED105: glcts::ShaderRenderCase::init() (in /home/idr/devel/graphics/ESCTS-3.0.3.0-20140530.build/cts/glcts) ==1920== ==1920== Conditional jump or move depends on uninitialised value(s) ==1920== at 0x7C56D40: brw::vec4_instruction::get_src(brw_vec4_prog_data const*, int) (brw_reg.h:241) ==1920== by 0x7C592B2: brw::vec4_generator::generate_code(cfg_t const*) (brw_vec4_generator.cpp:994) ==1920== by 0x7C5A0B6: brw::vec4_generator::generate_assembly(cfg_t const*, unsigned int*) (brw_vec4_generator.cpp:1371) ==1920== by 0x7C5523A: brw_vs_emit (brw_vec4.cpp:1880) ==1920== by 0x7C71729: do_vs_prog (brw_vs.c:295) ==1920== by 0x7C71F72: brw_vs_precompile (brw_vs.c:545) ==1920== by 0x7C4D103: brw_link_shader (brw_shader.cpp:79) ==1920== by 0x7B0B553: _mesa_glsl_link_shader (ir_to_mesa.cpp:3038) ==1920== by 0x7A174E0: link_program (shaderapi.c:915) ==1920== by 0x7A18C7E: _mesa_LinkProgram (shaderapi.c:1383) ==1920== by 0xBD6F01: glu::Program::linkProgram(unsigned int, unsigned int, unsigned int, std::string&, unsigned long&) (in /home/idr/devel/graphics/ESCTS-3.0.3.0-20140530.build/cts/glcts) ==1920== by 0xBD63F5: glu::Program::Program(glu::RenderContext const&, char const*, char const*) (in /home/idr/devel/graphics/ESCTS-3.0.3.0-20140530.build/cts/glcts) ==1920== glcts: brw_reg.h:241: brw_reg brw_reg(unsigned int, unsigned int, unsigned int, brw_reg_type, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int): Assertion `nr < 128' failed. Patches on mesa-dev: http://lists.freedesktop.org/archives/mesa-dev/2014-September/067661.html http://lists.freedesktop.org/archives/mesa-dev/2014-September/067662.html It works well on latest mesa master branch. dEQP Core GL-CTS-2.0 (0x0052484b) starting.. target implementation = 'X11' Test case 'ES3-CTS.shaders.struct.uniform.sampler_array_vertex'.. Vertex compile time = 2.602000 ms Fragment compile time = 0.151000 ms Link time = 0.478000 ms Pass (Pass) DONE! Test run totals: Passed: 1/1 (100.00%) Failed: 0/1 (0.00%) Not supported: 0/1 (0.00%) Warnings: 0/1 (0.00%) commit 7865026c04f6cc36dc81f993bc32ddda2806ecb5 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Thu Sep 11 22:07:41 2014 -0700 i965/vec4: Make type_size() return 0 for samplers. The FS backend has always used 0, and the VS backend has always used 1. I think 1 is just working around other problems, and is incorrect. Samplers are baked in; nothing uses the UNIFORM register we would create, and we shouldn't upload any constant values for them. Fixes ES3-CTS.shaders.struct.uniform.sampler_array_vertex. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Tested-by: Ian Romanick <ian.d.romanick@intel.com> commit 2408f166db1d81f2e9cc86b3f413ddba5ba537fa Author: Kenneth Graunke <kenneth@whitecape.org> Date: Thu Sep 11 22:07:40 2014 -0700 i965: Skip allocating UNIFORM file storage for uniforms of size 0. Samplers take up zero slots and therefore don't exist in the params array, nor are they included in stage_prog_data->nr_params. There's no need to store their size in param_size, as it's only used for dealing with arrays of "real" uniforms (ones uploaded as shader constants). We run into all kinds of problems trying to refer to the uniform storage for variables that don't have uniform storage. For one, we may use some other variable's index, or access out of bounds in arrays. In the FS backend, our extra 2 * MaxSamplerImageUnits params for texture rectangle rescaling paper over a lot of problems. In the VS backend, we claim samplers take up a slot, which also papers over problems. Instead, just skip allocating storage for variables that don't have any. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Tested-by: Ian Romanick <ian.d.romanick@intel.com> Verified.Fixed. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.