Date: Mon, 21 Dec 2009 10:47:15 -0600 From: Robert Noland <rnoland@FreeBSD.org> To: Steve Polyack <korvus@comcast.net> Cc: freebsd-x11 <freebsd-x11@freebsd.org> Subject: Re: PCI Radeon 9250 - DRI/DRM in 8.0-RELEASE Message-ID: <1261414036.2304.1.camel@balrog.2hip.net> In-Reply-To: <4B2FA5F3.8020605@comcast.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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); robert. > > > > 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 > >> > >> > > > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -- Robert Noland <rnoland@FreeBSD.org> FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1261414036.2304.1.camel>