After upgrading from F18 to F19 using fedup, I was getting a segfault starting Xorg[1]. It turns out my case seemed almost identical to another case[2], but since they seemed to be from separate drivers I filed a separate bug. The catalyst driver also did not work for me, but for an entirely different reason. (My ASUS laptop has a Radeon HD 7730M) I didn't have time to look into it further at that point, so I just filed the bug and did weekly yum upgrades, hoping a package would get fixed or bumped that would fix my problem. As of today, that still had not happened and no one had responded to my bug report. Having a bit of free time, I decided to look into it. Since the stack trace seemed to indicate the mesa-dri-drivers were at fault (I accidentally forgot the stack trace in the bug report, but it is almost identical to that in [2], replacing sis_drv with radeon_dri), I rebuilt the latest from git and tried that. After replacing the old version with the newly built radeon_dri.so, I was able to boot into X without a problem.
The latest mesa in the repos still does not solve this problem, so I just wanted to bring it to the maintainer's attention that an update for this package should probably be expedited.
Best regards, Morgan
[1] https://bugzilla.redhat.com/show_bug.cgi?id=984256 [2] https://bugzilla.redhat.com/show_bug.cgi?id=965605
On Thu, 2013-08-01 at 20:21 +0800, Morgan Howe wrote:
After upgrading from F18 to F19 using fedup, I was getting a segfault starting Xorg[1]. It turns out my case seemed almost identical to another case[2], but since they seemed to be from separate drivers I filed a separate bug. The catalyst driver also did not work for me, but for an entirely different reason. (My ASUS laptop has a Radeon HD 7730M) I didn't have time to look into it further at that point, so I just filed the bug and did weekly yum upgrades, hoping a package would get fixed or bumped that would fix my problem. As of today, that still had not happened and no one had responded to my bug report. Having a bit of free time, I decided to look into it. Since the stack trace seemed to indicate the mesa-dri-drivers were at fault (I accidentally forgot the stack trace in the bug report, but it is almost identical to that in [2], replacing sis_drv with radeon_dri), I rebuilt the latest from git and tried that. After replacing the old version with the newly built radeon_dri.so, I was able to boot into X without a problem.
The latest mesa in the repos still does not solve this problem, so I just wanted to bring it to the maintainer's attention that an update for this package should probably be expedited.
We don't simply bump Mesa to bleeding-edge git on stable releases. It'll fix your bug, sure, but it could just as well break 2x as many things as it fixes...
On Thu, Aug 1, 2013 at 11:12 PM, Adam Williamson awilliam@redhat.comwrote:
On Thu, 2013-08-01 at 20:21 +0800, Morgan Howe wrote:
The latest mesa in the repos still does not solve this problem, so I just wanted to bring it to the maintainer's attention that an update for this package should probably be expedited.
We don't simply bump Mesa to bleeding-edge git on stable releases. It'll fix your bug, sure, but it could just as well break 2x as many things as it fixes...
I didn't say you need to bump it to bleeding edge git. I'm just letting you know that there's a pretty serious bug in the current version of mesa that is affecting at least a few people - probably even more who just rolled back to F18 and didn't bother filing a bug report. I'm well aware that a version bump might introduce new bugs, but just thought someone might want to consider at least looking into it since a completely broken X is a fairly major issue.
On Thu, Aug 1, 2013 at 3:50 PM, Morgan Howe mthowe@gmail.com wrote:
I didn't say you need to bump it to bleeding edge git. I'm just letting you know that there's a pretty serious bug in the current version of mesa that is affecting at least a few people - probably even more who just rolled back to F18 and didn't bother filing a bug report. I'm well aware that a version bump might introduce new bugs, but just thought someone might want to consider at least looking into it since a completely broken X is a fairly major issue.
okay im a little confused. You filed it and then closed it as upstream.
How does that help the package maintainer in Fedora keep track of this as an outstanding issue to possibly address as an update?
You've short circuited the bug workflow a bit by jumping the gun and marking your own issue as resolved. I believe the intent with regard to the UPSTREAM resolution in our bugzilla workflow is for "maintainers" to use to mark as resolved with the intention of pulling new upstream release and pushing it as an update some time soonish. If as the reporter you mark it as resolved, you've greatly reduced the chance that a maintainer is going to notice the bug as still outstanding. So you might want to rethink how you handled this report.
-jef
----- Original Message -----
From: "Jef Spaleta" jspaleta@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Friday, 2 August, 2013 10:14:31 AM Subject: Re: Mesa needs an update?
On Thu, Aug 1, 2013 at 3:50 PM, Morgan Howe mthowe@gmail.com wrote:
I didn't say you need to bump it to bleeding edge git. I'm just letting you know that there's a pretty serious bug in the current version of mesa that is affecting at least a few people - probably even more who just rolled back to F18 and didn't bother filing a bug report. I'm well aware that a version bump might introduce new bugs, but just thought someone might want to consider at least looking into it since a completely broken X is a fairly major issue.
okay im a little confused. You filed it and then closed it as upstream.
How does that help the package maintainer in Fedora keep track of this as an outstanding issue to possibly address as an update?
You've short circuited the bug workflow a bit by jumping the gun and marking your own issue as resolved. I believe the intent with regard to the UPSTREAM resolution in our bugzilla workflow is for "maintainers" to use to mark as resolved with the intention of pulling new upstream release and pushing it as an update some time soonish. If as the reporter you mark it as resolved, you've greatly reduced the chance that a maintainer is going to notice the bug as still outstanding. So you might want to rethink how you handled this report.
Also unless he rebuild the upstream mesa in rpm with the same flags, I'm not sure this is guaranteed fixed upstream.
Dave.
On Fri, Aug 2, 2013 at 8:38 AM, David Airlie airlied@redhat.com wrote:
Also unless he rebuild the upstream mesa in rpm with the same flags, I'm not sure this is guaranteed fixed upstream.
I'd be happy to help debug this. I'm currently trying to find where I can see the flags used for the Fedora build. If someone could point me toward where I can get that information, I will rebuild and confirm that the latest upstream fixes the issue with Fedora's specific build configuration.
On Fri, 2013-08-02 at 08:50 +0800, Morgan Howe wrote:
On Fri, Aug 2, 2013 at 8:38 AM, David Airlie airlied@redhat.com wrote: Also unless he rebuild the upstream mesa in rpm with the same flags, I'm not sure this is guaranteed fixed upstream.
I'd be happy to help debug this. I'm currently trying to find where I can see the flags used for the Fedora build. If someone could point me toward where I can get that information, I will rebuild and confirm that the latest upstream fixes the issue with Fedora's specific build configuration.
The 'easiest' thing to do would actually be to just modify the Fedora .src.rpm with a current git snapshot as the source; that way you know you're building it the same way, just with newer source code.
Since this no longer seems to be a Fedora specific issue, I have filed a bug upstream with Mesa. Thanks to everyone for your help.
https://bugs.freedesktop.org/show_bug.cgi?id=67690
Morgan
On Fri, Aug 2, 2013 at 8:38 AM, David Airlie airlied@redhat.com wrote:
Also unless he rebuild the upstream mesa in rpm with the same flags, I'm not sure this is guaranteed fixed upstream.
Dave, for the sake of having the conversation in a single place, I'm responding to your comment on bugzilla here. I tried your package which did not fix the issue. Since I somehow forgot to add it in the actual case, for reference here is the stack trace:
[ 70025.932] (EE) Backtrace: [ 70025.932] (EE) 0: /usr/bin/Xorg (OsLookupColor+0x129) [0x46edb9] [ 70025.932] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x34e180ef9f] [ 70025.933] (EE) 2: /usr/lib64/dri/radeonsi_dri.so (radeon_drm_winsys_create+0xb9) [0x7f7f564a53b9] [ 70025.934] (EE) 3: /usr/lib64/dri/radeonsi_dri.so (_init+0x3cc1) [0x7f7f561dc011] [ 70025.934] (EE) 4: /usr/lib64/dri/radeonsi_dri.so (dri_flush+0x3b2) [0x7f7f564a0fa2] [ 70025.934] (EE) 5: /usr/lib64/dri/swrast_dri.so (driIndexConfigAttrib+0x57d) [0x7f7f53c4a7cd] [ 70025.935] (EE) 6: /usr/lib64/xorg/modules/extensions/libglx.so (_glthread_GetID+0x71d1) [0x7f7f57e02cb1] [ 70025.935] (EE) 7: /usr/lib64/xorg/modules/extensions/libglx.so (_glthread_GetID+0x679a) [0x7f7f57e0180a] [ 70025.936] (EE) 8: /usr/bin/Xorg (InitExtensions+0x41) [0x4ba101] [ 70025.936] (EE) 9: /usr/bin/Xorg (_init+0x38e0) [0x429980] [ 70025.936] (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x34e1021b75] [ 70025.936] (EE) 11: /usr/bin/Xorg (_start+0x29) [0x4267b1] [ 70025.937] (EE) 12: ? (?+0x29) [0x29] [ 70025.937] (EE) [ 70025.937] (EE) Segmentation fault at address 0x0
After installing your package, I noticed one major difference between yours and the upstream git that I built. Since I am not using the same Fedora configure flags as you had asked, mine is not building with --with-gallium-drivers which is apparently not a default. My mesa build only included libradeon_dri.so and *not* libradeonsi_dri.so, which is what actually fixed the problem. So I removed your and my packages, and reinstalled the latest from the yum repository, then removed libradeonsi_dri.so. This also fixes the issue, so the problem is obviously with the gallium drivers and not necessarily the current version of mesa. I will try one more time rebuilding the latest from git with gallium drivers enabled and see if the issue still exists upstream.
Morgan
On Fri, Aug 2, 2013 at 9:22 AM, Morgan Howe mthowe@gmail.com wrote:
On Fri, Aug 2, 2013 at 8:38 AM, David Airlie airlied@redhat.com wrote:
Also unless he rebuild the upstream mesa in rpm with the same flags, I'm not sure this is guaranteed fixed upstream.
Dave, for the sake of having the conversation in a single place, I'm responding to your comment on bugzilla here. I tried your package which did not fix the issue. Since I somehow forgot to add it in the actual case, for reference here is the stack trace:
[ 70025.932] (EE) Backtrace: [ 70025.932] (EE) 0: /usr/bin/Xorg (OsLookupColor+0x129) [0x46edb9] [ 70025.932] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x34e180ef9f] [ 70025.933] (EE) 2: /usr/lib64/dri/radeonsi_dri.so (radeon_drm_winsys_create+0xb9) [0x7f7f564a53b9] [ 70025.934] (EE) 3: /usr/lib64/dri/radeonsi_dri.so (_init+0x3cc1) [0x7f7f561dc011] [ 70025.934] (EE) 4: /usr/lib64/dri/radeonsi_dri.so (dri_flush+0x3b2) [0x7f7f564a0fa2] [ 70025.934] (EE) 5: /usr/lib64/dri/swrast_dri.so (driIndexConfigAttrib+0x57d) [0x7f7f53c4a7cd] [ 70025.935] (EE) 6: /usr/lib64/xorg/modules/extensions/libglx.so (_glthread_GetID+0x71d1) [0x7f7f57e02cb1] [ 70025.935] (EE) 7: /usr/lib64/xorg/modules/extensions/libglx.so (_glthread_GetID+0x679a) [0x7f7f57e0180a] [ 70025.936] (EE) 8: /usr/bin/Xorg (InitExtensions+0x41) [0x4ba101] [ 70025.936] (EE) 9: /usr/bin/Xorg (_init+0x38e0) [0x429980] [ 70025.936] (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x34e1021b75] [ 70025.936] (EE) 11: /usr/bin/Xorg (_start+0x29) [0x4267b1] [ 70025.937] (EE) 12: ? (?+0x29) [0x29] [ 70025.937] (EE) [ 70025.937] (EE) Segmentation fault at address 0x0
After installing your package, I noticed one major difference between yours and the upstream git that I built. Since I am not using the same Fedora configure flags as you had asked, mine is not building with --with-gallium-drivers which is apparently not a default. My mesa build only included libradeon_dri.so and *not* libradeonsi_dri.so, which is what actually fixed the problem. So I removed your and my packages, and reinstalled the latest from the yum repository, then removed libradeonsi_dri.so. This also fixes the issue, so the problem is obviously with the gallium drivers and not necessarily the current version of mesa. I will try one more time rebuilding the latest from git with gallium drivers enabled and see if the issue still exists upstream.
That should have been radeon_dri.so and radeonsi_dri.so, without the lib prefix, of course.
I just tried latest upstream gallium driver and can confirm that the issue still exists. The stack trace is slightly different with the latest version:
[ 72427.843] (EE) Backtrace: [ 72427.843] (EE) 0: /usr/bin/Xorg (OsLookupColor+0x129) [0x46edb9] [ 72427.844] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x34e180ef9f] [ 72427.844] (EE) 2: /usr/lib64/dri/radeonsi_dri.so (radeon_drm_winsys_create+0xb9) [0x7fbab6804019] [ 72427.845] (EE) 3: /usr/lib64/dri/radeonsi_dri.so (create_screen+0x9) [0x7fbab652b3d9] [ 72427.846] (EE) 4: /usr/lib64/dri/radeonsi_dri.so (dri2_init_screen+0x45) [0x7fbab67fff75] [ 72427.846] (EE) 5: /usr/lib64/dri/swrast_dri.so (driIndexConfigAttrib+0x57d) [0x7fbab3f9a7cd] [ 72427.847] (EE) 6: /usr/lib64/xorg/modules/extensions/libglx.so (_glthread_GetID+0x71d1) [0x7fbab8162cb1] [ 72427.848] (EE) 7: /usr/lib64/xorg/modules/extensions/libglx.so (_glthread_GetID+0x679a) [0x7fbab816180a] [ 72427.848] (EE) 8: /usr/bin/Xorg (InitExtensions+0x41) [0x4ba101] [ 72427.848] (EE) 9: /usr/bin/Xorg (_init+0x38e0) [0x429980] [ 72427.848] (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x34e1021b75] [ 72427.849] (EE) 11: /usr/bin/Xorg (_start+0x29) [0x4267b1] [ 72427.849] (EE) 12: ? (?+0x29) [0x29] [ 72427.849] (EE) [ 72427.849] (EE) Segmentation fault at address 0x0
Morgan
On Fri, Aug 2, 2013 at 8:14 AM, Jef Spaleta jspaleta@gmail.com wrote:
On Thu, Aug 1, 2013 at 3:50 PM, Morgan Howe mthowe@gmail.com wrote:
I didn't say you need to bump it to bleeding edge git. I'm just letting
you
know that there's a pretty serious bug in the current version of mesa
that
is affecting at least a few people - probably even more who just rolled
back
to F18 and didn't bother filing a bug report. I'm well aware that a
version
bump might introduce new bugs, but just thought someone might want to consider at least looking into it since a completely broken X is a fairly major issue.
okay im a little confused. You filed it and then closed it as upstream.
How does that help the package maintainer in Fedora keep track of this as an outstanding issue to possibly address as an update?
You've short circuited the bug workflow a bit by jumping the gun and marking your own issue as resolved. I believe the intent with regard to the UPSTREAM resolution in our bugzilla workflow is for "maintainers" to use to mark as resolved with the intention of pulling new upstream release and pushing it as an update some time soonish. If as the reporter you mark it as resolved, you've greatly reduced the chance that a maintainer is going to notice the bug as still outstanding. So you might want to rethink how you handled this report.
That may have been a mistake on my part due to lack of knowledge on your bugzilla workflow, apologies for that. I haven't filed a bug report before and wasn't sure how that should be handled. I've reassigned the bug from xorg-x11-drv-ati to mesa, but I can't seem to reopen (only assign) the bug.
On Thu, Aug 1, 2013 at 4:38 PM, Morgan Howe mthowe@gmail.com wrote:
That may have been a mistake on my part due to lack of knowledge on your bugzilla workflow, apologies for that. I haven't filed a bug report before and wasn't sure how that should be handled. I've reassigned the bug from xorg-x11-drv-ati to mesa, but I can't seem to reopen (only assign) the bug.
It can be a little confusing. Different groups even inside this project will use different workflows depending on the rate of bugs they have to deal with. Anything hardware specific is automatically complicated as it becomes harder to reproduce for one particular person using their standard development machine.
My rule of thumb... I only close the bugs I open under two conditions: I've figured out it was user error or misconfiguration on my part (hey it happens to all of us) or I can confirm the fix has propagated into the packaging system and the bug is still open, which normally I won't have to do as our update system lets maintainers close associated bugs when updates roll out.
-jef
On Fri, Aug 2, 2013 at 8:57 AM, Jef Spaleta jspaleta@gmail.com wrote:
My rule of thumb... I only close the bugs I open under two conditions: I've figured out it was user error or misconfiguration on my part (hey it happens to all of us) or I can confirm the fix has propagated into the packaging system and the bug is still open, which normally I won't have to do as our update system lets maintainers close associated bugs when updates roll out.
Thanks, Jef. Apologies again for my beginner's mistake and I will keep that in mind in the future. :)