[Dri-devel] mach64-0-0-6-branch
I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've updated the mach64 driver to Mesa 5 based on the changes to the Rage 128 driver. Testing hasn't shown any problems so far. I haven't adapted the mach64 drm to the os-independence changes yet. I could start this, but we are going to need a generic replacement for the pci_alloc_consistent Linux interface. I think it's probably best to hold off on making that switch, pending the changes Jose has proposed: http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg08243.html In the meantime, the drm can still be compiled and used from the old linux kernel directory like the other drivers which have yet to be converted. I'd recommend that people using the mach64-0-0-5-branch from CVS update to this new branch and report any regressions or new bugs to the list. Sometime in the next few weeks, I'll also be updating the GATOS Xvideo patch available at the site in my sig. Since the GATOS head is now based on current XFree86 cvs, I may not have a new patch until 4.3.0 is released and changes get propagated back to the DRI and GATOS trees. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch
> [...] Since the GATOS head is now based > on current XFree86 cvs, I may not have a new patch until 4.3.0 is released > and changes get propagated back to the DRI and GATOS trees. Could anyone tell me if I'll find recent GATOS stuff merged into the current XFree86-4.3 pre-releases ? I did not find the answer neither on the GATOS pages nor in the XFree86 CVS 'changes.html' document. I _did_ expect XFree86-4.3 to be 'up to date' with GATOS and would like to see some sort of proof - _before_ downloading tons of source code, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch
Leif Delgass wrote: I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've updated the mach64 driver to Mesa 5 based on the changes to the Rage 128 driver. Testing hasn't shown any problems so far. I haven't adapted the mach64 drm to the os-independence changes yet. I could start this, but we are going to need a generic replacement for the pci_alloc_consistent Linux interface. I think it's probably best to hold off on making that switch, pending the changes Jose has proposed: http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg08243.html In the meantime, the drm can still be compiled and used from the old linux kernel directory like the other drivers which have yet to be converted. I'd recommend that people using the mach64-0-0-5-branch from CVS update to this new branch and report any regressions or new bugs to the list. Sometime in the next few weeks, I'll also be updating the GATOS Xvideo patch available at the site in my sig. Since the GATOS head is now based on current XFree86 cvs, I may not have a new patch until 4.3.0 is released and changes get propagated back to the DRI and GATOS trees. Seems to work for me as long as I don't try to use my Radeon at the same time. I have my setup as follows: HEAD 1 HEAD 0 On-board RageXL Radeon 8500 (initialised by BIOS) (Initialised by XFree86) DRI enabled DRI enabled DOES NOT WORK HEAD 1 HEAD 0 On-board RageXL Radeon 8500 (initialised by BIOS) (Initialised by XFree86) DRI disabled DRI enabled DOES WORK HEAD 1 HEAD 0 On-board RageXL Radeon 8500 AGP (initialised by BIOS) (Initialised by XFree86) DRI enabled DRI disabled NOT TESTED HEAD 0 On-board RageXL (initialised by BIOS) DRI enabled DOES WORK I can not have the Radeon initialised by the BIOS since the the RageXL can not then be initialised later. I do have a problem with Radeon with subsequent X server starts. It can not access the V_BIOS and tries to use extremely bogus values. Unless someone here knows how to fix this I will send a mail to XFree86-devel. Attached is the output for the Dual-head DRI failure case. This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.99.2 (DRI mach64-0-0-6-branch) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 21 October 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.5.59-test i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Fri Feb 14 16:40:16 2003 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "Default Layout" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Videocard1_0" (**) |-->Screen "Screen1" (1) (**) | |-->Monitor "Monitor1" (**) | |-->Device "Videocard0" (**) |-->Input Device "DevInputMice" (**) |-->Input Device "Keyboard0" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "gb" (**) XKB: layout: "gb" (==) Keyboard: CustomKeycode disabled (**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc:unscaled,/usr/X11R6/lib/X11/fonts/75dpi:unscaled,/usr/X11R6/lib/X11/fonts/100dpi:unscaled,/usr/X11R6/lib/X11/fonts/misc,/usr/X11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/fonts/Speedo,/usr/X11R6/lib/X11/fonts/cyrillic,/usr/X11R6/lib/X11/fonts/TTF,/usr/X11R6/lib/X11/fonts/msttcorefonts,/usr/X11R6/lib/X11/fonts/OTF,/usr/share/fonts/default/Type1,/usr/lib/openoffice/share/fonts/truetype,/usr/share/fonts/ja/TrueType" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (++) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such device) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.2.99.2, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libp
Re: [Dri-devel] mach64-0-0-6-branch
On Tue, 2003-02-11 at 20:11, Leif Delgass wrote: > I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been > updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've > updated the mach64 driver to Mesa 5 based on the changes to the Rage 128 > driver. Testing hasn't shown any problems so far. > > I haven't adapted the mach64 drm to the os-independence changes yet. I > could start this, but we are going to need a generic replacement for the > pci_alloc_consistent Linux interface. I think it's probably best to hold > off on making that switch, pending the changes Jose has proposed: > http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg08243.html > > In the meantime, the drm can still be compiled and used from the old linux > kernel directory like the other drivers which have yet to be converted. > > I'd recommend that people using the mach64-0-0-5-branch from CVS update to > this new branch and report any regressions or new bugs to the list. > Sometime in the next few weeks, I'll also be updating the GATOS Xvideo > patch available at the site in my sig. Since the GATOS head is now based > on current XFree86 cvs, I may not have a new patch until 4.3.0 is released > and changes get propagated back to the DRI and GATOS trees. I've been working on this locally a little, but haven't tackled the pci_alloc_consistent in a proper manner yet (the corresponding interface for us is bus_dma, which I am just beginning to understand while working on ati_pcigart.h/drm_scatter.h conversion). If you would approve of me moving the mach64 files to shared/drm/kernel, I could at least work on things incrementally (much of this stuff is mechanical changes), and then hopefully provide something pretty to review for pci_alloc_consistent. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch
On 15 Feb 2003, Eric Anholt wrote: > On Tue, 2003-02-11 at 20:11, Leif Delgass wrote: > > I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been > > updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've > > updated the mach64 driver to Mesa 5 based on the changes to the Rage 128 > > driver. Testing hasn't shown any problems so far. > > > > I haven't adapted the mach64 drm to the os-independence changes yet. I > > could start this, but we are going to need a generic replacement for the > > pci_alloc_consistent Linux interface. I think it's probably best to hold > > off on making that switch, pending the changes Jose has proposed: > > http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg08243.html > > > > In the meantime, the drm can still be compiled and used from the old linux > > kernel directory like the other drivers which have yet to be converted. > > > > I'd recommend that people using the mach64-0-0-5-branch from CVS update to > > this new branch and report any regressions or new bugs to the list. > > Sometime in the next few weeks, I'll also be updating the GATOS Xvideo > > patch available at the site in my sig. Since the GATOS head is now based > > on current XFree86 cvs, I may not have a new patch until 4.3.0 is released > > and changes get propagated back to the DRI and GATOS trees. > > I've been working on this locally a little, but haven't tackled the > pci_alloc_consistent in a proper manner yet (the corresponding interface > for us is bus_dma, which I am just beginning to understand while working > on ati_pcigart.h/drm_scatter.h conversion). > > If you would approve of me moving the mach64 files to shared/drm/kernel, > I could at least work on things incrementally (much of this stuff is > mechanical changes), and then hopefully provide something pretty to > review for pci_alloc_consistent. As long as the Linux build still works, that's fine by me. If you want to create the makefile links, move it to shared, and work on macro-izing the ioctls and whatnot, go for it. I was going to do this eventually, but if you're eager to get started, that's great. Of course, this will all have to happen in the mach64-0-0-6-branch for now, until we get the DRM interface/security changes done. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64-0-0-6-branch dri bug report
Hello, I had been using the mach64-0-0-5-branch in linux for a while but recently I upgraded my install and thus gave a shot at the mach64-0-0-6-branch and encountered a problem. This report is broken into sections: 1 - Problem description 2 - System information 3 - XF86Config-4 --- 1) Problem Description: I first tried the mach64-20031128-linux.i386.tar.bz2 daily snapshot with XFree86-4.3-23mdk. Kernel modules built fine and insmod'ed. DRI was not working; the relevant section on XFree86.0.log reads: (II) ATI(0): [drm] created "mach64" driver at busid "PCI:1:0:0" (II) ATI(0): [drm] added 8192 byte SAREA at 0xd0ba (II) ATI(0): [drm] mapped SAREA 0xd0ba to 0x40016000 (II) ATI(0): [drm] framebuffer handle = 0xf500 (II) ATI(0): [drm] added 1 reserved context for kernel (II) ATI(0): [drm] Will request asynchronous DMA mode (WW) ATI(0): [agp] AGP not available (WW) ATI(0): [agp] AGP failed to initialize -- falling back to PCI mode. (WW) ATI(0): [agp] Make sure you have the agpgart kernel module loaded. (II) ATI(0): [drm] register handle = 0xf410 (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 (II) ATI(0): [drm] removed 1 reserved context for kernel (II) ATI(0): [drm] unmapping 8192 bytes of SAREA 0xd0ba 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 So I figured that a patch that Mandrake put on X may have been causing the problem -- so I downloaded the mach64-0-0-6-branch from CVS yesterday and re-built a clean XFree86 -- same problem. I hope that this bug report helps and thank the dri development people for their hard work. --- 2) System information: Kernel 2.4.22 from kernel.org; preempt patch XFree86: 4.3.0 Arch: x86 --- 3) XF86Config-4 relevent secitons: Section "Module" Load "dbe" # Double-Buffering Extension #Load "v4l" # Video for Linux Load "extmod" Load "type1" Load "freetype" Load "glx" # 3D layer Load "dri" EndSection Section "DRI" Mode 0666 EndSection Section "Device" Identifier "device1" VendorName "ATI" BoardName "ATI Rage Mobility" Driver "ati" Option "DPMS" EndSection -- -- Chris _ ~ _/ _/ _/ _/ _/ _/ _/_/_/ _/_/ _/ _/_/ c .. _/ _/ _/ _/ _/ _/@ > _/ _/ _/ _/ _/ _/_/ @,- ==>chrissoma.978.org<== _ ~ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch dri bug report
Christopher, On Mon, Dec 01, 2003 at 12:46:55AM -0500, Christopher Gleba wrote: > > Hello, > > I had been using the mach64-0-0-5-branch in > linux for a while but recently I upgraded my > install and thus gave a shot at the > mach64-0-0-6-branch and encountered a problem. > This report is broken into sections: > > 1 - Problem description > 2 - System information > 3 - XF86Config-4 > > --- > 1) Problem Description: > > I first tried the mach64-20031128-linux.i386.tar.bz2 > daily snapshot with XFree86-4.3-23mdk. Kernel modules > built fine and insmod'ed. DRI was not working; the > relevant section on XFree86.0.log reads: > > (II) ATI(0): [drm] created "mach64" driver at busid "PCI:1:0:0" > (II) ATI(0): [drm] added 8192 byte SAREA at 0xd0ba > (II) ATI(0): [drm] mapped SAREA 0xd0ba to 0x40016000 > (II) ATI(0): [drm] framebuffer handle = 0xf500 > (II) ATI(0): [drm] added 1 reserved context for kernel > (II) ATI(0): [drm] Will request asynchronous DMA mode > (WW) ATI(0): [agp] AGP not available > (WW) ATI(0): [agp] AGP failed to initialize -- falling back to PCI mode. > (WW) ATI(0): [agp] Make sure you have the agpgart kernel module loaded. 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 to your /etc/modules.conf > (II) ATI(0): [drm] register handle = 0xf410 > (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). > (II) ATI(0): [drm] removed 1 reserved context for kernel > (II) ATI(0): [drm] unmapping 8192 bytes of SAREA 0xd0ba 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 > So I figured that a patch that Mandrake put on X may > have been causing the problem -- so I downloaded the > mach64-0-0-6-branch from CVS yesterday and re-built > a clean XFree86 -- same problem. > 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. Jose Fonseca --- This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate. http://www.wrgsurveys.com/2003/osdntech03.php?site=8 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch dri bug report
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: lspci -vv: 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) (prog-if 00 [VGA]) Subsystem: Hewlett-Packard Company: Unknown device 0011 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=128K] Capabilities: [50] AGP version 1.0 Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate= Capabilities: [5c] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 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 byNot tainted mach64 85368 0 agpgart18896 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 @ 0xf800 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 @ 0xf800 kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0 > > (II) ATI(0): [drm] register handle = 0xf410 > > (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 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 0xd0ba 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 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. 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. 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. -- -- Chris _ ~ _/ _/ _/ _/ _/ _/ _/_/_/ _/_/ _/ _/_/ c .. _/ _/ _/ _/ _/ _/@ > _/ _/ _/ _/ _/ _/_/ @,- ==>chrissoma.978.org<== _ ~~~
Re: [Dri-devel] mach64-0-0-6-branch dri bug report
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 byNot tainted > mach64 85368 0 > agpgart18896 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 @ 0xf800 > 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 @ 0xf800 > 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 = 0xf410 > > > (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 0xd0ba 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
Re: [Dri-devel] mach64-0-0-6-branch dri bug report
Chris, On Thu, Dec 04, 2003 at 05:02:17PM -0500, Christopher Gleba wrote: > Hello Jose, > > > 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). > > When you mentioned this and the fact that you as well as I had no idea > what was going on, I decided to re-compile everything (kernel, XFree86) > cleanly without any vendor or personal patches. It turns out that I > made a grave mistake in the information I provided and I sincerely > apologize. > > It turns out that I mis-configured lilo and when I rebooted a kernel > with the software suspend patch was being booted rather then a clean one > as I had thought (and I *knew* that swsusp causes problems with video > cards). When I booted with a clean kernel, mach64 drm worked fine (and > I got 270fps with glxgears rather then the ususal 110fps :)). > > Again, please accept my apology for my mistake and I thank you for your > patience. I learned while working in telecommunications that one must > make sure that all their stuff is good before contacting the other end > -- I failed in that regard this time. I am at your disposal if you ever > need any experimental mach64 testing or help in general. No need to appologise! I know you did your best to provide all the useful details and that's what matters. Also, will this experience it will be easier to detect similar cases in the future. > Nonetheless, I've included the debug output, the agpgart source with the > software suspend patch added as well as without it and the software > suspend patch itself for both the list archives in case anyone else runs > into this problem. Also, I know that 2.6.0+ uses software suspend, so > the debugging information below may help when it comes time for a 2.6 > port. Thanks for the info. I don't know whose's fault is that sw suspend doesn't work with mach64 dri (it could be sw suspend patch, mach64 drm, or the agpgart). I know that radeon driver has suspend/resume support, but I think it's for hardware suspend. Since I'm quite busy ATM I'm inclined to just wait and see how things go from here. [...] Regards, Jose Fonseca --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch dri bug report
On Sun, 2003-12-07 at 18:43, Josà Fonseca wrote: > > On Thu, Dec 04, 2003 at 05:02:17PM -0500, Christopher Gleba wrote: > > > > It turns out that I mis-configured lilo and when I rebooted a kernel > > with the software suspend patch was being booted rather then a clean one > > as I had thought (and I *knew* that swsusp causes problems with video > > cards). When I booted with a clean kernel, mach64 drm worked fine (and > > I got 270fps with glxgears rather then the ususal 110fps :)). [...] > > Nonetheless, I've included the debug output, the agpgart source with the > > software suspend patch added as well as without it and the software > > suspend patch itself for both the list archives in case anyone else runs > > into this problem. Also, I know that 2.6.0+ uses software suspend, so > > the debugging information below may help when it comes time for a 2.6 > > port. > > Thanks for the info. > > I don't know whose's fault is that sw suspend doesn't work with mach64 > dri (it could be sw suspend patch, mach64 drm, or the agpgart). I know > that radeon driver has suspend/resume support, but I think it's for > hardware suspend. No, it's also for software suspend (Charl wrote it to be able to use that), but it only has an effect for a suspend/resume cycle while the server is running; it's weird that the mere fact that the kernel is patched for software suspend should have an effect on DRI initialisation. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Fwd: Re: [Dri-devel] mach64-0-0-6-branch dri bug report]
Forgot the attachment in the last post. -Forwarded Message- From: Christopher Gleba <[EMAIL PROTECTED]> To: José Fonseca <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: [Dri-devel] mach64-0-0-6-branch dri bug report Date: Tue, 02 Dec 2003 14:57:50 -0500 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: lspci -vv: 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) (prog-if 00 [VGA]) Subsystem: Hewlett-Packard Company: Unknown device 0011 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=128K] Capabilities: [50] AGP version 1.0 Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate= Capabilities: [5c] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 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 byNot tainted mach64 85368 0 agpgart18896 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 @ 0xf800 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 @ 0xf800 kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0 > > (II) ATI(0): [drm] register handle = 0xf410 > > (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 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 0xd0ba 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 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. 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 a
[Fwd: Re: [Dri-devel] mach64-0-0-6-branch dri bug report]
I'm copying the list sans attachments in case someone else runs into the same problem as I (for the archives) -- it turns out that the "bug" was just my own stupidity. -Forwarded Message- From: Christopher Gleba <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Dri-devel] mach64-0-0-6-branch dri bug report Date: Thu, 04 Dec 2003 17:02:17 -0500 Hello Jose, > 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). When you mentioned this and the fact that you as well as I had no idea what was going on, I decided to re-compile everything (kernel, XFree86) cleanly without any vendor or personal patches. It turns out that I made a grave mistake in the information I provided and I sincerely apologize. It turns out that I mis-configured lilo and when I rebooted a kernel with the software suspend patch was being booted rather then a clean one as I had thought (and I *knew* that swsusp causes problems with video cards). When I booted with a clean kernel, mach64 drm worked fine (and I got 270fps with glxgears rather then the ususal 110fps :)). Again, please accept my apology for my mistake and I thank you for your patience. I learned while working in telecommunications that one must make sure that all their stuff is good before contacting the other end -- I failed in that regard this time. I am at your disposal if you ever need any experimental mach64 testing or help in general. Nonetheless, I've included the debug output, the agpgart source with the software suspend patch added as well as without it and the software suspend patch itself for both the list archives in case anyone else runs into this problem. Also, I know that 2.6.0+ uses software suspend, so the debugging information below may help when it comes time for a 2.6 port. > 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. As shown below it seems that the drm module is being initialized and then the errors come afterward -- that is, with the software suspend patch. > Also, before loading XFree86, manually load the agpgart module and the > mach64 with the debug option: > insmod agpgart > insmod mach64 drm_opts=debug Output is below: 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 @ 0xf800 kernel: [drm] Debug messages ON kernel: [drm:drm_count_cards] kernel: [drm:drm_count_cards] numdevs = 1 kernel: [drm:mach64_stub_register] kernel: [drm:mach64_stub_register] calling inter_module_register kernel: [drm:mach64_ctxbitmap_next] drm_ctxbitmap_next bit : 0 kernel: [drm:mach64_ctxbitmap_init] drm_ctxbitmap_init : 0 kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0 kernel: [drm:mach64_open_helper] pid = 15561, minor = 0 kernel: [drm:mach64_setup] kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 kernel: [drm:mach64_flush] pid = 15561, device = 0xe200, open_count = 1 kernel: [drm:mach64_release] open_count = 1 kernel: [drm:mach64_release] pid = 15561, device = 0xe200, open_count = 1 kernel: [drm:mach64_fasync] fd = -1, device = 0xe200 kernel: [drm:mach64_takedown] kernel: [drm:mach64_do_cleanup_dma] mach64_do_cleanup_dma kernel: [drm:mach64_open_helper] pid = 15561, minor = 0 kernel: [drm:mach64_setup] kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0246400, nr= 0x00, dev 0xe200, auth=1 kernel: [drm:mach64_flush] pid = 15561, device = 0xe200, open_count = 1 kernel: [drm:mach64_release] open_count = 1 kernel: [drm:mach64_release] pid = 15561, device = 0xe200 , open_count = 1 kernel: [drm:mach64_fasync] fd = -1, device = 0xe200 kernel: [drm:mach64_takedown] kernel: [drm:mach64_do_cleanup_dma] mach64_do_cleanup_dma kernel: [drm:mach64_open_helper] pid = 15561, minor = 0 kernel: [drm:mach64_setup] kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0086401, nr= 0x01, dev 0xe200, auth=1 kernel: [drm:mach64_ioctl] pid=15561, cmd=0xc0086401, nr= 0x01, dev 0xe200, auth=1 kernel: [drm:mac
admin note RE: [Dri-devel] mach64-0-0-6-branch dri bug report
just a few words for the future, nothing serious... > -Original Message- > From: Christopher Gleba [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 04, 2003 23:02 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [Dri-devel] mach64-0-0-6-branch dri bug report > Size: 220 kB i am pretty sure that an e-mail of that size might be qualified to get handled as a bugzilla bug report. at least only the folks that want the full set of attachments have to download them if they do want them. -Alex. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
