Date: Tue, 22 Dec 2009 11:46:12 -0500 From: Steve Polyack <korvus@comcast.net> To: Robert Noland <rnoland@FreeBSD.org> Cc: freebsd-x11 <freebsd-x11@freebsd.org> Subject: Re: PCI Radeon 9250 - DRI/DRM in 8.0-RELEASE Message-ID: <4B30F7D4.9040307@comcast.net> In-Reply-To: <1261414036.2304.1.camel@balrog.2hip.net> References: <4B213D8F.6080906@comcast.net> <1260474623.2281.8.camel@balrog.2hip.net> <4B215405.2080502@comcast.net> <1260476369.2281.16.camel@balrog.2hip.net> <1260556637.2281.19.camel@balrog.2hip.net> <4B2647C6.6080101@comcast.net> <4B2F9E41.909@comcast.net> <1261412678.2302.10.camel@balrog.2hip.net> <4B2FA5F3.8020605@comcast.net> <1261414036.2304.1.camel@balrog.2hip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/21/09 11:47, Robert Noland wrote: > On Mon, 2009-12-21 at 11:44 -0500, Steve Polyack wrote: > >> On 12/21/09 11:24, Robert Noland wrote: >> >>> On Mon, 2009-12-21 at 11:11 -0500, Steve Polyack wrote: >>> >>> >>>> Robert, >>>> The drm_mmap patch >>>> (http://people.freebsd.org/~rnoland/drm_mmap_fix.patch) that you >>>> provided seems to have solved my issues: >>>> >>>> OpenGL vendor string: Tungsten Graphics, Inc. >>>> OpenGL renderer string: Mesa DRI R200 20060602 x86/MMX/SSE2 TCL >>>> OpenGL version string: 1.3 Mesa 7.4.4 >>>> >>>> (II) [drm] DRM interface version 1.2 >>>> (II) [drm] DRM open master succeeded. >>>> (II) RADEON(0): [drm] Using the DRM lock SAREA also for drawables. >>>> (II) RADEON(0): [drm] framebuffer handle = 0x30000000 >>>> (II) RADEON(0): [drm] added 1 reserved context for kernel >>>> (II) RADEON(0): X context handle = 0x1 >>>> (II) RADEON(0): [drm] installed DRM signal handler >>>> (II) RADEON(0): [pci] 8192 kB allocated with handle 0xe964c000 >>>> (II) RADEON(0): [pci] ring handle = 0x40000000 >>>> (II) RADEON(0): [pci] Ring mapped at 0x28a7d000 >>>> (II) RADEON(0): [pci] Ring contents 0x00000000 >>>> (II) RADEON(0): [pci] ring read ptr handle = 0x50000000 >>>> (II) RADEON(0): [pci] Ring read ptr mapped at 0x286ff000 >>>> (II) RADEON(0): [pci] Ring read ptr contents 0x00000000 >>>> (II) RADEON(0): [pci] vertex/indirect buffers handle = 0x60000000 >>>> (II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x30c00000 >>>> (II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000 >>>> (II) RADEON(0): [pci] GART texture map handle = 0x70000000 >>>> (II) RADEON(0): [pci] GART Texture map mapped at 0x30e00000 >>>> (II) RADEON(0): [drm] register handle = 0x10000000 >>>> (II) RADEON(0): [dri] Visual configs initialized >>>> (II) RADEON(0): RADEONRestoreMemMapRegisters() : >>>> (II) RADEON(0): MC_FB_LOCATION : 0xefffe000 0x1fff0000 >>>> (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 >>>> (==) RADEON(0): Backing store disabled >>>> (II) RADEON(0): [DRI] installation complete >>>> (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers >>>> (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers >>>> (II) RADEON(0): [drm] dma control initialized, using IRQ 16 >>>> (II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808 >>>> (WW) RADEON(0): DRI init changed memory map, adjusting ... >>>> (WW) RADEON(0): MC_FB_LOCATION was: 0xefffe000 is: 0xefffe000 >>>> (WW) RADEON(0): MC_AGP_LOCATION was: 0xffffffc0 is: 0xffffffc0 >>>> (II) RADEON(0): RADEONRestoreMemMapRegisters() : >>>> (II) RADEON(0): MC_FB_LOCATION : 0xefffe000 0xefffe000 >>>> (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 >>>> (II) RADEON(0): Direct rendering enabled >>>> (II) RADEON(0): Render acceleration enabled for R200 type cards. >>>> >>>> I'm also getting the "set memattr inconsistently" messages, but I saw >>>> your previous email regarding that and will apply that patch as well >>>> when I get a chance. >>>> >>>> >>> I'm going to have to remove some local patches from my tree and try to >>> get this fixed. The patch that I posted apparently doesn't resolve the >>> inconsistent mapping. I hadn't realized that the patch that warns about >>> this had made it into the tree. >>> >> Whether it resolves it or not I cannot say, I wasn't able to get it to >> build: >> >> ===> drm/drm (all) >> cc -pipe -O2 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE >> -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include >> /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq >> -finline-limit=8000 --param inline-unit-growth=100 --param >> large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/GENERIC >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx >> -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector >> -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls >> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign >> -fformat-extensions -c >> /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_scatter.c >> cc1: warnings being treated as errors >> /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_scatter.c: In function >> 'drm_sg_alloc': >> /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_scatter.c:85: warning: >> passing argument 1 of 'pmap_change_attr' makes integer from pointer >> >> line 85: >> pmap_change_attr(dmah->vaddr, request->size, >> PAT_WRITE_COMBINING); >> > pmap_change_attr((vm_offset_t)dmah->vaddr, request->size, > PAT_WRITE_COMBINING); > I made this change and you were right, the messages remain. After a few hours of usage today I began noticing some minor text corruption in rdesktop (to a Windows XP machine), and in the KeePass application (native/X/FreeBSD). I haven't seen it anywhere else yet, but I've never seen this before. Some, but not all text in rdesktop has artifacting on the top of tall characters. The corruption in Keepass is more general garbling of the text, although it is still remotely readable. Let me know if you would like to see screenshots. Thanks
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B30F7D4.9040307>