[sane-devel] Problem with sane-1.0.9, PPC, ScanJet 4C

Peter Kirchgessner peter@kirchgessner.net
Sun, 08 Dec 2002 10:48:28 +0100

Hi Keith,

at first please check that all the sources of the backend are build 
completely. Remove all hp*.o and hp*.lo-files from the backend directory 
and build it again. The log file tells that an assertion failed at line 
3501 of hp-option.c. But with v1.01 it should be at line 3515.
But this will not solve all the problems.
It seems that there is a problem with the SCSI communication on PPC.
With backend V0.96 or V1.01 without option dumb-read, the backend 
sometimes does not get the complete response from the scanner. The 
backend tries to read 16 bytes from the scanner with sanei_scsi_cmd. The 
function returns with no error. But the returned data is missing the 
last byte of the response. This gives the debug message "malformed 
response". Maybe this is a timing problem. To check this, add to 
hp-scl.c at line 740 an usleep (10000):

--- hp-scl.c.orig       Fri Dec  6 20:38:59 2002
+++ hp-scl.c    Sun Dec  8 10:42:27 2002
@@ -737,7 +737,7 @@
        read_cmd[2] = *len >> 16;
        read_cmd[3] = *len >> 8;
        read_cmd[4] = *len;
+usleep (10000);
        RETURN_IF_FAIL( sanei_scsi_cmd (this->fd, read_cmd,
                                        sizeof(read_cmd), dest, len) );

Build the backend and try it again without option dumb-read. Tell me 



Keith Clayton schrieb:
> Hi Peter,
> Thanks for taking a look at this.  If you need anything else let me
> know.  I'll be happy to test anything or dig into things a bit deeper
> for you if needed.
> Cheers,
> Keith
> On Sat, 2002-12-07 at 11:34, Peter Kirchgessner wrote:
>>Hi Keith,
>>gzip it and send it to me.
>>Keith Clayton schrieb:
>>>Hi all,
>>>I just recently was given an HP scanjet 4c and I'm trying to get it
>>>working with my system.  So far no luck.  I guess most obivious is that
>>>it was known to be working on Win98 before I got it .. so
>>>I'm running Linux 2.4.19 on a PPC machine.  Compiled SANE-1.0.9 from
>>>source using gcc-3.2.1 . . compilation was fine, uneventful.
>>>SCSI generic is compiled into the kernel and the scanner is recognized
>>>at boot time as /dev/sgc.  I have an internal scsi cd-rw drive that is
>>>working fine with cdrecord (uses scsi-generic) and an old external
>>>syquest which are both working fine also so SCSI looks ok.
>>>Here's my output from cat /proc/scsi/scsi
>>>Attached devices:
>>>Host: scsi0 Channel: 00 Id: 00 Lun: 00
>>>  Vendor: YAMAHA   Model: CRW4416S         Rev: 1.0h
>>>  Type:   CD-ROM                           ANSI SCSI revision: 02
>>>Host: scsi0 Channel: 00 Id: 01 Lun: 00
>>>  Vendor: SyQuest  Model: EZ135S           Rev: 1_12
>>>  Type:   Direct-Access                    ANSI SCSI revision: 02
>>>Host: scsi0 Channel: 00 Id: 02 Lun: 00
>>>  Vendor: HP       Model: C2520A           Rev: 3503
>>>  Type:   Processor                        ANSI SCSI revision: 02
>>>I've created a symlink from /dev/scanner to /dev/sgc and when I run
>>>sane-find-scanner, it sees an HP C2520A at /dev/sgc, /dev/sg2 and
>>>/dev/scanner.  So far so good.
>>>When I run scanimage -L however, no scanners are found.  Note: for
>>>testing right now, I'm running as root and I checked the permissions of
>>>/dev/sgc just to be sure (0660)
>>>I searched the mail archives and couldn't find any recent issues with
>>>PPC and the HP backend so I went to the faq.  Found the HP faq and
>>>looked at that.  Mentioned device i/o errors with certain scsi cards and
>>>mentioned upgrading the HP backend to v1.0.1
>>>So, first I ran SANE_DEBUG_HP=255 scanimage -L with the old backend
>>>(v0.96 IIRC) and captured the output then I upgraded to v1.0.1. 
>>>Recompiled just find but
>>>That one dumped core on me with an error
>>>scanimage: hp-option.c:3501: sanei_hp_optset_scanmode: Assertion `mode'
>>>when I ran scanimage -L.  
>>>I ran SANE_DEBUG_HP=255 scanimage -L with that backend and captured that
>>>output as well.
>>>With each backend, it appears that sane and my HP4C are talking but that
>>>SANE is getting unexpected responeses (endian problems?)
>>>So, I'm not sure where to go with this.  I don't know myself what the
>>>communication "should" look like.
>>>I'd be happy to post my debug output though it's rather lengthy.  I
>>>figured it'd be better to send it off list to anyone who could make
>>>sense of it.
>>>Thanks for any help anyone can give

Peter Kirchgessner