[sane-devel] HP4c & Buslogic BT-958

[abel deuring]

"Troy M. Campbell" wrote:
> 
> I don't know who to send this to or if it will help so please ignore this if
> it should go somewhere else or give me a hint as to whom to send it.
> 
> The general concensus seems to be  that the BT driver for Linux 2.4.x
> may be at fault but the driver hasn't change since the 2.1.x kernel.

Well, since nobody could yet find the cause of the problem, we can't be
sure ;) But Ray Curtis and Steve Lembark reported exactly the same
problem as you -- and they could both successfully use their HP scanners
with the aic7xxx driver. Moreover, James Klaas wrote about problems
using a Umax scanner with the Buslogic driver.

I asked Leonard Zubkoff, the maintainer of the Buslogic driver, to have
a look at the problem, but it seems that could not yet find the time to
do it.

> On digging around in the kernel-traffic site I found this from Linus Torvalds
> on 8-Mar-2001 in reference to 2.4.3:
> -------------------------------------------
> "....There are no actual BusLogic controller changes in the current 2.4.3-pre
> kernels at all, so there's something else going on.
> ......the only other SCSI change (apart from a lot of spelling fixes in
> comments etc) is some trivial error handling, like changing
> scsi_test_unit_ready to not have a result buffer (because it doesn't have a
> result except for the regular sense buffer). Which again certainly shouldn't
> be able to matter at all. "

The SCSI mid-layer had some changes between lk 2.2 and lk 2.4; this
might be part of the poblem.

> 
> <<http://kt.zork.net/kernel-traffic/kt20010316_111.html>>
> --------------------------------------------
> The "scsi_test_unit_ready" reminded me of a [SANE- DEVEL] post:
> 
> >>[sanei_debug] Setting debug level of hp to 255.
> >>[hp] sane_init called
> >>[hp] sane_init will finish with Success
> >>[hp] sane_get_devices called
> >>[hp] hp_read_config: hp backend v0.94 starts reading config file
> >>[hp] hp_read_config: processing line </dev/scanner>
> >>[hp] hp_read_config: processing line <option connect-scsi>
> >>[hp] hp_read_config: processing line <option disable-scsi-request>
> >>[hp] hp_read_config: attach /dev/scanner
> >>[hp] hp_get_dev: New device /dev/scanner, connect-scsi, scsi-request=0
> >>[hp] sanei_hp_device_new: /dev/scanner
> >>[hp] scsi_inquire: sending INQUIRE
> >>[hp] scsi_new: sending TEST_UNIT_READY
> >>[hp] scsi_flush: writing 2 bytes:
> >>[hp]  0x0000  1B 45                                            .E
> >>[hp] scsi_flush: writing 7 bytes:
> >>[hp]  0x0000  1B 2A 73 32 35 37 45                             .*s257E
> >>[hp] scl_inq: read failed (Error during device I/O)
> >>[hp] scl_errcheck: Can't read SCL error stack: Error during device I/O
> >>[hp] sanei_hp_device_new: SCL reset failed
> >>[hp] scsi_close: closing fd 4
> >>[hp] sane_get_devices will finish with Success
> >>scanimage: no SANE devices found
> >>[hp] sane_exit called
> >>[hp] sane_exit will finish
> 
> The TEST_UNIT_READY is where things start failing.  I "diff"ed
> scsi_error.c  in 2.4.17 and 2.2.19.

I don't think so. After TEST UNIT READY, two WRITE commands are sent to
the scanner ("scsi_flush: writing 2 bytes" / "scsi_flush: writing 7
bytes"), and the next command, a READ fails ("scl_inq: read failed").

> 
> In regards to TEST_UNIT_READY,
> 
> 2.4.x looks like:
>         SCpnt->request_buffer = NULL;
>         SCpnt->request_bufflen = 0;
>         SCpnt->use_sg = 0;
>         SCpnt->cmd_len = COMMAND_SIZE(SCpnt->cmnd[0]);
>         SCpnt->underflow = 0;
>         SCpnt->sc_data_direction = SCSI_DATA_NONE;
>         scsi_send_eh_cmnd(SCpnt, SENSE_TIMEOUT);
> 
> 2.2.x looks like
>         SCpnt->request_buffer = scsi_result;
>         SCpnt->request_bufflen = 256;
>         SCpnt->use_sg = 0;
>         SCpnt->cmd_len = COMMAND_SIZE(SCpnt->cmnd[0]);
>         scsi_send_eh_cmnd (SCpnt, SENSE_TIMEOUT);

The should not matter, because TEST UNIT READY should not read or write
any data; only the SCSI status byte is returned by the device. 

> 
> I don't know enough about sane.i to know what its looking for
> but if it is looking for a buffer of info from TEST_UNIT_READY, it
> clearly won't be getting it from 2.4.x scsi .
> 
> Tell me to go away if I'm out in left field someplace.

No, it's OK to write on this list ;)

Abel