| Summary: | Xorg segfault when a web browser is opened | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | keiron.davies |
| Component: | Other | Assignee: | mesa-dev |
| Status: | RESOLVED MOVED | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | CC: | massabnaeem160 |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Output of journalctl -b
/home/usernaym/.local/share/xorg/Xorg.0.log.old & Xorg.0.log |
||
|
Description
keiron.davies
2019-03-07 16:47:26 UTC
Created attachment 143575 [details]
/home/usernaym/.local/share/xorg/Xorg.0.log.old & Xorg.0.log
Here are the Xorg logs from the same Chromium crash.
Can you isolate whether it was the Mesa or xserver-xorg-video-amdgpu update that triggered it? (In reply to Michel Dänzer from comment #2) > Can you isolate whether it was the Mesa or xserver-xorg-video-amdgpu update > that triggered it? I'm not sure how I'd roll back either one, the PPA no longer has the old packages (I'll see if they're cached on disk). The only way I can conceive of is building them from git myself, but I suppose I'd have to be careful to use the same build options as the PPA (libs, llvm 9.0 etc.) Can you suggest which would be easier to build? There are a relatively small number of accepted commits between the updates, bisection should be possible, it's just not something I've ever done before. I've confirmed the same behaviour with kernel 4.20, just to make sure it wasn't a 5.0 bug that didn't present itself for a few days. Also, setting amdgpu.dc=1 as a kernel command line parameter allows me to launch Firefox and navigate here but then the same crash occurs when I interact with a dropdown menu. No difference in log output. I found that the previously built .debs were available on launchpad, so I reverted packages to isolate. After rolling back xserver-xorg-video-amdgpu to the previously working version and rebooting there was no change to the problem behaviour. Next I reverted the updates to Mesa, where I ended up in dependency hell for not paying proper attention. After using my /var/log/apt/history.log to figure out which packages I needed, I made corrections, rebooted, and the problem behaviour is gone. So this change does seem to be located in Mesa after commit 6fa923a65daf1ee73c5cc763ade91abc82da7085. I will update xserver-xorg-video-amdgpu alone and see if that makes any change, but I doubt it. Weirdly, the backtrace of the crash doesn't look directly related to Mesa. Maybe there's memory corruption, in which case running Xorg in valgrind might give a clue. (Make sure debugging symbols are available for /usr/lib/xorg/Xorg and radeonsi_dri.so at least) Other than that, bisecting Mesa is probably the best way to make progress. > Display Server: x11 (X.Org 1.19.6 ) drivers: ati,vesa You should use the radeon or amdgpu kernel driver with a Hawaii card. Update to ubuntu cosmic. See: https://wiki.archlinux.org/index.php/AMDGPU#Enable_Southern_Islands_(SI)_and_Sea_Islands_(CIK)_support (In reply to fin4478 from comment #6) > > Display Server: x11 (X.Org 1.19.6 ) drivers: ati,vesa > > You should use the radeon or amdgpu kernel driver with a Hawaii card. Update > to ubuntu cosmic. See: > > https://wiki.archlinux.org/index.php/ > AMDGPU#Enable_Southern_Islands_(SI)_and_Sea_Islands_(CIK)_support A cursory glance at the attached journald logs would reveal I am booting with kernel parameters 'radeon.cik_support=0 amdgpu.cik_support=1', have blacklisted radeon, and am running AMDGPU (unless I am very much mistaken). lspci -k reports: 05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii PRO [Radeon R9 290/390] (rev 80) Subsystem: ASUSTeK Computer Inc. STRIX R9 390 Kernel driver in use: amdgpu Kernel modules: radeon, amdgpu As for bisecting this issue - building Mesa is a little overwhelming for me and I haven't been able to find a comprehensible and up to date guide for my distro in my spare time. I can figure out how to install build dependencies, but the sheer number of compile time options is perplexing. There's a good start in the PPA buildlog for the package, but parsing and understanding it is slow. Once I've built it, would it make more sense to try to generate .debs and install it all, or somehow run the system with this version installed to /opt? (In reply to keiron.davies from comment #7) > Once I've built it, would it make more sense to try to generate .debs and > install it all, or somehow run the system with this version installed to > /opt? The former, otherwise it may not get picked up for everything by the Xorg process. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/935. |
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.