Bug 98492 - X-Plane 10 Core Dumping when using Real-Weather or any clouds
Summary: X-Plane 10 Core Dumping when using Real-Weather or any clouds
Status: RESOLVED DUPLICATE of bug 97909
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-29 17:08 UTC by Amarildo
Modified: 2018-04-12 02:06 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
journalctl (16.87 KB, text/plain)
2016-10-29 17:08 UTC, Amarildo
Details
GALLIUM_DDEBUG-1 (33.03 KB, text/plain)
2016-11-04 14:04 UTC, Amarildo
Details
GALLIUM_DDEBUG-2 (1.54 KB, text/plain)
2016-11-04 14:05 UTC, Amarildo
Details

Description Amarildo 2016-10-29 17:08:51 UTC
Created attachment 127609 [details]
journalctl

X-Plane crashes when using Real_weather or when setting up any kinds of clouds for the Sim.

As per journalctl would suggest, libpthreads isn't the cause. I've isntalled it here on Arch and the sim still crashes.
Comment 1 Nicolai Hähnle 2016-11-04 10:40:18 UTC
Hi Amarildo, could you provide a backtrace with debug symbols of radeonsi? Also, if you could reproduce this with an apitrace and upload it somewhere, that would be very helpful.
Comment 2 Amarildo 2016-11-04 14:04:34 UTC
Created attachment 127758 [details]
GALLIUM_DDEBUG-1

GALLIUM_DDEBUG="pipelined 2000"
FILE 1
Comment 3 Amarildo 2016-11-04 14:05:04 UTC
Created attachment 127759 [details]
GALLIUM_DDEBUG-2

GALLIUM_DDEBUG 2
Comment 4 Amarildo 2016-11-04 14:05:43 UTC
(In reply to Nicolai Hähnle from comment #1)
> Hi Amarildo, could you provide a backtrace with debug symbols of radeonsi?
> Also, if you could reproduce this with an apitrace and upload it somewhere,
> that would be very helpful.

Absolutely. I just need to know what is the exact command to launch the simulator with. Could you specify it to me? 

I ran it with `GALLIUM_DDEBUG="pipelined 2000"` and I'm attatching the resulting files now.

In the mean time I'll record it and upload the video yo YouTube.

Cheers
Comment 5 Nicolai Hähnle 2016-11-15 14:02:08 UTC
So I'm confused, you're seeing hangs now?

Judging by another X-Plane 10-related bug report, you should run with the MESA_EXTENSION_OVERRIDE=-GL_AMD_pinned_memory environment variable setting.

If you're still seeing crashes, please install debug symbols for the radeonsi driver and run in gdb. I.e.: `MESA_EXTENSION_OVERRIDE=-GL_AMD_pinned_memory gdb X-Plane-x86_64`, and then `run --force_run`.
Comment 6 Amarildo 2016-11-16 21:25:43 UTC
(In reply to Nicolai Hähnle from comment #5)
> So I'm confused, you're seeing hangs now?
> 
> Judging by another X-Plane 10-related bug report, you should run with the
> MESA_EXTENSION_OVERRIDE=-GL_AMD_pinned_memory environment variable setting.
> 
> If you're still seeing crashes, please install debug symbols for the
> radeonsi driver and run in gdb. I.e.:
> `MESA_EXTENSION_OVERRIDE=-GL_AMD_pinned_memory gdb X-Plane-x86_64`, and then
> `run --force_run`.

Hi Nicolai,

The hangs only happen with the radeon Kernel driver. Today I tested linux-4.8.8 with the radeon Kernel driver, with mesa-git and llvm-svn, and the system hanged. However, setting up clouds did not make the Sim crash.
I'm yet to test X-Plane with radeon, mesa-git llvm-svn, and that environment you specified.

-----------------

The crash mentioned on this bug only happen with the amdgpu Kernel driver. Last time I tried I couldn't use this driver with regular/stable Mesa.

Setting up `MESA_EXTENSION_OVERRIDE='-GL_AMD_pinned_memory'` WORKS! :D Could you explain what it does? Could you push a patch so users are not required to run this environment manually?

Thank you very much for your support so far.
Comment 7 Nicolai Hähnle 2016-11-21 09:18:15 UTC
What this setting does is disable support for the specified extension. The problem here is that the application uses the extension in a problematic way: by the way the extension is phrased, it should only work for allocations at a page-level granularity. X-Plane 10 tries to use it for a different granularity and doesn't check for error results (which it really must).

We could hack around the page-level granularity limitations in the same way that the closed-source driver does it, but I'm hesitant to do so because it can never be a complete fix: if two pinned buffers overlap on the same page, we simply cannot support that currently. So who knows what other potential application bugs we'd just be papering over.

As for a patch, we might add a driconf-based application-specific workaround for this.
Comment 8 Timothy Arceri 2018-04-12 02:06:20 UTC

*** This bug has been marked as a duplicate of bug 97909 ***


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.