Problems with the 'flush-8:0' process in 2.6.35.3

Problems with the 'flush-8:0' process in 2.6.35.3

[Andrej Podzimek]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

Hello,

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? How could I track this down? In fact I don't even know whether this is related to Reiser4 or not. It may be a bug in VFS. I don't use 'noflushd' or anything of that kind. (Some people reported similar problems related to noflushd. So this is not the case.) If this is unrelated to Reiser4, where should I report it?

Andrej


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 6343 bytes --]

Re: Problems with the 'flush-8:0' process in 2.6.35.3

[Edward Shishkin]

Andrej Podzimek wrote:
> Hello,

Hello.

>
> 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?

> In fact I don't even know whether this is related to Reiser4 or not.

Which kernel version did you have before upgrade?

Thanks,
Edward.

> It may be a bug in VFS. I don't use 'noflushd' or anything of that
> kind. (Some people reported similar problems related to noflushd. So
> this is not the case.) If this is unrelated to Reiser4, where should I
> report it?
>
> Andrej
>

Re: Problems with the 'flush-8:0' process in 2.6.35.3

[Edward Shishkin]

Edward Shishkin wrote:
> Andrej Podzimek wrote:
>   
>> Hello,
>>     
>
> Hello.
>
>   
>> 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?

Thanks,
Edward.

>   
>> In fact I don't even know whether this is related to Reiser4 or not.
>>     
>
> Which kernel version did you have before upgrade?
>
> Thanks,
> Edward.
>
>   
>> It may be a bug in VFS. I don't use 'noflushd' or anything of that
>> kind. (Some people reported similar problems related to noflushd. So
>> this is not the case.) If this is unrelated to Reiser4, where should I
>> report it?
>>
>> Andrej
>>
>>     
>
>
>   

Re: Problems with the 'flush-8:0' process in 2.6.35.3

[Andrej Podzimek]

[-- Attachment #1.1: Type: text/plain, Size: 2313 bytes --]

>>> 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 #1.2: flushbacktrace.bz2 --]
[-- Type: application/x-bzip, Size: 2676 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 6343 bytes --]