joel.bertr...@systella.fr (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) writes:
> I have tested and result is worse.
I have used that code for days without any ill effects.
> Kernel boots. Init starts iscsid and I believe my /etc/rc.d/iscsictl
>script is called :
> ${command} add_send_target -a 192.168.12.2:3260
> ${command} add_send_target -a 192.168.12.3:3260
> ${command} refresh_targets
> ${command} list_targets
> Kernel enters in hard lock after "${command} list_targets".
The command list_targets shouldn't do any iSCSI or network
operation. It just queries iscsid for the list and prints it.
refresh_targets connects to the iSCSI target and retrieves
the information.
The real iSCSI operations only start after you use "login"
to attach a SCSI device (sdX).
I start to doubt that this has anything to do with iSCSI.
Can you see if the lock already occurs after refresh_targets
(possibly waiting a little bit) ?
What does happen when you don't issue the iscsictl commands
but instead just do a network connection to 192.168.12.2:3260
with e.g. telnet or nc ?
