http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c shuang qiu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sqiu@novell.com AssignedTo|bnc-team-screening@forge.pr |lnussel@novell.com |ovo.novell.com | -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c1 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schrottmehl@onlinehome.de --- Comment #1 from Johannes Meixner 2009-12-03 09:08:59 UTC --- *** Bug 559724 has been marked as a duplicate of this bug. *** http://bugzilla.novell.com/show_bug.cgi?id=559724 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c3 --- Comment #3 from Stanislav Brabec 2009-12-03 11:19:23 CET --- 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 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c5 --- Comment #5 from norbert müller 2009-12-04 09:45:17 UTC --- 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 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c7 --- Comment #7 from Stanislav Brabec 2009-12-04 13:33:00 CET --- 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. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c9 --- Comment #9 from norbert müller 2009-12-06 12:43:58 UTC --- Created an attachment (id=331233) --> (http://bugzilla.novell.com/attachment.cgi?id=331233) 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? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c11 --- Comment #11 from Stanislav Brabec 2009-12-07 18:28:45 CET --- 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)? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c13 --- Comment #13 from Stanislav Brabec 2009-12-07 19:00:06 CET --- 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. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c15 --- Comment #15 from norbert müller 2009-12-07 21:42:44 UTC --- Created an attachment (id=331450) --> (http://bugzilla.novell.com/attachment.cgi?id=331450) 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 :-) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c17 --- Comment #17 from Stanislav Brabec 2009-12-08 18:11:44 CET --- 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? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c19 --- Comment #19 from norbert müller 2009-12-09 08:54:12 UTC --- (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/x8..., 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). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c21 --- Comment #21 from norbert müller 2009-12-11 14:30:47 UTC --- Created an attachment (id=332192) --> (http://bugzilla.novell.com/attachment.cgi?id=332192) 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) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c23 --- Comment #23 from Stanislav Brabec 2009-12-11 17:04:20 CET --- 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. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c24 --- Comment #24 from Stanislav Brabec 2009-12-11 17:40:56 CET --- Reported upstream: http://sourceforge.net/mailarchive/forum.php?thread_name=1260548449.8482.36.camel%40hammer.suse.cz&forum_name=libusb-devel -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c26 --- Comment #26 from Daniel Fuhrmann 2009-12-16 17:24:00 UTC --- 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 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c28 E. Wolf changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kleinerwolf@gmail.com --- Comment #28 from E. Wolf 2009-12-18 21:39:58 UTC --- 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? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c30 --- Comment #30 from E. Wolf 2009-12-18 23:19:07 UTC --- 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. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c32 pierre Labarbe changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pierre.5933@gmail.com --- Comment #32 from pierre Labarbe 2009-12-19 13:33:11 UTC --- 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 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c34 --- Comment #34 from Pierre COUTANT 2009-12-22 08:51:18 UTC --- (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. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c36 --- Comment #36 from Pierre COUTANT 2009-12-23 08:11:10 UTC --- (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.h...

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) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c38 --- Comment #38 from pierre Labarbe 2009-12-23 10:12:03 UTC --- 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 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c40 --- Comment #40 from pierre Labarbe 2009-12-28 16:36:48 UTC --- 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 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c42 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gblackman@aanet.com.au --- Comment #42 from Johannes Meixner 2010-04-14 11:05:47 UTC --- *** Bug 596411 has been marked as a duplicate of this bug. *** http://bugzilla.novell.com/show_bug.cgi?id=596411 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c44 --- Comment #44 from Stanislav Brabec 2010-06-01 22:51:43 CEST --- 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. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c46 --- Comment #46 from pierre Labarbe 2010-06-02 09:19:50 UTC --- Created an attachment (id=366352) --> (http://bugzilla.novell.com/attachment.cgi?id=366352) 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 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c48 --- Comment #48 from pierre Labarbe 2010-06-02 09:28:41 UTC --- 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 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c50 --- Comment #50 from Stanislav Brabec 2010-06-02 17:03:20 CEST --- 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. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=559697 http://bugzilla.novell.com/show_bug.cgi?id=559697#c52 --- Comment #52 from Stanislav Brabec 2010-06-02 21:24:54 CEST --- 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". -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=559697 https://bugzilla.novell.com/show_bug.cgi?id=559697#c54 Stanislav Brabec changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |oneukum@suse.com --- Comment #54 from Stanislav Brabec 2014-09-01 14:50:52 CEST --- 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=559697 https://bugzilla.novell.com/show_bug.cgi?id=559697#c56 Stanislav Brabec changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #56 from Stanislav Brabec 2014-09-01 15:52:30 CEST --- 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.