On 1/2/25 9:30 PM, bugzilla-daemon@xxxxxxxxxx wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=219652 > > --- Comment #10 from Alan Stern (stern@xxxxxxxxxxxxxxxxxxx) --- > Re comment #8: I would like to know the answers to the questions asked in > comment #4 about the bad kernel: > > In sd_read_capacity(), does sd_try_rc16_first() return true? > > And why doesn't the "Very big device. Trying to use READ CAPACITY(16)" line,> along with the subsequent call to read_capacity_16(), get executed in the bad > kernel? I see it. With the new code we think the command is failing. We then retry the command 3 times like you described you saw in the trace. Then because on the 3rd retry we get 0xfffffffe instead of 0xffffffff, we don't hit the check below like I mentioned before: sector_size = read_capacity_10(sdkp, sdp, buffer); if (sector_size == -EOVERFLOW) goto got_data; if (sector_size < 0) return; if ((sizeof(sdkp->capacity) > 4) && (sdkp->capacity > 0xffffffffULL)) { int old_sector_size = sector_size; sd_printk(KERN_NOTICE, sdkp, "Very big device. " "Trying to use READ CAPACITY(16).\n"); sector_size = read_capacity_16(sdkp, sdp, lim, buffer); With the old kernel, we saw the first try succeed. We then saw the 0xffffffff and then tried read_capacity_16 above. And the reason for the difference was that with the new code, I forgot to add a check for if there was even an error. We ended up always retrying 3 times and that lead us to get the 0xfffffffe value on that last retry. so we need: diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index adee6f60c966..2dcf225c7017 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -210,6 +210,9 @@ static int scsi_check_passthrough(struct scsi_cmnd *scmd, struct scsi_sense_hdr sshdr; enum sam_status status; + if (!scmd->result) + return 0; + if (!failures) return 0;
