Bug 130144 - Scanning with USB scanner (Brother MFC8820DN) fails with SuSE 10.0 kernel.
Summary: Scanning with USB scanner (Brother MFC8820DN) fails with SuSE 10.0 kernel.
Status: RESOLVED WONTFIX
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Final
Hardware: i386 SuSE Linux 10.0
: P5 - None : Major
Target Milestone: ---
Assignee: Olaf Hering
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-22 11:11 UTC by Andreas Pfaller
Modified: 2005-10-31 14:55 UTC (History)
1 user (show)

See Also:
Found By: Customer
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Patch mentioned in Comment #4 (1.75 KB, patch)
2005-10-25 18:01 UTC, Andreas Pfaller
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Pfaller 2005-10-22 11:11:04 UTC
I have problems with a Brother MFC8820DN (a Laser/Scanner/Fax combo)
using the scanner driver available from Brother (brscan-0.0.12-0.rpm). 
Even "rmmod usblp" (see Bug#127524) will not help.

An strace of
  scanimage -d 'brother:bus1;dev4' --format tiff --resolution 100 >test2.tiff
(with usblp unloaded) gives:
...
open("/proc/bus/usb/004/002", O_RDWR)   = 133
ioctl(133, USBDEVFS_CLAIMINTERFACE, 0xbf887cf4) = 0
ioctl(133, USBDEVFS_SETCONFIGURATION, 0xbf887cf4) = -1 EBUSY (Device or resource
busy)
write(2, "scanimage: open of device brothe"..., 76
  scanimage: open of device brother:bus1;dev4 failed: Error during device I/O
) = 76
munmap(0x40017000, 72816)               = 0
exit_group(1)                           = ?

Syslog reports:
  usb 4-2: usbfs: interface 1 claimed by usbfs while 'scanimage' sets config #1
(with usblp loaded this is "...claimed by usblp while...")

"scanimage -L" output:
device `v4l:/dev/video1' is a Noname BT878 video (Hauppauge (bt878)) virtual device
device `v4l:/dev/video0' is a Noname BT878 video (Hauppauge (bt878)) virtual device
device `brother:bus1;dev4' is a Brother MFC-8820D MFC Scanner

I booted 10.0 with an self-compiled vanilla 2.6.12 kernel (which I used with
SuSE 9.2 before I installed 10.0) and then the scanner works normally.

Using the package "sane-1.0.16-0.1" (obtained from
ftp://ftp.suse.com/pub/people/jsmeix/unsupported/sane/10.0/RPMS/)
instead of sane-1.0.15-20.i586.rpm (as supplied on 10.0 DVD)
shows exactly the same problems.

Relevant part of /proc/bus/usb/devices:
T:  Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=04f9 ProdID=0143 Rev= 1.00
S:  SerialNumber=000G3J149829
C:* #Ifs= 3 Cfg#= 1 Atr=c0 MxPwr=  2mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=07(print) Sub=01 Prot=02 Driver=(none)
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Just a note: While it seems from looking at /proc/bus/usb/devices
that a wrong device is used with "brother:bus1;dev4" this looks like
an internal naming problem within the brother driver as the open()
call uses the correct "/proc/bus/usb/004/002".
Comment 1 Olaf Hering 2005-10-24 09:24:43 UTC
try to stop hald, we have to find what keeps the entries in /proc/bus/usb/ busy.
Comment 2 Andreas Pfaller 2005-10-24 09:37:00 UTC
Exactly the same output (strace and sylog) after "rchal stop".
Comment 3 Olaf Hering 2005-10-25 11:34:23 UTC
can you attach the full strace output and also the ps axfu output? 
Comment 4 Andreas Pfaller 2005-10-25 17:59:31 UTC
Im the meantime I have had a look at the sources of Brothers sane 
driver available from 
http://solutions.brother.com/Library/sol/printer/linux/rpmfiles/sane_source/brother-sane-src-1.0.0-r011.tar.gz 
and the main problem seems to be the order in which it calls 
usb_claim_interface() and usb_set_configuration(). I managed to
compile the brother backend with the attached patch within an
updated sane source tree and the problem went anway.
 
The original version worked with kernels up to at least 2.6.12
since the kernel did not return EBUSY. The code returning
EBUSY was commented out. I my opinion a warning message
with printk that this behaviour will change would have been
a better idea.

I submitted some feedback to Brother via there feedback form
but recieved no reply yet. Maybe SuSE/Novell has some better contacts
to Brother to make them aware of this issue.

Still not solved is the problem with usblp (Bug#127524).
It does not really matter to me since I print via the network.
Comment 5 Andreas Pfaller 2005-10-25 18:01:27 UTC
Created attachment 55355 [details]
Patch mentioned in Comment #4
Comment 6 Olaf Hering 2005-10-25 21:17:55 UTC
Greg, can you comment on the missing printk or similar indicator?
Comment 7 Greg Kroah-Hartman 2005-10-25 22:24:42 UTC
This was a printk for a _long_ time before we removed this in the mainline kernel.

People ignored it then, it was wrong, but we gave them a year to fix their stuff...  I can point you at the upstream kernel.org bug entry if you wish.
Comment 8 Andreas Pfaller 2005-10-25 23:40:47 UTC
Greg, you probably mean the message "usb 4-2: usbfs: interface 1 claimed
by ...". The problem with this message is at least to me and 
probably also Brothers developers nothing indicates that userspace does
something wrong. It merely looks like a normal kernel status message.
It would have been helpful if it had indicated that an error
has been detected and that in the future this error will not be ignored.

Anyway, the reason for the problem is found. I will mark this bug as
"WONTFIX" as the kernel does nothing wrong and its Brother's job to 
distribute an updated sane driver.
Comment 9 Greg Kroah-Hartman 2005-10-26 22:32:40 UTC
Yes, sorry about the wording.  This was done by the upstream kernel developers
a long time ago, and we picked it up when we updated our kernel versions.