... >So the first thing that fails is the first scsi command being sent that >has the isWrite set to 0: > >[microtek] .get_scan_status 0... >[sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:6 isWrite:0 >[sanei_scsi] isRead dst_size:6 >[sanei_scsi] Executing command >[sanei_scsi] ExecuteTaskSync OK Trasferred 0 bytes >[microtek] get_scan_status(0): 0, 0, 0 -> #0 > >I would understand this better if this was a "read only" problem, but >this seems to be a "write only" problem, which doesn't make sense...
Has that "Multiple LUN" problem been ruled out yet? Perhaps the scanner is responding for some commands, but not for others. Another possible odd-ball issue is that this set of Microtek scanners does not use a SCSI-2 command set --- it's a variant of SCSI-1 with a lot of vendor-defined commands and completely non-standard sense codes. Perhaps the OS-X iokit is getting confused by that. (The linux scsi drivers have pretty much never returned the sense codes back to user-space without mangling them beyond recognition.) Another question: does the scanner ever start moving/making noises? The log snippets show that "start_scan" is received ok --- the scanner should start doing something after that. If not, maybe "start_scan" has not been received ok. Hmm... Quite possibly *none* of the commands (besides INQUIRY) have been received ok --- but the sense codes are being ignored, and the get_scan_status is the first command that is actually waiting for data to return from the scanner, hence the first one that hangs. -matt m.
