Radeon HD4850 DRI Issues

[Robert Noland]

On Mon, 2009-12-07 at 15:50 -0500, Greg Rowe wrote:
> Greetings,
>   I have an existing desktop system with a Gigabyte Radeon HD4850 1GB PCI 
> Express Card in it. The desktop has an ASUS P5N7A-VM main board, 4GB 
> ram(tested with 2GB also), Intel Core 2 Duo E6850, on-board video disabled in 
> the BIOS. The Radeon was purchased to replace a failed Nvidia card around 6 
> months ago. At that time the system was at 7.2 Stable and the best I could 
> ever get was running with DRI turned off and no acceleration. Enabling either 
> would lock up the X display forcing a reboot. I decided to wait and try again 
> after 8.0 was released and I must say a lot of progress has been made. 
> 
>  At 8.0 Stable/xorg 7.4.2, everything now works (including acceleration) 
> except for DRI. If I run with DRI enabled, I get no background colors, garbage 
> on a KDE background, and menu artifacts all over the screen and terminal 
> windows (TWM) until they finally become unusable. I've used TWM and FVWM in 
> all the testing to avoid any issues that may be KDE specific. I've tried the 
> RadeonHD driver in ports and the development version from ports and they both 
> make the system pretty much unusable with DRI on. The ATI driver from ports 
> actually works the best. Interestingly, with the radeonhd drivers and DRI, I 
> get tiny garbage all over the background screen and some of it appears to be 
> the ASUS Bios splash screen?
> 
>  I know 7.6.1 is due out soon, and maybe DRI will work then, but just in case 
> it something specific to my configuration or hardware I've attached the 
> information requested earlier this year by Robert to a person having almost 
> the same problem with a HD4550 card. I think that person finally did an amd64 
> build to get around the issue? If anyone sees anything I'm missing short of 
> waiting, I'd appreciate the info.
> 
> The attached files are as follows:
>  xorg.conf  - This is the one used for the tests and logs. I've also tried a 
> bare minimum xorg.conf with just the ati driver line it it and I get the same 
> problem with DRI.
> 
> Xorg.log_without_dri - Log with DRI turned off. Everything works including 
> glxgears. No XV though and xvinfo reports no adapters.
> 
> Xorg.log_with_dri - DRI enabled, TWM window manager. Black background instead 
> of the normal grey. Every time the menu button is clicked, the menu stays 
> visible in that location. Mouse clicks are hit and miss so the menus are all 
> over the screen. Xterm scrolling works for a while and then stops.
> 
> dmesg - System dmesg
> dmesg_drm - DRM messages from dmesg. DRI enabled.
> sysctl_hw.dri.0 - Result with DRI enabled.
> memcontrol_list - Result with DRI enabled.
> xvinfo - Result with DRI enabled.

Ok, I've found the issue now... It is a somewhat invasive solution
though, so it will take me a little time.

Basically, the issue is this.  We create a list of maps either in the
kernel or via userland requesting them to be added.  Each map has an
offset associated with it for mmap.  Mostly the offsets are all kernel
virtual addresses, but a few (register and framebuffer maps) are
physical addresses.  On i386, when we allocate scatter gather memory for
the GART aperture (32Mb on radeon) it is being allocated at the end of
the kva space.  I have gone back and looked at all of the reports of
this that I have and the framebuffer is always at 0xe0000000.  When the
kva returned by bus_dma overlaps with the physical address of the
framebuffer, we match the incorrect map when mmap is called and
therefore we are actually mapping the ring buffer inside of the
framebuffer, rather that out of the scatter gather memory where it
belongs.

I have never seen this issue on amd64.  On i386 when the framebuffer is
located lower than 0xe0000000 things mostly work as well.  I have to
overhaul the way that we handle mmap offsets to get this sorted out and
possibly make a couple of changes to libdrm, which is shared code.

robert.
 
> Thanks,
> Greg
> 
> _______________________________________________
> freebsd-x11 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"
-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD