When the kernel crashes, I'll be able to retrieve this buffer from the dump
Should none of the dump triggers work, then just watch it and trigger it yourself.
# echo c > /proc/sysrq-trigger
The hung multipath -v0 processes are usually spawned on behalf of udev events.
Before you begin the test, please record the current dm map (dmsetup table -v)
and the output of (lsscsi -lv) so I have a point of reference. Thanks.
hmm, try this.
kernel. panic_on_ oops = 0 softlockup_ panic = 0 unknown_ nmi_panic = 0 panic_on_ unrecovered_ nmi = 0 panic_on_ io_nmi = 0 hung_task_ panic = 0
kernel.
kernel.
kernel.
kernel.
kernel.
Make sure these are all set to 1 in /etc/sysctl.conf and then run sysctl -p
Also, lets configure ftrace, see if we get lucky and can catch the deadlock
as it happens.
[as root] debug/tracing
cd /sys/kernel/
echo function > current_tracer
echo 16000 > buffer_size_kb
echo "scsi_*" >> set_ftrace_filter
echo "fc_*" >> set_ftrace_filter
When the kernel crashes, I'll be able to retrieve this buffer from the dump
Should none of the dump triggers work, then just watch it and trigger it yourself.
# echo c > /proc/sysrq-trigger
The hung multipath -v0 processes are usually spawned on behalf of udev events.
Before you begin the test, please record the current dm map (dmsetup table -v)
and the output of (lsscsi -lv) so I have a point of reference. Thanks.