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/[email protected]/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 <[email protected]>
An: [email protected]
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.
_______________________________________________
xorg-driver-ati mailing list
[email protected]
http://lists.x.org/mailman/listinfo/xorg-driver-ati
