ahh.. so i think i've found the culprit behind the short reads

so this was the unexpected read of a 512-byte block on a 4k device you were trying to hunt down?

i think so

the sequence makes sense with the other scsi commands being sent

eh, thats nice find.

i'm going to try grabbing the block size from the device-blksize property (falling back to DEV_BSIZE) and use READ(10)

since I think we can safely pay any performance penalty on that read on anyone crazy enough to multi-path with parallel SCSI (if that's even possible)

(AFAICT, using the smallest CDB for READ/WRITE was to improve parallel SCSI performance)

i'd be skeptical if it makes a difference with SAS or FC

annoyingly though, the scsi standards don't say exactly when READ(6) was deprecated

danmcd: I know you said you're not around much, but your mlxcx change seems to have just caused a panic if you've got some time

Yeah, I'd think that on anything modern you're dealing with cache-line-ish chunks between host memory and adapter and 6 vs 10 vs .. is in the noise for command movement..

trying to read the backstory I found a note in a 2005 T10 doc which basically pleaded with people to migrate away from 6

uh, do we actually have parallel scsi HBA support?

if you have an ancient enough HBA, i suppose so

Yeah... jbk --> we need to loosen the VERIFY in mlxcx_explore_pcam() to be a if (!mlxcx_cmd_access_regseter()) return

because CX-4 doesn't have PCAM, I'm guessing.

Also, there's an ASSERT(c->mlc_pcam) that MIGHT just become the if (!c->mlc_pcam) return; we need.

SOrry for not having CX-4 to test, and good catch. If you've customers getting bitten, you can hotpatch an immediate return in the VERIFY() codepath instead of calling assfail().

(back to vacation...)

right now this is just a lab box

i'm in the middle of verifying a fix for a more critical issue w/ it and hit that (i just backed it out for now on my test branch)

but once that's resolved, I could probably work w/ you to test/diag/etc

if you have the availability

it has both cx-4 and cx-5 cards

so might be a nice test

i think there's some other boxes w/ cx-6 as well

@jbk --> illumos.org/issues/16129

→ BUG 16129: mlxcx_explore_pcam() in mlxcx(4D) doesn't play nice with ConnectX-4 parts anymore (New)

Weird.

I just noticed the caller of mlxcx_explore_pcam() doesn't go there unless the mlcap_general_flags_c (unsupported on CX-4?) reports PCAM is present.

unfortunately, it happens before a dump device is there

Try modifying the VERIFY() to be a return-if-false instead. That should make your CX-4 not regress, but still be good for CX-5 & CX-6.

Oh yeah.

so it means just kmdb on the console

But the fix is around the VERIFY(); if you can compile and replace you're okay too,.

(SERIOUSLY, back to vacation now.)

yeah, that pcam bit is not defined in cx-4

(I'll update the ticket)