*** Bug 559724 has been marked as a duplicate of this bug. ***

First, please install latest version from http://download.opensuse.org/repositories/hardware/

It should be based on libusb-1.0.6 and libusb-compat-0.1.3.

Please be patient packages, latest packages are not yet built.

If it starts to work we are done.

If not:

Please try the same with libusb0 and libusb-compat library version. But don't use standard library builds, but install special debug versions from these OSC repositories:

http://download.opensuse.org/repositories/hardware:/libusb0:/debug/
http://download.opensuse.org/repositories/hardware:/debug/

(Again wait for latest versions above.)

Then set USB_DEBUG=255 variable:
export USB_DEBUG=255
and run your scanning application, redirecting output to file.

Repeat the same session with old and compat library and attach results.

Then it may be possible to find a difference in libusb-1.0 or libusb-compat.

To be exact: To get a complete debug log, you have to replace both libraries by those from the debug repository:

libusb-0_1-4
and/or
libusb-1_0-0

Different settings are working:

standard libusb-1 works only with downgrading libusb-0 to this one:

http://download.opensuse.org/repositories/hardware:/libusb0/openSUSE_11.2/i586/libusb-0_1-4-0.1.12-140.1.i586.rpm

libusb-1 (1.0.6)from d.o.o/repos/hardware/ 

works with all teste libusb-o versions:

libusb-0 (0.1.12) hardware:/libusb0
libusb-0 (0.1.13-2.2) standard
libusb-0 (0.1.13-14.2) hardware

Can anybody confirm this?
Then please send libusb-1 from hardware to official 11.2update repo.

Daniel

For my case (MFC-8440, x86-64), still only the combinations with libusb-0 (0.1.12)
work reliably:
I tried the combinations:
libusb-1 (1.0.6) from d.o.o/repos/hardware/ 
libusb-1 (1.0.4) from standard

Sorry, I hit the commit button too early...

If I try the combination from d.o.o/repos/hardware/, i.e.

libusb-1_0-0-1.0.6-8.1.x86_64.rpm
libusb-0_1-4-0.1.13-14.2.x86_64.rpm:

the situation is a bit better than with the rpms from standard 11.2:
Small resolutions (like 200dpi, black) ususally work (but not always)

Higher resulutions and/or color still often lead to failures,
usually graceful with "sane_read: Error during device I/O".
Sometimes the scanner simply stop, I need 

The following command (600dpi+colour) still ALWAYS fails:
scanimage --resolution 600 > /tmp/dummy

So I still think it might be a failure of libusb-compat.

(I also tried a self-compile linux-2..6.32rc6, the only difference is that here /ar/log/messages told me "usbfs: usb_submit_urb returned -121" a few times)

To both reporters:

Please provide your debug logs as described in comment 2 (one with libusb0, one with the latest libusb1+libusb-compat). Without it, debugging cannot be done.

Important: I need both libusb0 and libusb1 logs.


To get an insight:

There are two principially different libusb-0_1-4 versions.

libusb-0_1-4-0.1.12 (known as libusb0): This is an old historic version used in old openSUSE versions. This library works stand-alone. Your application was probably developed and tested with it.

libusb-0_1-4-0.1.13 (known as libusb-compat): This is a new version. It is only a translation layer, that converts old libusb0 calls to libusb1 calls. This version cannot work stand-alone. It always needs libusb-1_0-0 (known as libusb1).

Most problems of libusb-0_1-4-0.1.13 come from the compatibility emulation layer, but the problem may be also caused by an incompatibility of the new libusb1 with your harware. That is why you need to update both for purpose of testing.

To norbert müller: If your application works with libusb0, kernel change does not help. This is a problem of libusb. Error -121 is EREMOTEIO Remote I/O error:

From /usr/src/linux/Documentation/usb/error-codes.txt:

-EREMOTEIO              The data read from the endpoint did not fill the
                        specified buffer, and URB_SHORT_NOT_OK was set in
                        urb->transfer_flags.

This error may be related to the emulation behavior.

Created attachment 331230 [details]
Debug using libusb-1_0-0-1.0.6-10.1.x86_64.rpm and libusb-0_1-4-0.1.13-16.2.x86_64.rpm

Teh file was produced using
scanimage > /dev/null 2> debug-0.1.13neu

The scanner stops after line 2788 of the debug file has been written.
I had to stop the scanning programm (scanimage: received signal 2)

Created attachment 331233 [details]
Debug using libusb-0_1-4-0.1.12-142.1.x86_64.rpm

I could not find a debugging version of libusb-1.0.0-1.0.4..., only the libusb-1_0-0-1.0.6-10.1.x86_64.rpm. But strangely, the debugging output is very short. So it is essentially useless...

It was produced using  libusb-0_1-4-0.1.12-142.1.x86_64.rpm and 1_0-0-1.0.6-10.1.x86_64.rpm, with 
export USB_DEBUG=255
scanimage > scan-0.1.12 > debug-0.1.12

How can I produce a more useful output?

Thanks. The first log is exactly what I needed in this step.

Did scanner start to scan in comment 8?

The log contain surprisingly many successfully ignored errors. Could you try the same as previous once again, but don't log the output to file, but use a syslog? It would be useful to know exact time stamp for each line logged. I guess that

scanimage 2>&1 | logger

should do it. Then cut relevant part from /var/log/messages.

The log seems to be very repetitive and time stamps for each line would make better image what is standard behavior and what is error.

Debugging version of libusb0 should be available here:

http://download.opensuse.org/repositories/hardware:/libusb0:/debug/openSUSE_11.2/

I found brscan-0.2.4 on Brother web pages. It is an Open Source application, so I can check the code there as well. It seems that brscan is able to create its own log. Could you provide this log as well (for both libusb0 and libusb1+compat)?

Same problem is reported here:

http://www.linux-club.de/viewtopic.php?f=60&t=106361&p=660328#p660325

we should also test this new brscan 0.2.5. Or ask if this ne driver is build against new libusb.

Daniel

Regarding comment 6, kernel change:

Upgrade from kernel 2.6.31.x to 2.6.32* _does_ mean change:

Linux 2.6.32 adds support for a bulk continuation URB flag. this should be set on all URBs in the transfer except the first. also set the SHORT_NOT_OK flag on all of them, to raise error conditions on short transfers.

Looking at the log, it may be possible that the driver depends on incomplete multi-part bulk reads. Let's wait for the libusb0 debug log.

Please let me know, which kernel you used for making logs you attach. If there will be any need, we can try to switch betweel 2.6.31 and 2.6.32.


Regarding comment 12 - build against new libusb:

No, it is not possible to build the driver against new libusb. New libusb require rewrite of USB code.

Such rewrite would be possibly smaller and more error-proff, but the rewrite is not a topic for this bug.

This bug solution requires improvement of libusb-compat (+libusb1) behavior to behave more exactly like libusb0. If it will be done, original driver should start to work again.

It will possibly fix other driver for different devices. We must do it anyway - there are too many proprietary programs, that depend on exact behavior of libusb0. We should emulate it as good as possible.

Created attachment 331449 [details]
log message of scans with debug

I now tried logging the debug messages. Here I did the following:

I started an "xscanimage 2>&1 | logger". This has the advantage that I could wait a few seconds between starting the program and starting the scan itself.

(1) Timestamps from 21:44:31 to 21:44:33 belong to the initialization of xsanimage (finding the scanner etc.)

(2) Timestamps from 21:44:48 to 21:45:02 belong to a (successfull) scan (200dpi, b/w). The scanner did not have to stop during this scan, so all data was transferred in one "bulk".

(3) Timestamps from 21:45:22 to 21:45:31 belong to an unsuccessfull scan (200dpi, colour). 

(I was able to do successfull b/w scans immediately after the colour scan, so after the I7O error the connection is still OK.)

Usually the scanner works as follows: It starts to scan a small portion of the scan area, then moves back a bit, then scans the next portion etc. In this case, the scan ended before moving back for the first or second time (the behaviour differs). So the problem might be connected to timeouts in the transmission. 

I fear that the is not much more information in this log than in the other attachments.

BTW: I tried to get more debugging output from xsaneimage, but failed. I was also unable to compile brscan2.4 on my machine. Furthermore I could not find brscan2.5. The only thing that I still could try would be to test a new kernel, but that would maybe not be very helpfull. 

Any further ideas how I could help you to find the problem?

Created attachment 331450 [details]
log messages of a large b/w scan, with delays but without I/O error

I just tried several b/w scans. For smaller resolutions, they worked fine.
But for the (very reasonable :-) ) resolution of 9600dpi, there is an interesting behaviour: 

The scanner was able to scan about 1/3 of the scan area, then it stopped, but WITHOUT an I/O error. About two minutes later, it suddenly again scanned a few millimeters. This seems to repeat until the scan is ready (it is still on its way, after now about 20 minutes...)

As I never noticed this before, I attached the corresponding part of /var/log/messages. Maybe you can find something interesting there...

I remember to have read some error reports on the net, where people told their scanner stopped without an I/O error and they had to interrupt the scan. Maybe that was the same behaviour and a few hours of patience would have led to a successfull scan :-)

Thanks, it is exactly what I need.

Could you also attach a debug log using debug version of libusb0, so I could see, how it should work with the original design?
http://download.opensuse.org/repositories/hardware:/libusb0:/debug/openSUSE_11.2/

I think as well, that the problem of libusb-compat may be caused by a different way of timeout handling. Some places of brscan source code behave differently depending on number of timeouts happened and context of the timeout.

Still expecting debug logs from libusb0 done with the same scanner paramaters as done with the unsuccessful scan.


Here is a short log analysis summary of unsuccessful scanning, comment 14, timestamps from 21:45:22 to 21:45:31.


The algorithm asks for transfer of 32000 bytes in 2 seconds.

Library splits this requirements to 2 URB transfers (it is larger than 16384 bytes) and sends request to the scanner.

Scanner did not fill the buffer completely and sent ~6000 bytes in the first transfer and ~500 bytes in the second transfer and library returned ~6500 bytes to the driver. It repeats every about ~50ms.

When no data are read, some magic in the driver is applied. It probably handles the step back before continuing.

It happened at 21:45:30. Less than 2 seconds later scanner stopped to work.

Did you press Ctrl+C at 21:45:31 or only scanner stopped to work in this moment?

There is a difference between successful and unsuccessful scanning with libusb1: Second URB after short transfer of first URB never gets any data.

(In reply to comment #17)
> Still expecting debug logs from libusb0 done with the same scanner paramaters
> as done with the unsuccessful scan.

In comment #7, I already gave the best debug log I could get: 

Somehow, libusb-0_1-4-0.1.12-142.1.x86_64.rpm does not produce more logging information than given there. Neither in combination with
  libusb-1_0-0-1.0.2-2.2.x86_64.rpm (which is a non-debug-version afaik)
nor with
  libusb-1_0-0-1.0.6-8.1.x86_64.rpm (which together with libusb-0_1-4-0.1.13 gave a reasonable error log)

I suspect that libusb-0_1-4-0.1.12-142.1.x86_64.rpm simply might not be a (full) debugging version. BTW, I also tried libusb-0_1-4-0.1.12-140.1.x86_64.rpm from 
http://download.opensuse.org/repositories/hardware:/libusb0/openSUSE_11.2/x86_64/, but I got the same poor logs.

I could not find a debugging version of libusb-1_0-0-1.0.2 anywhere.

If you could provide me with such a version, I will give it a try.
 
>... 
> When no data are read, some magic in the driver is applied. It probably handles
> the step back before continuing.
> 
> It happened at 21:45:30. Less than 2 seconds later scanner stopped to work.
> 
> Did you press Ctrl+C at 21:45:31 or only scanner stopped to work in this
> moment?

In that case, the scan stopped and reported I/O error. Only in the case mentioned in comment #15, I finally had to stop with Ctrl-C (but a lot later than the reported behaviour).

>I could not find a debugging version of libusb-1_0-0-1.0.2 anywhere.

True. The current libusb0 does not log successful bulk or control transfers, the most interesting for compatibility debugging, even in the highest bebugging level.

I made a patch that makes possible to log them at level 3 and more. It should log more with libusb-0_1-4-0.1.12-143.1, which should appear soon in hardware:libusb0:debug. It is untested yet, but it should work well.

Created attachment 332192 [details]
Log of xscanimage with 0_1-4-0.1.12-143.1

This now is a log with a debug version of libusb: 0_1-4-0.1.12-143.1
It was produced be "xscanimage |logger ".
The first lines belong to the initialization, then (marked by a lot of empty lines) I started the scanner at 15:09:54 (line 174)

I removed a few thousand lines of the log: Soon after the start of the successfull scan, the log is quite boring...

(The log was produced with an MFC-8440, different from the scanner in the previous logs; so below you find a log with the same configuration, but with  0_1-4-0.1.13-14.2 and, of course, an I/O error at the end)

Created attachment 332196 [details]
Log of xscanimage with 0_1-4-0.1.13-14.2

This log is the analog to the log in comment #21, but now with 0_1-4-0.1.13-14.2 and, of course, an I/O error at the end.

Again, there is an initialization phase and the log starts essentially al line 615.

Now I see a big difference how libusb0 and libusb-compat handles incomplete transfers:

libusb0:
- program starts with 32000 bytes request
- libusb splits 32000 bytes request to 2 URBs
- libusb asks for the first URB - 16384 bytes
- scanner returns short transfer 6668 bytes (or 0, if there are no data available yet)
- program decreases 32000 bytes by 6688 each time, but if 16384 bytes limit is reached, it again returns to 32000
- loop repeats until scan is complete

libusb-compat:
- program starts with 32000 bytes request
- libusb splits 32000 bytes request to 2 URBs
- libusb asks for the first URB - 16384 bytes
- scanner returns short transfer 6668 bytes (or 0, if there are no data available yet)
- libusb asks for the second URB (even if previous URB returned 0)
- scanner returns some amount of data (e. g. 3584 bytes)
- libusb concatenates both transfers and returns the data block (e. g. 10252 bytes).
- program decreases 32000 bytes by e. g. 10252 bytes and enters loop
- next loop run requests 21748 bytes, returns 3084+0
- next loop run requests 18664 bytes, returns 6668+0
- it repeats many times, until it reaches:
- next loop run requests x bytes, returns 6668+(small amount of data less than about 700 bytes)

It seems that 1 byte on URB confuses scanner and scanning stops.

The behavior difference and way to fix is obvious.

What is actually happening is not obvious. It seems that libusb0 always requests URB with 16384 bytes, size requested by libusb-compat varies. It may confuse the scanner or trigger a timing problem or race condition. Even firmware error is possible.

Reported upstream:

http://sourceforge.net/mailarchive/forum.php?thread_name=1260548449.8482.36.camel%40hammer.suse.cz&forum_name=libusb-devel

There is the same problem with a multifunction MFC-7420. The scanner stops on an I/O error message on a resolution higher than 200 points. This with a 32 bits PC.

Thanks for yoour work, I am unable to help you.

I did a fresh install and installed the new brscan2-0.2.5 from:

http://filebin.ca/ddjqtn/PS02364.zip

And now scanning works out of the box

Daniel

The bug in libusb-compat/libusb-1.0 was confirmed. Even if the new version works, we should fix libusb compatibility layer to work with any version that worked with libusb-0.1.

The current upstream summary:

There seems to be an error in incorrect cancelling continuation URB requests. I will prepare new test case and ask reporter with broken combination for a new logs sool.

Older kernels are not capable to cancel continuation URB requests. libusb-1.0 or libusb-compat must return to the old (slower) behavior - as for new data only if old data block was received.

Please try the rpm (brscan2) from Brother Japan. It can be found here:
http://solutions.brother.co.jp/support/os/linux/scanner/driver.html#brscan2

For me it works fine, maybe it is the solution for anyone else?

BTW updating brscan2 does not help anyway for scanners which are only supported by brscan(without the 2).

Sorry. Sure, I've forgotten some more informations (two comments above): The japanese brscan2 driver works fine for my MFC-260C. But at Brother Japan there are the brscan and the brscan3 driver as well. The brscan or brscan3 driver should be tested by people with related scanners, to clear this issue.

This must be the same upfdated drivers, another user got from brother to test, the 0.2.5 version for brscan2 and others for brscan and brscan3.

Probabely the issue is solved, when upstream usb is fixed, and when the new driver is available from brother everywhere.

For me it works now!

Please test with brscan and brscan3.

with broother dcp 7030 using brscan3 , I have the same behaviour , the scaner start and stop in a few second and I Get this error message ::"ereur pendant la lecture d'I/O sur le peripherique", error during readind  I/0 on the device. 
 I used this scaner without any problem with suse 11.0 and 11.1.

So , I think that is not normal to wait something from Brother which has deliver driver fine for the previous distribution.

Thanks 

Pierre

brscan driver from brother.co.jp is exactly the same as from brother.com (last updated 2007.Sep.27) - so does not work with our "MFC-8440".
Downgrading libusb-0 fixed that here too so far.

(In reply to comment #28)
> Please try the rpm (brscan2) from Brother Japan. It can be found here:
> http://solutions.brother.co.jp/support/os/linux/scanner/driver.html#brscan2
> 
> For me it works fine, maybe it is the solution for anyone else?

Hello,
I have installed the rpm brscan2-0.2.5-1 and my MFC-7420 scanner works perfectly now.
I tried a color 1200 dpi (405.6 Mo) with success. Then I tried the max (9600 dpi) > 1 Go but then the machine stops with a time-out error (I suppose).
Nevertheless the problem is solved for my machine; thank you.

  comment about 34 : If I go to 
http://welcome.solutions.brother.com/bsc/public_s/id/linux/en/download_scn.html

you can see that for MFC 7420 and a plat form x8664 you have to select brscan 2 and the version is brscan 2-0.2.5.1 , x 86.64 ;rpm , it is not necessary to go brother Japabn , it the same as it is written in comment 33,

So if brdrscan2 is correct the problem is for Brscan 3 and the scaners wchich have to use it, 

my case dcp 7030

I repeat I had no problem with Suse x86 64 11.0 and 11.1

and other distribution like ubuntu 9.04 or mandriva 2009.1

problem of kernel or something else

(In reply to comment #35)
>   comment about 34 : If I go to 
> http://welcome.solutions.brother.com/bsc/public_s/id/linux/en/download_scn.html
> 
> you can see that for MFC 7420 and a plat form x8664 you have to select brscan 2
> and the version is brscan 2-0.2.5.1 , x 86.64 ;rpm , it is not necessary to go
> brother Japabn , it the same as it is written in comment 33,
> 
> So if brdrscan2 is correct the problem is for Brscan 3 and the scaners wchich
> have to use it, 
> 
> my case dcp 7030
> 
> I repeat I had no problem with Suse x86 64 11.0 and 11.1
> 
> and other distribution like ubuntu 9.04 or mandriva 2009.1
> 
> problem of kernel or something else

I precise my OS is a x86 32 bits (no a 64 bits)

IIf uou open this web page 

http://welcome.solutions.brother.com/bsc/public_s/id/linux/en/faq_scn.html

and yoy select 

When scanning I receive the error "Error during device I/O".

you find this page

"# When scanning I receive the error "Error during device I/O".


The Brother Linux scanner driver works only with a superuser by default.
To use it with a normal user, you will have to make some settings.
Setting for normal users "

setting for normal user give 

"openSUSE11.2
    1. Open "/etc/udev/rules.d/55-libsane.rules"
    2. Add the following 2 lines at the last of the device entry. (just before "# The following rule...")

    # Brother
    ATTR{idVendor}=="04f9", MODE="0664", GROUP="lp", ENV{libsane_matched}="yes"

    3. Restart the OS.

page top

openSUSE 11.1
    1. Open "/etc/udev/rules.d/55-libsane.rules"
    2. Add 2 lines for Brother products.

    The lines to be added---------------------------------

    #Brother
    ATTR{idVendor}=="04f9", MODE="0666", GROUP="scanner", ENV{libsane_matched}="yes""

it is different for suse 11.1 and suse 11.2

during my instal this information was not updated and i have modified like for suse 11.1 

now I modified 55 libsane rules and I get the same problem

I observe that mode is 664 and every where "mode 664" ha to bee replace  by  "mode 666"

I wil try to replace 664 by 666 and will give the result

my comment 37 , replacement 664 by 666 give the same behaviour

the scaner start and stop and i getr error message I/O

Thaks for comments from experts

Pierre

Regarding comment 37 and comment 38: It is a different problem. Reporting as bug 566976. Please subscribe to this bug if you want to follow it.

Thanks for the comment 39, I have understand that mode 664 or 666 is an other problem, it is not the reason why now the same work witj suse 11.2 is not able to use coorectly the sanner , instaed with suse 11.0 and 11.1 . Yje scaber start and stop.

And it is not a propblem of driver

excuse mee , my mast comment is not correct, some mistake in type writting,

I repeat 

Thanks for the comment 39, 
I have understood that mode 664 or 666 is an other
problem, 
it is not the reason why now, the same work with suse 11.2 is not able
to use correctly the scanner , instead with suse 11.0 and 11.1 iy is correct . 

Now my scanner dc7030 Brther usind  brscan 3 start and stop in a few secon.

And it is not a problem of driver

Thanjs to identifie the solution

*** Bug 596411 has been marked as a duplicate of this bug. ***

Can wee expect a solution for suse 11,3  at the moment nothing is coming, I have mde a trial to day with the scaner and nothing new

thanks for an answer, evne if wee have nthing well to expect

The behaviour with suse 11.0 and 11;1 was perfect, to tay when I launched sane the answer is no device... something diferrent than I got in december , comment 32 

"with broother dcp 7030 using brscan3 , I have the same behaviour , the scaner
start and stop in a few second and I Get this error message ::"ereur pendant la
lecture d'I/O sur le peripherique", error during readind  I/0 on the device. 
 I used this scaner without any problem with suse 11.0 and 11.1."

No. The real solution means a complete rewrite of libusb0 compatibility layer, and it will not happen before openSUSE 11.3.

For openSUSE 11.3, you can use a work around: Install libusb0 instead of libusb-compat:

- Add repository http://download.opensuse.org/repositories/hardware:/libusb0/ to your repositories and assign higher priority to it.

- then install libusb-0_1-4 from this repository.

It will completely fix all compatibility issues.

I did not want to return to the old libusb code for openSUSE 11.3, as these issues affect only low percentage of users and it is easy to work-around them by the steps above. The new libusb should have a bit better performance in most other cases.

Fix of comment #44: The real solution does not mean a complete rewrite of libusb0 compatibility layer, but "only" complete rewrite of libusb0 compatibility buffering code.

Created attachment 366352 [details]
The libusb installed in my system

The description , what is installed on my Pc , The vendor is opensuse and yhe distrution installed is suse 11.2 X 86.64

I have try to instal the repository sugested by Stanislas Babec , but I Have not find how to to do it, as the file attached indicate , a libus-0_1-4 is installed, the vendor is suse.

If I search libusb-0_1-4  I found a suggestion with one click instal , wchich is perhaps the good 
below the first line

libusb-0_1-4-x86                hardware/openSUSE_11.2

What do you suggest??

Thanks 1000 times , and more

I have try to instal the repository sugested by Stanislas Babec , but I Have not find how to to do it, as the file attached indicate , a libus-0_1-4 is installed, the vendor is suse.

If I search libusb-0_1-4  I found a suggestion with one click instal , wchich is perhaps the good 
below the first line

libusb-0_1-4-x86                hardware/openSUSE_11.2

What do you suggest??

Thanks 1000 times , and more

I have read an other time the answers , and I think that if I used one click instal i have to use this 


libusb-0_1-4                        hardware:libusb0/openSUSE_11.2

Thanks For the answer that I am waiting 

Pierre

If you are affected by the problem in this bug, libusb-0_1-4 from hardware:libusb0 should fix your system. If it does not, it is a different problem.

Note: There are two completely different libusb-0_1-4 packages.

The new one is present in openSUSE:11.2, openSUSE:11.3, hardware and hardware:debug. This version uses libusb1 and compatibility layer. This works better for most users except brscan users (and maybe few others).

The old one is present in openSUSE < 11.2, hardware:libusb0 and hardware:libusb0:debug. This version uses the original old code base. It works in all cases, but it is probably slighly slower. If you use brscan, only this version works for you.

There are two ways to install:

1) Fast way, that may work: 1-Click install. You must be aware of two natures of this library. :debug repositories are intended for creating debug logs. In other cases you don't need them.

2) Slower way that works for sure: Using YaST2 -> Software Repositories

2.1) Add http://download.opensuse.org/repositories/hardware:/libusb0/openSUSE_11.2 (or 11.3 for future 11.3)

2.2) Increase just-added repository priority.

2.3) Using YaST2 -> Software Management, click to All, then search for libusb-0_1-4

2.4) Then click at Available and pick the package frm hardware:libusb0.

2.5) Apply, agree with provider change. Package is installed and you are done.

Thanks , For mee it will bee well to find the quality I had with the oldest oensuse. I understand that the libdvd is not for mee with brscan , but the oldest is the only way. 

But I dont find the solution to follow you have suggested

First One click_instal : if I search libusb0, exactly written like you the answer is : No packages found that matched your query

If I make the same research with libusb-0 I get a lot of answers with always the same name libdvd-O-1-4 is there the good one??, my other question about the solution with one click , you speak about libusb0debug ; I Dont know who to use debug file

Second ; I dont know how to add http://download.opensuse.org/repositories/hardware:/libusb0/openSUSE_11.2, with Yast 

If launch yast I can choice add , then choice http ,

then next , then : nom du serveur and I paste http://download.opensuse.org/repositories/hardware:/libusb0/openSUSE_11.2 , I can write a name of the depositorie and after next I get : you can imagine a message error.


Thanks for more explanations

Pierre

To First: You have to search for libusb-0_1-4 (or simply libusb and pick the correct libusb-0_1-4). libusb0 is the name of the repository, not the name of the package.

2.1) If you add the complete URL, then Click to "Specify URL..." and "Next". "Repository Name:" can be anything you want (e. g. "libusb0"), and paste URL to "URL".

Thanks , yesterday I followed your instructions, in the twoo case I got the same result , depositorie installed , 
Now I have 

installed 

libusb-0_1-4 distribution hardware: libusb0/opensuse_11.2

I have reoeat all the install of dcp 7030 and modified the libsane.rules with this twoo lines 

# Brother DCP-7030
ATTR{idVendor}=="04f9", ATTR{idProduct}=="01ea", MODE="0664", GROUP="lp",
ENV{libsane_matched}="yes"

and it works fine 

Thank you

Re-checking status of this bug. However the bug itself is obsolete, the problem can re-appear anywhere else.

According to the upstream (comment 24), the bug was caused by kernel.

Oliver, could you confirm, that in current kernels "given an example of 3 16kb bulk URBs submitted in parallel, if the first one ends early then the other 2 will be immediately cancelled with no possibility for data to arrive in them, 
as if they had never been submitted"?

Reference: http://sourceforge.net/p/libusb/mailman/message/24185174/

If the (first) request in sequence returns short transfer, is there any chance that continuation URBs return any data?

Original problem in short:

libusb0:
If the bulk read request size > MAX_USBFS_BUFFER_SIZE, it submits URBs sequentially. In case of short read, no more URBs are requested.

libusb1:
If the bulk read request size > MAX_USBFS_BUFFER_SIZE, it splits the transfer to URBs and request them in parallel, using USBFS_URB_SHORT_NOT_OK and USBFS_URB_BULK_CONTINUATION, where appropriate. It has a code handling EREMOTEIO for short transfers (they will concatenate all returned data and return them to user).

The bug reported here is apparently caused by a coincidence of several things:

* The driver attempts to guess scan line size by the amount of data returned: It fails, if continuation request returned next scanline and libusb0 concatenated both. It confuses the driver.

* Sometimes it happens that amount of data to read and amount of data returned differ by less than <256 bytes.

* Firmware bug that caused scanner to hang if URB is <256 bytes is submitted.

(In reply to comment #54)

> Oliver, could you confirm, that in current kernels "given an example of 3 16kb
> bulk URBs submitted in parallel, if the first one ends early then the other 2
> will be immediately cancelled with no possibility for data to arrive in them, 
> as if they had never been submitted"?

Yes, this issue is fixed.

OK. In this case we can completely close this bug:

- The original bug report became obsolete with a new release of drivers.

- The background of this bug is fixed as well, and the problem should never happen in similar conditions again.

- Whether the manufacturer fixed the scanner to not freeze on USB bulk reads <256 bytes is above the scope of this bug.