Bug 11870 - AIGLX DRM Probe Removes RADEON DRM Lock
AIGLX DRM Probe Removes RADEON DRM Lock
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/other
unspecified
Other FreeBSD
: medium blocker
Assigned To: Default DRI bug account
:
: 6463 12443 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-06 13:57 UTC by vehemens
Modified: 2008-01-16 10:13 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
locking workaround and cleanup (2.18 KB, patch)
2007-08-06 14:13 UTC, vehemens
no flags Details | Splinter Review
revised drm_drv.c patch (949 bytes, patch)
2007-08-19 15:42 UTC, vehemens
no flags Details | Splinter Review
Revised patch with style(9) fixes. (1.29 KB, patch)
2007-08-30 10:54 UTC, Jung-uk Kim
no flags Details | Splinter Review
FreeBSD-current-compatible version of patch 11334 (1.07 KB, patch)
2007-08-31 10:05 UTC, Coleman Kane
no flags Details | Splinter Review
screen corruption w/ patch 11358 (821.10 KB, image/jpeg)
2007-09-17 05:25 UTC, Igor Mozolevsky
no flags Details
xlog for 11602 (43.92 KB, text/plain)
2007-09-17 05:27 UTC, Igor Mozolevsky
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description vehemens 2007-08-06 13:57:25 UTC
An AIGLX DRM probe removes the lock obtained by the RADEON DRM probe causing my machine to hang during server initialization.
Comment 1 vehemens 2007-08-06 14:13:34 UTC
Created attachment 11013 [details] [review]
locking workaround and cleanup

Locking workaround was provided Kostik Belousov kostikbel@gmail.com.  It modifies drm_close to only remove locking on the last close.  He recommends that device cloning as the final fix.

Patch tested on FreeBSD 7.0 current.
Comment 2 Eric Anholt 2007-08-15 14:22:18 UTC
This looks pretty close, but now the file-priv-last-close code isn't being called until the whole-device last-close.  Looks solvable, though.

I've pushed a test exposing the issue for now.
Comment 3 vehemens 2007-08-19 15:42:01 UTC
Created attachment 11176 [details] [review]
revised drm_drv.c patch

Moved the file_priv->refs == 0 check earlier.  Patch includes the shared-code comment, but not the style required white-space changes.
Comment 4 Jung-uk Kim 2007-08-30 10:54:16 UTC
Created attachment 11334 [details] [review]
Revised patch with style(9) fixes.
Comment 5 Coleman Kane 2007-08-31 10:05:15 UTC
Created attachment 11358 [details] [review]
FreeBSD-current-compatible version of patch 11334

Modified Jung-uk Kim's patch to compile on FreeBSD-current
Comment 6 Coleman Kane 2007-08-31 10:07:29 UTC
I have the following video hardware (on an AMD64 Athlon64 Mobile laptop):

drm0: <ATI Radeon RV350 Mobility 9600 M10 NP> on vgapci0
info: [drm] AGP at 0xe0000000 256MB
info: [drm] Initialized radeon 1.25.0 20060524
info: [drm] Setting GART location based on new memory map
info: [drm] Loading R300 Microcode
info: [drm] writeback test succeeded in 1 usecs

Comment 7 Coleman Kane 2007-08-31 10:18:09 UTC
Oops, forgot to mention that after I applied the attached patch, I have compiz working properly as my window manager, with all of the eye candy goodies it provides. It works much better than the in-tree behavior (kernel panic and I have to hard-power-off the box!), and it seems almost 99% perfectly useable.

BTW I am using the open-source r300 driver, as it's the only functional one for FreeBSD/amd64.

I get pretty darn good performance from all of them, including the plugins where an app is updating a window that is viewable during some sort of transformation effect (for example, manual Cube rotation while watching a YouTube video works very well).

Anybody know how to enable FSAA with the Open-Source r300 driver?

Three minor "bad" effects that I've noticed:
If I am using the "decoration" plugin, and have "/apps/compiz/plugins/decoration/allscreens/options/shadow_match" set to "any", then I get these ugly thick white borders around every on screen element that is not a normal window (menus, tooltips, etc...), while the shadows seem to appear fine for the normal window. I set this value to "none" and the artifacts went away (and I still seem to have drop-shadows from my windows).

A slow-down in the default (mode 0) resize method in compiz. It is too slow for me to use, as it sends update requests back to the window during the resize, causing the window to redraw itself (and re-lay-out its contents). This has been a relatively slow feature in most WM's for me though, and I think it is more likely linked to how GTK+ handles this event.

I have also noticed that the Totem video player seems to black-out the video when any screen event happens. If I re-size or move the Totem window, however, the video is redisplayed just fine. I added the "video" plugin to compiz and I get this behavior.
Comment 8 Michel Dänzer 2007-09-17 04:20:30 UTC
*** Bug 6463 has been marked as a duplicate of this bug. ***
Comment 9 Michel Dänzer 2007-09-17 04:23:28 UTC
*** Bug 12443 has been marked as a duplicate of this bug. ***
Comment 10 Igor Mozolevsky 2007-09-17 05:25:20 UTC
Created attachment 11602 [details]
screen corruption w/ patch 11358

screen corruption occurs at the top of the screen on T43p
Comment 11 Igor Mozolevsky 2007-09-17 05:27:54 UTC
Created attachment 11603 [details]
xlog for 11602
Comment 12 Igor Mozolevsky 2007-09-17 07:39:05 UTC
the driver still needs to have reasonableness checks like those described in http://bugs.freedesktop.org/show_bug.cgi?id=12443#c5
Comment 13 Eric Anholt 2007-10-17 12:52:49 UTC
jkim's version committed.
Comment 14 Coleman Kane 2007-10-24 15:05:54 UTC
(In reply to comment #13)
> jkim's version committed.
> 

Where was it committed? I still don't see it in FreeBSD -CURRENT...
Comment 15 Robert Noland 2007-10-24 15:09:37 UTC
This was committed to git master, I've asked anholt to commit to freebsd src as well.
Comment 16 Igor Mozolevsky 2008-01-15 16:50:54 UTC
Screen corruption still occurs on T43p (and it seems the screen is not repainted) unless         

Option      "CPPIOMode" "yes"

is specified.
Comment 17 Robert Noland 2008-01-15 21:06:16 UTC
I don't see how this is related to the original bug and I have not seen this on any radeon chipset that I have access to.
Comment 18 Igor Mozolevsky 2008-01-16 01:51:37 UTC
Applying the above patch (11334) leads to screen corruption and no refresh when running apps. Also see http://www.freebsd.org/cgi/query-pr.cgi?pr=119324
Comment 19 Robert Noland 2008-01-16 10:02:59 UTC
I still don't see any evidence that this is related to locking or AIGLX, which is the origin of this bug.  The user in the FreeBSD PR isn't even using AIGLX.  This issue appears to be chipset specific and may not be drm related at all.  Please file this as a new bug, including versions of xserver, mesa, ddx driver, and drm modules.  Also, please verify that the problem does not exist if dri is disabled and what steps are required to demonstrate the screen corruption.
Comment 20 Eric Anholt 2008-01-16 10:13:47 UTC
Re-resolve bug from invalid reopening.