Michael van Elst a écrit :
> joel.bertrand%systella.fr@localhost (=?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.
I _believe_ that last output on console is iscsictl list_targets as
last information written on console, I'm not sure. Maybe kernel hangs in
iscsictl login.
> 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 ?
I haven't tried. I cannot disconnect these NAS this night. But both NAS
answer to ping requests, https and ssh. Network seems run as expected.
Both NAS are directly connected to server (each NAS is connected to a
dedicated interface, both NAS are on the same network as ethernet
interfaces are bridged).
Attachment:
signature.asc
Description: OpenPGP digital signature