OK, I could use some help on SCSI internals: *lot* of information 
on request.

where we've gotten to so far is that the scanner will respond to 
commands but doesn't acquire an image. Also, I noticed some dmesg 
stuff I hadn't seen before.

As noted the scanner does work in MacOS so I don't suspect 
cabling, but as Abel points out, Apple could have put some effort 
into making that idiot-proof.


-------- Original Message --------
Subject: Re: Some more information
Date: Fri, 22 Feb 2002 14:11:50 +0100
From: abel deuring <adeuring@gmx.net>
Reply-To: a.deuring@satzbau-gmbh.de
To: Oliver Rauch <oliver.rauch@rauch-domain.de>
CC: paul beard <paulbeard@mac.com>
References: <3C75E0B9.5020906@mac.com> 
<3C760BAB.116B43D3@rauch-domain.de>

Oliver Rauch wrote:
 >
 > paul beard wrote:
 > >
 > > I noticed these tidbits in dmesg as well . . . . esp0 is the bus
 > > where the scanner lives (by itself). This machines has two scsi
 > > busses . . . . why 1 is the internal and 0 the external makes no
 > > sense.
 > >
 > > It's an NCR controller as well: those seem to get high marks.
 > >
 > > esp0 at obio0 offset 0x10000 irq 12: NCR53C94, 25MHz, SCSI ID 7
 > > scsibus0 at esp0: 8 targets, 8 luns per target
 > >
 > > <dmesg>
 > > uk0 at scsibus0 target 2 lun 0: <UMAX, Astra 1200S, V2.7> SCSI2
 > > 6/scanner fixed
 > > uk0: unknown device
 > > esp0 at obio0 offset 0x10000 irq 12: NCR53C94, 25MHz, SCSI ID 7
 > > scsibus0 at esp0: 8 targets, 8 luns per target
 > > esp0: illegal command: 0xc2 (state 2, phase 3, prevphase 1)
 > > esp0: SCSI bus reset
 > > esp0: illegal command: 0xc2 (state 2, phase 3, prevphase 1)
 > > esp0: illegal command: 0xc2 (state 2, phase 3, prevphase 1)
 > > esp0: SCSI bus reset
 > > esp0: SCSI bus reset
 > > esp0: illegal command: 0xc2 (state 2, phase 3, prevphase 1)
 > > esp0: illegal command: 0xc2 (state 2, phase 3, prevphase 1)
 > > esp0: SCSI bus reset
 > > esp0: illegal command: 0xc2 (state 2, phase 3, prevphase 1)
 > > esp0: SCSI bus reset
 > > </dmesg>
 >
 > The umax backend does not use command 0xc2
 > May there be an other program that tries to access the scanner 
device
 > while sane-umax talks to the scanner?

This command 0xc2 looks really suspicious. It is a vendor specific
command, AFAIK, in Sane only the Canon backend uses such vendor 
specific
commands, and it is very unlikely that the Canon backend is actually
involved. And from the result of an INQUIRY this backend knows that it
does not support your scanner.

But the bus reset would explain, why scanning fails. If the reset 
occurs
while the Umax backend tries to scan, both the backend and the scanner
will be "confused": A READ command sent to a scanner immediately 
after a
reset will most likely not work.

 >
 > In the other debug output it looks like your system does not
 > support command queueing. Please edit 
/usr/local/etc/sane.d/umax.conf
 > and set the option maxqueue to 1:
 >
 >         option scsi-maxqueue 1
 >
 > and make sure that no other scsi-maxqueue command is in umax.conf

I don't think that this option is relevant for NetBSD. 
sanei_scsi.c uses
for NetBSD the sanei_scsi_req_enter variant at the end if the file,
which simply calls sanei_scsi_cmd2, i.e., we don't have any real
queueing, neither inside the kernel nor inside sanei_scsi.c. OTOH, it
can't be wrong to set the queue depth to 1.

But I noticed in the debug output from xsane that the wrong length 
byte
for the INQUIRY command is well reproducible: A "grep 'cdb: 12\|06 
08 02
02' xsane.out" shows that all INQUIRY commands with 5 byte data length
return 0 in byte 4, while all INQUIRYs with a larger data length 
return
the (probably correct) value 0x9c.

So it seems that there are a few issues with the SCSI system of your
machine.

A more general SCSI question: (I assume that the folks who adapted
NetBSD to the Apple hardware know this, but let us be sure ;) The 
reason
that Apple installs two SCSI busses in many of their computers is to
have a fast internal bus for the hard disks; this bus needs the usual
careful setup: proper cabling and termination; for the external bus
Apple managed to design the interface in an amazing "error-friendly"
way. I have seen several absolutely wrong setups working flawlessly,
like a 1.5 m cable at the end of the bus without a device and 
without a
terminator. This can only work for slow transfer speeds, so I 
wonder if
the NetBSD kernel really ensures that the speed of the external bus is
really 5 MHz. Do you see anything related messages with dmesg or 
in some
log files?

Abel