Joerg Schilling wrote: > Alexander Motin <m...@freebsd.org> wrote: > >>> Compare the number of sense bytes I like to request (18) with the number >>> previous FreeBSD versions did actually request. It is obvious that in case >>> there is a resid reported onm an old kernel, libscg (with your chanhge) >>> would >>> believe that probably less that the absolute minumum of sense data is >>> available. >> Kernel code I have changed affects only controllers without automatic >> sense fetching. For such controllers CAM previously always reported zero >> sense_resid, independently of requested size (which actually was also >> ignored in this case). So previously whatever you asked for 18 or 32 >> bytes - sense_resid was always zero, like if you got full 18 or 32 >> bytes. That was wrong. Now, in the same situation, if device wants to >> return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid >> respectively, meaning 18 and 20 bytes of received sense. >> >> AFAIK sense_resid always measured from the requested sense_len. In my >> patch for libscg you may see that I have changed both request and >> response paths. Resulted sense_count should be absolutely the same. > > What is the requested size with the various HBAs in earlier kernels?
For HBAs with automatic sense fetching -- as passed in sence_len request field. In case of libscg it was SSD_FULL_SIZE before and I've set it to be real value now. Returned sense_resid should be real in both cases, respecting submitted sense_len. For HBAs without sense fetching, CAM was always requesting SSD_FULL_SIZE and returned fake zero sense_resid, like if it just completely fulfilled sense_len from request. Now it should start honor sense_len on request and return real sense_resid on reply, relative to sense_len. -- Alexander Motin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
