dtrace discuss - Jun 2008 - io:::wait-start -- invalid address

I''m trying to use the io:::wait-start and wait-done probes, and
according to the docs, args[1] points to a devinfo_t. When I try to
access e.g. args[1]->dev_minor or args[1]->dev_instance or dev_statname
from the io:::wait-start/done probe, then I get frequently [but not
always] errors like

    dtrace: error on enabled probe ID 247 (ID 58:
    io:genunix:biowait:wait-start): invalid address (0x0) in action #1
    at DIF offset 196

The dev_name always seems to be "nfs" when this happens [accessing
dev_name never failed with "invalid address"], although I have doubts,
whether the affected I/O requests are really NFS I/O requests [I rather
think these are disk I/Os]. I also introduced an

    ERROR
    {
        stack();
    }

probe in order to capture the stack when the error happens, and in most
error cases I got something like

                  0x133877c0
                  0x1402310
                  genunix`biowait+0x20
                  genunix`bwrite_common+0x1ac
                  ufs`bmap_write+0x9dc
                  ufs`wrip+0x448
                  ufs`ufs_write+0x580
                  genunix`fop_write+0x20
                  genunix`write+0x268
                  genunix`dtrace_systrace_syscall32+0xac
                  unix`syscall_trap32+0xcc

but also e.g.

                  0xebc50c0
                  0x1402310
                  genunix`biowait+0x20
                  scsi`scsi_uscsi_handle_cmd+0x20c
                  sd`sd_send_scsi_cmd+0x114
                  sd`sd_send_scsi_TEST_UNIT_READY+0x100
                  sd`sd_dkio_get_vtoc+0x6c
                  sd`sdioctl+0xbc0
                  genunix`fop_ioctl+0x20
                  genunix`ioctl+0x184
                  genunix`dtrace_systrace_syscall32+0xac
                  unix`syscall_trap32+0xcc

or

                  0x114de840
                  0x1402310
                  genunix`biowait+0x20
                  scsi`scsi_uscsi_handle_cmd+0x20c
                  sd`sd_send_scsi_cmd+0x114
                  sd`sd_send_scsi_TEST_UNIT_READY+0x100
                  sd`sd_dkio_get_geometry+0x4c
                  sd`sdioctl+0xb54
                  genunix`fop_ioctl+0x20
                 
    cl_quorum`__1cZquorum_ioctl_with_retries6FpnFvnode_ilpi_i_+0x28
                  cl_quorum`__1cWquorum_scsi_get_sblkno6FpnFvnode_rL_i_+0x4c
                 
    cl_quorum`__1cbFquorum_disk_initialize_reserved6FpnFvnode_rL_i_+0x8c
                  0x7b72f2a4
                 
    cl_quorum`__1cVquorum_algorithm_implbAprocess_device_quorum_info6M_v_+0x20c
                 
   
cl_quorum`__1cVquorum_algorithm_implWinitialize_quorum_info6MrnTquorum_table_struct__v_+0x568
                 
   
cl_quorum`__1cVquorum_algorithm_implUquorum_table_updated6MrnFCORBALEnvironment__v_+0x330
                 
   
cl_haci`__1cZclconf_infr_callback_implKdid_update6MpkcnDccrPccr_update_type_rnFCORBALEnvironment__v_+0x108
                 
    cl_haci`__1cMtable_accessPcall_did_update6MpcnDccrPccr_update_type__v_+0xb8
                 
    cl_haci`__1cTupdatable_copy_implGunlock6MrnFCORBALEnvironment__v_+0xec
                 
    cl_haci`__1cQtable_trans_implNunlock_copies6MrnFCORBALEnvironment__v_+0x4c

or

                  0x135650c0
                  0x1402310
                  genunix`biowait+0x20
                  genunix`bwrite_common+0x1ac
                  ufs`ufs_sbwrite+0x108
                  ufs`ufs_trans_sbwrite+0x8c
                  ufs`ufs_checkclean+0x1e8
                  ufs`ufs_update+0x290
                  ufs`ufs_sync+0x2c
                  genunix`vfs_sync+0x98
                  genunix`syssync+0x4
                  genunix`dtrace_systrace_syscall32+0xac
                  unix`syscall_trap32+0xcc


Am I doing anything wrong or might this be a bug in the devinfo_t
translators? Is it illegal to access dev_minor, dev_instance,... from
these probes?

Thanks,
Gerhard