[sane-devel] Canoscan 2700f
Jonathan Knight wrote: Arrggh... I cannot believe it was something so stupid that caused by 2700F not to work. Okay. Here's what I did. I took Abel's advice. I put the sg module back to the default. I reset the default buffer size to the standard 32K and ran up sane 1.0.13. I duly collected the output and noted the error at the end [sanei_scsi] sanei_scsi_req_wait: read 64 bytes [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success [sanei_scsi] sense buffer: f0 00 44 00 00 00 00 06 00 00 00 00 60 00 00 00 [sanei_scsi] target status: 02 host status: driver status: 0008 [canon] sense_handler [canon] canon_sense_handler(3, 0x8055718, (nil)) [canon] sense buffer: f0 00 44 00 00 00 00 06 00 00 00 00 60 00 00 00 [canon] sense message: problem not analyzed (unknown SCSI class) A quick rumage on the net reveals that 44 is hardware error and 60 00 is lamp failure. I'd decoded this two days ago and ignored it because quite clearly the lamp was fine. Jonathan, firstly: great to hear that most of your problems are fixed now. The lack of really meanful error messages in Sane bother me since quite some time. Many SCSI scanners can return sense data similar the to that you mentioned (other errors I've seen or read about are fuse blown [ok, obviously not for every fuse ;)], location of paper jam, calibration error), but to only way Sane can reported them at present is via debug messages. Hopefully we can fix that with Sane version 2. That should save users a few gray hairs. I quickly followed up with scanimage -d 'canon:/dev/sg3' which bombed. H. Tried xsane which gave a segmentaion failure. Not to worry - I've got five versions of sane ready to test, lets see what the latest version is that works. I can now report that sane-1.0.11 now works perfectly with my 2700F with no messing with the SG module and a default buffer size of 32768. However 1.0.12 and 1.0.13 do not work so something funny happened there. Is anyone fixing the problem or shall I try to make ammends for my foolishness by trying to track down the bug? I think we don't don't need amends or apologies or whatever ;) But if you feel comfortable debugging Sane, go ahead ;) Anyway, I don't know that much about the Canon backend, but some other part of Sane may also have caused the crash. So, could you run scanimage or xsane under gdb, so that we can get clue, where the error occurs? (as usual, setting SANE_DEBUG_SANEI_SCSI and SANE_DEBUG_CANON is also useful.) cheers Abel
[sane-devel] CanoScan 2700F
If the latest Sane version crashes *after* doing the prescan and *before* doing the main scan, turn off the autofocus capability for the FS2700 in canon.c. This is a known problem, but I could not take care of it because I do not have a FS2700. But if you see this bug, you have already made a lot of progress. :-) Regards, Ulrich Deiters
[sane-devel] Canoscan 2700f
Hi everyone. I have a canoscan 2700F which has been the bain of my life on Linux since the day I bought it. It basically doesn't work at all unless you fiddle a number of things to get it working. I would like to make contact with other 2700F owners who have successfully got the canoscan to run on Redhat 9. I had the scanner running on redhat 9 until a recent up2date which patched the kernel and sane. Since then nothing worked. I've gone through my checklist of things that need to be fiddled with and all of those seem fine. The sense buffer that's returned for sane 1.0.12 gives a lamp failure. On 1.0.5 the process hangs when trying to preview or scan. For the record - here's the checklist I go through: 1. Make sure IRQ 10 is set for legacy ISA in the BIOS 2. echo 131072 /proc/scsi/sg/def_reserved_size 3. patch sg.c with the non-standard scsi command lengths 4. configure /etc/sane.d/canon.conf (I do smile when sane lists the 2700F driver status as good when in order to get it working you have to patch and recompile the kernel. Hardly something most users will consider an easy option) That list has managed to get the scanner to run under redhat 7 and 9 until now. If anyone has the scanner running under the latest redhat 9 kernel then I'd like to know what else needs changing to achieve that. I intend to try and older version of sg.c to see if that's the problem. -- __jonat...@cs.keele.ac.ukJonathan Knight, / Department of Computer Science / _ __ Telephone: +44 1782 583437 University of Keele, Keele, (_/ (_) / / Fax : +44 1782 713082 Staffordshire. ST5 5BG. U.K.
[sane-devel] Canoscan 2700f
Jonathan Knight wrote: Hi everyone. I have a canoscan 2700F which has been the bain of my life on Linux since the day I bought it. It basically doesn't work at all unless you fiddle a number of things to get it working. I would like to make contact with other 2700F owners who have successfully got the canoscan to run on Redhat 9. I had the scanner running on redhat 9 until a recent up2date which patched the kernel and sane. Since then nothing worked. I've gone through my checklist of things that need to be fiddled with and all of those seem fine. The sense buffer that's returned for sane 1.0.12 gives a lamp failure. On 1.0.5 the process hangs when trying to preview or scan. For the record - here's the checklist I go through: 1. Make sure IRQ 10 is set for legacy ISA in the BIOS So you have an ISA SCSI adapter? they may indeed be a bit difficult to configure. If this really bothers you, I'd recommend to buy a cheap PCI SCSI adapter. You can get good used one for a few Euro or Pound at Ebay. My personal favourites are adapters that work with the sym53c8xx driver or the aic7xxx driver. And with a PCI SCSI adapter, you'll be able to use SCSI transfer block sizes larger then 64kB. 2. echo 131072 /proc/scsi/sg/def_reserved_size A buffer size larger than 64k is not reasonable for ISA adapters, due to the broken ISA DMA architecture. Moreover, Sane negotiates the size of the buffer independly (OK, perhaps not in Sane 1.0.5 -- I'd need to look into the sources to be sure), but version 1.0.12 definitely does this. 3. patch sg.c with the non-standard scsi command lengths This patch is only necessary for really old SG drivers -- no need tor a recent Linux version like RH9. 4. configure /etc/sane.d/canon.conf (I do smile when sane lists the 2700F driver status as good when in order to get it working you have to patch and recompile the kernel. Hardly something most users will consider an easy option) As said above, it should not be necessary to recompile the SG driver since, ummm, I guess, at least 3 or 4 years. Can't recall, when exactly the SG driver (version 2.x) got the ability to explicitly set the command length, and when I made sanei_scsi.c aware of the capabilities of version 3 of the SG driver. That list has managed to get the scanner to run under redhat 7 and 9 until now. If anyone has the scanner running under the latest redhat 9 kernel then I'd like to know what else needs changing to achieve that. I intend to try and older version of sg.c to see if that's the problem. Alternatively, it would be intersting to see what exactly goes wrong with the unpatched SG driver. The output of SANE_DEBUG_CANON=255 SANE_DEBUG_SANEI_SCSI=255 scanimage (or the output some other Sane program with SANE_DEBUG_CANON and SANE_DEBUG_SANEI_SCSI set to 255) would give us a clue. Abel
[sane-devel] Canoscan 2700f
jonat...@cs.keele.ac.uk said: (I do smile when sane lists the 2700F driver status as good when in order to get it working you have to patch and recompile the kernel. Hardly something most users will consider an easy option) Generally speaking the driver status refers to the quality and comprehensiveness of the scanner driver. It does *not* refer to how easy it is to setup. As such it means in this instance that once setup your 2700F will function correctly giving good scans in all modes, and all or nearly all the features of the scanner supported. Most of your problems seem to stem from using an ancient and decrepit ISA SCSI card. I strongly suspect that if you where using a PCI SCSI card you would have a much easier time. JAB. -- Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk Northumberland, United Kingdom. Tel: +44 1661-832195
