> I haven't seen this behaviour in ages! It is an > nVidia issue, as they > replace a system library (actually several of them) with > nVidia-specific > versions. For some reason, those replaced libraries > don't work 100% with > the kinit system. To prove this, fire up gdb and > attach to the frozen > process. When you generate a backtrace, you will see > nVidia binary blobs > at the most recent call depth, even though kinit obviously > does not > compile/link against nVidia. Ah, confirmation. :) I don't know how to attach to the frozen process or generate a backtrace. Probably should learn. :) I don't think I need to do any of that to confirm what I already see. I know that the proprietary Nvidia drivers replace a few files. The question is how do I/we work around that? I have 3.5.10 running here as well as 3.5.13. I don't have this problem in 3.5.10 with the Nvidia drivers installed. Asking people to temporarily restore the stock X libs or disable the Nvidia drivers will cause people to laugh and forget about testing or using TDE. That is not a doable solution for newbies who are interested in TDE. 1. Is there any damage in startkde of running kdetcompmgr as a background task? 2. What process started in startkde is launching kconf_update? 3. Why is kconf_update being launched? 4. Is there a way to prevent kconf_update from running? Darrell