Linux Virtualization - Sep 2009 - INFO: task journal:337 blocked for more than 120 seconds

Hello all,

Anybody found this problem before? I kept hitting this issue for 2.6.31
guest kernel even with a simple network test.

INFO: task kjournal:337 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_sec" disables this
message.

kjournald	D 00000041	0	337	2 0x00000000

My test is totally being blocked.

Thanks
Shirley

On Wed, Sep 30, 2009 at 02:11:52PM -0700, Shirley Ma
wrote:
> Hello all,
> 
> Anybody found this problem before? I kept hitting this issue for 2.6.31
> guest kernel even with a simple network test.
> 
> INFO: task kjournal:337 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_sec" disables
this message.
> 
> kjournald	D 00000041	0	337	2 0x00000000
> 
> My test is totally being blocked.
I've hit this in the past with ext3, mounting with data=writeback made it
disappear.

On Thu, 2009-10-01 at 16:03 -0500, Javier Guerra wrote:
> deadline is the most recommended one for virtualization hosts.  some
> distros set it as default if you select Xen or KVM at installation
> time.  (and noop for the guests)
I spoke too earlier, after a while noop scheduler hit the same issue. I
am switching to deadline to test it again.

Thanks
Shirley

On 09/30/09 14:11, Shirley Ma wrote:
> Anybody found this problem before? I kept hitting this issue for 2.6.31
> guest kernel even with a simple network test.
>
> INFO: task kjournal:337 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_sec" disables
this message.
>
> kjournald	D 00000041	0	337	2 0x00000000
>
> My test is totally being blocked.
I'm assuming from the lists you've posted to that this is under KVM? 
What disk drivers are you using (virtio or emulated)?

Can you get a full stack backtrace of kjournald?

Kevin Bowling submitted a RH bug against Xen with apparently the same
symptoms (https://bugzilla.redhat.com/show_bug.cgi?id=526627).  I'm
wondering if there's a core kernel bug here, which is perhaps more
easily triggered by the changed timing in a virtual machine.

Thanks,
    J