I have problems with Samsung SCX-3205 scanner on Toshiba Satellite L855. When is scanner connected to the notebook (via USB) I can see it via `scanimage -L` on first attempt but on any other attempt I can't see it any more, unless I turn the scanner off and on. Currently using 3.5.3-1.fc17.x86_64 kernel (but it also happens with 3.6.0-0.rc4.git2.1.fc18). The latest working kernel is 2.6.39-1.fc16 on that hardware (2.6.40 which was in fact 3.0, I guess, does not work). That scanner with identical OS - Fedora 17 - worked well on Lenovo T510 (Sandy Bridge -- USB 2.0 only), the new Toshiba L855 (Ivy Bridge with USB 3.0 -- xHCI) fails here. I somehow think it's related to the xhci driver, hence Cc-ing Sarah. Is there a way how to disable xhci driver in favor of ehci (xhci and ehci are both compiled-in), so I can try with ehci?
Created attachment 79941 [details] lspci.2.6.39-1.fc16.x86_64
Created attachment 79951 [details] lspci.3.5.3-1.fc17.x86_64
Created attachment 79961 [details] lspci-v.2.6.39-1.fc16.x86_64
Created attachment 79971 [details] lspci-v.3.5.3-1.fc17.x86_64
Created attachment 79981 [details] lspci-vv.2.6.39-1.fc16.x86_64
Created attachment 79991 [details] lspci-vv.3.5.3-1.fc17.x86_64
Created attachment 80001 [details] lsusb.2.6.39-1.fc16.x86_64
Created attachment 80011 [details] lsusb.3.5.3-1.fc17.x86_64
Created attachment 80021 [details] lsusb-v.2.6.39-1.fc16.x86_64
Created attachment 80031 [details] lsusb-v.3.5.3-1.fc17.x86_64
Created attachment 80041 [details] lsusb-vv.2.6.39-1.fc16.x86_64
Created attachment 80051 [details] lsusb-vv.3.5.3-1.fc17.x86_64
On Wed, Sep 12, 2012 at 05:06:16PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > Summary: Samsung SCX-3205 scanner does not work with Toshiba > Satellite L855 Please post this on the linux-usb@vger.kernel.org mailing list.
If this is still seen with modern kernels please update
It works for me with kernel-3.12.5-302.fc20.x86_64.
What update should I provide? It worked for a while but I had to return to USB2 via EHCI. The symptoms are the same: with USB3 via xHCI the scanner appears in output of `scanimage -L` but disappears on second (or any other) attempt to initialize it via scanimage. Reopening.
Knowing that it fails on 3.12 is the information needed. This may well not be a kernel bug - some USB1/2 hardware fails on USB3 controllers even though it should all be compatible. From a quick search all the reports I see are Linux rather than Windows however.
I suspect this is due to a long-standing xHCI driver bug. There's a proposed fix, but it's still in RFC: http://marc.info/?l=linux-usb&m=138116117104619&w=2 Michal: can you try applying that patch and see if it helps? Another related bug report, for reference: http://marc.info/?l=linux-usb&m=138758292722526&w=2
Created attachment 120771 [details] kernel warnings with the patch from previous comment Tried that patch on top of 3.13.0-0.rc6.git0.1 and it works for me. Tried `simple-scan`, `xsane`, and `scan-image`. However I get kernel warnings when the program e.g. xsane starts and ends. Also especially xsane became sluggish when asked to turn itself off. Kernel warnings follow in the attachment.
Thanks for testing Michal. Ok, so I know what the root cause of your issue is. It's not surprising that the patch has race conditions that cause list corruption, since it was a pretty early RFC. I'll need to take the patch and rework it a bit before I get the race conditions worked out. In the meantime, have you tried unplugging and replugging the scanner in between scans? This has worked in the past for other people with this issue.
(In reply to Sarah Sharp from comment #20) > In the meantime, have you tried unplugging and replugging the scanner in > between scans? This has worked in the past for other people with this issue. Have to say, I did not at that time. Luckily, this is not needed anymore. I just tested kernel-3.19.3-200.fc21.x86_64 with USB3 with the Samsung scanner and it worked fine for a resolution of 150 DPI, and less. With 300 DPI it got sluggish, the scanning device moved 1 cm ahead and then 0.5 cm back, all the time, I got the scan in the end but the scanning process was one fold slower that with USB2. With DPI set to 2400 it got practically unusable. There were no messages of interest in systemd's journal. Let me know if there's anything I can do to help.
Surprisingly, with kernel-4.1.2-200.fc22.x86_64 everything works as expected up to 2400 DPI (the maximum for the scanner). The only concern I have is following message I have three times in the kernel log for 150 DPI scanning, and 42 times for 300 DPI scanning: xhci_hcd 0000:00:14.0: WARN Event TRB for slot 4 ep 6 with no TDs queued?