Date: Mon, 21 Dec 2009 11:44:35 -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: <4B2FA5F3.8020605@comcast.net> In-Reply-To: <1261412678.2302.10.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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); > Anyway, I'm glad that this gets things > working at least. I still need to test with some other cards, but so > far, I think the following have been tested. > > r6/700 amd64 pci-e > r600 i386 pci-e > r200 i386 pci (This should be the same code paths for r300 as well) > mga amd64 agp > > It still needs to be checked on intel and nouveau, at least. > > robert. > > >> Thanks!! >> -Steve Polyack >> >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B2FA5F3.8020605>