Three proposals
Warner Losh <[email protected]> Wed, 26 Feb 2025 14:17:08 -0700
| Newsgroups | gmane.os.freebsd.devel.scsi |
|---|---|
| Message-ID | <CANCZdfotu_AANc9VN70CTQGSeivZ48ytqYc0uPAgBTUU714x+Q@mail.gmail.com> |
--00000000000044f8f3062f12198a Content-Type: text/plain; charset="UTF-8" Greetings, I've been looking at all the quirks and was thinking of doing the following to cope: (1) Do a MODE SENSE for page 8 and only do the SYNCHRONIZE CACHE if the WCE bit is enabled. From my readings and searching of the standard, this is the only time we need it. Most of the drives that have the SYNC CACHE quirk that I have I can't set that to '1' anyway (and it defaults to 0 on them). Also, convert all the SIMs that intercept SYNC CACHE and just have them fail it. da can now cope with the failure and will never send it again once it fails. By avoiding SYNC CACHE here (and maybe other) circumstances, we avoid a huge number of drives that just go out to lunch when it is issued. (2) Stop generating READ(6) and WRITE(6). I'll keep the workaround for that, but also expand it to READ(10) and WRITE(10) since Universal Flash Filesystem apparently doesn't support them. But eliminating generating READ(6) etc will also help us work by default better. The reason to try to minimize CDB length (limited CDB buffer) is long since gone. (3) Add detection for bogus INQUIRY + EVPD replies and auto-quirk not sending them. This likely needs to be in XPT not DA. Maybe with an exception for serial number (since the umass SIM handles this well, maybe we have a similar rule for other SIMs). This may not help a lot, but might also be a good hint for when NOT to send SYNC CACHE. I've noticed several of the da devices that I have that have the NO_SYNC_CACHE quirk also do this and generally only understand a super-duper restricted set of commands (not RBC, something even smaller) and maybe we can gently probe this condition to allow us to avoid trouble on drives that implement too little of the subset... Comments? Warner --00000000000044f8f3062f12198a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Greetings,<div><br></div><div>I've been looking at all= the quirks and was thinking of doing the following to cope:</div><div><br>= </div><div>(1) Do a MODE SENSE for page 8 and only do the SYNCHRONIZE CACHE= if the WCE bit is enabled. From my readings and searching=C2=A0of the stan= dard, this is the only time we need it. Most of the drives that have the SY= NC CACHE quirk that I have I can't set that to '1' anyway (and = it defaults to 0 on them). Also, convert all the SIMs that intercept SYNC C= ACHE and just have them fail it. da can now cope with the failure and will = never send it again once it fails. By avoiding SYNC CACHE here (and maybe o= ther) circumstances, we avoid a huge number of drives that just go out to l= unch when it is issued.</div><div><br></div><div>(2) Stop generating READ(6= ) and WRITE(6). I'll keep the workaround for that, but also expand it t= o READ(10) and WRITE(10) since Universal Flash Filesystem apparently doesn&= #39;t support them.=C2=A0 But eliminating generating READ(6) etc will also = help us work by default better. The reason to try to minimize CDB length=C2= =A0(limited CDB buffer) is long since gone.</div><div><br></div><div>(3) Ad= d detection for bogus INQUIRY=C2=A0+ EVPD replies and auto-quirk not sendin= g them. This likely needs to be in XPT not DA. Maybe with an exception for = serial number (since the umass SIM handles this well, maybe we have a simil= ar rule for other SIMs). This may not help a lot, but might also be a good = hint for when NOT to send SYNC CACHE. I've noticed several of the da de= vices that I have that have the NO_SYNC_CACHE quirk also do this and genera= lly only understand a super-duper restricted set of commands (not RBC, some= thing even smaller) and maybe we can gently probe this condition to allow u= s to avoid trouble on drives that implement too little of the subset...<br>= <br>Comments?</div><div><br></div><div>Warner</div></div> --00000000000044f8f3062f12198a--