From: Felix <fx...@gm...> - 2002-05-31 00:30:18
|
Hi, I reported lockups shortly after starting the Xserver with a gcc 3.0 compiled drm module that triggered the strange permission problem. Now I tested it without loading the dri Xserver module in XF86Config and got the same lockup. The following messages in XFree86.1.log indicate that the problem is that the 2D driver currently doesn't work without drm: (II) ATI(0): Direct rendering disabled Symbol DRILock from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmMach64WaitForIdle from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmMach64EngineReset from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRIUnlock from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRIUnlock from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRIUnlock from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRILock from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmMach64WaitForIdle from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmMach64EngineReset from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRILock from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRIUnlock from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpAcquire from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpGetMode from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpVendorId from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpDeviceId from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpEnable from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpAlloc from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpBind from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAddMap from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmMap from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAddMap from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmMap from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpFree from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpRelease from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpRelease from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpRelease from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRIQueryVersion from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRICreateInfoRec from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRIScreenInit from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmGetVersion from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmFreeVersion from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmFreeVersion from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAddMap from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRIDestroyInfoRec from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRIDestroyInfoRec from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRIDestroyInfoRec from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRIFinishScreenInit from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAddBufs from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmMach64InitDMA from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmMapBufs from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRIGetSAREAPrivate from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmUnmapBufs from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmMach64CleanupDMA from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmUnmap from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmUnmap from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpUnbind from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpFree from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmAgpRelease from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRICloseScreen from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol DRIDestroyInfoRec from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! I will recompile my entire kernel with gcc-3.0 tomorrow to see if the permission goes away, but this is still a problem, I think. The 2D Xserver should work without DRI loaded. Regards, Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Felix <fx...@gm...> - 2002-05-31 01:03:18
|
On Fri, 31 May 2002 02:30:11 +0200 Felix Kühling <fx...@gm...> wrote: > Hi, > > I reported lockups shortly after starting the Xserver with a gcc 3.0 > compiled drm module that triggered the strange permission problem. Now I > tested it without loading the dri Xserver module in XF86Config and got > the same lockup. The following messages in XFree86.1.log indicate that > the problem is that the 2D driver currently doesn't work without drm: [...] > > I will recompile my entire kernel with gcc-3.0 tomorrow to see if the > permission goes away, but this is still a problem, I think. The 2D > Xserver should work without DRI loaded. I couldn't sleep, so I tried it right away :). The permission problem disappeared after recompiling the entire kernel with gcc-3.0. Sergey, I hope you're familiar with compiling your own kernel ;-). Regards, Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: F. <j_r...@ya...> - 2002-05-31 10:18:35
|
On 2002.05.31 02:03 Felix Kühling wrote: > On Fri, 31 May 2002 02:30:11 +0200 > Felix Kühling <fx...@gm...> wrote: > > > Hi, > > > > I reported lockups shortly after starting the Xserver with a gcc 3.0 > > compiled drm module that triggered the strange permission problem. Now > I > > tested it without loading the dri Xserver module in XF86Config and got > > the same lockup. The following messages in XFree86.1.log indicate that > > the problem is that the 2D driver currently doesn't work without drm: > [...] > > > > I will recompile my entire kernel with gcc-3.0 tomorrow to see if the > > permission goes away, but this is still a problem, I think. The 2D > > Xserver should work without DRI loaded. > > I couldn't sleep, so I tried it right away :). The permission problem > disappeared after recompiling the entire kernel with gcc-3.0. Sergey, I > hope you're familiar with compiling your own kernel ;-). > > Regards, > Felix Great Felix! I bet that you slept much better after too! ;-) José Fonseca |
From: Sergey V. U. <ser...@cl...> - 2002-05-31 12:45:38
|
> Great Felix! I bet that you slept much better after too! ;-) But the question is still open - what in DRM interfaces makes them so gcc-dependable? Why gcc3-built module cannot properly interact with gcc2.96-built kernel? Or this question is not interesting to anyone? Sergey |
From: F. <j_r...@ya...> - 2002-05-31 14:30:33
|
On 2002.05.31 13:35 Sergey V. Udaltsov wrote: > > Great Felix! I bet that you slept much better after too! ;-) > But the question is still open - what in DRM interfaces makes them so > gcc-dependable? Why gcc3-built module cannot properly interact with > gcc2.96-built kernel? Or this question is not interesting to anyone? > > Sergey > You're quite right, Sergey. This problem will most surely hunt us as gcc3 becomes more mainstream. Nevertheless, there is no guarantee that the problem is in the DRM interface, or for example in the linux headers. So until gcc-3.1 is considered officially as a recommended compiler to the linux kernel, and since we now know how to circumvent it, I personally prefer to dedicate to other more demanding matters. Regards, José Fonseca |
From: Michel <mi...@da...> - 2002-05-31 16:32:12
|
On Fri, 2002-05-31 at 14:35, Sergey V. Udaltsov wrote: > > Great Felix! I bet that you slept much better after too! ;-) > But the question is still open - what in DRM interfaces makes them so > gcc-dependable? Why gcc3-built module cannot properly interact with > gcc2.96-built kernel? Kernel modules may rely on kernel internal data structures, which may be laid out differently in memory by different compilers. I don't think you can expect this to work, but if I'm wrong I'm sure Linus will LART me. :) --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Linus T. <tor...@tr...> - 2002-05-31 17:08:03
|
On 31 May 2002, Michel D=E4nzer wrote: > > Kernel modules may rely on kernel internal data structures, which may b= e > laid out differently in memory by different compilers. I don't think yo= u > can expect this to work, but if I'm wrong I'm sure Linus will LART me. > :) Different compilers may indeed have different layout rules, but I haven't= =20 heard of any such changes in gcc-3.x, and it would be fairly unexpected.=20 Now, if the kernel was compiled with C++ and used virtual inheritance,=20 that would be a different issue ;) There was some discussion on the gcc lists about the proper way to pad=20 structures with variable arrays at the end, but as far as I can tell that= =20 shouldn't affect Linux anyway, and I don't think the behaviour had=20 actually changed. So I think it's more likely that it's either a gcc-3.x bug, or a latent kernel bug that is exposed by a better compiler (they do happen: places where parts of the kernel depend on unspecified behaviour. They get fixed when noticed, but they can be hard to find). It would probably be a good idea to do a full "strace" on the successful=20 and failing cases, and try to see what the difference is in order to hunt= =20 it down a bit. Linus |
From: Sergey V. U. <ser...@cl...> - 2002-05-31 19:18:54
|
> Different compilers may indeed have different layout rules, but I haven't > heard of any such changes in gcc-3.x, and it would be fairly unexpected. > Now, if the kernel was compiled with C++ and used virtual inheritance, > that would be a different issue ;) Also, I've heard they've changed something in the mangling... > It would probably be a good idea to do a full "strace" on the successful > and failing cases, and try to see what the difference is in order to hunt > it down a bit. For me it's not a problem. But if all the works are done inside kernel (in DRM module) - will strace help? So should I post strace log here? Regards, Sergey |
From: Sergey V. U. <ser...@cl...> - 2002-06-04 23:28:14
|
:EEEEEEEE Well, I built kernel 2.4.18-0.26 (from RH Rawhide SRPM) and got much trouble. The worst of it that my vmware does not work any more:( The vm* modules are built OK but I get OOPS loading them. Well, but even drm does not work any better. I rebuilt mach64.o again and still get those "Permission denied" messages. Any clues? Regards, Sergey |
From: Michel <mi...@da...> - 2002-05-31 21:20:25
|
On Fri, 2002-05-31 at 02:30, Felix K=FChling wrote:=20 >=20 > I reported lockups shortly after starting the Xserver with a gcc 3.0 > compiled drm module that triggered the strange permission problem. Now I > tested it without loading the dri Xserver module in XF86Config and got > the same lockup. The following messages in XFree86.1.log indicate that > the problem is that the 2D driver currently doesn't work without drm: >=20 > (II) ATI(0): Direct rendering disabled > Symbol DRILock from module /usr/X11R6-mach64004/lib/modules/drivers/atimi= sc_drv.o is unresolved! > Symbol drmMach64WaitForIdle from module /usr/X11R6-mach64004/lib/modules/= drivers/atimisc_drv.o is unresolved! > Symbol drmMach64EngineReset from module /usr/X11R6-mach64004/lib/modules/= drivers/atimisc_drv.o is unresolved! > Symbol DRIUnlock from module /usr/X11R6-mach64004/lib/modules/drivers/ati= misc_drv.o is unresolved! > Symbol DRIUnlock from module /usr/X11R6-mach64004/lib/modules/drivers/ati= misc_drv.o is unresolved! > Symbol DRIUnlock from module /usr/X11R6-mach64004/lib/modules/drivers/ati= misc_drv.o is unresolved! > Symbol DRILock from module /usr/X11R6-mach64004/lib/modules/drivers/atimi= sc_drv.o is unresolved! > Symbol drmMach64WaitForIdle from module /usr/X11R6-mach64004/lib/modules/= drivers/atimisc_drv.o is unresolved! > Symbol drmMach64EngineReset from module /usr/X11R6-mach64004/lib/modules/= drivers/atimisc_drv.o is unresolved! > Symbol DRILock from module /usr/X11R6-mach64004/lib/modules/drivers/atimi= sc_drv.o is unresolved! > Symbol DRIUnlock from module /usr/X11R6-mach64004/lib/modules/drivers/ati= misc_drv.o is unresolved! > Symbol drmAgpAcquire from module /usr/X11R6-mach64004/lib/modules/drivers= /atimisc_drv.o is unresolved! > Symbol drmAgpGetMode from module /usr/X11R6-mach64004/lib/modules/drivers= /atimisc_drv.o is unresolved! > Symbol drmAgpVendorId from module /usr/X11R6-mach64004/lib/modules/driver= s/atimisc_drv.o is unresolved! > Symbol drmAgpDeviceId from module /usr/X11R6-mach64004/lib/modules/driver= s/atimisc_drv.o is unresolved! > Symbol drmAgpEnable from module /usr/X11R6-mach64004/lib/modules/drivers/= atimisc_drv.o is unresolved! > Symbol drmAgpAlloc from module /usr/X11R6-mach64004/lib/modules/drivers/a= timisc_drv.o is unresolved! > Symbol drmAgpBind from module /usr/X11R6-mach64004/lib/modules/drivers/at= imisc_drv.o is unresolved! > Symbol drmAddMap from module /usr/X11R6-mach64004/lib/modules/drivers/ati= misc_drv.o is unresolved! > Symbol drmMap from module /usr/X11R6-mach64004/lib/modules/drivers/atimis= c_drv.o is unresolved! > Symbol drmAddMap from module /usr/X11R6-mach64004/lib/modules/drivers/ati= misc_drv.o is unresolved! > Symbol drmMap from module /usr/X11R6-mach64004/lib/modules/drivers/atimis= c_drv.o is unresolved! > Symbol drmAgpFree from module /usr/X11R6-mach64004/lib/modules/drivers/at= imisc_drv.o is unresolved! > Symbol drmAgpRelease from module /usr/X11R6-mach64004/lib/modules/drivers= /atimisc_drv.o is unresolved! > Symbol drmAgpRelease from module /usr/X11R6-mach64004/lib/modules/drivers= /atimisc_drv.o is unresolved! > Symbol drmAgpRelease from module /usr/X11R6-mach64004/lib/modules/drivers= /atimisc_drv.o is unresolved! > Symbol DRIQueryVersion from module /usr/X11R6-mach64004/lib/modules/drive= rs/atimisc_drv.o is unresolved! > Symbol DRICreateInfoRec from module /usr/X11R6-mach64004/lib/modules/driv= ers/atimisc_drv.o is unresolved! > Symbol DRIScreenInit from module /usr/X11R6-mach64004/lib/modules/drivers= /atimisc_drv.o is unresolved! > Symbol drmGetVersion from module /usr/X11R6-mach64004/lib/modules/drivers= /atimisc_drv.o is unresolved! > Symbol drmFreeVersion from module /usr/X11R6-mach64004/lib/modules/driver= s/atimisc_drv.o is unresolved! > Symbol drmFreeVersion from module /usr/X11R6-mach64004/lib/modules/driver= s/atimisc_drv.o is unresolved! > Symbol drmAddMap from module /usr/X11R6-mach64004/lib/modules/drivers/ati= misc_drv.o is unresolved! > Symbol DRIDestroyInfoRec from module /usr/X11R6-mach64004/lib/modules/dri= vers/atimisc_drv.o is unresolved! > Symbol DRIDestroyInfoRec from module /usr/X11R6-mach64004/lib/modules/dri= vers/atimisc_drv.o is unresolved! > Symbol DRIDestroyInfoRec from module /usr/X11R6-mach64004/lib/modules/dri= vers/atimisc_drv.o is unresolved! > Symbol DRIFinishScreenInit from module /usr/X11R6-mach64004/lib/modules/d= rivers/atimisc_drv.o is unresolved! > Symbol drmAddBufs from module /usr/X11R6-mach64004/lib/modules/drivers/at= imisc_drv.o is unresolved! > Symbol drmMach64InitDMA from module /usr/X11R6-mach64004/lib/modules/driv= ers/atimisc_drv.o is unresolved! > Symbol drmMapBufs from module /usr/X11R6-mach64004/lib/modules/drivers/at= imisc_drv.o is unresolved! > Symbol DRIGetSAREAPrivate from module /usr/X11R6-mach64004/lib/modules/dr= ivers/atimisc_drv.o is unresolved! > Symbol drmUnmapBufs from module /usr/X11R6-mach64004/lib/modules/drivers/= atimisc_drv.o is unresolved! > Symbol drmMach64CleanupDMA from module /usr/X11R6-mach64004/lib/modules/d= rivers/atimisc_drv.o is unresolved! > Symbol drmUnmap from module /usr/X11R6-mach64004/lib/modules/drivers/atim= isc_drv.o is unresolved! > Symbol drmUnmap from module /usr/X11R6-mach64004/lib/modules/drivers/atim= isc_drv.o is unresolved! > Symbol drmAgpUnbind from module /usr/X11R6-mach64004/lib/modules/drivers/= atimisc_drv.o is unresolved! > Symbol drmAgpFree from module /usr/X11R6-mach64004/lib/modules/drivers/at= imisc_drv.o is unresolved! > Symbol drmAgpRelease from module /usr/X11R6-mach64004/lib/modules/drivers= /atimisc_drv.o is unresolved! > Symbol DRICloseScreen from module /usr/X11R6-mach64004/lib/modules/driver= s/atimisc_drv.o is unresolved! > Symbol DRIDestroyInfoRec from module /usr/X11R6-mach64004/lib/modules/dri= vers/atimisc_drv.o is unresolved! >=20 > I will recompile my entire kernel with gcc-3.0 tomorrow to see if the > permission goes away, but this is still a problem, I think. The 2D > Xserver should work without DRI loaded. These messages are harmless unless one of the unresolved symbols is referenced, which shouldn't happen when DRI is disabled. And even if one of them was referenced, that would cause a server crash and not a lockup. (Unless the crash causes a lockup...) I think the messages can be silenced by adding the symbols to the xf86LoaderRefSymLists() call. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Felix <fx...@gm...> - 2002-06-01 22:44:11
|
On 31 May 2002 23:20:19 +0200 Michel Dänzer <mi...@da...> wrote: > On Fri, 2002-05-31 at 02:30, Felix Kühling wrote: > > > > I reported lockups shortly after starting the Xserver with a gcc 3.0 > > compiled drm module that triggered the strange permission problem. Now I > > tested it without loading the dri Xserver module in XF86Config and got > > the same lockup. The following messages in XFree86.1.log indicate that > > the problem is that the 2D driver currently doesn't work without drm: [...] > These messages are harmless unless one of the unresolved symbols is > referenced, which shouldn't happen when DRI is disabled. And even if one > of them was referenced, that would cause a server crash and not a > lockup. (Unless the crash causes a lockup...) I had a closer look at this. I get a lockup when I run the Xserver without DRI after switching from a 2D accelerated XFree86 4.1 server to the text console. If DRI is loaded there is no problem. If I start the Mach64-Xserver after a reboot and without DRI there is no problem either. I guess this means that the 3D driver puts the card in some state that the 2D driver relies on and the old Xserver messes it up. Regards, Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Leif D. <lde...@re...> - 2002-06-02 02:02:38
|
On 31 May 2002, Michel D=E4nzer wrote: > On Fri, 2002-05-31 at 02:30, Felix K=FChling wrote:=20 > >=20 > > I reported lockups shortly after starting the Xserver with a gcc 3.0 > > compiled drm module that triggered the strange permission problem. No= w I > > tested it without loading the dri Xserver module in XF86Config and go= t > > the same lockup. The following messages in XFree86.1.log indicate tha= t > > the problem is that the 2D driver currently doesn't work without drm: > >=20 > > (II) ATI(0): Direct rendering disabled > > Symbol DRILock from module /usr/X11R6-mach64004/lib/modules/drivers/a= timisc_drv.o is unresolved! > > Symbol drmMach64WaitForIdle from module /usr/X11R6-mach64004/lib/modu= les/drivers/atimisc_drv.o is unresolved! [ yadda yadda yadda ... ] > > Symbol DRICloseScreen from module /usr/X11R6-mach64004/lib/modules/dr= ivers/atimisc_drv.o is unresolved! > > Symbol DRIDestroyInfoRec from module /usr/X11R6-mach64004/lib/modules= /drivers/atimisc_drv.o is unresolved! > >=20 > > I will recompile my entire kernel with gcc-3.0 tomorrow to see if the > > permission goes away, but this is still a problem, I think. The 2D > > Xserver should work without DRI loaded. >=20 > These messages are harmless unless one of the unresolved symbols is > referenced, which shouldn't happen when DRI is disabled. And even if on= e > of them was referenced, that would cause a server crash and not a > lockup. (Unless the crash causes a lockup...) >=20 > I think the messages can be silenced by adding the symbols to the > xf86LoaderRefSymLists() call. Thanks for the tip. I commited a fix for this that quiets these messages= . =20 I used xf86LoaderRefSymLists() in ATIPreInit (atipreinit.c) a la the r128 and Radeon drivers. Felix, 2D accel should work when dri is disabled with the current branch,= =20 so you might try running two Xservers based on the branch, one with dri=20 enabled and one with it disabled and see if you still have the lockup. A couple of weeks ago, I also made sure that the DDX in the DRI branch=20 explicitly sets the FIFO size to 128 entries, rather than reading the=20 regsiter and saving that value (which is restored on mode/vt switches), i= n=20 order to avoid the problem you mentioned before. IIRC, you had started=20 the DRI enabled server from a console with the xfree 4.1 server already=20 running. In that case, the DDX in the newly started server saved the=20 value set by the 4.1 server, which would cause a lockup with dri. In thi= s=20 case though, without dri enabled, I don't how that could be the problem. --=20 Leif Delgass=20 http://www.retinalburn.net |
From: Felix <fx...@gm...> - 2002-06-02 12:21:11
|
Hi, I submitted another message about this yesterday. It didn't show up in the SourceForge archive and you didn't refer to it, so I'm submitting it again: ---------------------------------------------------------------------- [Michel Dänzer <mi...@da...>] > These messages are harmless unless one of the unresolved symbols is > referenced, which shouldn't happen when DRI is disabled. And even if one > of them was referenced, that would cause a server crash and not a > lockup. (Unless the crash causes a lockup...) I had a closer look at this. I get a lockup when I run the Xserver without DRI after switching from a 2D accelerated XFree86 4.1 server to the text console. If DRI is loaded there is no problem. If I start the Mach64-Xserver after a reboot and without DRI there is no problem either. I guess this means that the 3D driver puts the card in some state that the 2D driver relies on and the old Xserver messes it up. ---------------------------------------------------------------------- Maybe it's again a problem with the FIFO size. Just a guess. Anyway, I think I'll switch to the new accelerated server as you proposed. It seems that I'm just asking for trouble with my current config :) Regards, Felix On Sat, 1 Jun 2002 22:02:14 -0400 (EDT) Leif Delgass <lde...@re...> wrote: > On 31 May 2002, Michel Dänzer wrote: > > > On Fri, 2002-05-31 at 02:30, Felix Kühling wrote: > > > > > > I reported lockups shortly after starting the Xserver with a gcc 3.0 > > > compiled drm module that triggered the strange permission problem. Now I > > > tested it without loading the dri Xserver module in XF86Config and got > > > the same lockup. The following messages in XFree86.1.log indicate that > > > the problem is that the 2D driver currently doesn't work without drm: > > > > > > (II) ATI(0): Direct rendering disabled > > > Symbol DRILock from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! > > > Symbol drmMach64WaitForIdle from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! > > [ yadda yadda yadda ... ] > > > > Symbol DRICloseScreen from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! > > > Symbol DRIDestroyInfoRec from module /usr/X11R6-mach64004/lib/modules/drivers/atimisc_drv.o is unresolved! > > > > > > I will recompile my entire kernel with gcc-3.0 tomorrow to see if the > > > permission goes away, but this is still a problem, I think. The 2D > > > Xserver should work without DRI loaded. > > > > These messages are harmless unless one of the unresolved symbols is > > referenced, which shouldn't happen when DRI is disabled. And even if one > > of them was referenced, that would cause a server crash and not a > > lockup. (Unless the crash causes a lockup...) > > > > I think the messages can be silenced by adding the symbols to the > > xf86LoaderRefSymLists() call. > > Thanks for the tip. I commited a fix for this that quiets these messages. > I used xf86LoaderRefSymLists() in ATIPreInit (atipreinit.c) a la the r128 > and Radeon drivers. > > Felix, 2D accel should work when dri is disabled with the current branch, > so you might try running two Xservers based on the branch, one with dri > enabled and one with it disabled and see if you still have the lockup. > A couple of weeks ago, I also made sure that the DDX in the DRI branch > explicitly sets the FIFO size to 128 entries, rather than reading the > regsiter and saving that value (which is restored on mode/vt switches), in > order to avoid the problem you mentioned before. IIRC, you had started > the DRI enabled server from a console with the xfree 4.1 server already > running. In that case, the DDX in the newly started server saved the > value set by the 4.1 server, which would cause a lockup with dri. In this > case though, without dri enabled, I don't how that could be the problem. > > -- > Leif Delgass > http://www.retinalburn.net > > __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Leif D. <lde...@re...> - 2002-06-02 17:48:13
|
On Sun, 2 Jun 2002, Felix K=FChling wrote: > Hi, >=20 > I submitted another message about this yesterday. It didn't show up in > the SourceForge archive and you didn't refer to it, so I'm submitting i= t > again: >=20 > ---------------------------------------------------------------------- >=20 > [Michel D=E4nzer <mi...@da...>] > > These messages are harmless unless one of the unresolved symbols is > > referenced, which shouldn't happen when DRI is disabled. And even if = one > > of them was referenced, that would cause a server crash and not a > > lockup. (Unless the crash causes a lockup...) >=20 > I had a closer look at this. I get a lockup when I run the Xserver > without DRI after switching from a 2D accelerated XFree86 4.1 server to > the text console. If DRI is loaded there is no problem. If I start the > Mach64-Xserver after a reboot and without DRI there is no problem > either. >=20 > I guess this means that the 3D driver puts the card in some state that > the 2D driver relies on and the old Xserver messes it up. Since the dri branch driver works on it's own without dri enabled, I don'= t see how it could be a 3D driver dependency. Unless I'm not understanding you, the problem is with two 2D drivers without dri enabled on either. =20 Maybe it's a bad interaction between xfree 4.1 and 4.2? I just tried starting a 4.2 based gatos driver, then switching to a text console and starting the dri branch driver with dri disabled. I can switch back and forth between them and to a text console without a lockup. I don't have = a 4.1 server anymore so I can't test that. =20 > ---------------------------------------------------------------------- >=20 > Maybe it's again a problem with the FIFO size. Just a guess. This shouldn't be a problem when dri isn't enabled. =20 > Anyway, I think I'll switch to the new accelerated server as you > proposed. It seems that I'm just asking for trouble with my current > config :) ok. I'm still curious about what the problem is, though. How recent is=20 the dri branch build you're using? Is the 4.1 server a vanilla xfree=20 release or a gatos driver? >=20 > On Sat, 1 Jun 2002 22:02:14 -0400 (EDT) > Leif Delgass <lde...@re...> wrote: >=20 > > On 31 May 2002, Michel D=E4nzer wrote: > >=20 > > > On Fri, 2002-05-31 at 02:30, Felix K=FChling wrote:=20 > > > >=20 > > > > I reported lockups shortly after starting the Xserver with a gcc = 3.0 > > > > compiled drm module that triggered the strange permission problem= . Now I > > > > tested it without loading the dri Xserver module in XF86Config an= d got > > > > the same lockup. The following messages in XFree86.1.log indicate= that > > > > the problem is that the 2D driver currently doesn't work without = drm: > > > >=20 > > > > (II) ATI(0): Direct rendering disabled > > > > Symbol DRILock from module /usr/X11R6-mach64004/lib/modules/drive= rs/atimisc_drv.o is unresolved! > > > > Symbol drmMach64WaitForIdle from module /usr/X11R6-mach64004/lib/= modules/drivers/atimisc_drv.o is unresolved! > >=20 > > [ yadda yadda yadda ... ] > >=20 > > > > Symbol DRICloseScreen from module /usr/X11R6-mach64004/lib/module= s/drivers/atimisc_drv.o is unresolved! > > > > Symbol DRIDestroyInfoRec from module /usr/X11R6-mach64004/lib/mod= ules/drivers/atimisc_drv.o is unresolved! > > > >=20 > > > > I will recompile my entire kernel with gcc-3.0 tomorrow to see if= the > > > > permission goes away, but this is still a problem, I think. The 2= D > > > > Xserver should work without DRI loaded. > > >=20 > > > These messages are harmless unless one of the unresolved symbols is > > > referenced, which shouldn't happen when DRI is disabled. And even i= f one > > > of them was referenced, that would cause a server crash and not a > > > lockup. (Unless the crash causes a lockup...) > > >=20 > > > I think the messages can be silenced by adding the symbols to the > > > xf86LoaderRefSymLists() call. > >=20 > > Thanks for the tip. I commited a fix for this that quiets these mess= ages. =20 > > I used xf86LoaderRefSymLists() in ATIPreInit (atipreinit.c) a la the = r128 > > and Radeon drivers. > >=20 > > Felix, 2D accel should work when dri is disabled with the current bra= nch,=20 > > so you might try running two Xservers based on the branch, one with d= ri=20 > > enabled and one with it disabled and see if you still have the lockup. > > A couple of weeks ago, I also made sure that the DDX in the DRI branc= h=20 > > explicitly sets the FIFO size to 128 entries, rather than reading the= =20 > > regsiter and saving that value (which is restored on mode/vt switches= ), in=20 > > order to avoid the problem you mentioned before. IIRC, you had start= ed=20 > > the DRI enabled server from a console with the xfree 4.1 server alrea= dy=20 > > running. In that case, the DDX in the newly started server saved the= =20 > > value set by the 4.1 server, which would cause a lockup with dri. In= this=20 > > case though, without dri enabled, I don't how that could be the probl= em. > >=20 > > --=20 > > Leif Delgass=20 > > http://www.retinalburn.net > >=20 > >=20 >=20 >=20 > __\|/__ ___ ___ ___ > __Tsch=FC=DF_______\_6 6_/___/__ \___/__ \___/___\___You can do anythin= g,___ > _____Felix_______\=C4/\ \_____\ \_____\ \______U___just not everything_= ___ > fx...@gm... >o<__/ \___/ \___/ at the same time! >=20 --=20 Leif Delgass=20 http://www.retinalburn.net |
From: Felix <fx...@gm...> - 2002-06-02 18:10:45
|
On Sun, 2 Jun 2002 13:48:02 -0400 (EDT) Leif Delgass <lde...@re...> wrote: [...] > > I had a closer look at this. I get a lockup when I run the Xserver > > without DRI after switching from a 2D accelerated XFree86 4.1 server to > > the text console. If DRI is loaded there is no problem. If I start the > > Mach64-Xserver after a reboot and without DRI there is no problem > > either. > > > > I guess this means that the 3D driver puts the card in some state that > > the 2D driver relies on and the old Xserver messes it up. > > Since the dri branch driver works on it's own without dri enabled, I don't > see how it could be a 3D driver dependency. Unless I'm not understanding > you, the problem is with two 2D drivers without dri enabled on either. What I mean is that the problem does not occur when I start the new Xserver with DRI. So I concluded that the 3D driver does something that prevents the problem from happening that the 2D driver should better do himself. But when I think about it again it could also be the 2D acceleration which is disabled when DRI is loaded. So 4.2 2D accel locks up when 4.1 2D accel has been running just before. > Maybe it's a bad interaction between xfree 4.1 and 4.2? I just tried Yes, definitely. > starting a 4.2 based gatos driver, then switching to a text console and > starting the dri branch driver with dri disabled. I can switch back and > forth between them and to a text console without a lockup. I don't have a > 4.1 server anymore so I can't test that. > > > ---------------------------------------------------------------------- > > > > Maybe it's again a problem with the FIFO size. Just a guess. > > This shouldn't be a problem when dri isn't enabled. Ok, it's probably 2D acceleration. > > Anyway, I think I'll switch to the new accelerated server as you > > proposed. It seems that I'm just asking for trouble with my current > > config :) > > ok. I'm still curious about what the problem is, though. How recent is > the dri branch build you're using? Is the 4.1 server a vanilla xfree > release or a gatos driver? This is the start of the server output: This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org and patches submitted to fixes@XFree86.Org. 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.1.0.1 / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 21 December 2001 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/FAQ) Build Operating System: Linux 2.4.17 i686 [ELF] It's the one that comes with Debian Woody. I wouldn't take any bets on how vanilla that is. Unfortunately there is no XFree86 4.2 in Debian, not even in unstable. Regards, Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |