Re: [Dri-devel] [Announce] Savage 3D driver in CVS
I recompiled a static Xserver so that could get a backtrace inside the driver. This is the result: Program received signal SIGSEGV, Segmentation fault. 0x080532e3 in SavageHelpSolidROP (pScrn=0x8624270, fg=0xb724, pm=-1, rop=0xb728) at savage_accel.c:758 758 pm &= infoRec->FullPlanemask; (gdb) bt #0 0x080532e3 in SavageHelpSolidROP (pScrn=0x8624270, fg=0xb724, pm=-1, rop=0xb728) at savage_accel.c:758 #1 0x080636e1 in SAVAGEDRISetupForSolidFill (pScrn=0x8624270, color=0, rop=0, planemask=4294967295) at savage_dri.c:1956 #2 0x08062e87 in SAVAGEDRIInitBuffers (pWin=0x87dd650, prgn=0x87e1350, index=0) at savage_dri.c:1676 #3 0x0849ee66 in DRIWindowExposures (pWin=0x87dd650, prgn=0x87e1350, bsreg=0x0) at dri.c:1569 #4 0x081c90f2 in miHandleValidateExposures (pWin=0x87dd948) at miwindow.c:468 #5 0x0814f8c1 in MapWindow (pWin=0x87dd650, client=0x87588b8) at window.c:2841 #6 0x08126641 in ProcMapWindow (client=0x87588b8) at dispatch.c:688 #7 0x08125e9c in Dispatch () at dispatch.c:450 #8 0x0813d3d4 in main (argc=11, argv=0xbd84, envp=0xbdb4) at main.c:435 Apperently the DRI code in the savage driver uses accel functions even if acceleration is disabled. Maybe you can try disabling individual XAA acceleration functions. See the XF86Config-4 manual page for details. There are lots of options like XaaNoCPUToScreenColorExpandFill. Felix On Sat, 20 Dec 2003 17:25:55 -0300 Rafael Maximo <[EMAIL PROTECTED]> wrote: > At 02:58 PM 20/12/2003, Felix Kühling wrote: > > >We had a similar problem with the 2D driver on the savage-1_0_0-branch. > >Accelerated stuff worked just fine for me but direct frame buffer access > >was broken. It turned out to be quite simple to fix. However, this fix > >didn't work for Maximo, so I suspect that on Savage4 either 2D > >acceleration is broken with tiling or tiling works differently and > >direct frame buffer was still broken. > > > >Maximo, you can find out which of the above is true by disabling 2D > >acceleration and see if direct fb access works. Maybe disabling 2D accel > >would be a workaround until we fix the real problem. > > I tried to use the "NoAccel" option, with this option the 2D is not > corrupted but when i try to run glxgears the X server go back to the shell > prompt and it doesn't show any error. > > bye. > > > Rafael Máximo __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- 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] Side band Address control
On Thu, 2003-12-18 at 18:21, craig qu wrote: > > Is it possible to disable the side address mechanism > of Radeon 7000 by using command register(offset > CAP_PTR +8) bit SBA_ENABLE? and how? Bit 12 of the RADEON_AGP_CNTL register is called SBA_DIS, there's no further explanation in the docs though. -- 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_id=1278&alloc_id=3371&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [Announce] Savage 3D driver in CVS
Felix Kühling wrote: I recompiled a static Xserver so that could get a backtrace inside the driver. This is the result: Program received signal SIGSEGV, Segmentation fault. 0x080532e3 in SavageHelpSolidROP (pScrn=0x8624270, fg=0xb724, pm=-1, rop=0xb728) at savage_accel.c:758 758 pm &= infoRec->FullPlanemask; (gdb) bt #0 0x080532e3 in SavageHelpSolidROP (pScrn=0x8624270, fg=0xb724, pm=-1, rop=0xb728) at savage_accel.c:758 #1 0x080636e1 in SAVAGEDRISetupForSolidFill (pScrn=0x8624270, color=0, rop=0, planemask=4294967295) at savage_dri.c:1956 #2 0x08062e87 in SAVAGEDRIInitBuffers (pWin=0x87dd650, prgn=0x87e1350, index=0) at savage_dri.c:1676 #3 0x0849ee66 in DRIWindowExposures (pWin=0x87dd650, prgn=0x87e1350, bsreg=0x0) at dri.c:1569 #4 0x081c90f2 in miHandleValidateExposures (pWin=0x87dd948) at miwindow.c:468 #5 0x0814f8c1 in MapWindow (pWin=0x87dd650, client=0x87588b8) at window.c:2841 #6 0x08126641 in ProcMapWindow (client=0x87588b8) at dispatch.c:688 #7 0x08125e9c in Dispatch () at dispatch.c:450 #8 0x0813d3d4 in main (argc=11, argv=0xbd84, envp=0xbdb4) at main.c:435 Apperently the DRI code in the savage driver uses accel functions even if acceleration is disabled. Maybe you can try disabling individual XAA acceleration functions. See the XF86Config-4 manual page for details. There are lots of options like XaaNoCPUToScreenColorExpandFill. This probably won't work as the type of operations above aren't going through XAA to reach the accel functions, but instead calling them directly. There are two cases that spring to mind where this happens: - New window creation - A solid fill blit is used to initialize the back and depth buffers. I've never really been convinced that it was the job of the X server to do this initialization, but in any case it (or the 3D driver) could just as easily issue a 'clear' ioctl to the drm. - Window moves - Copy blits are used to move the contents of the back and depth buffers to their new locations. Both of these operations can be disabled at the expense of some corruption at the times of these events. Look in the _dri.c file in the 2d driver for where these are being called. Keith --- 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
[Dri-devel] Strange lockups with DRI on Radeon 8500LE
Hi! After upgrading my box to latest trunk DRI, I got strange problem - XServer did not start correctly, e.g. it hangs after init dri stuff. But I can ssh to this box, and SysRq keys are working and I can sync/umount/reboot. If I comment Load "dri"/remove radeon.o module - all works fine except DRI =) So what it can be? Problems with build/my hands or is a problem with videocard? FYI, fglrx drivers works fine. PS Seeking archives of this list, I don't find anything related my problem, and this looks strange because my videocard isn't very exotic :-/ Some related info: $ lspci -vv 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R200 QL [Radeon 8500 LE] (prog-if 00 [VGA]) Subsystem: Hightech Information System Ltd.: Unknown device 013a 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: [58] AGP version 2.0 Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate= Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- -- WBR, Konstantin chat with ==>ICQ: 109916175 Lepikhov,speak to ==>JID: [EMAIL PROTECTED] aka L.A. Kostis write to ==>mailto:[EMAIL PROTECTED] ...The information is like the bank...(c) EC8OR 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.3.99.12 (DRI trunk) Release Date: 10 September 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.22-std-up-alt8 i686 [ELF] Current Operating System: Linux lks.home 2.4.22-std-up-alt8 #1 Mon Nov 10 00:15:21 MSK 2003 i686 Build Date: 18 December 2003 Changelog Date: 10 September 2003 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. 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: Sun Dec 21 16:36:02 2003 (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "Server Layout" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "ATI Radeon" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "AutoRepeat" "250 30" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "us,ru" (**) XKB: layout: "us,ru" (**) Option "XkbOptions" ",grp:caps_toggle,grp_led:scroll" (**) XKB: options: ",grp:caps_toggle,grp_led:scroll" (==) Keyboard: CustomKeycode disabled (**) FontPath set to "tcp/localhost:7100" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6-DRI/lib/modules" (**) Option "AllowNonLocalXvidtune" (--) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such device) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.7 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6-DRI/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.3.99.12, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6-DRI/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.7 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,2530 card 147b,0507 rev 02 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,2532 card , rev 02 class 06,04,00 hdr 01 (II) PCI: 00:1e:0: chip 8086,244e card , rev 04 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,2440 card , rev 04 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,244b card 147b,0507 rev 04 class 01,01,80 hdr 00 (II) PCI: 00:1f:2: chip 8086,2442 card 147b,0507 rev 04 class 0c,03,
Re: [Dri-devel] Strange lockups with DRI on Radeon 8500LE
On Sun, 2003-12-21 at 14:55, Konstantin Lepikhov wrote: > Hi! > > After upgrading my box to latest trunk DRI, I got strange problem - > XServer did not start correctly, e.g. it hangs after init dri stuff. But I > can ssh to this box, and SysRq keys are working and I can > sync/umount/reboot. If I comment Load "dri"/remove radeon.o module - all > works fine except DRI =) So what it can be? Problems with build/my hands > or is a problem with videocard? FYI, fglrx drivers works fine. > > PS Seeking archives of this list, I don't find anything related my problem, > and this looks strange because my videocard isn't very exotic :-/ > Try disabling AGPFastWrite, this option work fine on some systems and not at all on others. -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- 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] Strange lockups with DRI on Radeon 8500LE
On Sun, 2003-12-21 at 14:55, Konstantin Lepikhov wrote: > > After upgrading my box to latest trunk DRI, I got strange problem - > XServer did not start correctly, e.g. it hangs after init dri stuff. But I > can ssh to this box, and SysRq keys are working and I can > sync/umount/reboot. If I comment Load "dri"/remove radeon.o module - all > works fine except DRI =) So what it can be? Problems with build/my hands > or is a problem with videocard? FYI, fglrx drivers works fine. Have you tried not enabling AGP fast writes? I'm a bit confused by the log and config files you attached: the config says AGP 4x, the log 1x; the config contains Option "UseFBDev", but the log shows no trace of the fbdevhw module; and last but not least, the log seems to show a complete and successful startup with DRI enabled? Please clarify. -- 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_id=1278&alloc_id=3371&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 2D corruption workaround
On Sun, 21 Dec 2003 08:35:14 -0500 Keith Whitwell <[EMAIL PROTECTED]> wrote: > Felix Kühling wrote: > > I recompiled a static Xserver so that could get a backtrace inside the > > driver. This is the result: > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x080532e3 in SavageHelpSolidROP (pScrn=0x8624270, fg=0xb724, pm=-1, > > rop=0xb728) at savage_accel.c:758 > > 758 pm &= infoRec->FullPlanemask; > > (gdb) bt > > #0 0x080532e3 in SavageHelpSolidROP (pScrn=0x8624270, fg=0xb724, pm=-1, > > rop=0xb728) at savage_accel.c:758 > > #1 0x080636e1 in SAVAGEDRISetupForSolidFill (pScrn=0x8624270, color=0, rop=0, > > planemask=4294967295) at savage_dri.c:1956 > > #2 0x08062e87 in SAVAGEDRIInitBuffers (pWin=0x87dd650, prgn=0x87e1350, > > index=0) at savage_dri.c:1676 > > #3 0x0849ee66 in DRIWindowExposures (pWin=0x87dd650, prgn=0x87e1350, > > bsreg=0x0) at dri.c:1569 > > #4 0x081c90f2 in miHandleValidateExposures (pWin=0x87dd948) at miwindow.c:468 > > #5 0x0814f8c1 in MapWindow (pWin=0x87dd650, client=0x87588b8) at window.c:2841 > > #6 0x08126641 in ProcMapWindow (client=0x87588b8) at dispatch.c:688 > > #7 0x08125e9c in Dispatch () at dispatch.c:450 > > #8 0x0813d3d4 in main (argc=11, argv=0xbd84, envp=0xbdb4) > > at main.c:435 > > > > Apperently the DRI code in the savage driver uses accel functions even > > if acceleration is disabled. Maybe you can try disabling individual XAA > > acceleration functions. See the XF86Config-4 manual page for details. > > There are lots of options like XaaNoCPUToScreenColorExpandFill. > > This probably won't work as the type of operations above aren't going through > XAA to reach the accel functions, but instead calling them directly. The idea is that the driver thinks accel is enabled so it'll initialize the XAA and we don't get a segfault (hopefully). Still XAA won't use the accelerated functions if they are disabled by Xaa... options. I havn't looked into the details, so I may be missing something. Anyway, the hope is that the accelerated functions are responsible for the corruption Maximo is observing. To find that out is the whole purpose of these experiments. ;-) > > There are two cases that spring to mind where this happens: > > - New window creation > - A solid fill blit is used to initialize the back and depth buffers. > I've > never really been convinced that it was the job of the X server to do this > initialization, but in any case it (or the 3D driver) could just as easily > issue a 'clear' ioctl to the drm. There is no clear ioctl in the savage driver ATM. In fact there are no driver-specific ioctls at all (only for mapping PCI DMA buffers if AGP is not available). All hardware access is done in user space. :-/ > > - Window moves > - Copy blits are used to move the contents of the back and depth > buffers to > their new locations. > > > Both of these operations can be disabled at the expense of some corruption at > the times of these events. Look in the _dri.c file in the 2d driver for where > these are being called. It's always good to have several options. Maximo, you can try this too if you still get segfaults when disabling individual acceleration functions. > > Keith __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- 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] Re: [Mesa3d-dev] [patch] TNL render problems
Felix Kühling wrote: On Sat, 20 Dec 2003 08:01:07 -0500 Keith Whitwell <[EMAIL PROTECTED]> wrote: Felix Kühling wrote: Hi, while working on the savage driver I found two problems. One with tnl/t_vb_render.c, the other one with tnl_dd/t_dd_tritmp.h. Both started since I use different hardware primitives for quads and triangles/polygons. TAG(quad) in t_dd_tritmp.h calls RASTERIZE( GL_TRIANGLES ) directly before QUAD( (v[0]), (v[1]), (v[2]), (v[3]) ). RASTERIZE should be called with GL_QUADS so that the driver selects the correct hardware primitive. Also I believe that we could use the same condition as in TAG(triangle), namely if (DO_UNFILLED) RASTERIZE( GL_QUADS ); This looks ok. I wonder when this condition will be true anyway. But without this RASTERIZE is called for every single quad! The second problem is in t_vb_render.c with clipped primitives. When a clipped primitive is rendered the PrimitiveNotify callback gets called with GL_POLYGON. When the next unclipped primitive is drawn we have to call PrimitiveNotify again with the original primitive type. I think this is a misunderstanding. Although at a hardware level, you may be rendering with who knows what primitive, at a GL level, you are still attempting to render a TRIANGLE, QUAD, whatever. The only time a difference between TRIANGLES, QUADS and POLYGONS emerges is if flat shading is active, in which case a different vertex is choosen to provide the color for the whole primitive. Is this the problem you're seeing, or is it something less subtle? I am aware of the flat shading issue, but this is not the problem here. Polygons are rendered using triangles. I use a different hardware primitive for Quads. So after rendering a clipped quad as a polygon (using triangles as hardware primitve) I have to tell the driver that the next primitive is going to be a quad again and that it has to select the right hardware primitive. Without this some quads got rendered as triangles with half the quad missing after a clipped quad was rendered as a polygon. Hmm. Sounds like we need to explictly restore the old primitive type after clipping, or to always try and set the primitive type but shortcircuit the operation if there is no change. Your patch looks like it's doing this, but isn't the cleanest code. I'd rather see a 'current' primitive in the tnl context maybe, and only call Driver.PrimitiveNotify() when that primitive changes. Thinking about it again, this is only a problem with quads, so the calls to PrimitiveNotify after clipped triangles and lines could be removed from the patch. I'd prefer to see all these things treated uniformly to cater to any future hardware with similar issues. Keith --- 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
Re: [Dri-devel] Re: [Mesa3d-dev] [patch] TNL render problems
Keith Whitwell wrote: Felix Kühling wrote: On Sat, 20 Dec 2003 08:01:07 -0500 Keith Whitwell <[EMAIL PROTECTED]> wrote: Felix Kühling wrote: Hi, while working on the savage driver I found two problems. One with tnl/t_vb_render.c, the other one with tnl_dd/t_dd_tritmp.h. Both started since I use different hardware primitives for quads and triangles/polygons. TAG(quad) in t_dd_tritmp.h calls RASTERIZE( GL_TRIANGLES ) directly before QUAD( (v[0]), (v[1]), (v[2]), (v[3]) ). RASTERIZE should be called with GL_QUADS so that the driver selects the correct hardware primitive. Also I believe that we could use the same condition as in TAG(triangle), namely if (DO_UNFILLED) RASTERIZE( GL_QUADS ); This looks ok. I wonder when this condition will be true anyway. But without this RASTERIZE is called for every single quad! The second problem is in t_vb_render.c with clipped primitives. When a clipped primitive is rendered the PrimitiveNotify callback gets called with GL_POLYGON. When the next unclipped primitive is drawn we have to call PrimitiveNotify again with the original primitive type. I think this is a misunderstanding. Although at a hardware level, you may be rendering with who knows what primitive, at a GL level, you are still attempting to render a TRIANGLE, QUAD, whatever. The only time a difference between TRIANGLES, QUADS and POLYGONS emerges is if flat shading is active, in which case a different vertex is choosen to provide the color for the whole primitive. Is this the problem you're seeing, or is it something less subtle? I am aware of the flat shading issue, but this is not the problem here. Polygons are rendered using triangles. I use a different hardware primitive for Quads. So after rendering a clipped quad as a polygon (using triangles as hardware primitve) I have to tell the driver that the next primitive is going to be a quad again and that it has to select the right hardware primitive. Without this some quads got rendered as triangles with half the quad missing after a clipped quad was rendered as a polygon. Hmm. Sounds like we need to explictly restore the old primitive type after clipping, or to always try and set the primitive type but shortcircuit the operation if there is no change. Your patch looks like it's doing this, but isn't the cleanest code. I'd rather see a 'current' primitive in the tnl context maybe, and only call Driver.PrimitiveNotify() when that primitive changes. Hmm. This would have to be done in conjunction with restoring the old primitive after rendering each clipped primitive. I still think this would work out cleaner than the 'last_clipped' variable, etc that you're using at the moment. Keith --- 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
[Dri-devel] Re: Strange lockups with DRI on Radeon 8500LE
Hi Michel! Sunday 21, at 03:20:33 PM you wrote: > On Sun, 2003-12-21 at 14:55, Konstantin Lepikhov wrote: > > > > After upgrading my box to latest trunk DRI, I got strange problem - > > XServer did not start correctly, e.g. it hangs after init dri stuff. But I > > can ssh to this box, and SysRq keys are working and I can > > sync/umount/reboot. If I comment Load "dri"/remove radeon.o module - all > > works fine except DRI =) So what it can be? Problems with build/my hands > > or is a problem with videocard? FYI, fglrx drivers works fine. > > Have you tried not enabling AGP fast writes? > > I'm a bit confused by the log and config files you attached: the config > says AGP 4x, the log 1x; the config contains Option "UseFBDev", but the > log shows no trace of the fbdevhw module; and last but not least, the > log seems to show a complete and successful startup with DRI enabled? > Please clarify. I send different logs/configs sorry about that. In previous XFree86.log.0, I'm use AGPMode "1" and commented "UseFBDev" "1" and yes, this XFree86.log.0 of hanged XFree86 server, it doesn't init keyboard/mouse and my screen is blank. Now I show XFree86.log.0 and related XF86Config-4 with disabled fast writes. In this case I have the same xserver hangs :( -- WBR, Konstantin chat with ==>ICQ: 109916175 Lepikhov,speak to ==>JID: [EMAIL PROTECTED] aka L.A. Kostis write to ==>mailto:[EMAIL PROTECTED] ...The information is like the bank...(c) EC8OR 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.3.99.12 (DRI trunk) Release Date: 10 September 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.22-std-up-alt8 i686 [ELF] Current Operating System: Linux lks.home 2.4.22-std-up-alt8 #1 Mon Nov 10 00:15:21 MSK 2003 i686 Build Date: 18 December 2003 Changelog Date: 10 September 2003 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. 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: Sun Dec 21 18:02:17 2003 (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "Server Layout" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "ATI Radeon" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "AutoRepeat" "250 30" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "us,ru" (**) XKB: layout: "us,ru" (**) Option "XkbOptions" ",grp:caps_toggle,grp_led:scroll" (**) XKB: options: ",grp:caps_toggle,grp_led:scroll" (==) Keyboard: CustomKeycode disabled (**) FontPath set to "tcp/localhost:7100" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6-DRI/lib/modules" (**) Option "AllowNonLocalXvidtune" (--) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such device) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.7 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6-DRI/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.3.99.12, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6-DRI/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.3.99.12, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.7 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x8000f940, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,2530 card 147b,0507 rev 02 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,2532 card , rev 02 class 06,04,00 hdr 01 (II) PCI: 00:1e:0: chip 8086,244e card , rev 04 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,2440 card , rev 04 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,244b card 147b,0507 rev 04 class 01,01,80 hdr 00 (II) PCI: 00:1f:2: chip 8086,2442 card 147b,0507 rev 04 class 0c,03,00 hdr 00 (II) PCI: 00:1f:3: chip 8086,2443 card 147b,0507 rev 04 class 0c,05,00 hdr 00 (II) PCI: 00:1f:4: chip 8086,2444 card 147b,0507 rev 04 class
Re: [Dri-devel] Re: [Mesa3d-dev] [patch] TNL render problems
On Sun, 21 Dec 2003 09:52:32 -0500 Keith Whitwell <[EMAIL PROTECTED]> wrote: > Keith Whitwell wrote: > > Felix Kühling wrote: > > > >> On Sat, 20 Dec 2003 08:01:07 -0500 > >> Keith Whitwell <[EMAIL PROTECTED]> wrote: > >> > >> > >>> Felix Kühling wrote: > >>> > Hi, > > while working on the savage driver I found two problems. One with > tnl/t_vb_render.c, the other one with tnl_dd/t_dd_tritmp.h. Both > started > since I use different hardware primitives for quads and > triangles/polygons. > > TAG(quad) in t_dd_tritmp.h calls RASTERIZE( GL_TRIANGLES ) directly > before QUAD( (v[0]), (v[1]), (v[2]), (v[3]) ). RASTERIZE should be > called with GL_QUADS so that the driver selects the correct hardware > primitive. Also I believe that we could use the same condition as in > TAG(triangle), namely > > if (DO_UNFILLED) > RASTERIZE( GL_QUADS ); > >>> > >>> > >>> This looks ok. > >>> > >>> > I wonder when this condition will be true anyway. But without this > RASTERIZE is called for every single quad! > > The second problem is in t_vb_render.c with clipped primitives. When a > clipped primitive is rendered the PrimitiveNotify callback gets called > with GL_POLYGON. When the next unclipped primitive is drawn we have to > call PrimitiveNotify again with the original primitive type. > > >>> > >>> I think this is a misunderstanding. Although at a hardware level, > >>> you may be rendering with who knows what primitive, at a GL level, > >>> you are still attempting to render a TRIANGLE, QUAD, whatever. > >>> > >>> The only time a difference between TRIANGLES, QUADS and POLYGONS > >>> emerges is if flat shading is active, in which case a different > >>> vertex is choosen to provide the color for the whole primitive. Is > >>> this the problem you're seeing, or is it something less subtle? > >> > >> > >> > >> I am aware of the flat shading issue, but this is not the problem here. > >> > >> Polygons are rendered using triangles. I use a different hardware > >> primitive for Quads. So after rendering a clipped quad as a polygon > >> (using triangles as hardware primitve) I have to tell the driver that > >> the next primitive is going to be a quad again and that it has to select > >> the right hardware primitive. Without this some quads got rendered as > >> triangles with half the quad missing after a clipped quad was rendered > >> as a polygon. > > > > > > Hmm. Sounds like we need to explictly restore the old primitive type > > after clipping, or to always try and set the primitive type but > > shortcircuit the operation if there is no change. > > > > Your patch looks like it's doing this, but isn't the cleanest code. I'd > > rather see a 'current' primitive in the tnl context maybe, and only call > > Driver.PrimitiveNotify() when that primitive changes. > > Hmm. This would have to be done in conjunction with restoring the old > primitive after rendering each clipped primitive. > > I still think this would work out cleaner than the 'last_clipped' variable, > etc that you're using at the moment. My first approach was to restore the old primitive after each clipped one. But that would result in reduntant primitive switching if several primitives are clipped in a row. Therefore I came up with the last_clipped variable. > > Keith Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- 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
[Dri-devel] Join forces towards DRI support for Savage4, Twister, Prosavage?
Hello Tim, as mentioned earlier on [EMAIL PROTECTED] I'm working on the savage S3 code drop, specifically on the 3D driver. A few days ago I managed to get a working 3D driver ported to Mesa 4. It is now in DRI CVS on the savage-2-0-0-branch. However, many users (including myself) are experiencing more or less serious problems with the 2D driver from the code drop. We have to use it for now as it is the only driver we have that is DRI aware. It also has some nice features that would be worth integrating into a reliable 2D driver, like interpolated scaling of video overlays or hardware motion compensation. I have no experience with XFree86 2D drivers and not much useful documentation of the Savage hardware. I was hoping that we could join forces towards a Savage 2D and 3D driver combination for future XFree86 releases. Therefore I'm writing to you as the maintainer of the Savage 2D driver now. Please get in touch if you're interested. We can discuss further details later on. Happy holidays and best regards, Felix Disclaimer: I'm only speaking for myself here, not as a representative of the DRI team. However, I do believe that a cooperation would make everybody happy. ;-) __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- 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] Re: [Mesa3d-dev] [patch] TNL render problems
Felix Kühling wrote: On Sun, 21 Dec 2003 09:52:32 -0500 Keith Whitwell <[EMAIL PROTECTED]> wrote: Keith Whitwell wrote: Felix Kühling wrote: On Sat, 20 Dec 2003 08:01:07 -0500 Keith Whitwell <[EMAIL PROTECTED]> wrote: Felix Kühling wrote: Hi, while working on the savage driver I found two problems. One with tnl/t_vb_render.c, the other one with tnl_dd/t_dd_tritmp.h. Both started since I use different hardware primitives for quads and triangles/polygons. TAG(quad) in t_dd_tritmp.h calls RASTERIZE( GL_TRIANGLES ) directly before QUAD( (v[0]), (v[1]), (v[2]), (v[3]) ). RASTERIZE should be called with GL_QUADS so that the driver selects the correct hardware primitive. Also I believe that we could use the same condition as in TAG(triangle), namely if (DO_UNFILLED) RASTERIZE( GL_QUADS ); This looks ok. I wonder when this condition will be true anyway. But without this RASTERIZE is called for every single quad! The second problem is in t_vb_render.c with clipped primitives. When a clipped primitive is rendered the PrimitiveNotify callback gets called with GL_POLYGON. When the next unclipped primitive is drawn we have to call PrimitiveNotify again with the original primitive type. I think this is a misunderstanding. Although at a hardware level, you may be rendering with who knows what primitive, at a GL level, you are still attempting to render a TRIANGLE, QUAD, whatever. The only time a difference between TRIANGLES, QUADS and POLYGONS emerges is if flat shading is active, in which case a different vertex is choosen to provide the color for the whole primitive. Is this the problem you're seeing, or is it something less subtle? I am aware of the flat shading issue, but this is not the problem here. Polygons are rendered using triangles. I use a different hardware primitive for Quads. So after rendering a clipped quad as a polygon (using triangles as hardware primitve) I have to tell the driver that the next primitive is going to be a quad again and that it has to select the right hardware primitive. Without this some quads got rendered as triangles with half the quad missing after a clipped quad was rendered as a polygon. Hmm. Sounds like we need to explictly restore the old primitive type after clipping, or to always try and set the primitive type but shortcircuit the operation if there is no change. Your patch looks like it's doing this, but isn't the cleanest code. I'd rather see a 'current' primitive in the tnl context maybe, and only call Driver.PrimitiveNotify() when that primitive changes. Hmm. This would have to be done in conjunction with restoring the old primitive after rendering each clipped primitive. I still think this would work out cleaner than the 'last_clipped' variable, etc that you're using at the moment. My first approach was to restore the old primitive after each clipped one. But that would result in reduntant primitive switching if several primitives are clipped in a row. Therefore I came up with the last_clipped variable. I see where you're going. I agree that probably some further mechanism would be required to make my scheme efficient. If primitive switching is a significant cost, is it worthwhile using hardware quads when clipping is known to be likely? This problem doesn't show up in the other drivers because when clipping is known likely, they all decompose all 'higher' primitives to triangles. This means more vertices are sent to the card, but at the benefit of sending fewer primitives. For vertex-buffers where VB->ClipOrMask == 0, and it is known that clipping will not occur, there is the code in eg. i830_render.c which will endeavour to send whole primitives down to the card. Note that even in this case it is not always advantageous to do so - large numbers of small triangle-strips or fans are handled faster on the i830 by sending a single large list of triangles due to the overheads of starting a new primitive. Keith --- 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
Re: [Dri-devel] Savage 2D corruption workaround
Having briefly looked at the savage_dri.c file in cvs, there are several XAA-like functions defined there, so there are two versions, one for DRI (in savage_dri.c) and ones for XAA (in savage_accel.c). e.g.: static void SAVAGEDRISetupForScreenToScreenCopy( ScrnInfoPtr pScrn, int xdir, int ydir, int rop, unsigned planemask, int transparency_color); static void SAVAGEDRISubsequentScreenToScreenCopy( ScrnInfoPtr pScrn, int x1, int y1, int x2, int y2, int w, int h); static void SAVAGEDRISetupForSolidFill( ScrnInfoPtr pScrn, int color, int rop, unsigned planemask); static void SAVAGEDRISubsequentSolidFillRect( ScrnInfoPtr pScrn, int x, int y, int w, int h); Alex --- Felix Kühling <[EMAIL PROTECTED]> wrote: > On Sun, 21 Dec 2003 08:35:14 -0500 > Keith Whitwell <[EMAIL PROTECTED]> wrote: > > > Felix Kühling wrote: > > > I recompiled a static Xserver so that could get a backtrace > inside the > > > driver. This is the result: > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > 0x080532e3 in SavageHelpSolidROP (pScrn=0x8624270, fg=0xb724, > pm=-1, > > > rop=0xb728) at savage_accel.c:758 > > > 758 pm &= infoRec->FullPlanemask; > > > (gdb) bt > > > #0 0x080532e3 in SavageHelpSolidROP (pScrn=0x8624270, > fg=0xb724, pm=-1, > > > rop=0xb728) at savage_accel.c:758 > > > #1 0x080636e1 in SAVAGEDRISetupForSolidFill (pScrn=0x8624270, > color=0, rop=0, > > > planemask=4294967295) at savage_dri.c:1956 > > > #2 0x08062e87 in SAVAGEDRIInitBuffers (pWin=0x87dd650, > prgn=0x87e1350, > > > index=0) at savage_dri.c:1676 > > > #3 0x0849ee66 in DRIWindowExposures (pWin=0x87dd650, > prgn=0x87e1350, > > > bsreg=0x0) at dri.c:1569 > > > #4 0x081c90f2 in miHandleValidateExposures (pWin=0x87dd948) at > miwindow.c:468 > > > #5 0x0814f8c1 in MapWindow (pWin=0x87dd650, client=0x87588b8) at > window.c:2841 > > > #6 0x08126641 in ProcMapWindow (client=0x87588b8) at > dispatch.c:688 > > > #7 0x08125e9c in Dispatch () at dispatch.c:450 > > > #8 0x0813d3d4 in main (argc=11, argv=0xbd84, > envp=0xbdb4) > > > at main.c:435 > > > > > > Apperently the DRI code in the savage driver uses accel functions > even > > > if acceleration is disabled. Maybe you can try disabling > individual XAA > > > acceleration functions. See the XF86Config-4 manual page for > details. > > > There are lots of options like XaaNoCPUToScreenColorExpandFill. > > > > This probably won't work as the type of operations above aren't > going through > > XAA to reach the accel functions, but instead calling them > directly. > > The idea is that the driver thinks accel is enabled so it'll > initialize > the XAA and we don't get a segfault (hopefully). Still XAA won't use > the > accelerated functions if they are disabled by Xaa... options. I > havn't > looked into the details, so I may be missing something. Anyway, the > hope > is that the accelerated functions are responsible for the corruption > Maximo is observing. To find that out is the whole purpose of these > experiments. ;-) > > > > > There are two cases that spring to mind where this happens: > > > > - New window creation > > - A solid fill blit is used to initialize the back and depth > buffers. I've > > never really been convinced that it was the job of the X server to > do this > > initialization, but in any case it (or the 3D driver) could just as > easily > > issue a 'clear' ioctl to the drm. > > There is no clear ioctl in the savage driver ATM. In fact there are > no > driver-specific ioctls at all (only for mapping PCI DMA buffers if > AGP > is not available). All hardware access is done in user space. :-/ > > > > > - Window moves > > - Copy blits are used to move the contents of the back and depth > buffers to > > their new locations. > > > > > > Both of these operations can be disabled at the expense of some > corruption at > > the times of these events. Look in the _dri.c file in the 2d > driver for where > > these are being called. > > It's always good to have several options. Maximo, you can try this > too > if you still get segfaults when disabling individual acceleration > functions. > > > > > Keith > > __\|/_____ ___ > - > Felix ___\_e -_/___/ __\___/ __\_ You can do anything, >Kühling (_\Ä// /_/ /) just not everything > [EMAIL PROTECTED] \___/ \___/ Uat the same time. > > > --- > 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] > htt
[Dri-devel] radeon_lighting.c in mesa-newtree
it looks like the file Mesa-newtree/src/mesa/drivers/dri/radeon/radeon_lighting.c isnt needed anymore. At least it isnt in the Makefile. Andreas --- 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
Re: [Dri-devel] Re: Strange lockups with DRI on Radeon 8500LE
On Sun, 2003-12-21 at 16:10, Konstantin Lepikhov wrote: > > I send different logs/configs sorry about that. In previous XFree86.log.0, > I'm use AGPMode "1" and commented "UseFBDev" "1" and yes, this > XFree86.log.0 of hanged XFree86 server, it doesn't init keyboard/mouse and > my screen is blank. I assume the monitor can handle [EMAIL PROTECTED] Can you log in remotely and see whether the X server hogs the CPU, and if so, whether killing it helps? Anything interesting in the kernel output? > Now I show XFree86.log.0 and related XF86Config-4 with disabled fast > writes. In this case I have the same xserver hangs :( Have you tried AGP 1x with fast writes disabled? -- 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_id=1278&alloc_id=3371&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Strange lockups with DRI on Radeon 8500LE
Hi Michel! Sunday 21, at 06:26:27 PM you wrote: > On Sun, 2003-12-21 at 16:10, Konstantin Lepikhov wrote: > > > > I send different logs/configs sorry about that. In previous XFree86.log.0, > > I'm use AGPMode "1" and commented "UseFBDev" "1" and yes, this > > XFree86.log.0 of hanged XFree86 server, it doesn't init keyboard/mouse and > > my screen is blank. > > I assume the monitor can handle [EMAIL PROTECTED] Can you log in remotely > and see whether the X server hogs the CPU, and if so, whether killing it > helps? Anything interesting in the kernel output? > Yes, my monitor can handle this resolution and refresh OK here is logs: # ps -waux | grep X xfs 1736 0.0 1.5 6052 3860 ?S19:14 0:00 /usr/X11R6/bin/xfs -port 7100 -daemon -user xfs lakostis 9026 0.0 0.4 1960 1032 tty3 S21:47 0:00 /bin/sh /usr/X11R6/bin/startx lakostis 9038 0.0 0.2 2116 572 tty3 S21:47 0:00 xinit /home/lakostis/.xinitrc -- /etc/X11/xinit/xserverrc :0 root 9039 98.8 2.9 150916 7556 ? R21:47 18:26 /usr/X11R6/bin/X -nolisten tcp :0 # kill -9 `pidof X` && ps -waux | grep X xfs 1736 0.0 1.5 6052 3860 ?S19:14 0:00 /usr/X11R6/bin/xfs -port 7100 -daemon -user xfs lakostis 9026 0.0 0.4 1960 1032 tty3 S21:47 0:00 /bin/sh /usr/X11R6/bin/startx lakostis 9038 0.0 0.2 2116 572 tty3 S21:47 0:00 xinit /home/lakostis/.xinitrc -- /etc/X11/xinit/xserverrc :0 root 9039 98.9 2.9 150916 7556 ? R21:47 21:04 /usr/X11R6/bin/X -nolisten tcp :0 # kill -15 `pidof X` && ps -waux | grep X xfs 1736 0.0 1.5 6052 3860 ?S19:14 0:00 /usr/X11R6/bin/xfs -port 7100 -daemon -user xfs root 9039 99.0 0.0 00 ?RW 21:47 21:46 [X] Yes X server hogs the CPU and don't killed anymore :( # cat /proc/modules radeon114112 1 ip_nat_ftp 3024 0 (unused) ip_nat_irc 2448 0 (unused) ip_conntrack_ftp3856 1 ip_conntrack_irc3152 1 ipt_MASQUERADE 1432 0 (autoclean) iptable_nat17208 2 (autoclean) [ip_nat_ftp ip_nat_irc ipt_MASQUERADE] ipt_REJECT 3352 0 (autoclean) ipt_LOG 3544 0 (autoclean) ipt_limit984 0 (autoclean) ipt_state696 0 (autoclean) iptable_filter 1732 0 (autoclean) ip_conntrack 18216 4 [ip_nat_ftp ip_nat_irc ip_conntrack_ftp ip_conntrack_irc ipt_MASQUERADE iptable_nat ipt_state] ip_tables 12120 9 [ipt_MASQUERADE iptable_nat ipt_REJECT ipt_LOG ipt_limit ipt_state iptable_filter] ppp_deflate 3192 0 (autoclean) zlib_inflate 19748 0 (autoclean) [ppp_deflate] zlib_deflate 18744 0 (autoclean) [ppp_deflate] bsd_comp4504 0 (autoclean) ppp_async 6816 0 (autoclean) vmnet 18664 4 vmmon 23092 0 (unused) af_packet 12424 2 (autoclean) nfsd 69136 8 (autoclean) lockd 48144 1 (autoclean) [nfsd] sunrpc 64220 1 (autoclean) [nfsd lockd] parport_pc 25320 1 (autoclean) lp 6496 0 (autoclean) parport23040 1 (autoclean) [parport_pc lp] autofs4 8212 1 (autoclean) snd-intel8x0 17256 0 (unused) snd-mpu401-uart 2912 0 [snd-intel8x0] snd-pcm-oss37092 0 (unused) snd-mixer-oss 10928 0 [snd-pcm-oss] snd-cs46xx 65700 0 snd-pcm56576 0 [snd-intel8x0 snd-pcm-oss snd-cs46xx] snd-timer 13380 0 [snd-pcm] snd-ac97-codec 36344 0 [snd-intel8x0 snd-cs46xx] gameport1628 0 [snd-intel8x0 snd-cs46xx] snd-rawmidi12352 0 [snd-mpu401-uart snd-cs46xx] snd-seq-device 3744 0 [snd-rawmidi] snd30436 0 [snd-intel8x0 snd-mpu401-uart snd-pcm-oss snd-mixer-oss snd-cs46xx snd-pcm snd-timer snd-ac97-codec snd-rawmidi snd-seq-device] soundcore 3652 9 [snd] snd-page-alloc 5836 0 [snd-intel8x0 snd-cs46xx snd-pcm] w83627hf 12912 0 (unused) eeprom 3368 0 (unused) i2c-proc5780 0 [w83627hf eeprom] i2c-isa 748 0 (unused) i2c-i8014436 0 (unused) i2c-core 14564 0 [w83627hf eeprom i2c-proc i2c-isa i2c-i801] ppp_generic20636 1 (autoclean) [ppp_deflate bsd_comp ppp_async] slhc4960 0 (autoclean) [ppp_generic] 8139too14824 1 (autoclean) mii 2544 0 (autoclean) [8139too] crc32 2880 0 (autoclean) [8139too] sg 30588 0 (autoclean) floppy 48540 0 (autoclean) sd_mod 12044 0 usb-storage72640 0 ehci-hcd 16168 0 (unused) usb-uhci
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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] Re: Strange lockups with DRI on Radeon 8500LE
On Sun, 2003-12-21 at 20:14, Konstantin Lepikhov wrote: > > Here is logs from dmesg: > > > > Linux agpgart interface v0.99 (c) Jeff Hartmann > agpgart: Maximum main memory to use for agp memory: 203M > agpgart: Detected Intel i850 chipset > agpgart: AGP aperture is 64M @ 0xe000 > radeonfb: ref_clk=2700, ref_div=12, xclk=2 from BIOS > Console: switching to colour frame buffer device 80x25 > radeonfb: ATI Radeon 8500 QL DDR SGRAM 128 MB > radeonfb: DVI port no monitor connected > radeonfb: CRT port CRT monitor connected Does not loading radeonfb make a difference? (It shouldn't, but...) > [drm] Initialized radeon 1.10.0 20020828 on minor 0: ATI Radeon QL R200 8500 LE > [drm] Loading R200 Microcode Hmm, I suspect this could be related to the new card memory layout introduced with the radeon DRM 1.10.0. Can you try either the DRM or the 2D driver from before November 4th? -- 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_id=1278&alloc_id=3371&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
