On Sun, 2005-07-10 at 11:58 -0400, Ben Collins wrote:
> I didn't see that the scsi code made a distinction here. I thought it did
> the conversion for all devices if use_10_for_{rw,ms} was set, and did the
> fallback when it got ILLEGAL_REQUEST. Is there something in there that
> will disable use_10_for_{rw,ms} if it's not TYPE_RBC?
It doesn't. As you say, the flags are universal for the device,
whatever the ULD is. However, as you also say, if MS_10 fails with
ILLEGAL_REQUEST we do fall back to MS_6.
> Ok, I see something different in the MODE_SENSE:
[...]
> Looking the pre TYPE_RBC code, I can see that the modepage change wasn't
> there, so sure enough we were using 8. Could this cause an
> ILLEGAL_REQUEST, and thus disable use_10_for_{rw,ms}?
Yes, that was the core of the bug Al was fixing. sd has been requesting
caching data for a while now. However, for RBC devices it was probing
the wrong mode page and failing. After the changes we actually get the
correct caching data.
> I'm starting to understand some of the code paths here. So before all of
> this, TYPE_RBC was not recognized by the scsi layer as a "disk" type
> device (which is why sbp2 forced TYPE_DISK for TYPE_RDC devices when
> commands passed into the scsi layer).
Exactly, but trying to pretend they were true TYPE_DISK was also causing
issues (most notably the cache problem).
James
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
