I have a d script <http://blogs.sun.com/chrisg/entry/scsi_d_improvements>
that does this:
fbt:scsi:scsi_destroy_pkt:entry,
fbt:scsi:scsi_transport:entry
/ARGUMENT_TEST/
{
this->arg_test_passed = 1;
PRINT_TIMESTAMP();
PRINT_DEV_FROM_PKT(this->pkt);
printf("%s 0x%2.2x %9s address %2.2d:%2.2d, lba 0x%*.*x, ",
this->name,
this->cdb[0],
scsi_ops[(uint_t)this->cdb[0], this->sa] != 0 ?
scsi_ops[(uint_t)this->cdb[0], this->sa] : "Unknown",
this->pkt->pkt_address.a_target,
this->pkt->pkt_address.a_lun,
this->lbalen, this->lbalen,
this->lba);
printf("len 0x%6.6x, control 0x%2.2x timeout %d CDBP %p",
this->len, this->control,
this->pkt->pkt_time, this->cdb);
}
fbt:scsi:scsi_transport:entry
/this->arg_test_passed == 1/
{
printf(" %s(%d)", execname, pid);
}
The only place that "this->arg_test_passed" is set in in the probe
above yet occasionally and without any errors I get the printf from
"printf(" %s(%d)", execname, pid);"in the second probe but
none of the printf from the first probe. Clearly the probe is firing as
otherwise I would get nothing but the output has been lost.
Is there anyway to find out why?
--chris
This message posted from opensolaris.org
Hi Chris,
Let''s consider the following conditions:
1. scsi_transport:entry has fired
2. ARGUMENT_TEST (whatever it is) is false
Then the outcome would be:
1. this->arg_test_passed is uninitialized
2. It''s value in the second probe clause is unpredictable. (Unlike
globals and thread-locals, clause-locals are not automatically set
to zero)
Chip
Chris Gerhard wrote:> I have a d script
<http://blogs.sun.com/chrisg/entry/scsi_d_improvements> that does this:
>
> fbt:scsi:scsi_destroy_pkt:entry,
> fbt:scsi:scsi_transport:entry
> /ARGUMENT_TEST/
> {
> this->arg_test_passed = 1;
> PRINT_TIMESTAMP();
> PRINT_DEV_FROM_PKT(this->pkt);
> printf("%s 0x%2.2x %9s address %2.2d:%2.2d, lba 0x%*.*x, ",
> this->name,
> this->cdb[0],
> scsi_ops[(uint_t)this->cdb[0], this->sa] != 0 ?
> scsi_ops[(uint_t)this->cdb[0], this->sa] : "Unknown",
> this->pkt->pkt_address.a_target,
> this->pkt->pkt_address.a_lun,
> this->lbalen, this->lbalen,
> this->lba);
> printf("len 0x%6.6x, control 0x%2.2x timeout %d CDBP %p",
> this->len, this->control,
> this->pkt->pkt_time, this->cdb);
> }
>
>
> fbt:scsi:scsi_transport:entry
> /this->arg_test_passed == 1/
> {
> printf(" %s(%d)", execname, pid);
> }
>
> The only place that "this->arg_test_passed" is set in in the
probe above yet occasionally and without any errors I get the printf from
"printf(" %s(%d)", execname, pid);"in the second probe but
none of the printf from the first probe. Clearly the probe is firing as
otherwise I would get nothing but the output has been lost.
>
> Is there anyway to find out why?
>
> --chris
>
>
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>
Hi again Chris, I''m thinking a solution would be to have a third probe clause for scsi_transport:entry, that has a predicate with the opposite outcome of ARGUMENT_TEST, and sets this->arg_test_passed to 0; Chip Chris Gerhard wrote:> I have a d script <http://blogs.sun.com/chrisg/entry/scsi_d_improvements> that does this: > > fbt:scsi:scsi_destroy_pkt:entry, > fbt:scsi:scsi_transport:entry > /ARGUMENT_TEST/ > { > this->arg_test_passed = 1; > PRINT_TIMESTAMP(); > PRINT_DEV_FROM_PKT(this->pkt); > printf("%s 0x%2.2x %9s address %2.2d:%2.2d, lba 0x%*.*x, ", > this->name, > this->cdb[0], > scsi_ops[(uint_t)this->cdb[0], this->sa] != 0 ? > scsi_ops[(uint_t)this->cdb[0], this->sa] : "Unknown", > this->pkt->pkt_address.a_target, > this->pkt->pkt_address.a_lun, > this->lbalen, this->lbalen, > this->lba); > printf("len 0x%6.6x, control 0x%2.2x timeout %d CDBP %p", > this->len, this->control, > this->pkt->pkt_time, this->cdb); > } > > > fbt:scsi:scsi_transport:entry > /this->arg_test_passed == 1/ > { > printf(" %s(%d)", execname, pid); > } > > The only place that "this->arg_test_passed" is set in in the probe above yet occasionally and without any errors I get the printf from "printf(" %s(%d)", execname, pid);"in the second probe but none of the printf from the first probe. Clearly the probe is firing as otherwise I would get nothing but the output has been lost. > > Is there anyway to find out why? > > --chris > > > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >
Probe-local variable (this->foo) don''t necessarily start with a
value of 0
(as opposed to global and thread-local variables). You can solve this problem
by initializing this->arg_test_passed to 0 each time before performing the
argument test:
fbt:scsi:scsi_transport:entry
{
this->arg_test_passed = 0;
}
fbt:scsi:scsi_transport:entry
/ARGUMENT_TEST/
{
this->arg_test_passed = 1;
...
}
Adam
On Tue, Mar 13, 2007 at 12:13:14PM -0700, Chris Gerhard
wrote:> I have a d script
<http://blogs.sun.com/chrisg/entry/scsi_d_improvements> that does this:
>
> fbt:scsi:scsi_destroy_pkt:entry,
> fbt:scsi:scsi_transport:entry
> /ARGUMENT_TEST/
> {
> this->arg_test_passed = 1;
> PRINT_TIMESTAMP();
> PRINT_DEV_FROM_PKT(this->pkt);
> printf("%s 0x%2.2x %9s address %2.2d:%2.2d, lba 0x%*.*x, ",
> this->name,
> this->cdb[0],
> scsi_ops[(uint_t)this->cdb[0], this->sa] != 0 ?
> scsi_ops[(uint_t)this->cdb[0], this->sa] : "Unknown",
> this->pkt->pkt_address.a_target,
> this->pkt->pkt_address.a_lun,
> this->lbalen, this->lbalen,
> this->lba);
> printf("len 0x%6.6x, control 0x%2.2x timeout %d CDBP %p",
> this->len, this->control,
> this->pkt->pkt_time, this->cdb);
> }
>
>
> fbt:scsi:scsi_transport:entry
> /this->arg_test_passed == 1/
> {
> printf(" %s(%d)", execname, pid);
> }
>
> The only place that "this->arg_test_passed" is set in in the
probe above yet occasionally and without any errors I get the printf from
"printf(" %s(%d)", execname, pid);"in the second probe but
none of the printf from the first probe. Clearly the probe is firing as
otherwise I would get nothing but the output has been lost.
>
> Is there anyway to find out why?
>
> --chris
>
>
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
--
Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Chris,
FYI: Philosophical variations on a theme (forgiving the D pseudo-code):
----------------
probe
/ (not) test /
{
this->var = 0;
}
probe
/ test /
{
this->var = 1;
}
----------------
probe
{
this->var = 0;
}
probe
/ test /
{
this->var = 1;
}
----------------
probe
{
this->var = test ? 0 : 1;
}
----------------
Chip