<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> I found it. void radeon_vram_location in radeon_device.c says * Note: GTT start, end, size should be initialized before calling this * function on AGP platform. * * Note: We don't explicitly enforce VRAM start to be aligned on VRAM size, * this shouldn't be a problem as we are using the PCI aperture as a reference. * Otherwise this would be needed for rv280, all r3xx, and all r4xx, but * not IGP. * so does this mean i just have to re-apply the old patch i found ? struct radeon_mc in radeon.h contains aper_base as a member which could be set using the code snippet below. Cheers Jochen <div class="moz-forward-container"> -------- Original-Nachricht -------- <table class="moz-email-headers-table" border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Betreff: </th> <td>Fwd: Fwd: Re: regression on RV280 card freeze, patch not applicable any more</td> </tr> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Datum: </th> <td>Fri, 25 Oct 2013 11:31:32 +0200</td> </tr> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Von: </th> <td>Jochen Rollwagen <a class="moz-txt-link-rfc2396E" href="mailto:joro-2013@t-online.de"><joro-2013@t-online.de></a></td> </tr> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">An: </th> <td><a class="moz-txt-link-abbreviated" href="mailto:xorg-driver-ati@lists.x.org">xorg-driver-ati@lists.x.org</a></td> </tr> </tbody> </table> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> I've done some more researching and found the following: <div class="moz-forward-container"> - There's another follow-on-patch ("Extend the alignement workaround to post-rv280 chips as well") to the one indicated below (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://cgit.freedesktop.org/%7Eagd5f/xf86-video-ati/commit/?id=b2145aea36bb035bff048366c607b967d70fff49">http://cgit.freedesktop.org/~agd5f/xf86-video-ati/commit/?id=b2145aea36bb035bff048366c607b967d70fff49</a>) that applies to not only RV280 but "rv280, all r3xx, and all r4xx, but not IGP" (even stranger that its being lost hasn't been recognized). - the piece of code affected seems to be (IMHO) in drivers/gpu/drm/radeon/: The (Radeon ?) Register RADEON_CONFIG_APER_0_BASE is defined in radeon_reg.h but never used in the driver: radeon_reg.h:#define RADEON_CONFIG_APER_0_BASE 0x0100 Since i don't assume that Radeon hardware has changed too much since 2006 i also assume that this register definition is still valid i.e. the register still exists on those cards :-). So why is it never used/set/read in the kernel driver ? The same applies to the xf86-video-ati driver, the register is defined but never used/set/read. Strange. But maybe the driver can do without setting or reading registers ? :-) in r100.c there's static u32 r100_get_accessible_vram(struct radeon_device *rdev) { u32 aper_size; u8 byte; aper_size = RREG32(RADEON_CONFIG_APER_SIZE); /* Set HDP_APER_CNTL only on cards that are known not to be broken, * that is has the 2nd generation multifunction PCI interface */ if (rdev->family == CHIP_RV280 || rdev->family >= CHIP_RV350) { WREG32_P(RADEON_HOST_PATH_CNTL, RADEON_HDP_APER_CNTL, ~RADEON_HDP_APER_CNTL); DRM_INFO("Generation 2 PCI interface, using max accessible memory\n"); return aper_size * 2; } That's the code executed on my machine according to dmesg. Missing (from the original patch, not applicable any more because of driver reorganization) seems to be CARD32 aper0_base = INREG(RADEON_CONFIG_APER_0_BASE); aper0_base &= ~(mem_size - 1); info->mc_fb_location = (aper0_base >> 16); The patch that seems to have removed/overridden this code is: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41307.html">http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41307.html</a> According to that patch, it was "booted on PCI r100, PCIE rv370, IGP rs400". So IMHO this could be a classical regression for an AGP RV280 card (like mine) and might explain why PCI mode works. this is Additionally corroborated by this post (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://comments.gmane.org/gmane.comp.freedesktop.xorg/5429">http://comments.gmane.org/gmane.comp.freedesktop.xorg/5429</a>): "Roland Scheidegger wrote: > I've tried the patch with my radeon 9000pro, and it does not work there > neither. Issues are pretty similar, moving (3d) windows around leaves > artifacts (and eventually even a gpu lockup), xawtv overlay still > doesn't work, but on this setup I got the mouse pointer back at least. I got the patch to work when disabling this: * The above doesn't necessarily work. For example, I've seen machines * with 128Mb configured as 2x64Mb apertures. I'm now _always_ setting * RADEON_HOST_PATH_CNTL. OUTREGP (RADEON_HOST_PATH_CNTL, RADEON_HDP_APER_CNTL, ~RADEON_HDP_APER_CNTL); (which was previously done only on some chip families). I _think_ this is not correct on all cards as the apertures may not be configured correctly (and X doesn't set them up neither, if those correspond to the RADEON_CONFIG_APER registers)" Could a Radeon guru confirm this or am i totally lost? by the way, Haiku OS seems to have the patch :-) : <pre>// graphics card addresses correspond to physical CPU addresses as much as possible static void Radeon_SetupMCAddresses_Direct( device_info *di ) { shared_info *si = di->si; uint32 aper0 = INREG( di->regs, RADEON_CONFIG_APER_0_BASE ); // bug in asics mean memory must be aligned to memory size... if ( IS_DI_R300_VARIANT || di->asic == rt_rv280 ) { aper0 &= ~( di->local_mem_size - 1 );</pre> Cheers Jochen -------- Original-Nachricht -------- <table class="moz-email-headers-table" border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Betreff: </th> <td>Fwd: Re: regression on RV280 card freeze, patch not applicable any more</td> </tr> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Datum: </th> <td>Fri, 18 Oct 2013 15:32:18 +0200</td> </tr> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Von: </th> <td>Jochen Rollwagen <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:joro-2013@t-online.de"><joro-2013@t-online.de></a></td> </tr> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">An: </th> <td><a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:xorg-driver-ati@lists.x.org">xorg-driver-ati@lists.x.org</a></td> </tr> </tbody> </table> <pre>sorry about that. Anyway, i checked drivers/gpu/drm/radeon and drivers/char/agp/uninorth-agp.c and can't seem to find the patch indicated below. Might it have gone missing :-) ? Am 08.10.2013 18:41, schrieb Michel Dänzer: > [ Please always follow up to the mailing list ] > > On Die, 2013-10-08 at 14:53 +0200, Jochen Rollwagen wrote: >> Am 08.10.2013 10:03, schrieb Michel Dänzer: >>> On Sam, 2013-10-05 at 15:13 +0200, Jochen Rollwagen wrote: >>>> I’m running a RV280 based Radeon 9200 card (I know, an ancient card) >>>> in a Mac Mini G4 (powerpc-architecture) with Ubuntu Precise and the >>>> latest 3.4.64-kernel/ati driver and get lockups when trying to run the >>>> card in AGP mode (KMS enabled). The lockups happen when resetting the >>>> card (that’s what I can infer from the oops-screen). >>> It's the other way around: The kernel radeon driver resets the card to >>> try and get it running again after a lockup. >>> >>> >>>> PCI mode works. After researching I found a old bug that was fixed >>>> back in 2006 (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://bugs.freedesktop.org/show_bug.cgi?id=6011">https://bugs.freedesktop.org/show_bug.cgi?id=6011</a>) that >>>> looks like the freeze I experience (since PCI mode – which allocates >>>> 64 MB of memory - works and AGP mode which by default allocates 256 MB >>>> doesn’t). The card has 64 mb memory. >>>> >>>> >>>> So the first question is, could this be the problem that causes the >>>> lockups ? >>> Not really. The GART and VRAM memory apertures aren't directly related, >>> and the fix for the bug above should still be incorporated in the >>> current radeon KMS code. >>> >>> >>> Does radeon.agpmode=1 or radeon.agpmode=4 work? >>> >>> >> Thank you for your reply. First, none of the agpmodes work, they just >> take more or less time to lockup the card (1 - slowest, 4 fastest). >> Secondly, if you write that the fix "should be incorporated in the >> current code", i'm somewhat lost because it definitely isn't there. > It's in the kernel now. > > Well........no. I checked the 3.4.64 kernel sources after my last Mail and the code isn't in the drivers/gpu/drm/radeon sources. But of course i might have overlooked something. </pre> </div> </div> </body> </html>