On Wed, Apr 19, 2017 at 06:36:00PM +0200, Michael Weissenbacher wrote: > On 19.04.2017 16:04, Carlos Maiolino wrote: > > If I am not blind, the task currently owning the cpu isn't listed there, which I > > suppose to be already running. > Correct, the only process utilizing the CPU is xfsaild. It is also the > only process doing I/O, and it looks like it's doing only reads. It > (xfsaild) never shows up in dmesg as blocked. > A snippet of tracepoint output from the fs might also be interesting when you hit this state. E.g., 'trace-cmd start -e xfs:*' and save the output of /sys/kernel/debug/tracing/trace_pipe to a file for a few seconds or so. > > Next time you hit it, could you please paste the stack trace of the task owning > > the cpu? Which I suppose to be xfsaild according to your report. > > > > A simple `cat /proc/<pid>/stack` is probably enough > Sure, will do. BTW, is the original /proc/meminfo output you posted from the system in a normal state or when the problem occurs? If the former, could you include it while the problem occurs as well? Brian > > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
