xf86-video-ati with patch-src-radeon_driver.c freeze the system

Roland Smith rsmith at xs4all.nl
Tue Mar 1 21:45:10 UTC 2011


On Tue, Mar 01, 2011 at 02:05:45PM -0700, Warren Block wrote:
> ...Well, that was interesting.  Swapped out my 4650 and X1650 cards 
> again, and starting X locked up.  I swear it worked a couple of days ago 
> when I tested it with the stock port patches.

:-)

>  Just swapped it for my  normal HD4650.
> 
> FreeBSD lightning 8.2-STABLE FreeBSD 8.2-STABLE #0: Mon Feb 28 18:43:21 
> MST 2011     root at lightning:/usr/obj/usr/src/sys/LIGHTNING  i386
> 
> X1650:  512M, PCIE: mem_size 20000000, aper_size 0
> HD4650: 512M, PCIE: mem_size 20000000, aper_size 0

Mine doesn't set aper_size to zero. Could that have something to to with the
i386/amd64 difference? 
 
> Yet the HD4650 has worked every time...

Question is, does it work without the patch in the ports tree?

> Is the original patch outdated?  Here's the code:
> 
>      /* Fix for RN50, M6, M7 with 8/16/32(??) MBs of VRAM -
>         Novell bug 204882 + along with lots of ubuntu ones */
>      if (aper_size > mem_size)
>          mem_size = aper_size;

On neither of our systems this code would be executed, since mem_size>aper_size.

>      /* don't map the whole FB in the internal address space.
>       * we don't currently use fb space larger than the aperture
>       * size and on cards with more than 512 MB of vram, this can overflow
>       * the internal top of gart calculation on some systems.
>       * Limit it to cards with more than 512 MB as this causes problems
>       * on some other cards due to the way the ddx and drm set up the
>       * internal memory map.
>       * See fdo bug 24301.
>       */
 
> And then the patch, with the exact opposite test:
> 
>      if (mem_size > aper_size)
>          mem_size = aper_size;

Typo? This is definitely what is giving me problems.

> So unless they are equal, mem_size will be set to aper_size afterwards.
> The original code continues:
> 
>      if (mem_size > 0x20000000)
>          mem_size = aper_size;

This will not be executed on my system, but it will be on yours, it seems.

> Looks to me like it's not getting out of there without setting mem_size 
> to zero.  Whether aper_size should really be zero, no idea.  That seems 
> like an upstream bug.

Since aper_size seems to be used to limit the size of the framebuffer, I'd think
that a value of 0 is a bug!

I'm nuking the patch in my ports tree, that's for sure;

    # cd /usr/ports/x11-drivers/xf86-video-ati/files
    # truncate -s 0 patch-src-radeon_driver.c
    # chflags schg,sunlnk patch-src-radeon_driver.c

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20110301/9833b7bf/attachment.pgp


More information about the freebsd-x11 mailing list