Menu
▾
▴
Re: [Dri-devel] mach64-0-0-6-branch dri bug report
|
From: F. <jrf...@tu...> - 2003-12-04 12:50:03
|
Christopher, On Tue, Dec 02, 2003 at 02:57:50PM -0500, Christopher Gleba wrote: > > Hello Jose, > > Thank you for the response. > > > Do you have a PCI card? If not make sure the agpgart kernel module is > > loaded before the mach64 module, by adding > > > > pre-install mach64 modprobe -k agpgart > > Yes, it is an AGP card: > [...] > > and I had made sure that the agpgart module was loaded (that's why > I thought this problem was so odd): > > lsmod: > > Module Size Used by Not tainted > mach64 85368 0 > agpgart 18896 0 (unused) > > kernel messages: > > kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann > kernel: agpgart: Maximum main memory to use for agp memory: 203M > kernel: agpgart: Detected Intel 440BX chipset > kernel: agpgart: AGP aperture is 64M @ 0xf8000000 > kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0 > kernel: [drm] Module unloaded > kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann > kernel: agpgart: Maximum main memory to use for agp memory: 203M > kernel: agpgart: Detected Intel 440BX chipset > kernel: agpgart: AGP aperture is 64M @ 0xf8000000 > kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0 This is _very_ odd. The agpgart appears to be loaded OK before the mach64 module, but it's not used found by the later! > > > (II) ATI(0): [drm] register handle = 0xf4100000 > > > (II) ATI(0): [dri] Visual configs initialized > > > (II) ATI(0): [dri] Block 0 base at 0xf4100400 > > > (WW) ATI(0): Not enough memory for local textures, disabling DRI > > > > And you should decrease the screen depth (16bpp is a must if you care for 3D performance). > > Oddly, it is already at 16bpp: > > XF86Config: > > Section "Screen" > Identifier "screen1" > Device "device1" > Monitor "monitor1" > DefaultColorDepth 16 > Subsection "Display" > Depth 16 > Virtual 1280 1024 > EndSubsection > EndSection Well, 1280*1024*2*3=7864320 which is quite close to the 8*1024*1024=8388608 you have on the chip. Since is the AGP memory is not available, you do not have enough memory on the chip for two 256x256*16bit textures... So the issue is the AGP... . > > XFree86.0.log: > > (II) Setting vga for screen 0. > (==) ATI(0): Chipset: "ati". > (**) ATI(0): Depth 16, (--) framebuffer bpp 16 > > xdpyinfo: > > screen #0: > dimensions: 1280x1024 pixels (361x292 millimeters) > resolution: 90x89 dots per inch > depths (7): 16, 1, 4, 8, 15, 24, 32 > > > > > (II) ATI(0): [drm] removed 1 reserved context for kernel > > > (II) ATI(0): [drm] unmapping 8192 bytes of SAREA 0xd0ba0000 at 0x40016000 > > > > > > Did a lsmod, agpgart and mach64 are loaded. Looked at > > > kernel logs and found: > > > > > > kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held > > > kernel: [drm:mach64_unlock] *ERROR* Process 1836 using kernel context 0 > > > kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held > > > kernel: [drm:mach64_unlock] *ERROR* Process 2427 using kernel context 0 > > > kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held > > > kernel: [drm:mach64_unlock] *ERROR* Process 2733 using kernel context 0 > > > kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held > > > kernel: [drm:mach64_unlock] *ERROR* Process 4150 using kernel context 0 > > > > Well, this is suerly a consequence of above, but these calls shouldn't > > be happening consedering DRM was disabled.... > > That's another thing that I thought was so odd and why I posted to the > list. My intuition (I am not an X developer) is that DRI is being > disabled as a result of the above errors? I'm not sure what's the casual relationship between these. If the mach64_dma_init() ioctl wasn't sucessful at least once, the "[drm] Initialized mach64 1.0.0 20020904 on minor 0" line would never appear in the log... By which order they appear on the kernel log? Please post the complete extract of the log which concerns the XFree initialization. Also, before loading XFree86, manually load the agpgart module and the mach64 with the debug option: insmod agpgart insmod mach64 drm_opts=debug > > > I hope that this bug report helps and thank the dri development > > > people for their hard work. > > > > See if the above tips help. Let us know otherwise. > > No dice so far. As mentioned before, the mach64-0-0-5-branch > on XFree86 4.2.0 used to work beautifully. I've attached the > XFree86.0.log from XFree86-4.3-23mdk with mach64-20031128-linux > applied. Unfortunately differences between mach64-0-0-5-branch and mach64-0-0-6-branch are precisly the former being for XFree86 4.2.0 and the later for 4.3.0. Otherwise we could try to checkout mach64-0-0-6-branch in diffrent times and determine which change caused this. > If there is any particular testing that I can do let me know -- if > need be I can download and compile the mach64-0-0-6-branch CVS branch > again and give that a shot. It's very strange that this doesn't work. If you compile the driver and the Xserver into /usr/X11R6-DRI/ and use that XFree86 server there shouln't be any binary incompatabilities problems (which I suspect are the cause of all this). > Also this system does not have any > important information on it so I can set up ssh root access if that > would help in testing at all. If that would help, let me know and give > me a few days to prepare the setup. That won't be necessary for the time being as there is not XFree86 locking - XFree86 simply fails to start with DRI, but you still have control over the machine. Jose Fonseca |