Tracing scsi commands with dtrace / wrong ctf data on S-x86?

Question

This is probably a bug, either in the kernel's CTF symbol information, or in dtrace:
I'm trying to trace scsi commands in the Solaris 10 b63 x86 kernel with dtrace, including any request sense
data received for failed scsi commands.
I've noticed that my D script (included below) prints bogus "sense key" values on S10_b63 (x86),
when the "es_key" member from a "struct scsi_extended_sense" is printed (see the
<sys/scsi/generic/sense.h> header file).
For example, when the first three bytes of a "struct scsi_extended_sense" are filled with the bytes
0x70, 0x00, 0x05, printing scb->sts_sensedata.es_key gives the output "1" instead of the expected "5".
Example:
dtrace: script 'scsi2.d' matched 3 probes
CPU     ID                    FUNCTION:NAME
  0  16099             scsi_transport:entry 46 02 00 00 00 00 00 00 08 00
  0  16387                     sdintr:entry state 37, reason 0, t/ms 2, to/s 5, arq sk/asc/ascq 1 20 0The user level command that has send the "0x46" scsi GET CONFIGURATION command via an USCSI
ioctl prints the correct correct sense data ("5 20 0"):
get configuration: scsi command failed with status illegal request, invalid command operation code (sk/asc/ascq 5 20 00)Here's my D script:
#!/usr/sbin/dtrace -s
fbt::scsi_transport:entry
        pkt = (struct scsi_pkt *)arg0;
        cdb = pkt->pkt_cdbp;
        printf("%02x %02x %02x %02x %02x %02x %02x %02x %02x %02x",
                cdb[0], cdb[1], cdb[2], cdb[3], cdb[4],
                cdb[5], cdb[6], cdb[7], cdb[8], cdb[9]);
        this->start_time = timestamp;
fbt::sdintr:entry
        tim = (timestamp - this->start_time) / 1000000;
        pkt = (struct scsi_pkt *)arg0;
        scb = (struct scsi_arq_status *)pkt->pkt_scbp;
        printf("state %x, reason %x, t/ms %d, to/s %d, %sarq sk/asc/ascq %x %x %x",
                pkt->pkt_state, pkt->pkt_reason, tim, pkt->pkt_time,
                pkt->pkt_state & 0x20 ? "" : "no ",
                pkt->pkt_state & 0x20 ? scb->sts_sensedata.es_key : 0,              /* <<<<<<<<< */
                pkt->pkt_state & 0x20 ? scb->sts_sensedata.es_add_code : 0,
                pkt->pkt_state & 0x20 ? scb->sts_sensedata.es_qual_code : 0);

Answer 1

This is indeed a bug: thanks for finding it and sorry for the trouble. There is an issue with
the way the D compiler is trying to decode bit-fields of length greater than one byte on x86,
of which es_key is such a bit-field. We'll get a bug filed on this for you and get it fixed.
-Mike