Hi Allan, I compared scanimage and xsane logs, and I found a difference after "Reader task terminated".
It seems that scanimage has a problem closing the scanner. I removed scanned data in the log files for better reading. Hope this helps. Cheers, Rolf Am 08.08.2015 um 00:29 schrieb m. allan noah: > After a bit of searching, this looks like a bug in libusb-compat: > http://sourceforge.net/p/libusbx/mailman/libusbx-devel/thread/522af646.7060...@redhat.com/ > > allan > > On Fri, Aug 7, 2015 at 6:21 PM, m. allan noah <kitno...@gmail.com> wrote: >> Rolf- can you get a log of the scanimage and xsane shutdown sequences, >> and see if they call something in a different order? I had one report >> of this same error with the Fujitsu iX500, but I never reproduced. >> >> allan >> >> On Fri, Aug 7, 2015 at 5:40 PM, Rolf Bensch <r...@bensch-online.de> wrote: >>> Hello, >>> >>> I just fixed an usb communication problem with OpenSuse and the Pixma >>> backend. >>> >>> Scanning with xsane is working with my CS9000F scanner. But if I'm >>> scanning with scanimage, I always get this message at the end of each scan: >>> "libusb: warning [libusb_close] internal signalling read failed, closing >>> anyway" >>> >>> Then I need to terminate scanimage with 2x CTRL C. And sometimes the USB >>> bus is blocked for my scanner until I reboot the machine. The scanned >>> image is OK. >>> >>> I'm testing OpenSuse 13.2 in VirtualBox 5.0 on Ubuntu 14.04.1, both x86_64. >>> >>> Maybe you can give me a hint where to look to fix this issue or Allan >>> can fix this for me. I'm not very familiar with the usb library. >>> >>> Many thanks for your help. >>> >>> Cheers, >>> Rolf >>> >>> Am 04.08.2015 um 13:11 schrieb Johannes Meixner: >>>> >>>> Hello, >>>> >>>> On Aug 3 14:08 m. allan noah wrote (excerpt): >>>>> ... I know that Gentoo has some systemd compilation fixes. >>>> >>>> Everey Linux distribution should submit their patches to SANE >>>> upstream (provided their changes make sense for upstream). >>>> >>>> Here our (i.e. openSUSE) patches that we still have: >>>> >>>> >>>> 1) >>>> Right now I filed >>>> https://alioth.debian.org/tracker/index.php?group_id=30186&atid=410366 >>>> with my fix-buffer-overflow.patch attached >>>> that fixes a too small array in backend/niash.c >>>> >>>> >>>> 2) >>>> My re-add-SANE_CAP_ALWAYS_SETTABLE.patch re-adds SANE_CAP_ALWAYS_SETTABLE >>>> to sane.h which was erroneously removed in sane-backends-1.0.20 so that >>>> sane-frontends and xsane can no longer build, see >>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527675 >>>> >>>> re-add-SANE_CAP_ALWAYS_SETTABLE.patch >>>> ----------------------------------------------------------------------------- >>>> >>>> --- include/sane/sane.h.orig 2009-06-12 10:19:19.000000000 +0200 >>>> +++ include/sane/sane.h 2009-06-12 10:20:12.000000000 +0200 >>>> @@ -115,6 +115,7 @@ SANE_Device; >>>> #define SANE_CAP_AUTOMATIC (1 << 4) >>>> #define SANE_CAP_INACTIVE (1 << 5) >>>> #define SANE_CAP_ADVANCED (1 << 6) >>>> +#define SANE_CAP_ALWAYS_SETTABLE (1 << 7) >>>> >>>> #define SANE_OPTION_IS_ACTIVE(cap) (((cap) & SANE_CAP_INACTIVE) >>>> == 0) >>>> #define SANE_OPTION_IS_SETTABLE(cap) (((cap) & >>>> SANE_CAP_SOFT_SELECT) != 0) >>>> ----------------------------------------------------------------------------- >>>> >>>> >>>> The re-add-SANE_CAP_ALWAYS_SETTABLE.patch still applies for >>>> current sane-backends-git20150804.tar.gz so that I assume >>>> SANE_CAP_ALWAYS_SETTABLE is still missing in sane-backends. >>>> >>>> I did not verify whether or not meanwhile all SANE frontends >>>> also no longer use SANE_CAP_ALWAYS_SETTABLE so that it could >>>> meanwhile be really removed in sane-backends. >>>> >>>> >>>> 3) >>>> My fix-mustek_pp_ccd300.c.patch fixes undefined 'foo = ++foo modulo bar' >>>> operations in mustek_pp_ccd300.c see >>>> https://bugzilla.opensuse.org/show_bug.cgi?id=498435 >>>> and >>>> https://alioth.debian.org/tracker/index.php?func=detail&aid=311857&group_id=30186&atid=410366 >>>> where the upstream maintainer did not understand what is wrong and >>>> closed it as "Wont Fix" so that we must keep this patch forever >>>> to make at least the code somehow valid for the compiler. >>>> fix-mustek_pp_ccd300.c.patch is attached to the above >>>> alioth.debian.org bug tracker issue. >>>> Of course because the result of 'foo = ++foo' is undefined >>>> I cannot know if my patch implements what is actually intended. >>>> My patch implements an arbitrary result that only makes the >>>> compiler happy. >>>> >>>> >>>> 4) >>>> My install-umax_pp-tool.patch installs tools/umax_pp as /usr/bin/umax_pp >>>> which is built but not installed but it is needed to recover from >>>> a failed scan with scanners which use the umax_pp backend, see >>>> http://bugs.debian.org/496833 >>>> >>>> install-umax_pp-tool.patch >>>> -------------------------------------------------------------------- >>>> --- tools/Makefile.am.orig 2009-02-20 17:51:09.000000000 +0100 >>>> +++ tools/Makefile.am 2009-06-05 15:08:45.000000000 +0200 >>>> @@ -7,8 +7,8 @@ >>>> AM_CPPFLAGS = -I. -I$(srcdir) -I$(top_builddir)/include \ >>>> -I$(top_srcdir)/include >>>> >>>> -bin_PROGRAMS = sane-find-scanner gamma4scanimage >>>> -noinst_PROGRAMS = sane-desc umax_pp >>>> +bin_PROGRAMS = sane-find-scanner gamma4scanimage umax_pp >>>> +noinst_PROGRAMS = sane-desc >>>> >>>> if CROSS_COMPILING >>>> HOTPLUG = >>>> -------------------------------------------------------------------- >>>> >>>> The install-umax_pp-tool.patch still applies for current >>>> sane-backends-git20150804.tar.gz so that I assume >>>> tools/umax_pp is still not installed by default. >>>> >>>> >>>> >>>> In general regarding parallel port scanner drivers: >>>> >>>> The above issues 3) and 4) are about parallel port scanner drivers. >>>> >>>> I wonder if support for parallel port scanners is still needed? >>>> >>>> I assume that basically nobody tests parallel port scanners. >>>> Probably also basically nobody usues parallel port scanners. >>>> >>>> In this case parallel port scanner drivers should be dropped >>>> because in practice they are no longer maintained. >>>> >>>> As a first step parallel port scanner drivers could be >>>> no longer built by default e.g. via something like >>>> configure --without-parport >>>> by default. >>>> >>>> >>>> Kind Regards >>>> Johannes Meixner >>> >>> >> >> >> >> -- >> "well, I stand up next to a mountain- and I chop it down with the edge >> of my hand" > > >
logs.tar.gz
Description: application/gzip
-- sane-devel mailing list: sane-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org