"isert: isert_setup_id: rdma_bind_addr() failed: -19" spam, followed by Recursive Fault on reboot
Hello
I'm trying (failing) to get iSER working. After rebooting with some settings saved in targetcli, I got an endless stream of messages like this:
[ 192.701299] isert: isert_setup_id: rdma_bind_addr() failed: -19 [ 192.702733] isert: isert_setup_id: rdma_bind_addr() failed: -19 [ 192.704021] isert: isert_setup_id: rdma_bind_addr() failed: -19 [ 192.705458] isert: isert_setup_id: rdma_bind_addr() failed: -19 [ 192.706979] isert: isert_setup_id: rdma_bind_addr() failed: -19
I tried deleting everything from targetcli, but the flood would not stop. The ib_isert module did not unload. When rebooting I got a "Recursive Fault" with a stacktrace inside configfs.
I hope this is enough information to fix this bug. I assumed the stacktrace would be saved to the log so I didn't write it down, and I haven't been able to retrace all the wrong stuff I did trying to make iSER work.
Linux Version: Linux 4.8.15-2~bpo8+2 (Debian 8 Backports)
--
Stevie Trujillo
Quoted 2 lines
Hello
Hey Steve,
Quoted 8 lines
I'm trying (failing) to get iSER working. After rebooting with some settings saved in targetcli, I got an endless stream of messages like this:
[ 192.701299] isert: isert_setup_id: rdma_bind_addr() failed: -19 [ 192.702733] isert: isert_setup_id: rdma_bind_addr() failed: -19 [ 192.704021] isert: isert_setup_id: rdma_bind_addr() failed: -19 [ 192.705458] isert: isert_setup_id: rdma_bind_addr() failed: -19 [ 192.706979] isert: isert_setup_id: rdma_bind_addr() failed: -19
You get -ENODEV errors because you don't have an RDMA device. This is probably due to the fact that the mlx5_ib (or mlx4_ib, depending on your device) is not loaded.
Can you try loading mlx[4|5]_ib module before you enable iser on a network portal?
I do see that mlx5 and mlx4 are requesting the mlx_ib module at probe time, I wander how that didn't happen on your system..
I didn't see a endless loop of this error? can you share your targetcli json?
Quoted 9 lines
I tried deleting everything from targetcli, but the flood would not stop. The
ib_isertmodule did not unload. When rebooting I got a "Recursive Fault" with a stacktrace inside configfs.I hope this is enough information to fix this bug. I assumed the stacktrace would be saved to the log so I didn't write it down, and I haven't been able to retrace all the wrong stuff I did trying to make iSER work.
Linux Version: Linux 4.8.15-2~bpo8+2 (Debian 8 Backports)
Would it be possible to try with upstream kernel and report what you are seeing?
On Sun, 29 Jan 2017 09:39:39 +0200
Sagi Grimberg <[email protected]> wrote:
Hello, thank you very much for your help. I'm very sorry but I think I've made too many changes to my system to recreate the problem. I tried recreating my targtetcli config and downgrading linux+userspace+firmware to the versions I used when it broke, but never got this problem again :(
Quoted 32 lines
Quoted 9 lines
I'm trying (failing) to get iSER working. After rebooting with some settings saved in targetcli, I got an endless stream of messages like this:
[ 192.701299] isert: isert_setup_id: rdma_bind_addr() failed: -19 [ 192.702733] isert: isert_setup_id: rdma_bind_addr() failed: -19 [ 192.704021] isert: isert_setup_id: rdma_bind_addr() failed: -19 [ 192.705458] isert: isert_setup_id: rdma_bind_addr() failed: -19 [ 192.706979] isert: isert_setup_id: rdma_bind_addr() failed: -19You get
-ENODEVerrors because you don't have an RDMA device. This is probably due to the fact that themlx5_ib(ormlx4_ib, depending on your device) is not loaded.Can you try loading mlx[4|5]_ib module before you enable iser on a network portal?
I do see that mlx5 and mlx4 are requesting the
mlx_ibmodule at probe time, I wander how that didn't happen on your system..I didn't see a endless loop of this error? can you share your targetcli json?
Quoted 9 lines
I tried deleting everything from targetcli, but the flood would not stop. The
ib_isertmodule did not unload. When rebooting I got a "Recursive Fault" with a stacktrace inside configfs.I hope this is enough information to fix this bug. I assumed the stacktrace would be saved to the log so I didn't write it down, and I haven't been able to retrace all the wrong stuff I did trying to make iSER work.
Quoted 4 lines
Quoted 1 line
Linux Version: Linux 4.8.15-2~bpo8+2 (Debian 8 Backports)
Would it be possible to try with upstream kernel and report what you are seeing?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html