Twice since a new install my system has become unresponsive -- because I have no room left in my /var partition. [What I installed was SuSE 10.0 (32 bit). Also installed xorg 6.9 from the supplementary SuSE gwdg.de repository. (Once I installed xorg 6.9, it could not find the driver module. I switched video cards - it still could not find modules. So I added ModulePath lines to xorg.conf pointing to where the driver was - that bypassed THAT problem.) ] What is happening is that 'WaitForIdle' messages (hundreds of megabytes of them) are being written to Xorg.0.log. Two problems with this: 1) It is SERIOUS when the system is left with 0 bytes free in the /var partition. No matter WHAT the warning message, writes into /var ought to be avoided when the partition becomes 90+% full. 2) My system will NEVER go into idle. I have a background (compute-intensive) task that takes 100% of the available CPU cycles 24/7. A design which assumes that "Idle" will ever be available is faulty. This is somewhat like bug 473, except that my video card is an ATI 9600, and my xorg.conf does not load the dri module. The (edited) log I'm trying to enclose was left over from a time when I manually terminated X - not from when my /var was left with 0 bytes free. .
Created attachment 5307 [details] edited Xorg.0.log showing excessive 'WaitingForIdle' messages
Created attachment 5308 [details] xorg.conf
'waitforidle' has nothing to do with the cpu, but instead refers to waiting until the gpu becomes idle (i.e. all pending requests have been completed). as for /var, we can't do anything about that, aside from fixing the bug that leads to the debug spew.
<quote>'waitforidle' has nothing to do with the cpu, but instead refers to waiting until the gpu becomes idle (i.e. all pending requests have been completed).</quote> Thanks. Some more info: This is on a system with two AthlonMP CPUs. And as far as I can tell the GPU is not being called to display anything complex - just the GNOME screen. The background applications (in separate virtual screens) use only text in GNOME terminals (one of them having a number counting down "in place" at three second intervals). On one of the problem occasions I might have had gkrellm (CPUs + temperature) running, but not at any other time.
I think this debugging message was only temporarily enabled in the course of testing Benjamin Herrenschmidt's memmap patches; AFAICT it's disabled in all released versions and current CVS branches. I suggest switching to one of those.
Did Michels tip resolve your issue?
(In reply to comment #6) > Did Michels tip resolve your issue? Sort of. I don't have the energy to fetch/install 6.9 from CVS. And a cursory search did not turn up where I could get a replacement Radeon driver without the debug output. So I back-leveled my system to xorg 6.8.2 - that resolved *my* issue. Unfortunately, I do not know (and therefore haven't contacted) whoever ported xorg 6.9 to SuSE 10.0. AFAIK the SuSE 10.0 repository on gwdg.de for xorg 6.9 __still__ contains the Radeon driver version that generated hundreds of megabytes of log data when installed to my system.
Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status. Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.