From owner-freebsd-ppc@FreeBSD.ORG Sat Dec 1 16:43:56 2012 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A321598; Sat, 1 Dec 2012 16:43:56 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 24AAB8FC08; Sat, 1 Dec 2012 16:43:55 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id qB1GQPNL068390; Sat, 1 Dec 2012 17:26:26 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <50BA2FB1.5060509@fgznet.ch> Date: Sat, 01 Dec 2012 17:26:25 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: matt Subject: Re: PPC DRM graphics testing References: <50972E9E.3010101@gmail.com> <50974ECD.5010702@fgznet.ch> <50988FE0.9030806@gmail.com> <50989EA0.5020509@fgznet.ch> <5098CA4F.7020306@gmail.com> <509A8B3D.8030703@fgznet.ch> <50B82E9C.5030800@gmail.com> <50B8559F.6090708@gmail.com> In-Reply-To: <50B8559F.6090708@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: x11@freebsd.org, freebsd-ppc@freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 16:43:56 -0000 On 30.11.12 07:43, matt wrote: > On 11/29/12 20:56, Nathan Whitehorn wrote: >> >> >> On Thu, 29 Nov 2012, matt wrote: >> >>> On 11/07/12 08:24, Andreas Tobler wrote: >>>> On 06.11.12 09:29, matt wrote: >>>>> On 11/05/12 21:22, Andreas Tobler wrote: >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>> A good idea, but it didn't help. Backtrace was slightly different, but >>>>> nothing decisive. exaCopyDirty() seems to be involved quite often. >>>>> >>>>> I also found 7.7 will not work, because although they left in r200, >>>>> they >>>>> stripped out UMS. >>>>> >>>>> So it's back to the drawing board, or at least poking at sources >>>>> and/or >>>>> gdb for a while :) >>>> Just a short notice from my side. I finally managed to get the pci >>>> radeon 9200 work, means I can startx. >>>> I had some issues until I found out how to make Xorg recognize the pci >>>> card which is not in the primary pci domain. >>>> >>>> I needed this string in the xorg.conf, under the section "Device" >>>> >>>> BusID "PCI:1@1:2:0" >>>> >>>> Important is ":domain@bus:". >>>> >>>> Regarding drm, I get hardlocks as soon as I start glxgears or other >>>> samples. No more info yet. >>>> >>>> Here the render string: >>>> --- >>>> direct rendering: Yes >>>> OpenGL renderer string: Mesa DRI R200 (RV280 5961) 20090101 TCL >>>> --- >>>> >>>> Chipset: "ATI Radeon 9200 5961 (AGP)" (ChipID = 0x5961) >>>> Mapped VideoRAM: 131072 kByte (128 bit DDR SDRAM) >>>> >>>> Note, it is a PCI card, not an AGP one. >>>> >>>> Also, I do run old Xorg (X.Org X Server 1.7.7 and the 6.14.3 ati pkg.). >>>> >>>> I'll continue playing a bit. >>>> >>>> Andreas >>>> >>>> >>> I got a Apple OEM Radeon 9260 256M AGP 8x. I chopped the two resistors >>> that allow it to work in an MDD, it worked fine for OS X. >>> >>> I still don't have working DRM, however glxgears actually shows the >>> gears. One to two frames are emitted before the card crashes and loops >>> in drmCommandNone. >>> >>> Turning on dev.dri.0.debug=1, I'm seeing an ioctl completing and >>> returning '35' periodically. Not sure what a positive return value >>> means, or what ioctl is being called (I assume it's a flush or something >>> in drmCommandNone). >>> >>> So I'm starting to think it's the MDD that's the issue, but I'm not sure >>> why. I tried adding the 2x_reset quirk in agp.ko, even though it seems >>> unecessary and Linux has no 2x quirk for this chipset either. >>> >>> Doesn't U3 have hardware byteswappers or something...? >> >> Thanks for doing these tests! I wanted to point out that a bug in the >> AGP driver cannot be ruled out. It's fairly simple but never really >> got tested until quite recently when you started looking at this and >> drm began working. >> -Nathan > Puzzles are fun, and if the result is compiz on a powermac all the > better :). > > Well, it at least works fine on the G5 agp bridge. So if it is an AGP > issue, it's a quirk in Uninorth-2 possiby. It'd be interesting to see if > drm was OK on pci macs. BusType "PCI" didn't fix Xorg, but I'm not sure > that means that agp is ok? > > Jung-uk Kim had a little program to test the gart, but unfortunately > it's heavy on the ia32 assembly. > > Some other things I have yet to try are to disable one processor and to > swap everything to the other MDD. > I am still trying to figure out what the meaning of drm returning 35 > over and over might be as well. I quess I'm now in the same boat as you :) With a mac mini which has a "agp0: " bridge. Starting X is ok, but as soon as I launch glxgears I get a complete freeze. Looking in some sources (lnx, drivers/char/agp) gives a hint that there are some distinctions between uninorth revs. Although mine is not mentioned. Looking around. Andreas