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