Hi!
On Sun, Jan 13, 2019 at 12:27:19PM +0100, Tom Bachreier wrote: > Last night I got a "blocked for more than 300 seconds." message in syslog - > see <https://paste.debian.net/1060134/ <https://paste.debian.net/1060134/>> > (link valid for 90 days). > > Log summary: > Jan 13 02:34:44 osprey kernel: [969696.242745] INFO: task md127_raid5:238 > blocked for more than 300 seconds. > Jan 13 02:34:44 osprey kernel: [969696.242772] Call Trace: > Jan 13 02:34:44 osprey kernel: [969696.242789] ? __schedule+0x2a2/0x870 > Jan 13 02:34:44 osprey kernel: [969696.242995] INFO: task dmcrypt_write:904 > blocked for more than 300 seconds. > Jan 13 02:34:44 osprey kernel: [969696.243223] INFO: task jbd2/dm-2-8:917 > blocked for more than 300 seconds. > Jan 13 02:34:44 osprey kernel: [969696.243525] INFO: task mpc:6622 blocked > for more than 300 seconds. > Jan 13 02:34:44 osprey kernel: [969696.243997] INFO: task kworker/u8:0:6625 > blocked for more than 300 seconds. I am occasionally having very similar issues with my RAID1, task blocking for more than 120 seconds, for no obvious reason. I've started playing around with the vm.dirty_background_ratio and vm.dirty_ratio kernel parameters, suspecting file system caching being slow and the issue. [1] While lowering the values does seem to have helped, it has not completely eliminated the issue. So the jury for me is still out. > In this case I did a > $ fdisk -l /dev/sdf > and everything worked again. Not sure if/how this would interact with ongoing cache flushing. Jens [1] https://www.blackmoreops.com/2014/09/22/linux-kernel-panic-issue-fix-hung_task_timeout_secs-blocked-120-seconds-problem/
