Date: Mon, 03 Dec 2012 18:02:55 -0800 From: matt <sendtomatt@gmail.com> To: Andreas Tobler <andreast-list@fgznet.ch> Cc: x11@freebsd.org, Nathan Whitehorn <nwhitehorn@freebsd.org>, freebsd-ppc@freebsd.org Subject: Re: PPC DRM graphics testing Message-ID: <50BD59CF.1070501@gmail.com> In-Reply-To: <50BA2FB1.5060509@fgznet.ch> 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> <alpine.BSF.2.00.1211292254060.46502@banshee.munuc.org> <50B8559F.6090708@gmail.com> <50BA2FB1.5060509@fgznet.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/01/12 08:26, Andreas Tobler wrote: > 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: <Apple UniNorth 2 AGP Bridge>" 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 > > I have also seen those, there are some notes in the .h headers too. I just rebuilt the mdd system from scratch, due to the possible cvsup security issue...no change. At least we are handling the 2x reset quirk already...they just handle it differently obviously. The gart invalidation/flush notes are interesting (invalidate then reset then invalidate then use), but my reading of our agp code indicates we're handling that? I do see some stuff that is U3 specific we do not do (I think) but ironically U3 is working for us. :) It's quite puzzling but I haven't given it an in depth look...Darwin should be a good source as well. There are old references to lin KMS needing a fix for pci config space due to endian issues, which may have nothing to do with us at all, and there are some notes that some registers are big endian and others are little (?!). Still investigating, but I think that your test indicates a quirk with Uninorth-2 (and possibly earlier revisions), as this is also my agp bridge. Thanks, Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50BD59CF.1070501>