I use a 2.6.35.3 kernel and Reiser4 as the root file system. In a couple of minutes after boot, a kernel process called 'flush-8:0' takes up all the available CPU time. From that moment on, it is impossible to sync filesystems (and suspend, hibernate or reboot). (The 'sync' command halts indefinitely.) In some cases it is even impossible to log in. Existing sessions seem to work fine, to an extent. I first thought this was related to the GTT chipset coherency patch. (This patch fixes a one-year-old bug that caused all the Intel 855 class GPUs to be totally unusable.) However, removing the patch and testing with only a vanilla kernel (and Reiser4, of course) showed that 'flush-8:0' will eventually go mad, no matter if the GPU-related patch is present or not. The machine is an Asus M2400N laptop with a 100GB Seagate Momentus. Is this a known issue?Um, nop..How could I track this down?Could you try to catch sysrq-t output to take a look what the flush-8:0 doing?Any progress here? Also could you please check your partition with fsck?
Hello, sorry about the long delay. I had a very busy time. You asked about the kernel version I used before. It was 2.6.34.3. Reiser4 seemed to work fine there. The problems started when I moved to 2.6.35.3. As far as fsck is concerned, the partition seems to be OK (no error messages), but the fsck.reiser4 program fails on all of my partitions when closing the file system, saying that an internal error occurred. (I already reported this once and you inspected my file system metadata, concluding that this is a false alert and a bug in fsck.reiser4.) I catched a couple of stack traces with Magic-t during the time when the flush-8:0 process was consuming all the CPU time. They are attached. A couple of observations: * Once flush-8:0 gets crazy, it doesn't seem to stop. (It was still consuming all the CPU time after an hour...) * Everything looks normal right after boot. The flush-8:0 will usually get out of control a couple of minutes after boot. * There is a reliable trigger for this issue: sync. Once invoked, sync *never* returns and causes flush-8:0 to get out of control. Andrej
Attachment:
flushbacktrace.bz2
Description: application/bzip
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
