Re: Notes on kern/57133

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  Following up on this thread, I have more diagnostic output.  

The problem occurs when a call to scsipi_get_opcodeinfo() is made for a device.  By the time
the request hits the adapter, as shown in the below output, the discrepancy between xs->resid
and xs->datalen has already occurred.  I can see where xs->resid is set equal to xs->datalen in
scsipi_execute_xs(), but I haven't found where xs->resid gets zeroed out before it makes it to
the mpii(4) driver.  Clearly I'm missing something, so I'll keep looking.  I don't think it's
corruption or a threading problem, but, rather, something that's different about this
particular request path. One change I can try is to put the diagnostic printf higher in the
scsipi_request function, in case all the loading of data into the IOC's ccb buffers is
corrupting something.
In the mean time, if anyone has ideas, I'm all ears.

-thanks
-Brian


The below output is a snippet from the probing of sd0 on mpii0.
See the e-mail in kern/57133 for a full dmesg output on this card.


[  10.5750642] sd0: tagged queueing
[  10.7650647] mpii0(scsipi_request): resid = 0, datalen = 16384
[  10.7750642] mpii0(scsipi_request): SCSI command info is: 0xa3 0c 80 00 00 00 00 00 40 00 00 00
[  10.7750642] mpii0(scsipi_request): sx_control = 0x1020, XS_CTL_POLL = 0x2
[  10.7850642] mpii0: resid = 0, datalen = 16384
[  10.7950642] mpii0: SCSI command info is: 0xa3 0c 80 00 00 00 00 00 40 00 00 00