Fwd: Fwd: Fwd: Re: regression on RV280 card freeze, patch not applicable any more

Fri Oct 25 06:04:33 PDT 2013

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

-------- Original-Nachricht --------
Betreff: 	Fwd: Fwd: Re: regression on RV280 card freeze, patch not 
applicable any more
Datum: 	Fri, 25 Oct 2013 11:31:32 +0200
Von: 	Jochen Rollwagen <joro-2013 at t-online.de>
An: 	xorg-driver-ati at lists.x.org

I've done some more researching and found the following:

- There's another follow-on-patch ("Extend the alignement workaround to 
post-rv280 chips as well") to the one indicated below 
(http://cgit.freedesktop.org/~agd5f/xf86-video-ati/commit/?id=b2145aea36bb035bff048366c607b967d70fff49) 
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:

http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41307.html

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 
(http://comments.gmane.org/gmane.comp.freedesktop.xorg/5429):

/"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 :-) :

// 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 );

Cheers

Jochen
-------- Original-Nachricht --------
Betreff: 	Fwd: Re: regression on RV280 card freeze, patch not applicable 
any more
Datum: 	Fri, 18 Oct 2013 15:32:18 +0200
Von: 	Jochen Rollwagen <joro-2013 at t-online.de>
An: 	xorg-driver-ati at lists.x.org

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 (https://bugs.freedesktop.org/show_bug.cgi?id=6011) 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-driver-ati/attachments/20131025/ef184da1/attachment.html>