iSCSI initiator: iscontrol cannot be stopped or killed

27 views
Skip to first unread message

Mark Martinec

unread,
Nov 23, 2011, 7:26:21 PM11/23/11
to freebsd...@freebsd.org
Problem: the iscontrol process starts normally and establishes
a session and brings up a device, but it cannot be stopped.
It does not react to a HUP signal, and neither to KILL.

The /dev/da0 device is operational and the remote disk remains
normally accessible, regardless of how I try to (unsuccessfully)
shutdown the iscontrol process. The ps reports the state of the
process as "Ds", not doing anything. A ktrace does not show any
reaction to a received signal. A restart seems to be necessary
to break the iSCSI session.

Using FreeBSD 9.0-rc2, amd64, also tried with 9.0-PRERELEASE
(csup tag=RELENG_9 as of today). This used to work normally
as documented on the same host with the same iscsi.conf
config file before upgrading from 8.2 to 9.0.

Anybody else experiencing this problem? Suggestions welcome.

Mark
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

Mark Martinec

unread,
Nov 23, 2011, 8:25:48 PM11/23/11
to freebsd...@freebsd.org
On Thursday November 24 2011 01:35:28 Ryan Stone wrote:
> If you can get it back into this state,

Sure, *every* time.

> a procstat -k -k <iscontrol pid> would be very helpful.
> (the second -k is not a typo).

# procstat -k -k 5896
PID TID COMM TDNAME KSTACK
5896 102364 iscontrol - mi_switch+0x174 sleepq_timedwait+0x42 _sleep+0x301 ic_init+0x2f1
iscsi_ioctl+0x525 devfs_ioctl_f+0x7b kern_ioctl+0x115 sys_ioctl+0xfd amd64_syscall+0x450 Xfast_syscall+0xf7


Thanks

Mark Martinec

unread,
Nov 24, 2011, 12:06:32 PM11/24/11
to freebsd...@freebsd.org
> > If you can get it back into this state,
>
> Sure, *every* time.
>
> > a procstat -k -k <iscontrol pid> would be very helpful.
> > (the second -k is not a typo).
>
> # procstat -k -k 5896
> PID TID COMM TDNAME KSTACK
> 5896 102364 iscontrol - mi_switch+0x174
> sleepq_timedwait+0x42 _sleep+0x301 ic_init+0x2f1 iscsi_ioctl+0x525
> devfs_ioctl_f+0x7b kern_ioctl+0x115 sys_ioctl+0xfd amd64_syscall+0x450
> Xfast_syscall+0xf7

Additional info: the process is blocking on 'ffp', unresponsive to signals:

UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
0 5896 1 0 20 0 16424 1264 ffp Ds ?? 0:00.04 iscontrol -c /etc/iscsi.conf -n xxx

Ivan Voras

unread,
Nov 28, 2011, 7:23:58 AM11/28/11
to freebsd...@freebsd.org
On 24/11/2011 18:06, Mark Martinec wrote:
>>> If you can get it back into this state,
>>
>> Sure, *every* time.
>>
>>> a procstat -k -k<iscontrol pid> would be very helpful.
>>> (the second -k is not a typo).
>>
>> # procstat -k -k 5896
>> PID TID COMM TDNAME KSTACK
>> 5896 102364 iscontrol - mi_switch+0x174
>> sleepq_timedwait+0x42 _sleep+0x301 ic_init+0x2f1 iscsi_ioctl+0x525
>> devfs_ioctl_f+0x7b kern_ioctl+0x115 sys_ioctl+0xfd amd64_syscall+0x450
>> Xfast_syscall+0xf7
>
> Additional info: the process is blocking on 'ffp', unresponsive to signals:
>
> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
> 0 5896 1 0 20 0 16424 1264 ffp Ds ?? 0:00.04 iscontrol -c /etc/iscsi.conf -n xxx
>

You should probably ask at the freebsd-scsi@ mailing list. From looking
at the code it looks like "ffp" is used for LUN scan timeout.

Reply all
Reply to author
Forward
0 new messages