paul beard wrote:
> 
> [sane-devel list cc:ed]
> 
> I'm working with the SANE folks to figure out why the scsi scanner
> on my 9500's external bus is so flaky. We have worked through some
> compiler issues (too much optimization was causing values to get
> munged) and some patches to how SANE probes the scanner itself.
> 
> The scanner can be identified and almost works: still no image
> acquisition and we're seeing some bus resets while scan commands
> are being sent, which hoses things up.
> 
> Now we're down to this: can anyone clarify?
> 
>  > 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?

To add my $0.02:

- If an INQUIRY command with 5 byte data length is sent to the scanner
(a Umax Astra 1200S), byte 4 of the data (additional length) is 0, while
it should be 0x9c. This bug breaks some logic in sane-find-scanner and
in the Umax backend, but it can be easily fixed. For larger INQUIRY data
lengths, byte 4 contains the correct value. Oliver Rauch, the maintainer
of Sane's Umax backend, is not aware of any related firmware bugs, so
this could be a hardware or a kernel issue.

- a 161 (== 0x9c+5) byte INQUIRY returns only 160 bytes; while this
should not do any harm in itself (only the maximum scan resolution
detected by Sane's Umax backend might be wrong), it looks suspicious.

- Paul saw in the dmesg output these error messages:

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

It is very unlikely that the SCSI command 0xc2 was issued by a Sane
program, since the Umax backend uses not vendor specific commands. So
the question is, which program or which part of the kernel might have
issued these commands?

Abel

PS: I'm not subscribed to the port-macppc list, so please cc answers to
me.