Bug 1028549 - System Can't Claim SCSI Scanner [NEEDINFO]
System Can't Claim SCSI Scanner
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: sane-backends (Show other bugs)
19
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Nils Philippsen
Fedora Extras Quality Assurance
:
: 989241 (view as bug list)
Depends On:
Blocks: 1032805
  Show dependency treegraph
 
Reported: 2013-11-08 13:33 EST by KitchM
Modified: 2013-12-20 12:54 EST (History)
5 users (show)

See Also:
Fixed In Version: sane-backends-1.0.24-7.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1032805 (view as bug list)
Environment:
Last Closed: 2013-12-03 05:35:40 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tech: needinfo? (extras-qa)


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 919874 None None None Never

  None (edit)
Description KitchM 2013-11-08 13:33:59 EST
Description of problem:
SCSI Scanner not recognized by system

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Boot system
2.Run sane.
3.

Actual results:
No scanner

Expected results:
Should see scanner

Additional info:
Comment 1 Nils Philippsen 2013-11-14 05:50:51 EST
This bug report is missing essential information:

- What type of scanner is this?
- Please post the output of the following commands:

cat /proc/scsi/scsi
ls -lZ /dev/sg*
Comment 2 Nils Philippsen 2013-11-14 06:00:00 EST
Ahh, it's probably the scanner you mentioned in bug #919874, a Umax Astra 2400S attached to a Domex 536 SCSI host adapter. I'll still need the output of the two commands from comment #1, thanks!
Comment 3 Nils Philippsen 2013-11-14 06:06:43 EST
*** Bug 989241 has been marked as a duplicate of this bug. ***
Comment 4 KitchM 2013-11-14 10:32:28 EST
Umax Astra 2400S

Attached devices:
Host: scsi4 Channel: 00 Id: 01 Lun: 00
  Vendor: UMAX     Model: Astra 2400S      Rev: V1.1
  Type:   Scanner                          ANSI  SCSI revision: 02
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD400EB-00CP Rev: 06.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: PLEXTOR  Model: CD-R   PX-W2410A Rev: 1.02
  Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: ASUS     Model: DRW-1814BL       Rev: 1.14
  Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: KINGSTON SV300S3 Rev: 505A
  Type:   Direct-Access                    ANSI  SCSI revision: 05


crw-------  root root  ?                                /dev/sg0
crw-rw----  root disk  ?                                /dev/sg2
crw-rw----+ root cdrom ?                                /dev/sg3
crw-rw----+ root cdrom ?                                /dev/sg4
crw-rw----  root disk  ?                                /dev/sg5


Thank you.
Comment 5 Nils Philippsen 2013-11-15 11:30:42 EST
It seems as if the permissions of your scanner device /dev/sg0 aren't set up correctly. Please run the following command for me (as root) and post the output:

udevadm info --query=all /dev/sg0

We need to find out what udev makes of this device.
Comment 6 KitchM 2013-11-15 12:13:07 EST
Here's the response:

P: /devices/pci0000:00/0000:00:06.0/ata1/host0/target0:0:0/0:0:0:0/scsi_generic/sg0
N: sg0
E: DEVNAME=/dev/sg0
E: DEVPATH=/devices/pci0000:00/0000:00:06.0/ata1/host0/target0:0:0/0:0:0:0/scsi_generic/sg0
E: MAJOR=21
E: MINOR=0
E: SUBSYSTEM=scsi_generic




Thanks much.
Comment 7 Nils Philippsen 2013-11-20 16:10:42 EST
Sorry for the wait but I think that I have found the cause of your problem in the meantime (I could reproduce the issue with my own SCSI hardware):

- The udev rules shipped with sane-backends seem to have ceased working, I can only speculate that this is due to some changes in sysfs.
- This resulted in the system not recognizing your scanner as such, i.e. not giving your user the necessary permissions on its SCSI generic device file.
- I've modified my local udev rules and with the changes I did, my SCSI scanner was again recognized as such, and the device file got the proper permissions.

I've committed a patch upstream and will build packages containing the fix shortly.
Comment 8 Fedora Update System 2013-11-20 17:08:04 EST
sane-backends-1.0.24-7.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/sane-backends-1.0.24-7.fc18
Comment 9 Fedora Update System 2013-11-20 17:08:36 EST
sane-backends-1.0.24-7.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/sane-backends-1.0.24-7.fc19
Comment 10 Fedora Update System 2013-11-20 17:09:03 EST
sane-backends-1.0.24-7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/sane-backends-1.0.24-7.fc20
Comment 11 KitchM 2013-11-20 17:32:34 EST
Wow.  That sounds like good news.

When do you think it will be in the repos as an update?

Thanks.
Comment 12 Nils Philippsen 2013-11-21 05:08:01 EST
While the packages are not yet available through the updates-testing repository, you can download them directly:

- Follow the update link for your version of Fedora above (comment #8 ff.)
- On the update page, follow the link after "Builds:" into our build system and download the package files appropriate for you into a temporary directory. Check what you have installed with "rpm -qa sane-backends\* | sort" on the terminal command line, then pick the new versions of only the packages you have installed. Be sure to download 32bit and 64bit files where you have both installed on your system.
- Update to the new versions downloaded into the temporary directory: "yum localupdate sane-backends*.rpm"
Comment 13 KitchM 2013-11-21 14:34:07 EST
I just tried it a few times, including turning off the system and scanner, and rebooting it while turning on the scanner.  It is still not claimed.
Comment 14 Nils Philippsen 2013-11-22 11:49:49 EST
(In reply to KitchM from comment #13)
> I just tried it a few times, including turning off the system and scanner,
> and rebooting it while turning on the scanner.  It is still not claimed.

With it not being claimed I assume you refer to the output of "lshw" or its GUI respectively. I've just run this on my machine and it states that my scanner is "UNCLAIMED" as well:

[...]
              *-scanner UNCLAIMED
                   description: SCSI Scanner
                   physical id: 0.5.0
                   bus info: scsi@14:0.5.0
[...]

I assume that this means that no kernel device driver claims this device, which is perfectly correct: Scanner drivers are external to the Linux kernel which provides mechanisms (USB, SCSI) to transfer data between the scanner and a scanning application (e.g. xsane, scanimage, simple-scan).

Regardless of this, with the new package version the generic SCSI device for my scanner has the proper permissions for a logged-in user and scanning itself worked fine. Have you actually tried scanning, or did you just rely on this tool? I'm asking because in addition to questionably labeling SCSI devices (and presumably other devices which aren't handled by kernel drivers), it didn't even list my scanner while the scan was in progress, so I wouldn't put too much value in info by lshw alone.

Please try this:

- If you haven't tried it out yet, try to scan, e.g. using xsane. If that works, you can skip the following steps :).

Only if scanning with xsane doesn't work, continue:

- Run both "sane-find-scanner" and "scanimage -L" as your normal user while logged into a graphical desktop. If the latter command doesn't identify your scanner, run the commands again as root. Post the output of the commands.

- Identify your generic SCSI device file: Run "cat /proc/scsi/scsi", the position in the list determines the device file name: first is /dev/sg0, second is /dev/sg1 and so forth. I'll assume it's "/dev/sg0" below, please substitute the actual file name if it's different.

- Run the commands "udevadm info /dev/sg0" and "udevadm info --attribute-walk /dev/sg0 2>&1 | tee /tmp/udevadm-info-attrwalk.txt". Post the output of the first command and attach the output of the second (the file "/tmp/udevadm-info-attrwalk.txt") to this bug (it should be quite long).

Thanks!
Comment 15 Fedora Update System 2013-11-23 14:48:15 EST
Package sane-backends-1.0.24-7.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sane-backends-1.0.24-7.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-21847/sane-backends-1.0.24-7.fc18
then log in and leave karma (feedback).
Comment 16 KitchM 2013-11-26 12:52:08 EST
Yes, I was referring to lshw.

I turned on the scanner and rebooted the computer.  I ran xsane and selected to scan.  It operated the scanner and there was movement across the table, from one end to the other, but it never parked itself, and the program never received the data.  Ran sane-find-scanner and the terminal hung, and then the system hung.  Had to reset.

Neither now or before was there a scanner found in lshw.  At least I had that before today.  Odd.

So now I ran sane-find-scanner as root and got back:
 # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

  # No SCSI scanners found. If you expected something different, make sure that
  # you have loaded a kernel SCSI driver for your SCSI adapter.

could not fetch string descriptor: Pipe error
could not fetch string descriptor: Pipe error
  # No USB scanners found. If you expected something different, make sure that
  # you have loaded a kernel driver for your USB host controller and have setup
  # the USB system correctly. See man sane-usb for details.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary ports
  # can't be detected by this program.


No need to run xsane, I guess.

Ran cat /proc/scsi/scsi and received back:
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD400EB-00CP Rev: 06.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: PLEXTOR  Model: CD-R   PX-W2410A Rev: 1.02
  Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: ASUS     Model: DRW-1814BL       Rev: 1.14
  Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: KINGSTON SV300S3 Rev: 505A
  Type:   Direct-Access                    ANSI  SCSI revision: 05

I don't see my scsi domex card.

Can't run udevadm info /dev/sg0" and "udevadm info --attribute-walk /dev/sg0 2>&1 | tee /tmp/udevadm-info-attrwalk.txt" and results are attached.  There is no item for either the card or the scanner.
Comment 17 KitchM 2013-11-26 12:53:52 EST
lshw returns this info:
SCSI storage controller
/0/9/7


product: Domex 536 [134A:1]
vendor: DTC Technology Corp. [134A]
bus info: pci@0000:05:07.0
version: 00
width: 32 bits
clock: 33MHz
capabilities:
	scsi
configuration:
	driver: dmx3191d
	latency: 0
resources:
	irq: 17
	ioport: b400(size=32)
Comment 18 Fedora Update System 2013-12-03 05:35:40 EST
sane-backends-1.0.24-7.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 19 Nils Philippsen 2013-12-04 11:43:42 EST
(In reply to KitchM from comment #16)
> Ran cat /proc/scsi/scsi and received back:
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
>   Vendor: ATA      Model: WDC WD400EB-00CP Rev: 06.0
>   Type:   Direct-Access                    ANSI  SCSI revision: 05
> Host: scsi1 Channel: 00 Id: 00 Lun: 00
>   Vendor: PLEXTOR  Model: CD-R   PX-W2410A Rev: 1.02
>   Type:   CD-ROM                           ANSI  SCSI revision: 05
> Host: scsi1 Channel: 00 Id: 01 Lun: 00
>   Vendor: ASUS     Model: DRW-1814BL       Rev: 1.14
>   Type:   CD-ROM                           ANSI  SCSI revision: 05
> Host: scsi2 Channel: 00 Id: 00 Lun: 00
>   Vendor: ATA      Model: KINGSTON SV300S3 Rev: 505A
>   Type:   Direct-Access                    ANSI  SCSI revision: 05
> 
> I don't see my scsi domex card.

SCSI host adapters aren't listed in /proc/scsi/scsi, only devices connected to and recognized by them. I guess that either the host adapter isn't recognized, or it can't detect the scanner (perhaps it isn't properly terminated).

Please run this command to find out if the SCSI host adapter is known to Linux:

fgrep "" /sys/bus/scsi/devices/host*/scsi_host/host*/proc_name

It should then list the sys files of each IDE/SATA/SCSI adapter found and its associated name. On my machine, its output contains this line:

/sys/bus/scsi/devices/host14/scsi_host/host14/proc_name:sym53c8xx

It tells me that the SCSI bus #14 is driven by the sym53c8xx driver. I'd expect something containing "dmx3191d" as the /proc name for your SCSI card, if not the problem is deeper than some device permissions. In that case, check the output of "modinfo dmx3191d" as well.
Comment 20 KitchM 2013-12-04 12:10:29 EST
Returns:
/sys/bus/scsi/devices/host0/scsi_host/host0/proc_name:pata_amd
/sys/bus/scsi/devices/host1/scsi_host/host1/proc_name:pata_amd
/sys/bus/scsi/devices/host2/scsi_host/host2/proc_name:sata_nv
/sys/bus/scsi/devices/host3/scsi_host/host3/proc_name:sata_nv
/sys/bus/scsi/devices/host4/scsi_host/host4/proc_name:dmx3191d

So it seems to be recognized.
Comment 21 KitchM 2013-12-04 12:12:49 EST
I can change the ID on the back of the scanner (0 thru 9).  It is on 1 now, but used to be on 5, I believe.

The termination plug exists on the scanner, and has never been removed.
Comment 22 Nils Philippsen 2013-12-05 05:14:07 EST
(In reply to KitchM from comment #21)
> I can change the ID on the back of the scanner (0 thru 9).

This looks odd to me, usually it's either 0-7 ("narrow" SCSI) or 0-15 (wide SCSI).

> It is on 1 now, but used to be on 5, I believe.

Both should be safe as long as there are no other devices on the bus with conflicting IDs (the host adapter should use ID 7 for instance).

> The termination plug exists on the scanner, and has never been removed.

Hmm: The host adapter is recognized by the OS meanwhile, but not the scanner... that either seems to leave a problem in the driver (but the driver is very mature, stemming from 2000 or so) or a hardware issue. Have you successfully accessed the scanner from this computer using a different operating system (older Fedora version, alternative Linux distribution, Windows)?
Comment 23 Nils Philippsen 2013-12-05 05:24:12 EST
Oh, do you have any other SCSI device you could try connecting to that host adapter and check if it gets recognized by the kernel (i.e. is listed in /proc/scsi/scsi)? You need to reboot or issue a SCSI but reset so the kernel looks for newly attached devices:

echo "- - -" > /sys/bus/scsi/devices/host4/scsi_host/host4/scan
Comment 24 KitchM 2013-12-05 09:57:32 EST
I have used the scanner successfully on all other Linux distros I've used in the past, including Mandriva and Arch.  It is usually found automatically.  I cannot say if I ever had to configure anything before.

I have no other SCSI device to try.  This is my only one.
Comment 25 KitchM 2013-12-05 09:59:04 EST
BTW, I love SCSI because it is so fast, but I hate it because the cables are so short.  But I hate to replace the scanner because it has such high res and has served me very well.
Comment 26 Fedora Update System 2013-12-10 01:08:46 EST
sane-backends-1.0.24-7.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 27 Fedora Update System 2013-12-13 21:49:57 EST
sane-backends-1.0.24-7.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 28 KitchM 2013-12-20 12:54:21 EST
I just upgraded to Fedora 20.  Exact same problem exists.  Hardware Lister could not find the scanner and after a few reboots and turning the scanner off and on during reboot, it now states:
SCSI Scanner
/0/9/7/0.1.0

bus info: scsi@2:0.1.0

this device hasn't been claimed

Xsane could find no scanner before, but now it just freezes when attempting to scan.  I was able to close the app after it stopped responding.

Then I started GIMP, but it froze the whole system when it got to the part where it states:
Querying new Plug-ins
xsane

Had to reset computer and finish this post.

Do you think that it is just the operating system as a whole, and that I should just find another distro?

Note You need to log in before you can comment on or make changes to this bug.