[sane-devel] sane weirdness + UMAX Astra 1220 S

[abel deuring]

Hubert Figuiere wrote:
> 
> On Thu, 2002-02-28 at 23:48, paul wrote:
> > sounds familiar . . .  if Abel is reading this, perhaps he can
> > supply you with some diagnostic patches in hopes of working out
> > how this wacky Apple hardware works.
> 
> The weird stuff is that cdrecord works nicely :-)
> 
> > Did you run this by any of the linux PPC lists or newsgroups?
> 
> Nope. I don't follow them.
> 
> BTW, I now have sane-find-scanner stuck in a loop, probably waiting for
> the bus to reset.
> Here is its output:
> # Note that sane-find-scanner will find any scanner that is connected
> # to a SCSI bus and some scanners that are connected to the Universal
> # Serial Bus (USB) depending on your OS. It will even find scanners
> # that are not supported at all by SANE. It won't find a scanner that
> # is connected to a parallel or proprietary port.
> 
> [sanei_debug] Setting debug level of sanei_scsi to 255.
> [sanei_debug] Setting debug level of sanei_scsi to 255.
> [sanei_scsi] sanei_scsi_find_devices: vendor=(null) model=(null)
> type=Scanner
>         bus=1 chan=0 id=4 lun=0  num=5
> [sanei_scsi] lx_chk_id: 1,0  0,0  4,0  0,0
> [sanei_scsi] lx_scan_sg: k=0, exclude=5, missed=0
> [sanei_scsi] lx_chk_id: 1,0  0,0  4,0  0,0
> [sanei_scsi] lx_scan_sg: k=1, exclude=5, missed=1
> [sanei_scsi] lx_chk_id: 1,0  0,0  4,5  0,0
> [sanei_scsi] lx_scan_sg: k=2, exclude=5, missed=1
> [sanei_scsi] lx_chk_id: 1,1  0,0  4,0  0,0
> [sanei_scsi] lx_scan_sg: k=3, exclude=5, missed=1
> [sanei_scsi] lx_chk_id: 1,1  0,0  4,2  0,0
> [sanei_scsi] lx_scan_sg: k=4, exclude=5, missed=1
> [sanei_scsi] lx_chk_id: 1,1  0,0  4,3  0,0
> [sanei_scsi] lx_scan_sg: k=5, exclude=5, missed=1
> [sanei_scsi] lx_scan_sg: k=6, exclude=5, missed=1
> [sanei_scsi] lx_chk_id: 1,1  0,0  4,6  0,0
> [sanei_scsi] lx_scan_sg: k=7, exclude=5, missed=1
> [sanei_scsi] lx_scan_sg: k=8, exclude=5, missed=2
> [sanei_scsi] lx_scan_sg: k=9, exclude=5, missed=3
> [sanei_scsi] lx_scan_sg: k=10, exclude=5, missed=4
> [sanei_debug] Setting debug level of sanei_scsi to 255.
> [sanei_scsi] sanei_scsi_open: sanei_scsi_max_request_size=131072 bytes
> [sanei_scsi] sanei_scsi_open: open of `/dev/scanner' failed: No such
> device or address
> [sanei_debug] Setting debug level of sanei_scsi to 255.
> [sanei_scsi] sanei_scsi_open: SG driver version: 20140
> [sanei_scsi] sanei_scsi_open_extended: using 131072 bytes as SCSI buffer
> [sanei_scsi] trying to enable low level command queueing
> [sanei_scsi] sanei_scsi_open: Host adapter queue depth: 3
> [sanei_scsi] sanei_scsi_open: SG driver can change buffer size at run
> time
> [sanei_scsi] sanei_scsi_open: low level command queueing enabled
> [sanei_scsi] scsi_req_enter: entered 0x30029008
> [sanei_scsi] sanei_scsi.issue: 0x30029008
> [sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 3
> [sanei_scsi] sanei_scsi_req_wait: waiting for 0x30029008
> [sanei_scsi] sanei_scsi.issue: 0x30029008
> [sanei_scsi] sanei_scsi_req_wait: read 41 bytes
> [sanei_scsi] scsi_req_enter: entered 0x30029008
> [sanei_scsi] sanei_scsi.issue: 0x30029008
> [sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 3
> [sanei_scsi] sanei_scsi_req_wait: waiting for 0x30029008
> [sanei_scsi] sanei_scsi.issue: 0x30029008
> [sanei_scsi] sanei_scsi_req_wait: read 200 bytes
> [sanei_debug] Setting debug level of sanei_scsi to 255.
> [sanei_scsi] sanei_scsi_open: SG driver version: 20140
> [sanei_scsi] sanei_scsi_open_extended: using 131072 bytes as SCSI buffer
> [sanei_scsi] trying to enable low level command queueing
> [sanei_scsi] sanei_scsi_open: Host adapter queue depth: 3
> [sanei_scsi] sanei_scsi_open: SG driver can change buffer size at run
> time
> [sanei_scsi] sanei_scsi_open: low level command queueing enabled
> [sanei_scsi] scsi_req_enter: entered 0x30029008
> [sanei_scsi] sanei_scsi.issue: 0x30029008
> [sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 3
> [sanei_scsi] sanei_scsi_req_wait: waiting for 0x30029008
> [sanei_scsi] sanei_scsi.issue: 0x30029008
> [sanei_scsi] sanei_scsi_req_wait: read 41 bytes
> [sanei_scsi] scsi_req_enter: entered 0x30029008
> [sanei_scsi] sanei_scsi.issue: 0x30029008
> [sanei_scsi] scsi_req_enter: queue_used: 1, queue_max: 3
> [sanei_scsi] sanei_scsi_req_wait: waiting for 0x30029008
> [sanei_scsi] sanei_scsi.issue: 0x30029008
> [sanei_scsi] sanei_scsi_req_wait: read 172 bytes
> [sanei_debug] Setting debug level of sanei_scsi to 255.
> [sanei_scsi] sanei_scsi_open: SG driver version: 20140
> [sanei_scsi] sanei_scsi_open_extended: using 131072 bytes as SCSI buffer
> [sanei_scsi] trying to enable low level command queueing
> [sanei_scsi] sanei_scsi_open: Host adapter queue depth: 1
> [sanei_scsi] sanei_scsi_open: SG driver can change buffer size at run
> time
> [sanei_scsi] scsi_req_enter: entered 0x30029008
> [sanei_scsi] sanei_scsi.issue: 0x30029008

Hubert,

This looks interesting. "sanei_scsi.issue" being the last line of the
debug output indeed indicates that a SCSI command is stuck somewhere
inside the kernel. In theory, sanei_scsi_issue should simply pass a SCSI
command to the SG driver, wich in turn should pass this command to the
SCSI mid-level and to the adapter driver (or, more precisely, to the
command queue of the adapter driver). And the call should return, before
the kernel "looks" for a the result of this command, since Linux
processes SCSI commands asynchronously.

So you may indeed be right that the kernel tries to reset the SCSI bus.
Do you see any related stuff in /var/log/messages?

BTW, what is the output from "cat /proc/scsi/scsi" ?

[note: I don't like what I'm writing below, because it sounds somewhat
"magic"] I remeber that a readme file from a more or less recent version
of Retrospect recommands not to use the SCSI ID 5 for certain Macs. I
can't remeber which models -- if my memory does not "cheat", there were
some cryptic remarks about a bug in the SCSI chip of these macs. So it
might be worth to try another ID.

Abel