[sane-devel] HP4c & Buslogic BT-958

[Troy M. Campbell]

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.

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. "

<<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.

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);


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.

Troy