Date: Tue, 06 Nov 2012 06:22:40 +0100 From: Andreas Tobler <andreast-list@fgznet.ch> To: matt <sendtomatt@gmail.com> Cc: x11@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: PPC DRM graphics testing Message-ID: <50989EA0.5020509@fgznet.ch> In-Reply-To: <50988FE0.9030806@gmail.com> References: <50972E9E.3010101@gmail.com> <50974ECD.5010702@fgznet.ch> <50988FE0.9030806@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------030507010805020908070404
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
On 06.11.12 05:19, matt wrote:
> On 11/04/12 21:29, Andreas Tobler wrote:
>> On 05.11.12 04:12, matt wrote:
>>> So I've been plagued by issues on my rv250...the gpu is locking up at
>>> times and resulting in a backtrace that seems to indicate the card is no
>>> longer responding (drmCommandNone hangs on drmIoctl hangs on ioctl). At
>>> this point, I'm not sure if I have bad hardware, something is wrong with
>>> mesa for rv250, or something is wrong with drm. I unfortunately only
>>> have one PowerPC machine with a radeon card, so I'd love to see if
>>> anyone else has had any luck with similar configs (G4 tower with radeon
>>> AGP card).
>>>
>>> If anyone has a working radeon with DRM on powerpc, could you post
>>> glxinfo | fgrep 'render' (if you can get mesa-demos to compile...it's a
>>> chore). And/or results trying to run a 3d app like minetest, glxgears,
>>> whatever uses DRI would be really helpful in ruling out both my hardware
>>> and the drm code. I don't want to dig into the mesa mess unless I'm sure
>>> that's where the problem lies.¨
>> Both on a G5 in 32-bit mode. And mesa-demos are 'working'.
>>
>> Radeon 9600:
>> direct rendering: Yes
>> OpenGL renderer string: Mesa DRI R300 (RV350 4152) 20090101 TCL
>>
>>
>> Radeon 9800:
>> direct rendering: Yes
>> OpenGL renderer string: Mesa DRI R300 (R350 4E48) 20090101 TCL
>>
>> Andreas
>>
> Thanks, it makes me think AGP is fine on powerpc, and that it's probably
> my hardware or a mesa bug...I have seen a lot of historical discussion
> of the locking scheme in the r200 drivers, and it makes me wonder if
> that and/or smp are to blame. Apparently drmCommandNone is one of the
> few times drm actually waits for the card, so many different bugs that
> crash the gpu will appear with a similar back trace ending in
> drmCommandNone calling ioctl.
Hm, I can try to bring the Radeon 9200 PCI up and see how it behaves.
It'll take a few moments. But at least we have another config to compare.
Oh, and one thing to note, my config works with built-in (not a kernel
module) drm/radeondrm. Have you tried this too?
Kernel config:
# Direct Rendering modules for 3D acceleration.
device drm # DRM core module required by DRM drivers
device radeondrm # ATI Radeon
Attached the patch to make it compile.
Andreas
--------------030507010805020908070404
Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0";
name="radeon_conf.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="radeon_conf.diff"
Index: conf/files
===================================================================
--- conf/files (revision 242266)
+++ conf/files (working copy)
@@ -1175,9 +1175,9 @@
dev/drm/r300_cmdbuf.c optional radeondrm
dev/drm/r600_blit.c optional radeondrm
dev/drm/r600_cp.c optional radeondrm \
- compile-with "${NORMAL_C} ${NO_WUNUSED_VALUE} ${NO_WCONSTANT_CONVERSION}"
+ compile-with "${NORMAL_C_NOWERROR} ${NO_WUNUSED_VALUE} ${NO_WCONSTANT_CONVERSION}"
dev/drm/radeon_cp.c optional radeondrm \
- compile-with "${NORMAL_C} ${NO_WUNUSED_VALUE} ${NO_WCONSTANT_CONVERSION}"
+ compile-with "${NORMAL_C_NOWERROR} ${NO_WUNUSED_VALUE} ${NO_WCONSTANT_CONVERSION}"
dev/drm/radeon_cs.c optional radeondrm
dev/drm/radeon_drv.c optional radeondrm
dev/drm/radeon_irq.c optional radeondrm
--------------030507010805020908070404--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50989EA0.5020509>