Bug #1155

DRM update

Added by hasso about 6 years ago. Updated over 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

http://leaf.dragonflybsd.org/~hasso/dragonfly-patches/drm-update-20081029.patch
updates the DRM code to the very latest one from DRM git repo. Amongst
other things it brings in support for many newer Intel and AMD/ATI
chipsets.

Please test and report back any failure or success with brief info (dmesg
snippet will do in case of success) about chipset in use etc, please.

Note that there is at least one regression compared to the one in the
kernel - Intel DRM plays worse with XAA (mkay, it doesn't play at all in
some cases). Although still in use by some users due to performance
reasons, XAA is considered to be deprecated and bugs are closed in the
freedesktop.org bugzilla with WONTFIX. So I don't consider it as
showstopper.

History

#1 Updated by steve about 6 years ago

On Wed, 29 Oct 2008 09:31:57 +0200
Hasso Tepper <> wrote:

Hi - locked up and rebooted for me (ASUS A8V with Radeon 9200SE).
Last time round this happened too and the problem was that dma-buflist
and/or dma->pagelist weren't allocated - corecode fixed it then but I'm not
sure how.

#2 Updated by hasso about 6 years ago

http://leaf.dragonflybsd.org/mailarchive/users/2008-01/msg00012.html

This one? The cause can't be the same, this is fixed for sure in the
update as well.

And "rebooted" means that it paniced? Crashdump?

#3 Updated by steve about 6 years ago

On Thu, 30 Oct 2008 10:33:11 +0200
Hasso Tepper <> wrote:

That's the one - although that wasn't the proper fix.

Display froze, system rebooted, no panic, no message just a reboot.

#4 Updated by hasso about 6 years ago

Really strange. Never seen something like this ... Anyone has idea?

#5 Updated by corecode about 6 years ago

Interrupt foobar? These things tend to be hard to debug. Could be triple fault on the stack running the interrupt handler...

cheers
simon

#6 Updated by steve about 6 years ago

On Thu, 06 Nov 2008 12:11:12 +0100
"Simon 'corecode' Schubert" <> wrote:

Any idea how I can find out ? I'm perfectly willing to crash the
box again if there's any gain to be had from doing so.

#7 Updated by steve almost 6 years ago

On Wed, 29 Oct 2008 09:31:57 +0200
Hasso Tepper <> wrote:

I picked up a new video card (Radeon X1650 AGP) - it seems to be
working fine with this patch, Mesa-7.2 and xorg-server-1.5.1 (I've hacked
the pkgsrc packages to get those, if anyone wants the hackage let me know).
This on my ever troublesome A8V box.

#8 Updated by steve almost 6 years ago

On Wed, 29 Oct 2008 09:31:57 +0200
Hasso Tepper <> wrote:

Heh I spoke too soon when I said it worked fine with my new X1650 -
but it's close. From time to time an app using GLX would lock up in drmvbl
state - I looked around and it seemed that there was a problem with
vblank_disable_fn in drm_irq.c - a lock was taken on dev->vbl_lock and
there was a path out of the function that didn't unlock it - so I added the
unlock and I haven't been able to provoke a lockup since - patch below
(applies after your patch Hasso).

--- drm_irq.c.patched 2008-12-19 22:16:08 +0000
+++ drm_irq.c 2008-12-19 21:40:58 +0000
@@ -74,8 +74,10 @@
callout_deactivate(&dev->vblank_disable_timer);

DRM_DEBUG("vblank_disable_allowed=%d\n",
dev->vblank_disable_allowed);
- if (!dev->vblank_disable_allowed)
+ if (!dev->vblank_disable_allowed) {
+ DRM_SPINUNLOCK(&dev->vbl_lock);
return;
+ }

for (i = 0; i < dev->num_crtcs; i++) {
if (atomic_read(&dev->vblank[i].refcount) == 0 &&

#9 Updated by hasso over 5 years ago

Newer updated was committed.

Also available in: Atom PDF