From owner-freebsd-ppc@FreeBSD.ORG Fri Nov 30 06:44:17 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 11FEBA89; Fri, 30 Nov 2012 06:44:17 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C1AFD8FC12; Fri, 30 Nov 2012 06:44:16 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so219817pbc.13 for ; Thu, 29 Nov 2012 22:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WXiIWcqiGWXaeUZ2/KZDJLvUjc0l+IgABNVoxeQNU+U=; b=ifwiQmPoo9CdQ2BUKyzRD62+8+t4ncNseMntDp5AAD08GOOZO6RQJEWqIbdCXUtY+m fIllSHX+mZjtlzw3EOhbGNj6YO/S6Il14zQ8BwSR8ZMbc38McwdnzjkalspYnNvvH+23 sFPjYMxzNX+YTdjknaYvuKSTDwxwJ9qkoZNGnGVfdc8MucLqkB1HLhAEXRxpvEaQ+2ha SmsI6ekOlFr7WyEHSwVeNRzjP8bTO/tmuhsqwrrj3VZA7tGakMQFLTGChwjp2zof74/E 5HLen5juOV6PLLCbhOKhSymr+X+TxiAYcJOmcjJMLXL9JJlC52gu8loHX9IxDcVG5ERy /kaQ== Received: by 10.68.136.163 with SMTP id qb3mr2801988pbb.129.1354257856078; Thu, 29 Nov 2012 22:44:16 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id wg3sm2539470pbc.28.2012.11.29.22.44.12 (version=SSLv3 cipher=OTHER); Thu, 29 Nov 2012 22:44:14 -0800 (PST) Message-ID: <50B8559F.6090708@gmail.com> Date: Thu, 29 Nov 2012 22:43:43 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Nathan Whitehorn 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 30 Nov 2012 06:44:17 -0000 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. Matt