Comment 385 for bug 541511

(In reply to comment #229)
> Created an attachment (id=38135) [details]
> Failed chipset flush backtrace
>
> A backtrace from dmesg. Occurs with the V9 patch and 2.6.35.3.

Some extra notes on the issues mentioned above:

The "flush hang" problem (the 'flush-8:0' kernel process taking up all the CPU time) occurs no matter if compositing is off, no matter if intensive disk operations take place and no matter if the desktop is actually used. (It can easily happen right after boot when only KDM is displayed.)

The "flush hang" problem does not occur immediately in the moment when the backtrace appears. Minutes to tens of minutes elapse between the warning and the flush-8:0 process going out of control.

I tried the Reiser4 patch alone (without the V9 patch (and without X.org, of course)) and had no issues. Everything worked even after hours of uptime. But this could have just happened by chance...

I see there's some VFS related stuff in the backtrace. If I understand it well, a scheduling clock tick is involved. Could this be a bug related to interrupt disabling and other synchronization? If the VFS data integrity is compromised, it could possibly explain some of these issues.

I use a fully preemptible kernel and a 300Hz scheduling clock. The machine is an Asus M2400N (uniprocessor Pentium M).

What should I try next? Any suggestions?