Bug 14235
Summary: | SRP initiator lockup | ||
---|---|---|---|
Product: | Drivers | Reporter: | Bart Van Assche (bvanassche) |
Component: | Infiniband/RDMA | Assignee: | drivers_infiniband-rdma |
Status: | RESOLVED WILL_NOT_FIX | ||
Severity: | high | ||
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | Subsystem: | ||
Regression: | No | Bisected commit-id: |
Description
Bart Van Assche
2009-09-26 14:54:34 UTC
Once an SRP initiator system is in the state described above, killing fio and performing an SRP logout and login doesn't help -- SRP I/O remains impossible. Furthermore, rebooting the system with the reboot command isn't possible anymore -- the initiator system has to be reset or power cycled to get it working again. Once the initiator system is in this state, I see ever increasing values of zero_req_lim: # cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host7/scsi_host/host7/zero_req_lim 4129 # cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host7/scsi_host/host7/zero_req_lim 4177 And ftrace reveals the following: # cd /sys/kernel/debug/tracing # cat available_filter_functions |grep -E '^scsi_|^__scsi|^wait_for_completion|^srp|^__srp' >set_ftrace_filter # echo >trace # cat trace [...] 0) 2.657 us | scsi_request_fn(); 0) 3.476 us | scsi_request_fn(); 0) 3.232 us | scsi_request_fn(); 0) 2.741 us | scsi_request_fn(); 0) 2.675 us | scsi_request_fn(); 0) | scsi_request_fn() { 0) | scsi_dispatch_cmd() { 0) 0.481 us | scsi_log_send(); 0) 0.449 us | srp_queuecommand(); 0) | scsi_queue_insert() { 0) | __scsi_queue_insert() { 0) 1.077 us | scsi_device_unbusy(); 0) | scsi_run_queue() { 0) 1.984 us | scsi_request_fn(); 0) 3.671 us | } 0) 6.633 us | } 0) 7.489 us | } 0) + 10.727 us | } 0) + 13.366 us | } [...] After some discussion on the linux-rdma mailing list it has been agreed that a workaround will be implemented in the SCST target such that SCST-SRPT does no longer trigger the initiator lockup. Note: this workaround is available in SCST r1473. |