(In reply to comment #0)

> Related links:
> 
> * Possible solution: http://article.gmane.org/gmane.linux.usb.general/93288
>
To test this theory boot with usbcore.autosuspend=-1 on the kernel command line.

Should I edit the GRUB2 config or edit the config at startup, adding this option after "... splash=silent quiet showopts nomodeset"?

I copied the default opensuse 13.1 menuentry in grub.cfg. The linux line now reads:

linux   /vmlinuz-3.11.6-4-desktop root=UUID=a8659ed5-8ba7-4e98-a369-9f3d56b43725   resume=/dev/disk/by-id/ata-Corsair_Force_3_SSD_12136503000013410698-part6 splash=silent quiet showopts nomodeset usbcore.autosuspend=-1

Booting with this doesn't fix the problem (scanimage -L still works only once).

Is there a way to disable USB3 / xhci and try again with a pure USB2 stack?

Not on 13.1. The switch is done in the PCI initialisation. Blacklisting the module doesn't help. You need to build a kernel without XHCI.

Anything else I can try?

Where can I find current instructions to build a kernel myself? The only thing I could find is in the old Wiki and it's for version 10.3 ...

Note: I'm on holidays for a week, away from my PC, so I can't try anything right now.

I have now tried the same scanner with the same version of openSUSE and an old laptop. There, it works flawlessly.

So I'm pretty sure it's somehow connected to the kernel, USB stack and the Haswell chip set.

I have the same problem with my Canon CanoScan LiDE25 flatbed scanner. When I connect it to a USB3 port, scanimage -L doesn't work correctly. There are three possible outcomes: 1 - it reports the scanner correctly and then hangs for a very long time (this only happens on the first attempt after it is connected). 2 - It hangs for a while and then says that no scanners were identified. 3 - It immediately says that no scanners were identified.

When connecting the scanner to a USB3 port, sane-find-scanner as well as lsusb always detect the scanner correctly (i.e., repeatedly, even after scanimage -L failed to detect the scanner).

When connecting the scanner to a USB2 port on the same machine, everything works fine.

I see this behavior both on my desktop and laptop. My desktop has an Etron EJ168A USB3 controller. I am not sure what is in my laptop. But the behavior is clearly not specific to the Haswell chipset.

(In reply to comment #7)
> I have now tried the same scanner with the same version of openSUSE and an old
> laptop. There, it works flawlessly.
> 
> So I'm pretty sure it's somehow connected to the kernel, USB stack and the
> Haswell chip set.

Can you get an usbmon trace of the working kernel and a trace of the failing kernel?

Here is the information you wanted. Here is the device listing from the bad kernel / hardware combination:

T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 13 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=04c5 ProdID=11a2 Rev= 1.00
S:  Manufacturer=Fujitsu 
S:  Product=ScanSnap S1500
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 98mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=31875us

And this is the good one:

T:  Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  9 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=04c5 ProdID=11a2 Rev= 1.00
S:  Manufacturer=Fujitsu 
S:  Product=ScanSnap S1500
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 98mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=31875us

Created attachment 573547 [details]
Capture when it works

Created attachment 573549 [details]
Capture when it breaks

In both cases, the logs contain three events with a several second pause between them:

- Plugging in the device
- running scanimage -L
- running scanimage -L again

I still have this problem with openSUSE 13.2 and the latest patches and kernel as of Dec. 10th, 2014

Probably the same bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1102797

This is a real showstopper. After changing my primary system to a haswell based one, that only provides xhci driven usb devices. Interestingly, this problem bites primary people, that are using a scanner with linux. Mine is an Epson Perfection 4490 Photo.

The xhci driver throws this message:
rounding interval to 128 microframes, ep desc says 255 microframes
resulting in a non operational device.

The only solution, I found so far, is adding a USB2 only extension card:
http://www.startech.com/Cards-Adapters/USB-2/Card/4-Port-PCI-Express-Low-Profile-High-Speed-USB-Card~PEXUSB4DP

My new board is an Asus Z97-A. To cap all this, its UEFI BIOS is confused from time to time due to this card (2 of 3 reboots), where it fails to detect my keyboard properly, resulting in a additional beep during POST, and missing keyboard control within grub2. If I need keyboard control for grub2, I have to turn off the scanner before reboot. Oh well.

What I really dislike here is the way, how this issue is handled. 

There's some discussion on linux usb ML, but no solution.

Here's an interesting related thread:

http://thread.gmane.org/gmane.linux.usb.general/110579/focus=114763

I've tried to push this a bit further, and satisfied the requests of Intel hacker Mathias Nyman. Unfortunately, even 3.19-rc4 doesn't get this issue resolved.

Looks, like we will keep suffering.

(In reply to Hans-Peter Jansen from comment #15)
> 
> The only solution, I found so far, is adding a USB2 only extension card:
> http://www.startech.com/Cards-Adapters/USB-2/Card/4-Port-PCI-Express-Low-
> Profile-High-Speed-USB-Card~PEXUSB4DP
> 
Here still another working card:
http://www.reichelt.de/index.html?ACTION=3;ARTICLE=76568;SEARCH=LCS-6080

Don't solve the actual problem, I know.

Please test the kernel at

http://kernel.suse.com/packages/vanilla

Sorry for forgetting about this bug.

FYI, the problem is gone for me within the kernel 4.0 time frame, together with installing a more current iscan/iscan-plugin-gt-x750 package.
After these changes, my Epson 4490 Photo scanner does again, what it was made for!

Other xhci woes with sdcard readers could be solved with device firmware updates.

Unfortunately, there are some xhci issues left with certain harddisk cases, that couldn't be solved from the kernel usb hackers. The net effect is sponteaneous device disconnects, two (kind of devices) observed by me: a Toshiba 2,5" mobile harddisk, and a Fantec AluPro U3 external 2,5" case with Asmedia AS2105 controller. The Toshiba HD was from a friend, and couldn't be analysed in depth.

Oliver, if you like, I can send you the Fantec case as a gift, being limited to USB 2, is has no value for me anyway.

(In reply to Hans-Peter Jansen from comment #19)

> Unfortunately, there are some xhci issues left with certain harddisk cases,
> that couldn't be solved from the kernel usb hackers. The net effect is
> sponteaneous device disconnects, two (kind of devices) observed by me: a
> Toshiba 2,5" mobile harddisk, and a Fantec AluPro U3 external 2,5" case with
> Asmedia AS2105 controller. The Toshiba HD was from a friend, and couldn't be
> analysed in depth.

I got such a controller this week end and I am going to investigate.

> Oliver, if you like, I can send you the Fantec case as a gift, being limited
> to USB 2, is has no value for me anyway.

That would be cool.

The new kernel didn't change anything for me. When I connect my CanoScan LIDE 25 to a USB3 port it is detected:

% lsusb
<snip>
Bus 005 Device 005: ID 04a9:2220 Canon, Inc. CanoScan LIDE 25
<snip>

But xsane still reports that it cannot detect any devices, as does scanimage -L. Attaching it to a USB2 port still works. So the behavior is essentially the same as reported in comment #8. This is kernel version 4.3.0-rc5-113-g16c8b9c-1.gb8b1716-vanilla.

Johannes, this report says that upstream does not fix his scanner. Can you confirm that yours is working with current vanilla?

As an intermediate result:

USB 3 does not work with openSUSE Leap 42.1 Beta 1.

Details (excerpts) from my Leap 42.1 Beta 1 machine:
-----------------------------------------------------------------------------
# uname -a
Linux linux-4mnf.site 4.1.6-10-desktop #1 SMP PREEMPT
 Fri Aug 28 10:59:34 UTC 2015 (d867e86) x86_64 x86_64 x86_64 GNU/Linux

# lsusb | grep Canon
...
Bus 003 Device 017: ID 04a9:220e Canon, Inc. CanoScan N1240U/LiDE 30
...

# lsusb -t
...
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
    |__ Port 2: Dev 17, If 0, Class=Vendor Specific Class, Driver=, 12M
...

# dmesg | tail
...
... usb 3-2: new full-speed USB device number 17 using xhci_hcd
... usb 3-2: New USB device found, idVendor=04a9, idProduct=220e
... usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
... usb 3-2: Product: CanoScan
... usb 3-2: Manufacturer: Canon
...

# rpm -q sane-backends
sane-backends-1.0.24-2.5.x86_64

# export SANE_DEBUG_SANEI_USB=128

# sane-find-scanner
...
[sanei_debug] Setting debug level of sanei_usb to 128.
[sanei_usb] sanei_usb_init: initializing libusb-1.0
[sanei_usb] sanei_usb_scan_devices: marking existing devices
[sanei_usb] libusb_scan_devices: Looking for libusb-1.0 devices
...
[sanei_usb] libusb_scan_devices: found libusb-1.0 device (0x04a9/0x220e)
 interface 0 at libusb:003:017
[sanei_usb] store_device: add dn 1 with libusb:003:017
...
[sanei_usb] sanei_usb_scan_devices: device 01 is libusb:003:017
...
found USB scanner (vendor=0x04a9 [Canon], product=0x220e [CanoScan])
 at libusb:003:017

# scanimage -L
...
[sanei_debug] Setting debug level of sanei_usb to 128.
[sanei_usb] sanei_usb_init: initializing libusb-1.0
...
[sanei_usb] libusb_scan_devices: found libusb-1.0 device (0x04a9/0x220e)
 interface 0 at libusb:003:017
[sanei_usb] store_device: add dn 1 with libusb:003:017
...
[sanei_usb] sanei_usb_scan_devices: device 01 is libusb:003:017
...
[sanei_usb] sanei_usb_open: trying to open device `libusb:003:017'
[sanei_usb] sanei_usb_open: configuration nr: 0
[sanei_usb] sanei_usb_open:     interface nr: 0
[sanei_usb] sanei_usb_open:   alt_setting nr: 0
[sanei_usb] sanei_usb_open: endpoint nr: 0
[sanei_usb] sanei_usb_open: direction: 128
[sanei_usb] sanei_usb_open: address: 1 transfertype: 3
[sanei_usb] sanei_usb_open: found interrupt-in endpoint (address 0x01)
[sanei_usb] sanei_usb_open: endpoint nr: 1
[sanei_usb] sanei_usb_open: direction: 128
[sanei_usb] sanei_usb_open: address: 2 transfertype: 2
[sanei_usb] sanei_usb_open: found bulk-in endpoint (address 0x02)
[sanei_usb] sanei_usb_open: endpoint nr: 2
[sanei_usb] sanei_usb_open: direction: 0
[sanei_usb] sanei_usb_open: address: 3 transfertype: 2
[sanei_usb] sanei_usb_open: found bulk-out endpoint (address 0x03)
[sanei_usb] sanei_usb_open: opened usb device `libusb:003:017' (*dn=1)
[sanei_usb] sanei_usb_get_vendor_product: device 1: vendorID: 0x04a9,
 productID: 0x220e
[sanei_usb] sanei_usb_write_bulk: trying to write 4 bytes
[sanei_usb] 000 01 69 00 01                                     .i..            
[sanei_usb] sanei_usb_write_bulk: wanted 4 bytes, wrote 4 bytes
[sanei_usb] sanei_usb_read_bulk: trying to read 1 bytes
[sanei_usb] sanei_usb_read_bulk: read failed: Operation timed out
[sanei_usb] sanei_usb_close: closing device 1

No scanners were identified.
...

# dmesg | tail
[no new messages]
-----------------------------------------------------------------------------

I will update the kernel to one from
http://kernel.suse.com/packages/vanilla
and report whether or not this works...

It also does not work with newest sane-backends-1.0.25
that has some workarounds for USB 3
(without updtated kernel on Leap 42.1 beta 1):
-----------------------------------------------------------------------------
# osc getbinaries graphics sane-backends openSUSE_Leap_42.1 x86_64
...

# rpm -Uhv binaries/sane-backends-1.0.25-112.5.x86_64.rpm
 binaries/sane-backends-autoconfig-1.0.25-112.5.x86_64.rpm

# grep -v '^#' /etc/sane.d/dll.conf
plustek

# scanimage -L
...
[sanei_usb] sanei_usb_read_bulk: trying to read 1 bytes
[sanei_usb] sanei_usb_read_bulk: read failed: Operation timed out
[sanei_usb] sanei_usb_close: closing device 1
[sanei_usb] sanei_usb_set_altinterface: alternate = 0

No scanners were identified.
-----------------------------------------------------------------------------

For the fun of it:
My machine has 4 USB ports, two labeled with
the "super speed" USB logo (a.k.a. USB 3) and
two labeled with the normal USB logo (a.k.a. USB 2)
but for all 4 ports xhci is used and it fails on all 4 ports.

Now testing with kernel-vanilla:
-----------------------------------------------------------------------------
# zypper ar -f http://download.opensuse.org/repositories/Kernel:/vanilla/standard Kernel:vanilla
...
Repository 'Kernel:vanilla' successfully added
...
URI : http://download.opensuse.org/repositories/Kernel:/vanilla/standard
...

# zypper in --from Kernel:vanilla kernel-vanilla
...
Installing: kernel-vanilla-4.3.rc5.116.g81429a6-1.1.g2ce0222
...
Executing: /usr/bin/dracut ...
...
Some kernel modules could not be included: 
sd_mod
scsi_dh
unix
atkbd
i8042
ext4
swap
autofs4
ipv6
Update bootloader...
-----------------------------------------------------------------------------

That "ext4 kernel modules could not be included" doesn't look promising
because I use ext4 for '/' - nevertheless it reboots successfully
(i.e. never worry about messages ;-)

After reboot:
-----------------------------------------------------------------------------
# uname -a
Linux linux-4mnf.site 4.3.0-rc5-116-g81429a6-1.g2ce0222-vanilla #1
 SMP Sun Oct 18 10:04:19 UTC 2015 (2ce0222) x86_64 x86_64 x86_64 GNU/Linux

# lsusb | grep Canon
Bus 003 Device 002: ID 04a9:220e Canon, Inc. CanoScan N1240U/LiDE 30

# lsusb -t
...
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
    |__ Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=, 12M
...

# sane-find-scanner
...
found USB scanner (vendor=0x04a9 [Canon], product=0x220e [CanoScan],
 chip=LM9832/3) at libusb:003:002
...

# scanimage -L
device `plustek:libusb:003:002' is a Canon CanoScan N1240U/LiDE30
 flatbed scanner
-----------------------------------------------------------------------------

Good! - It does no longer fail!

Testing if it also works reliably for huge amount of data:
-----------------------------------------------------------------------------
# scanimage -v -d plustek:libusb:003:002 -x 210 -y 290
 --resolution 2400 >/tmp/image.pnm
scanimage: scanning image of size 19840x27400 pixels at 24 bits/pixel
scanimage: acquiring RGB frame
scanimage: min/max graylevel value = 0/255
scanimage: read 1630848000 bytes in total
# echo $?
0
-----------------------------------------------------------------------------

Hooray! It works reliably!

FYI:
It took about 25 minutes to receive that 1.6 GB of data from the scanner
(the scanner is not too fast ;-)

I assume the test in comment #25 was with sane-backends-1.0.25? I tested with sane-backends-1.0.24. Where can I find sane-backends-1.0.25?

Testing if it also works with sane-backends-1.0.24
that is by default in Leap:
----------------------------------------------------------------------------
# zypper in --oldpackage --from openSUSE-42.1-0 sane-backends
 sane-backends-autoconfig
...
Installing: sane-backends-1.0.24-2.5
...
Installing: sane-backends-autoconfig-1.0.24-2.5

# scanimage -L
device `plustek:libusb:003:002' is a Canon CanoScan N1240U/LiDE30
 flatbed scanner

# scanimage -v -d plustek:libusb:003:002 -x 210 -y 290
 --resolution 300 >/tmp/image2.pnm
scanimage: scanning image of size 2480x3425 pixels at 24 bits/pixel
scanimage: acquiring RGB frame
scanimage: min/max graylevel value = 0/255
scanimage: read 25482000 bytes in total

[Oops! - hangs up here]

^Cscanimage: received signal 2
...

# scanimage -L
[Oops! - hangs up]
----------------------------------------------------------------------------

It seems one needs both the new kernel plus sane-backends-1.0.25
to get it working reliably at USB 3.

See comment#24 wherefrom to get sane-backends-1.0.25.

FYI:
--------------------------------------------------------------------------
# osc results graphics sane-backends | grep succeeded  
openSUSE_Tumbleweed      i586       succeeded
openSUSE_Tumbleweed      x86_64     succeeded
openSUSE_Leap_42.1       i586       succeeded
openSUSE_Leap_42.1       x86_64     succeeded
openSUSE_Factory_PowerPC ppc64le    succeeded
openSUSE_Factory_PowerPC ppc64      succeeded
openSUSE_Factory_PowerPC ppc        succeeded
openSUSE_Factory         i586       succeeded
openSUSE_13.2            i586       succeeded
openSUSE_13.2            x86_64     succeeded
openSUSE_13.1            i586       succeeded
openSUSE_13.1            x86_64     succeeded
openSUSE_13.1            ppc64      succeeded
openSUSE_13.1            armv6l     succeeded
SLE_12                   x86_64     succeeded
SLE_12                   ppc64le    succeeded
--------------------------------------------------------------------------

For direct RPM download of sane-backends-1.0.25
from the OBS "graphics" project, use
http://download.opensuse.org/repositories/graphics/
and select your exact operating system and architecture.

FYI:
After I updated again to sane-backends-1.0.25 it works again
reliably on my machine (with the new kernel).

I seem to be stuck with an incompatible libgphoto2_port for sane-backends-1.0.25, so I will have to give that a pass I am afraid...

I think you also need the libgphoto2 from the OBS "graphics" project
because when sane-backends-1.0.25 is build in that project it
uses the other packages from that project during build
which means when libgphoto2 is newer in the OBS "graphics" project
then when sane-backends-1.0.25 is build in that project it uses
and requires that newer libgphoto2 from the OBS "graphics" project.

Indeed, but when I get the new libgphoto as well, I get this:

warning: libgphoto2-6-2.5.8-157.1.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 4f311b1d: NOKEY
error: Failed dependencies:
	libgphoto2_port.so.10()(64bit) is needed by (installed) shotwell-0.20.1-5.2.x86_64
	libgphoto2_port.so.10()(64bit) is needed by (installed) gvfs-backends-1.22.4-11.1.x86_64
	libgphoto2_port.so.10(LIBGPHOTO2_5_0)(64bit) is needed by (installed) shotwell-0.20.1-5.2.x86_64
	libgphoto2_port.so.10(LIBGPHOTO2_5_0)(64bit) is needed by (installed) gvfs-backends-1.22.4-11.1.x86_64

Sounds like the first step towards dependency hell...

Now I remember that I had same dependency issue on my SLES12 system
when I had installed sane-backends-1.0.25 from OBS "graphics".

I simply installed it there with "rpm --force" or "rpm --nodeps"
so that I have it now on my SLES12 system as follows:
----------------------------------------------------------------------------
# rpm -V sane-backends
Unsatisfied dependencies for sane-backends-1.0.25-119.1.x86_64:
  libgphoto2_port.so.12()(64bit) is needed
    by (installed) sane-backends-1.0.25-119.1.x86_64
  libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit) is needed
    by (installed) sane-backends-1.0.25-119.1.x86_64
----------------------------------------------------------------------------

For me plain "scanimage" works regardless of those unsatisfied dependencies
but I do not use desktop tools or GUI scanning tools that might have issues
because of those unsatisfied dependencies.

In the end sane-backends is only an application which means
that your system should not "explode" when you upgrade it with
unsatisfied dependencies. All what could happen as far as I can
imagine is that "scanimage" crashes or things like that.
If the new version fails it should help to downgrade
back to the version that was installed before.

Stupid me!

I forgot that I also build sane-backends-1.0.25
in my personal playground OBS home project "home:jsmeix":
--------------------------------------------------------------------------
osc results home:jsmeix sane-backends-1-0-25 | grep succeeded
openSUSE_Tumbleweed              i586       succeeded
openSUSE_Tumbleweed              x86_64     succeeded
openSUSE_Factory                 i586       succeeded
openSUSE_Factory                 x86_64     succeeded
openSUSE_Evergreen_11.4_standard i586       succeeded
openSUSE_Evergreen_11.4_standard x86_64     succeeded
openSUSE_13.2                    i586       succeeded
openSUSE_13.2                    x86_64     succeeded
openSUSE_13.1                    i586       succeeded
openSUSE_13.1                    x86_64     succeeded
SLE_12                           x86_64     succeeded
--------------------------------------------------------------------------

Because in my OBS home project "home:jsmeix" there is no libgphoto2
building sane-backends-1.0.25 there uses the "original" libgphoto2
from the system for which it is build (e.g. libgphoto2 from SLE_12
when it is built for SLE 12) so that the built sane-backends-1.0.25
fits well into the system for which it is built (e.g. into a SLES 12
system).

I have now installed sane-backends-1.0.25 from "home:jsmeix"
on my SLES 12 systems without any unsatisfied dependencies
where it works well for me.

For direct RPM package download from "home:jsmeix" read
https://build.opensuse.org/project/show/home:jsmeix
(excerpt):
---------------------------------------------------------------
Do not somehow add the whole "home:jsmeix"
repository to be used by your package
installer (e.g. via YaST).
Using the whole "home:jsmeix" repository
could be a perfect way to mess up your
system.
Instead only download the packages
of your particular interest which match
your excat system from the appropriate
sub-directory in
http://download.opensuse.org/repositories/home:/jsmeix/
and install them manually
(e.g. using plain "rpm").
If you are unexperienced with manual
installation, do not install any package
from "home:jsmeix".
.
.
.
The packages in the "home:jsmeix" project
are only for testing, without any guarantee
or warranty, and without any support.
As an extreme example, this means if your
complete computer center crashes because
of those packages, it is only your problem.
On the other hand this does not mean that
all those packages are known to be terrible
broken (but some of those packages could
be really broken) and none of those packages
are thoroughly tested so that any unexpected
issue can happen.
---------------------------------------------------------------

For openSUSE Leap 42.1 users I build now sane-backends-1.0.25
in OBS "home:jsmeix" also for "openSUSE_Leap_42.1".
For direct RPM download (cf. comment# 35) go to
http://download.opensuse.org/repositories/home:/jsmeix/openSUSE_Leap_42.1/x86_64

I have tested access to my scanner using sane-backends 1.0.25 from comment #35 and kernel 4.3.0-rc6-108-gce1fad2-1.g047c182-vanilla.

I initially tried configuring the scanner via YaST2 -> Scanner. This took a long time and eventually failed. It showed the CanoScan LIDE 25, but as "not configured". I then tried scanimage -L. This showed the scanner correctly, but the command was hanging for quite a long time after showing the entry for the LIDE 25. I then clicked to edit the unconfigured entry for the LIDE 25 in the YaST2 scanner tool. When I finished that, the configuration did complete successfully. I then tried scanimage -L a second time and this time it showed the correct entry and exited immediately. Finally I tested access to the scanner using xsane. This worked very well, both via USB3 and USB2.

So there is progress here, but something is still a bit wonky as evidenced by the initial failure to configure the scanner. It looks like scanimage -L is still not as reliable as it should be via USB3. I have seen two instances where scanimage -L still claimed not to have detected the scanner. Also the long timeouts are unworkable. They imply that xsane doesn't start up normally all the time. But when the scanner is detected normally, everything seems to work fine.

FYI:

There is nothing in the YaST scanner module that
can do any kind of "additional magic" to cure problems
in the underlying stack of various layers and subsystems
that is needed to use a USB scanner, cf. "Basics" in
https://en.opensuse.org/SDB:Configuring_Scanners

The YaST scanner module calls "sane-find-scanner" to detect scanners
(see /usr/lib/YaST2/bin/autodetect_scanners)
and an equivalent of "scanimage -L" to list active scanners
(see /usr/lib/YaST2/bin/determine_active_scanners).

When setting up a scanner all what the YaST scanner module does is
to activate a SANE backend (i.e. driver) in /etc/sane.d/dll.conf
(see /usr/lib/YaST2/bin/activate_scanner_backend)
and then it runs the "scanimage -L" equivalent to get the result.

When after scanner set up the YaST scanner module shows for
an activated backend "No scanner recognized by this driver"
it means that "scanimage -L" does not report the scanner and
that results that the YaST scanner module still shows the
scanner device as "Not configured" - i.e. something like this:
-----------------------------------------------------------------------
ACME FancyScanner 100     Not configured
acmescanbackend           No scanner recognized by this driver
-----------------------------------------------------------------------

In the end what I like to tell is:
Do not expect miracles from the YaST scanner module.

For testing and debugging in case of issues I recommend
1. calling plain "sane-find-scanner" to detect scanners, then
2. maually activating the driver in /etc/sane.d/dll.conf and finally
3. calling plain "scanimage -L" to see the result
because this way one gets more direct feedback from the system.

Which backend/driver should be the right one for a scanner model is listed
in the SANE descriptions files /usr/share/sane/descriptions*/*.desc
(cf. "Scanner" in https://en.opensuse.org/SDB:Configuring_Scanners)
from which /usr/share/doc/packages/sane-backends/sane-mfgs.html
is created. Display that HTML file in a browser to find out which
backend/driver should be the right one for a scanner model.
Also the YaST scanner module reads the SANE descriptions files
to create its list (see /usr/lib/YaST2/bin/create_scanner_database).

Sure, I can find my way around this. But I just wanted to point out that the average user would expect the YaST2 tool to work out of the box...

That being said, I found out yesterday that the system I did the tests on had faulty memory. I am not sure if that influenced the tests, so I will have to do them again I am afraid... :-(

An intermediate status FYI:

Currently we can no longer reproduce it.

Currently my Canon CanoScan N1240U/LiDE30 works with xhci
on all our testing computers - incuding the one where it
had faild as I reported above.

The only difference on that machine where it had failed
is that I had used it in BIOS legacy boot mode
and now I use it with UEFI.

On Oliver Neukum's comuter it had never failed.

From that follows:

It depends on the computer hardware where "hardware"
includes the computer's firmware (BIOS or UEFI).

There are computers where USB3 always "just works".

There are computers where USB3 fails under certain conditions.

Perhaps there are computers where USB3 always fails.

Our current guess for my particular computer is that when its
UEFI firmware initially uses USB (e.g. for the keyboard)
it somehow "does the right things" that result that xhci works
while in contrast when its BIOS firmware is used those "right things"
do not happen which lets then xhci fail.

What we will do now is to get it first and foremost reliably reproduced
so that then Oliver Neukum can find out what the "right things" are
that the kernel needs to do to make xhci work on our particular
testing computers.

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

Asus Z97-P , bios 2803 (last one)

Opensuse 13.1 x86_64 kernel 3.11.10
hp-lip 3.15.9 from suse printing 13.1

usb printer-scanner HP 1220 (usb 1.1) connected to a 1.1/2.0 plug of the MB

with my old asus M2N no pb with my printer-scanner

since i upgraded to Z97-P i get a pb to print and scan

i upgrade the kernel to 
a standard kernel 4.3.0-17 from http://download.opensuse.org/repositories/Kernel:/stable/standard/
and
sane-backend to 1.0.25 from http://download.opensuse.org/repositories/graphics/openSUSE_13.1/

i get some little progress :

- librefoffice writer : now it reads scanner features well but don't scan

- now i must only switch off , switch on the printer-scanner in order to get a ready printer-sacanner . previously i must to switch off the printer-scanner then shutdown the pc then start the pc then switch on the printer-scanner .

- after a fail scanning it is not necessary to kill xsane i cna quit it .

but

there are remaining problems :

- LO writer : i get a message "scan job started" and that's all
i must switch off, switch on the printer-scanner to make a scanning with other app

- skanlite detects the scanner but  i get a message "waiting for the scanner to start" and that's all
i must kill skanlite because it seems freezed
i must switch off , switch on the printer-scanner to make a scanning with other app

- xsane :
 if i don't wait after switching on the printer sacanner i can scan
but if i wait several minute i can't scan (error i/o)

after one scanning i can't scan (error i/o)

in addition :

in bios usb settings there are 3 parameters (default value in () ):

Legacy USB support (Enabled) : Enabled | Disabled

Intel xHCI mode (Smart auto) : Smart auto | Auto | Enabled | Disabled

EHCI Hand-off (Disabled) : Enabled | Disabled

i experimented with previous kernel that "Auto" is the best one .
perhaps i must to search again the best value for "Intel xHCI mode" ?

with previous kernel i tried the value "disable" for "Intel xHCI mode"
then same pb

Asus Z97-P gets an UEFI bios with secure boot .

i describe my pc setup :

in the first disk i installed LEAP 42.1 x86_64 to replace my old mandriva
in the 3rd disk opensuse 13.1 x86_64 is installed .

pc boots by default with LEAP 42.1 then LEAP 42.1 launches Opensuse 13.1 by default

when installing LEAP 42.1 i get a question "do you trust opensuse secureboot ?"
then i answer "yes" (i didn't know what to answer)

i wonder if i must change the boot loader from GRUB2 to GRUB2-UEFI for Opensuse 13.1 ? Is it related to my problem ?

thanks

with current kernel 4.3.0-17.1 i tried the value "disable" for "Intel xHCI mode"
then 
i didn't get the time to make any test . i get again this pb already encountered with previous kernel : after a random delay my mouse and kb are disabled !
then
i return to "Auto"

today i experiment printing .

result : it's worst than with previous kernel 3.11

with kernel 3.11 i can print one time before i/o error

with kernel 4.3.0-17.1 i can't print : 
- printing begins we see at the printer panel a blinking light indicating printer receives the text then suddenly the error indicator lights  .
i must switch off switch on the printer-scanner to initialize it again .
i must kill the process "hp" .

i get no problem with all other usb devices : mouse , kb , bluetooth dongle , webcam , card reader .

i assume there is a pb around xhci driver (other driver ohci , ehci , usblp ?) and usb 1.1 protocol , the one used by my printer-scanner .

Episteme, first of all, if you're uncertain with a foreign language, it is really awful to use acronyms like pb. This renders your expressions nearly unreadable. If you don't want to be ignored, stop this, please!

Next, did you read the complete thread? Yes, there are some issues related to xhci and scanners, but most of them were sorted out around the Linux 4.0 time frame.

If you still suffer from those, you should experiment with different BIOS settings and some distribution released kernel without any special xhci parameter, but only turn ONE knob at a time and test (this is a general advice).

Get used to scanimage to test the scanner.

Try different USB ports from your ATX area.

If all attempts fail, report to linux-usb, and/or consider purchasing a USB2 PCI card.

>> Episteme, first of all, if you're uncertain with a foreign language, it is 
>> really awful to use acronyms like pb. This renders your expressions nearly 
>> unreadable. If you don't want to be ignored, stop this, please!

sorry

>> If you still suffer from those, you should experiment with different BIOS 
>> settings 

i already experimented this without any success

>> experiment ...some distribution released kernel without any special xhci parameter

i don't understand "without any special xhci parameter"


>> Try different USB ports from your ATX area.

i tried all types of port (1/2.0 and 3.0) without any success


i will buy an usb 2 pci card

no more problem .

i get a pci usb 1.1/2.0 4+1 ports adapter (NEC chipset 13235)

http://www.amazon.fr/gp/product/B00O0TR60Y?psc=1&redirect=true&ref_=oh_aui_detailpage_o01_s01

Only FYI:

Currently it seems "USB3/xhci and scanners" is "fubar" according to the
"Xsane can't find scanner - again, but this one is USB" mail thread
on the sane-devel@lists.alioth.debian.org mailing list.

See in particular
http://lists.alioth.debian.org/pipermail/sane-devel/2016-January/034252.html
and
http://lists.alioth.debian.org/pipermail/sane-devel/2016-January/034254.html
(excerpts):
-----------------------------------------------------------------------------
Alessandro Zummo ... wrote:

A few days ago I changed my motherboard (now an Asus Z701-A,
kernel 4.3.3) and it seems that USB3 always fails while testing
my epsonds driver. All ports, even usb 2.0 ones, are under xhci

I'm now trying to understand if there's a problem with
the driver, libusb 1.0 or something else.


  sanei_usb_set_altinterface (dn, devices[dn].alt_setting);

which was supposed to fix things, seems to be the root cause
of my problem. removing it and adding a tweak to epsonds
greatly improved the success rate, which is now near to 100%


m. allan noah wrote:

Yes - it seems that recent linux kernels no longer like our workaround.
My current plan is to make that workaround controlled by an
environment variable, since we cannot know when it is required or not.
----------------------------------------------------------------------------

Because it seems things in the kernel are still changing
and because I am neither a USB nor a kernel expert
my current "plan" (more correctly all what I can do) is:
Waiting until first things in the kernel have stabilized
and then waiting until SANE upstream has adapted.

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

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

FYI:
sane-backends-1.0.27 RPM packages for openSUSE users
are now available in the openSUSE Build Service
development project "graphics" for manual download
for openSUSE Leap and openSUSE Tumbleweed from
http://download.opensuse.org/repositories/graphics/

In general see the section
"RPM packages of the 'sane-backends' scanner drivers"
at https://en.opensuse.org/SDB:Configuring_Scanners

The sane-backends version 1.0.27 release contains
in particular this change regarding USB3
for details see http://www.sane-project.org/
-----------------------------------------------------------------
 * Updated Linux USB3 workaround (see Note 3).
...
Note 3: The Linux USB3 workaround which was added
in version 1.0.25 is now disabled by default.
If you have difficulty using a scanner which previously worked,
or intermittent scanner availability, try setting the new
environment variable SANE_USB_WORKAROUND=1
before starting your frontend. 
-----------------------------------------------------------------

I assume the issue is fixed in sane-backends version 1.0.27.

i assume that hplip-sane does not use sane-backends thus problem is not fixed for my printer-scanner hp 1220. right?