[sane-devel] FreeBSD and Microtek Scanmaker II

[Nakal]

On Wednesday 18 June 2003 19:30, you wrote:

> 0) None of this generation of Microtek scanners supports SCSI
> disconnect. Disconnect needs to be disabled for the scanner device
> (if not the whole bus), and you should expect the scanner to
> monopolize the entire bus during a scan.

I really don't understand SCSI much. FreeBSD gives me still "unexpected 
disconnect" with my scanner, after I switched off "disconnection" in my 
controller's BIOS.

> 1) The firmware in the earlier Microtek scanners is particularly
> brain-dead with regards to timeouts like this.  Even worse, I have
> pretty extensive documentation from Microtek --- *but every scanner
> deviates from the documented behavior in some important way*.  Ugh.

Yes. It is a quite "cheap" scanner and came with a separate ISA SCSI-1 
controller. Now I'm using one with a Symantec chipset (Tekram 
DC390/UW). The scanner is attached to external UW bus. I wonder if it 
is really correct to connect it like this, but IT WORKED earlier (1 or 
2 years ago?) on Debian, so it should not be a problem.

> The Linux
> drivers are trying to be clever, but they assume that *every* device
> is SCSI-2, and since the codes do not conform to SCSI-2, they get
> squashed.
>
>    Probably, FreeBSD is doing the same thing.  What both OS's
> *should* do is just pass the poor sense codes up to the sense handler
> installed by the backend, which should be smart enough to deal with
> them.  Instead, the sense handler always gets called with a bunch of
> zeros!

Well, if I only had time to look at FreeBSD SCSI architecture, I would 
try to help. I wonder why they would remove information from the sense 
responses.

>     it is unclear which commands can be sent during that delay, if
> that delay can be polled (i.e. ask the scanner if it is ready) or if
> it must be guessed, etc, etc.

There is a possibility to compile the FreeBSD kernel with CAM debugging. 
This produces LOTS of information (see: man camcontrol(8)). With just a 
bit luck, there might be some useful information about the scanner's 
behavior.

> I'll start rummaging through my notes.  I'm recollecting now that I
> had a quick fix for this a couple of months ago --- but it was too
> late for the release back then, and then I got really really busy.

I don't know how many people are using old Microtek scanners. If it is 
too much trouble, simply forget it.

Martin