[sane-devel] Umax Astra 2400S w/ AEC-6712D hanging

[abel deuring]

DN Dunham wrote:

>> Yes, the Linux atp870u driver has/had a bug, which appears only for a 
>> few SCSI commands, so the scanner is at first recognzed, but some Sane 
>> backends issue commands that raise the bug. Some time ago, I tried to 
>> find a maintainer for this driver to report the bug and a fix, but 
>> there does not seem to exist any maintainer... So I suspect that the 
>> bug exists even in recent kernels.
>>
>> IIRC, fixing the bug was easy, it just requires to change 2 or 3 
>> source code lines. So you could recompile the atp870u driver. I you 
>> want to do that, let me know -- I'll search old emails to find the 
>> fix. But if you have never before compiled a Linux kernel, that might 
>> be a small adventure ;)
>>
> 
> I would be interested in learning what needs to be changed, if you have 
> the time to go through some e-mails for me. While I have compiled a 
> Linux kernel before, it was for a class rather than my own machine so it 
> would be a small adventure - provided a driver recompile would require 
> that I also recompile the kernel. I guess I need to get used to it 
> eventually.

Well, things look a bit more complicated than I expected:

I found the mails about the bug: The problem was that the atp870u driver 
set the data length for the INQUIRY command to a maximum of 0x24 bytes, 
which is too small for many scanners, including Umax scanners. But 
looking into the sources of the 2.4.18 kernel, it seems that this bug is 
meanwhile fixed. (A SCSI device responds to the INQUIRY command by 
returning information about itself, like device and model name, vendor 
name, device type etc. While the meaning of the first 0x24 bytes 
standardized, manufacturers are free to append non-standard data. For 
scanners, this can be things like the size of scan area, available scan 
resolution and so on.) But I think that I found another bug. Line 768 ff 
from atp870u.c:

/*
  *      Check transfer direction
  */
if ((dev->ata_cdbu[0] == WRITE_6) || (dev->ata_cdbu[0] == WRITE_10) ||
     (dev->ata_cdbu[0] == WRITE_12) || (dev->ata_cdbu[0] == 
MODE_SELECT)) {ev->ata_cdbu[0] == WRITE_10)
         outb((unsigned char) (j | 0x20), tmport++);
} else {
         outb(j, tmport++);
}

So it seems that the driver assumes that only the commands WRITE_6 
(0x0a), WRITE_10 (0x2a), WRITE_12 (0xaa) and MODE_SELECT (0x15) send 
data to a SCSI device.

Now, after a quick glimpse into the sources of the Umax backend I think 
that the backend uses the SCSI command codes 0 and 0x21 to upload gamma 
tables to the scanner (Oliver, can you confirm this?), but the atp870u 
driver will never send this data to the scanner. (there may be more 
non-SCSI-standard commands that send data to the scanner -- I'm too lazy 
to search for them...)

Assuming that my guess is right, the atp870u driver would need another 
bugfix -- but fixing this bug would require a level of comprehension of 
the internals of the Linux SCSI system which I do not have :(

A simple workaround would _perhaps_ be to add

	|| (dev->ata_cdbu[0] == 0x21) || (dev->ata_cdbu[0] == 0)

to the if expression, but especially the "== 0" part might have some 
side effects. 0 is the command TEST_UNIT_READY. I don't know, if or how 
this patch affects "regular" TEST_UNIT_READY command (with no data to be 
read or written).

If Oliver confirms that the Umax backend issues some "unusual" SCSI 
commands which write data to the scanner, it would probably be best to 
consult the Linux SCSI specialists on their mailing list.

> After checking out other options (such as the recompile and seeing what 
> Mr. Rauch might be able to tell me from the debug output I sent to the 
> list). Thanks for your assistance.

seems that I missed this mail. The debug output might actually give 
another hint, if my guess about the cause of the problem is correct: 
could you send it to me?

Abel