Re: iSCSI initiator: iscontrol cannot be stopped or killed

2011-12-05 Thread Mark Martinec
Xin LI wrote:
 Try procstat -kk pid to find the calling stack, as a start?
 This could be very useful when tracking down problems.
 Also the 'D' flag from ps(1) output in most times are not quite useful
 and ps -o wchan would tell you what exactly it was waiting for, just FYI.

Posted both a few days ago, you must have missed it.

Ivan Voras wrote:
 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.

Done, posted to freebsd-scsi@ mailing list.
Thanks for the suggestion.

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


Re: iSCSI initiator: iscontrol cannot be stopped or killed

2011-11-28 Thread Ivan Voras

On 24/11/2011 18:06, Mark Martinec wrote:

If you can get it back into this state,


Sure, *every* time.


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


# procstat -k -k 5896
   PIDTID 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 NIVSZRSS MWCHAN STAT  TT TIME COMMAND
 0  5896 1   0  20  0  16424   1264 ffpDs??  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.



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: iSCSI initiator: iscontrol cannot be stopped or killed

2011-11-28 Thread Xin LI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/23/11 16:26, Mark Martinec wrote:
 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.

Try procstat -kk pid to find the calling stack, as a start?  This
could be very useful when tracking down problems.

Also the 'D' flag from ps(1) output in most times are not quite useful
and ps -o wchan would tell you what exactly it was waiting for, just FYI.

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJO1BXMAAoJEATO+BI/yjfBd2AIAJW1xHR93fN5eROUz9rs1YiX
8ANhcPTLmScN04YJb65ytm/BYUVKAtUN/rct2seZPosHO+REvYJhF7Tz5DKRRHJX
h+LG65S3HNBR9GBLdadw5BusbvU+T18oTvrxnqPtB1vcn5pEvQk0xtw3M3R/PrIu
V45mACO0f51auQl8oHfTUKzY48k06eDszyQhlrGCbY1FTydUU2e8AqJKd6GEIx31
f6kd0WGTpcIam6WdONpTR08d2HoPp/zK0gUADW+S2NiKfzDCy/PvJL+02lK2YlEy
M6dvnk62X6Tfkv1SV947WZT57UMDZkXbVNgwjvxwT5tSKUUbeGGvm241ZnLN2HI=
=IZ2x
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: iSCSI initiator: iscontrol cannot be stopped or killed

2011-11-24 Thread Mark Martinec
  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
   PIDTID 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 NIVSZRSS MWCHAN STAT  TT TIME COMMAND
0  5896 1   0  20  0  16424   1264 ffpDs??  0:00.04 
iscontrol -c /etc/iscsi.conf -n xxx


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


iSCSI initiator: iscontrol cannot be stopped or killed

2011-11-23 Thread Mark Martinec
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: iSCSI initiator: iscontrol cannot be stopped or killed

2011-11-23 Thread Ryan Stone
On Wed, Nov 23, 2011 at 7:26 PM, Mark Martinec
mark.martinec+free...@ijs.si wrote:
 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.

If you can get it back into this state, a procstat -k -k iscontrol
pid would be very helpful.
(the second -k is not a typo).
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: iSCSI initiator: iscontrol cannot be stopped or killed

2011-11-23 Thread Mark Martinec
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
  PIDTID 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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org