Xin LI wrote:
> Try procstat -kk 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 d
-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
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 would be very helpful.
(the second -k is not a typo).
# procstat -k -k 5896
PIDTID COMM TDNAME KSTACK
5896 102364 iscontrol-
> > If you can get it back into this state,
>
> Sure, *every* time.
>
> > a procstat -k -k 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
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 would be very helpful.
> (the second -k is not a typo).
# procstat -k -k 5896
PIDTID COMM TDNAME KSTACK
58
On Wed, Nov 23, 2011 at 7:26 PM, 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.
If you can get it back into this state, a procstat -k -k
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 (unsucce
