Date: Tue, 05 May 2009 01:20:17 -0500 From: Robert Noland <rnoland@FreeBSD.org> To: David Johnson <david@usermode.org> Cc: freebsd-stable@freebsd.org Subject: Re: Xorg hangs with drmwtq in 7.2-RELEASE Message-ID: <1241504417.1828.19.camel@balrog.2hip.net> In-Reply-To: <200905042015.29394.david@usermode.org> References: <200905042015.29394.david@usermode.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-KMR4JhjSr3Fv0cSrcIRO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-05-04 at 20:15 -0700, David Johnson wrote: > This topic has been recently discussed twice before in the past month and= a=20 > half, but without resolution. It now reappears on my system as I upgrade = to=20 > 7.2-RELEASE. It does not happen with a build from RELENG_7 date=3D2009.03= .13. I=20 > am desperately hoping for a resolution. >=20 > To reiterate the problem: Xorg will occassionally hang. This only happens= when=20 > compositing it enabled. I am using KDE 4.2.2, radeon driver, all ports up= dated=20 > to this morning. About a third of the time the kernel locks up, and I can= not=20 > ssh into the system. The other half of the time I can ssh into the system= .=20 > There I notice that Xorg has the state of "drmwtq", with perhaps some oth= er=20 > GUI processes in the same state. >=20 > The video card is a Radeon X1550. I have tried with and without AGPMode s= et,=20 > and both XAA and EXA render modes. No change. >=20 > You can look at my xorg.conf and Xorg log at: > http://www.usermode.org/misc/xorg.conf > http://www.usermode.org/misc/Xorg.0.log.old >=20 > p.s. Posting to freebsd-stable, as this problem has been previously discu= ssed=20 > here. If this is no longer the appropriate list, please let me know. Unfortunately, hanging in drmwtq isn't really that informative... What this says is that we have submitted commands to the GPU and are waiting on it to process them. When userland tells us to wait for the event, we check to see if the card has already processed the command. If it has, then we just return immediately. If it hasn't, then we sleep waiting on an interrupt from the card once it has processed the command. We will sleep for at most 3 seconds, but userland (via libdrm) will just keep asking us over and over. This generally suggests that the GPU is locked up... Given that you say sometimes it locks up hard (usually a panic, that you can't see since X is running) and other times only X is stalled it might be related to this patch, if you haven't tried this on already. http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch I would usually suggest that you try AGPMode 1, but since you have already tried PCI mode, that should rule that out. You should be using EXA on this card, but having tried XAA is also good for a sanity check. I rarely get to run a card for very long anymore... I end up swapping cards out a few times a day lately, but I have recently been running an x600 pcie (r300) with compiz for at least several hours without issue. If you can figure out a way to reproduce it, or manage to get a core file from one of the panics that would help. Preferably without involving KDE, since I don't run it... I have also run an x1650 PCI-E somewhat recently, which is the closest I have to your card, though I don't remember exactly how long ago it was that I ran it for more than an hour. Probably 2 or 3 weeks ago. robert. > Thank you, --=20 Robert Noland <rnoland@FreeBSD.org> FreeBSD --=-KMR4JhjSr3Fv0cSrcIRO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkn/2qEACgkQM4TrQ4qfROMyLgCfXPI5R5f6OiMK5T538H4eQjHH cvAAnReLnHaElAcifouqNSAZdHSW2Gqe =FqRf -----END PGP SIGNATURE----- --=-KMR4JhjSr3Fv0cSrcIRO--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1241504417.1828.19.camel>