Just a bit of follow-up: it seems that on my first system on which I
noticed the error, and solved by swapping in an older Radeon X1300/X1550
card, I ended up doing in hardware what the fix below (implemented on
the second system where I had the error) did in software. The Xorg.0.log
on the first system shows that it's not using glamor but rather exa for
acceleration, and DRI3 is disabled. Looks like I'll be deploying this
20-ati-radeon.conf file to all my Radeon 3000-based SL7 systems, at
least until I see an ati driver update (which SL7.6 doesn't provide).
On 2018-12-03 14:20, Gilles Detillieux wrote:
> Thanks, Pat.
>
> Yes, I've done more digging since speculating on the cause of this,
> and that confirms that it's something deeper than that. It seems the
> problem is the ati driver hasn't kept up with changes to the Xorg 1.20
> server. There is an upstream fix to the driver
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__cgit.freedesktop.org_xorg_driver_xf86-2Dvideo-2Dati_commit_-3Fid-3D3c4c0213c11d623cba7adbc28dde652694f2f758&d=DwIDbA&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=omDRH4VQ2M6IrUHKoOlbZSJqy2HXLP0EYPdTi6xloG4&s=v1zDV9U8je8N_mzq4_2MOkyYsjfHwp4dt5K-Zd6dQgo&e=)
> that hasn't made its way down through Red Hat yet, but it updates
> glamor/gbm handling for the new server version.
>
> Two workarounds seem to have been suggested. One is to remove the ati
> driver altogether and let the kernel or Xorg server pick a different
> one (https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.archlinux.org_task_50397&d=DwIDbA&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=omDRH4VQ2M6IrUHKoOlbZSJqy2HXLP0EYPdTi6xloG4&s=JutPC6NdCAnncNKVECeq4F0-DH9UHiF6Bwot4HYytvs&e=). This was for Arch Linux.
> I don't know if RHEL/SL will handle this seemingly drastic fix, but I
> haven't been able to try it yet. A less drastic fix seems to be to
> disable glamor and use exa acceleration instead, and drop DRI to level
> 2
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linuxquestions.org_questions_slackware-2D14_xorg-2Dserver-2D1-2D20-2D0-2Dstarts-2Dwith-2Dlast-2Dshutdown-2Dscreenshot-2D4175632139_&d=DwIDbA&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=omDRH4VQ2M6IrUHKoOlbZSJqy2HXLP0EYPdTi6xloG4&s=QfOYRR1SPAS16rg69e0mzp_oV99So-Me6doEvsxkYgE&e=).
>
> I tried this second fix by creating a
> /etc/X11/xorg.conf.d/20-ati-radeon.conf file with the following:
>
> Section "Device"
>
> Identifier "Radeon"
> Driver "radeon"
> # Option "AccelMethod" "glamor"
> Option "AccelMethod" "exa"
> Option "DRI" "2"
>
> EndSection
>
> The system rebooted fine and so far the kernel logs are clean, but I'm
> not on-campus today (working remotely) so I won't know until I test
> further, tomorrow, if the fix worked. Andreas, you may want to give
> this a try too and let us know how it goes for you.
>
> Gilles
>
> On 2018-12-03 13:41, Pat Riehecky wrote:
>> I'd be surprised in the patch[1] made any difference on Radeon
>> systems. The code there is really only related to udev probing.
>>
>> There was a large jump in the ati driver from 7.5 to 7.6. My initial
>> thoughts are in that direction...
>>
>> Pat
>>
>> [1]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.freedesktop.org_xorg_xserver_commit_0816e8fca6194dfb4cc94c3a7fcb2c7f2a921386&d=DwIDbA&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=omDRH4VQ2M6IrUHKoOlbZSJqy2HXLP0EYPdTi6xloG4&s=_L222MY2piF4ySMoYFvZn6QKkmOhPLz72_42z9AHC68&e=
>>
>> On 12/3/18 11:29 AM, Gilles Detillieux wrote:
>>> Thanks for the feedback, Andreas. That saves me some testing time.
>>> It looks like the security bug
>>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_security_cve_cve-2D2018-2D14665&d=DwIDbA&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=VStRhNQ03emrmYLjFAIDre-xzZT0Ho_w1biFWTQSbtc&s=pGQ8kJ1ceFEdtE90n9wkzNyf0BcBKbllIvhnPdeLWjc&e=)
>>> needs physical access to the console to exploit. Fortunately that
>>> shouldn't be a problem in our environment, where the users are more
>>> interested in hacking neurons.
>>>
>>> I noticed in the Errata message for the xorg-x11-server update, it
>>> says "The SL Team added a fix for upstream bug 1650634". I'm
>>> wondering if this bug fix
>>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1650634&d=DwIDbA&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=VStRhNQ03emrmYLjFAIDre-xzZT0Ho_w1biFWTQSbtc&s=vz7Ui2PF_YcxXFRgPhPceXRL1HuDpy8255vaqI-vmbE&e=)
>>> broke things for the Radeon drivers. Seems a more likely cause than
>>> the CVE fix for an argument handling issue. That fix was to support
>>> the SL 7.6 upgrade on nVidia hardware. I'll have to see if the 7.6
>>> upgrade (now available) makes the problem go away for the radeon
>>> 3000. If not, I'll likely downgrade Xorg to 1.19 on our systems till
>>> I hear of a fix for this.
>>>
>>> Thanks again,
>>> Gilles
>>>
>>> On 2018-12-03 10:52, Andreas Nowack wrote:
>>>> I would exclude the kernel as source of the problem since downgrade
>>>> to Xorg 1.19 removes all the error messages and problems. (But due
>>>> to security bugs, Xorg 1.19 is not a real option).
>>>>
>>>> Best regards,
>>>> Andreas
>>>>
>>>>
>>>
>>
>
--
Gilles R. Detillieux E-mail: <[log in to unmask]>
Spinal Cord Research Centre WWW: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scrc.umanitoba.ca_&d=DwIDbA&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=omDRH4VQ2M6IrUHKoOlbZSJqy2HXLP0EYPdTi6xloG4&s=MHODL5LaF9xyotD0njo77RlMr-r06_JDK7OFGEeVJmQ&e=
Dept. of Physiology and Pathophysiology, Faculty of Health Sciences,
Univ. of Manitoba Winnipeg, MB R3E 0J9 (Canada)
|
