<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><span style="font-size:10pt;">
<div>I started investigating the problem because AGP mode used
to work <font color="#1F497D">with</font> the UMS drivers
(although I now understand they didn’t really use AGP memory)
and in the second patch I mentioned below Benjamin
Herrenschmidt stated that “there's a chip errata (for the
pre-R600 chips). On those chips, the aperture must be aligned
to the aperture size (that is FB_START in MC_FB_LOCATION must
be aligned to the aperture size).” Since that workaround/patch
definitely isn’t
in the current DRM code any more (probably got lost in the
transition to KMS) my idea was to re-apply the <font
color="#1F497D">three-line </font>workaround/patch (which
should be quite trivial given the comment in
radeon_vram_location in the drm kernel code).
But since you indicated that AGP has nothing to do with that
and PCI mode <font color="#1F497D">(agpmode = -1) </font>works
I guess there’s no point to do that.<font color="#1F497D"> </font></div>
<div><font color="#1F497D"> </font></div>
<div><font color="#1F497D" face="Calibri" size="2"><span
style="font-size:11pt;">Additionally, I found out that the
uninorth chipset used in my (PowerMac) machine has some
very “special” features, basically it doesn’t do address
mapping via the GART at all but directly uses
a 256 MB AGP aperture (other sizes seem not to be
supported) which has to be allocated coherently
non-cacheable (OpenBSD seems to have a working AGP/drm
radeon powermac driver, the info comes from their source
code). Although it would be rather trivial to port the
OpenBSD
code I’ll stick with PCI mode for now.</span></font></div>
</span><br>
Thanks for the info<br>
<br>
Jochen<br>
<br>
Am 11.11.2013 21:35, schrieb Alex Deucher:<br>
</div>
<blockquote
cite="mid:CADnq5_PzauJ6dJByRC-3mY74phNLiejvO38w=Qm6My3vmBR7GA@mail.gmail.com"
type="cite">
<pre wrap="">On Fri, Nov 8, 2013 at 2:35 AM, Jochen Rollwagen <a class="moz-txt-link-rfc2396E" href="mailto:joro-2013@t-online.de"><joro-2013@t-online.de></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Hello there,
i *think* i found a regression (card/system freeze in AGP mode) that must have been in the drm code for quite some time (since the switch to kms drivers) and possibly also the potential solution (re-apply an old patch from pre-kms-days). Affected seem to be older cards (actually, very old cards :-) before R600. I mailed this to the ati driver mailing list, but was told that this is a kernel/drm subject now, so i forward the mail interchange to this list. Details below, one has to start reading from the end upwards to get the chronological order, of course.
Could somebody give me a hint on how to re-apply the old patch or whether the info i found is valid ? The next step i would take is to insert some diagnostic messages in radeon_vram_location (see below) and build a new kernel.
</pre>
</blockquote>
<pre wrap="">
I'm not entirely sure what you are proposing to change, but none of
the stuff you mentioned below has to do with AGP. AGP is unstable
because AGP sucks. KMS unfortunately exacerbates that since it makes
much greater use of AGP memory than UMS ever did. To really fix AGP
with KMS, we'd probably need to manage two pools of memory, one
non-cache-coherent pool for AGP and one cache coherent pool that used
the on-chip gart, then fix up the kernel and userspace accel drivers
to use the appropriate pools.
Alex
</pre>
<blockquote type="cite">
<pre wrap="">Cheers
Jochen
-------- Original-Nachricht --------
Betreff: Fwd: Fwd: Fwd: Re: regression on RV280 card freeze, patch not applicable any more
Datum: Fri, 25 Oct 2013 15:04:33 +0200
Von: Jochen Rollwagen <a class="moz-txt-link-rfc2396E" href="mailto:joro-2013@t-online.de"><joro-2013@t-online.de></a>
An: <a class="moz-txt-link-abbreviated" href="mailto:xorg-driver-ati@lists.x.org">xorg-driver-ati@lists.x.org</a>
more info (and possible solution):
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/aligned to VRAM size 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 <a class="moz-txt-link-rfc2396E" href="mailto:joro-2013@t-online.de"><joro-2013@t-online.de></a>
An: <a class="moz-txt-link-abbreviated" href="mailto:xorg-driver-ati@lists.x.org">xorg-driver-ati@lists.x.org</a>
I've done some more researching and found the following:
- There's another follow-on-patch ("Extend the alignment workaround to post-rv280 chips as well") to the one indicated below (<a class="moz-txt-link-freetext" href="http://cgit.freedesktop.org/~agd5f/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".
- 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
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 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 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>):
* 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?
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 <a class="moz-txt-link-rfc2396E" href="mailto:joro-2013@t-online.de"><joro-2013@t-online.de></a>
An: <a class="moz-txt-link-abbreviated" href="mailto:xorg-driver-ati@lists.x.org">xorg-driver-ati@lists.x.org</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">[ Please always follow up to the mailing list ]
On Die, 2013-10-08 at 14:53 +0200, Jochen Rollwagen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Am 08.10.2013 10:03, schrieb Michel Dänzer:
</pre>
<blockquote type="cite">
<pre wrap="">On Sam, 2013-10-05 at 15:13 +0200, Jochen Rollwagen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">It's the other way around: The kernel radeon driver resets the card to
try and get it running again after a lockup.
</pre>
<blockquote type="cite">
<pre wrap="">PCI mode works. After researching I found a old bug that was fixed
back in 2006 (<a 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 ?
</pre>
</blockquote>
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">It's in the kernel now.
</pre>
</blockquote>
<pre wrap="">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.
_______________________________________________
dri-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/dri-devel">http://lists.freedesktop.org/mailman/listinfo/dri-devel</a>
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>