Opened 4 years ago

Closed 4 years ago

#11051 closed defect (fixed)

xf86-video-ati-18.1.0 (was xf86-video-ati-18.0.1 needs to be patched)

Reported by: christopher Owned by: Douglas R. Reno
Priority: normal Milestone: 8.4
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description

Hello,

I will attempt one last time to get a correction done to the book.

I found that with this driver that I got fence wait ring timeouts when booting into gnome running on xorg. I posted on the freedesktop bugzilla, against as it turned out the wrong existing bug report, but was pointed to the solution by Michel Dänzer, an employee of AMD and author of the required patches. This issue affects multiple distros and multiple desktop environments, ie kde, gnome, lxqt. The bug report is at:

https://bugs.freedesktop.org/show_bug.cgi?id=105381

The patches can be located in there git repository at:

https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/

They have been published there 7 days ago for 5 of the patches and 8 days ago for another. I did not bother with the patches but did a git pull and made sure the error went away that way, but there are both patches, and diff available.

Christopher.

Attachments (5)

gnomewayland (61.5 KB ) - added by christopher 4 years ago.
No ring timeouts running gnome on wayland
gnomexorg (67.2 KB ) - added by christopher 4 years ago.
example of the fence timeout when running gnome on xorg
xf86-video-ati-upstream_patches-1.diff (173.1 KB ) - added by thomas 4 years ago.
Just as an experiment, could you test the attached patch? Apply it as usual.
xf86-video-ati-18.0.1-upstream_patches-2.patch (140.6 KB ) - added by thomas 4 years ago.
First one is garbage - try this one
ati-upstream-fixes (19.5 KB ) - added by ken@… 4 years ago.
Upstream commits 3c4c0213c11d 499d2f9d5d30

Download all attachments as: .zip

Change History (21)

by christopher, 4 years ago

Attachment: gnomewayland added

No ring timeouts running gnome on wayland

by christopher, 4 years ago

Attachment: gnomexorg added

example of the fence timeout when running gnome on xorg

comment:1 by thomas, 4 years ago

"I will attempt one last time to get a correction done to the book." sounds like you have tried that multible times? I cannot find anything about that on the mailing list nor a ticket except this one. Anyway, maybe i'm blind (and if so, sorry for that) ...

It also sounds like you have identified a set of patches which are required to fix that issue. It would be helpful if you would supply information about those (since there are a lot of others in cgit, too). We could than try to combine that into a consolidated patch.

I had a quick look to those patches i assume you meant

2018-08-17	Remove drmmode_crtc_private_rec::present_vblank_* related code	Michel Dänzer	3	-48/+3
2018-08-17	Defer vblank event handling while waiting for a pending flip	Michel Dänzer	4	-8/+56
2018-08-17	Add radeon_drm_handle_event wrapper for drmHandleEvent	Michel Dänzer	4	-30/+96
2018-08-17	Add radeon_drm_wait_pending_flip function	Michel Dänzer	3	-17/+18
2018-08-17	Move DRM event queue related initialization to radeon_drm_queue_init	Michel Dänzer	5	-17/+19
2018-08-16	Use correct FB handle in radeon_do_pageflip	Michel Dänzer	1	-2/+2

and it turned out that these are not the only one required. The patches assumes modifications happened previously, for example in July

2018-07-12	Refactor drmmode_output_set_tear_free helper	Michel Dänzer	1	-10/+18

Long text short, it's a bit of work to extract the required patches without pulling in the whole history of changes since May, too. I#d also assume that a new release of the driver will not last very long, looks like they release every half a year or so.

by thomas, 4 years ago

Just as an experiment, could you test the attached patch? Apply it as usual.

by thomas, 4 years ago

First one is garbage - try this one

by ken@…, 4 years ago

Attachment: ati-upstream-fixes added

Upstream commits 3c4c0213c11d 499d2f9d5d30

comment:2 by ken@…, 4 years ago

Sorry, trac lost my comment - I get a somewhat different content in the diff. Also needs autoreconf.

I don't have the original problem on either of my radeons (maybe it only applies in desktop environments), so obviously I can't test that it fixes it. For the moment I have NOT tested that it applies and builds, nor that htere are any obvious regressions.

comment:3 by thomas, 4 years ago

nearly same problem here - no ATI card available for testing at all ... I also only applied the (second) patch and did a configure+make. No make install and of course no test.

If that remains as the last ticket before 8.3 release, I'd propose to simply push it over to 8.4. Looks like not too many people have this problem - while it seems that it really exists and may be really annoying for Christopher.

comment:4 by ken@…, 4 years ago

Actually, now that I've compared directories with your patch applied, and with mine applied, the configure change doesn't show up and the only differences are in .gitignore, src/Makefile.am, src/Makefile.in (mine has lost the latter). And yet looking at my patch in a term, and viewing yours in trac, the content in drmmode_display.c is different (trac shows a pink, i.e. deleted, #define in yours).

Also, searching for 'configure', in mine configure.ac is updated to check for glamor_finish and to check for the gbm module, no other matches, whereas in yours trac finds RRConfigureOutputProperty in an addition to drmmode_display.c - but no other references.

As usual, trac is being unpleasant.

comment:5 by ken@…, 4 years ago

And my patch pair do not build (after autoreconf) -

make[2]: Entering directory '/tmp/xf86-video-ati-18.0.1-ken/src'
  CC       ati.lo
gcc: error: GBM_CFLAGS@: No such file or directory

I'm obviously not cut out for this. Giving up.

comment:6 by christopher, 4 years ago

I am sorry but I *thought* that I had said that I have no idea which exact patches there were. Michel Dänzer said that it was patched in git master. I did a pull on that and built and installed from that.

As I posted this 8 days ago, I checked at the time of posting and the patches were there 8 days prior to that.

This bug only happens in desktop environments.

I still have the August 24 git pull that I did at the time. I have never been much good with making a diff. If anyone wishes to advise me of the exact commands I can do a diff of the git pull against the tarball release and maybe get a patch that way.

comment:7 by christopher, 4 years ago

I have located the patch series, it is a group of 10 patches that relate solely to the bug report that Michel said was applicable to my issue:

https://patchwork.freedesktop.org/series/45979/

comment:8 by Bruce Dubbs, 4 years ago

Milestone: 8.38.4

Too late for 8.3.

comment:9 by Bruce Dubbs, 4 years ago

Summary: xf86-video-ati-18.0.1 needs to be patchedxf86-video-ati-18.1.0 (was xf86-video-ati-18.0.1 needs to be patched)

Now at xf86-video-ati-18.1.0 This ticket probably is OBE.

comment:10 by Douglas R. Reno, 4 years ago

Since nobody has stepped up to take care of this, I'll go slot in my ATI card at next reboot.

comment:11 by ken@…, 4 years ago

It seems to work for me on a Caicos, but so did the previous version.

comment:12 by Douglas R. Reno, 4 years ago

It seems to only affect users of heavy DEs. I can verify that it works with GNOME, but that's about it. I much prefer the intel graphics in my system (I know it's odd to hear that) :-)

comment:13 by Douglas R. Reno, 4 years ago

Owner: changed from blfs-book to Douglas R. Reno
Status: newassigned

Fetching everything that I know I'll get to in the next few days, per Bruce

comment:14 by Douglas R. Reno, 4 years ago

I'm pleased to announce the 18.1.0 release of xf86-video-ati, the Xorg
driver for ATI/AMD Radeon GPUs supported by the radeon kernel driver.
This release supports xserver versions 1.13-1.20.

Highlights:

* Fixed random screen corruption and crashes when using GLAMOR with Xorg
  1.20.
* Support for leasing RandR outputs to clients.
* Various robustness fixes for TearFree. In particular, fixed several
  cases in which disabling TearFree at runtime would result in the Xorg
  process freezing or crashing.
* Fixed some m4 related build issues with older versions of autotools.

Plus other improvements and fixes. Thanks to everybody who contributed
to this release in any way!


Emil Velikov (1):
      Do not export the DriverRec RADEON

Jammy Zhou (1):
      Remove throttling from radeon_dri2_copy_region2

Jim Qu (1):
      Wait for pending scanout update before calling drmmode_crtc_scanout_free

Keith Packard (3):
      modesetting: Record non-desktop kernel property at PreInit time
      modesetting: Create CONNECTOR_ID properties for outputs [v2]
      Add RandR leases support

Michel Dänzer (55):
      Bail from dri2_create_buffer2 if we can't get a pixmap
      glamor: Bail CreatePixmap on unsupported pixmap depth
      Drop unused drmmode_create_bo_pixmap surface parameter
      EXA: Remove old RADEONEXACreatePixmap hook
      Only initialize libdrm_radeon surface manager for >= R600
      glamor: Don't store radeon_surfaces in pixmaps
      Factor out radeon_surface_initialize helper
      Move flush from radeon_scanout_do_update to its callers
      Refactor radeon_finish helper
      Add struct radeon_buffer
      glamor: Use GBM for BO allocation when possible
      Swap pixmap privates in radeon_dri2_exchange_buffers
      Ignore RADEON_DRM_QUEUE_ERROR (0) in radeon_drm_abort_entry
      Track DRM event queue sequence number in scanout_update_pending
      Abort scanout_update_pending event when possible
      Update RandR CRTC state if set_mode_major fails in set_desired_modes
      Simplify drmmode_crtc_scanout_update
      Don't call scanout_flip/update with a legacy RandR scanout buffer
      Simplify drmmode_handle_transform
      Set drmmode_crtc->scanout_id = 0 when TearFree is disabled
      Refactor drmmode_output_set_tear_free helper
      Wait for pending flips in drmmode_output_set_tear_free
      Replace 'foo == NULL' with '!foo'
      Call drmmode_do_crtc_dpms from drmmode_crtc_dpms as well
      Use drmmode_crtc_dpms in drmmode_set_desired_modes
      Check dimensions passed to drmmode_xf86crtc_resize
      Remove #if 0'd code
      Call drmmode_crtc_gamma_do_set from drmmode_setup_colormap
      glamor: Fix glamor_block_handler argument in radeon_glamor_finish
      glamor: Invalidate cached GEM handle in radeon_set_pixmap_bo
      Don't allocate drmmode_output->props twice
      Hardcode "non-desktop" RandR property name
      Remove drmmode_terminate_leases
      Use strcpy for RandR output property names
      Bump version to 18.0.99
      glamor: Use glamor_egl_create_textured_pixmap_from_gbm_bo when possible
      glamor: Set RADEON_CREATE_PIXMAP_DRI2 for DRI3 pixmaps
      Store FB for each CRTC in drmmode_flipdata_rec
      Use correct FB handle in radeon_do_pageflip
      Move DRM event queue related initialization to radeon_drm_queue_init
      Add radeon_drm_wait_pending_flip function
      Add radeon_drm_handle_event wrapper for drmHandleEvent
      Defer vblank event handling while waiting for a pending flip
      Remove drmmode_crtc_private_rec::present_vblank_* related code
      Add m4 directory
      Use AC_CONFIG_MACRO_DIR instead of AC_CONFIG_MACRO_DIRS
      EXA: Handle NULL BO pointer in radeon_set_pixmap_bo
      Handle ihandle == -1 in radeon_set_shared_pixmap_backing
      EXA: Handle ihandle == -1 in RADEONEXASharePixmapBacking
      glamor: Handle ihandle == -1 in radeon_glamor_set_shared_pixmap_backing
      Always delete entry from list in drm_queue_handler
      Don't use xorg_list_for_each_entry_safe for signalled flips
      Bail early from drm_wait_pending_flip if there's no pending flip
      Fix uninitialized use of local variable pitch in radeon_setup_kernel_mem
      Bump version for 18.1.0 release

comment:15 by Douglas R. Reno, 4 years ago

After installing this driver on my old build as well as my new one, I can confirm that it's fixed.

I will also say that getting firmware for this new card was a less than stellar experience.

comment:16 by Douglas R. Reno, 4 years ago

Resolution: fixed
Status: assignedclosed

Fixed at r20584

Note: See TracTickets for help on using tickets.