Bug 919874

Please check if you have the sane-backends-drivers-scanner package installed. Thanks!

Yes.  version 1.0.23-7.fc17   x86-64

A few questions:

- What kind of scanner hardware do you have? The lshw output above only seems to mention the SCSI controller model.

- Is it listed in /proc/scsi/scsi? Mind that SCSI doesn't automatically recognize a device being switched on so you need to make the device known manually to the OS if you switched it on after you booted your system.

Yes, that is the whole point.  While the scsi card is clearly seen, nothing takes ownership of it.  Therefore, nothing plugged into it will be seen.

The real question is why does the OS not take ownership of the card?

As one observation, I notice that the OS appears to be compiled to look for all sorts of bluetooth and input devices and various network cards I don't use.  It is even confused about my Sound Blaster sound card; it thinks it is an Ensoniq instead of Creative Labs.  Too bad it doesn't find standard scsi stuff.

The scanner is a Umax Astra 2400S.

I will reboot to check the last part for you.

Okay, rebooted with scanner on.  The scsi file only shows my drives, and nothing else.  It shows an SDD, an HDD, a CD-RW and a DVD-RW.

(In reply to comment #4)
> Yes, that is the whole point.  While the scsi card is clearly seen, nothing
> takes ownership of it.  Therefore, nothing plugged into it will be seen.
> 
> The real question is why does the OS not take ownership of the card?

This is because SCSI simply isn't designed for plug-and-play. "Real" SCSI hardware doesn't generate events if a device connected to the bus is switched on/off, or plugged in/out respectively. The only way to programmatically learn about new devices is to reset the SCSI bus in question, thus triggering device enumeration, which impedes normal operation and kills efficiency -- and doesn't remove devices that have gone either.

> As one observation, I notice that the OS appears to be compiled to look for
> all sorts of bluetooth and input devices and various network cards I don't
> use.

That's because the underlying layers (PCI/PCIe, USB, ...) allow for hot-plugging hardware, so if a device is plugged in /out, switched on/off the OS will be notified about it. Supporting plug-and-play in such an event-driven scenario is easy and fairly efficient.

(In reply to comment #5)
> Okay, rebooted with scanner on.  The scsi file only shows my drives, and
> nothing else.  It shows an SDD, an HDD, a CD-RW and a DVD-RW.

These are probably all ATA/SATA devices which are also handled by the Linux kernel SCSI layer -- please don't confuse this with actual SCSI hardware, the naming is a bit obtuse. The kernel SCSI layer itself should support hot-plugging in order to support eSATA for instance. Considering this, I guess the message "this device hasn't been claimed" means the kernel hasn't found a driver to operate your SCSI controller. Please tell me its PCI id, you can list devices with their ids and associated kernel drivers with "lspci -vnnk". Thanks.

Thanks very much, Nils, for that very clear explanation.  I liked it and found it helpful.

One additonal thing I might mention is that I have never not had my card recognized by any other Linux distro.

Here's the info you requested:
00:00.0 Memory controller [0580]: nVidia Corporation CK804 Memory Controller [10de:005e] (rev a3)
	Subsystem: ASUSTeK Computer Inc. A8N-E Mainboard [1043:815a]
	Flags: bus master, 66MHz, fast devsel, latency 0
	Capabilities: [44] HyperTransport: Slave or Primary Interface
	Capabilities: [e0] HyperTransport: MSI Mapping Enable+ Fixed-

00:01.0 ISA bridge [0601]: nVidia Corporation CK804 ISA Bridge [10de:0050] (rev a3)
	Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:815a]
	Flags: bus master, 66MHz, fast devsel, latency 0

00:01.1 SMBus [0c05]: nVidia Corporation CK804 SMBus [10de:0052] (rev a2)
	Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:815a]
	Flags: 66MHz, fast devsel, IRQ 255
	I/O ports at d800 [size=32]
	I/O ports at 4c00 [size=64]
	I/O ports at 4c40 [size=64]
	Capabilities: [44] Power Management version 2
	Kernel driver in use: nForce2_smbus

00:02.0 USB Controller [0c03]: nVidia Corporation CK804 USB Controller [10de:005a] (rev a2) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:815a]
	Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23
	Memory at d2002000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
	Kernel driver in use: ohci_hcd

00:02.1 USB Controller [0c03]: nVidia Corporation CK804 USB Controller [10de:005b] (rev a3) (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:815a]
	Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22
	Memory at 80000000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [44] Debug port: BAR=1 offset=0098
	Capabilities: [80] Power Management version 2
	Kernel driver in use: ehci_hcd

00:06.0 IDE interface [0101]: nVidia Corporation CK804 IDE [10de:0053] (rev f2) (prog-if 8a [Master SecP PriP])
	Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:815a]
	Flags: bus master, 66MHz, fast devsel, latency 0
	[virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
	[virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
	[virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
	[virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1]
	I/O ports at f000 [size=16]
	Capabilities: [44] Power Management version 2
	Kernel driver in use: pata_amd

00:08.0 IDE interface [0101]: nVidia Corporation CK804 Serial ATA Controller [10de:0055] (rev f3) (prog-if 85 [Master SecO PriO])
	Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:815a]
	Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21
	I/O ports at 09e0 [size=8]
	I/O ports at 0be0 [size=4]
	I/O ports at 0960 [size=8]
	I/O ports at 0b60 [size=4]
	I/O ports at d400 [size=16]
	Memory at d2001000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
	Kernel driver in use: sata_nv

00:09.0 PCI bridge [0604]: nVidia Corporation CK804 PCI Bridge [10de:005c] (rev a2) (prog-if 01 [Subtractive decode])
	Flags: bus master, 66MHz, fast devsel, latency 0
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=128
	I/O behind bridge: 0000b000-0000bfff

00:0a.0 Bridge [0680]: nVidia Corporation CK804 Ethernet Controller [10de:0057] (rev a3)
	Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:8141]
	Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20
	Memory at d2000000 (32-bit, non-prefetchable) [size=4K]
	I/O ports at c000 [size=8]
	Capabilities: [44] Power Management version 2
	Kernel driver in use: forcedeth

00:0b.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	Capabilities: [40] Power Management version 2
	Capabilities: [48] MSI: Enable+ Count=1/2 Maskable- 64bit+
	Capabilities: [58] HyperTransport: MSI Mapping Enable- Fixed-
	Capabilities: [80] Express Root Port (Slot+), MSI 00
	Capabilities: [100] Virtual Channel
	Kernel driver in use: pcieport

00:0c.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	Capabilities: [40] Power Management version 2
	Capabilities: [48] MSI: Enable+ Count=1/2 Maskable- 64bit+
	Capabilities: [58] HyperTransport: MSI Mapping Enable- Fixed-
	Capabilities: [80] Express Root Port (Slot+), MSI 00
	Capabilities: [100] Virtual Channel
	Kernel driver in use: pcieport

00:0d.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	Capabilities: [40] Power Management version 2
	Capabilities: [48] MSI: Enable+ Count=1/2 Maskable- 64bit+
	Capabilities: [58] HyperTransport: MSI Mapping Enable- Fixed-
	Capabilities: [80] Express Root Port (Slot+), MSI 00
	Capabilities: [100] Virtual Channel
	Kernel driver in use: pcieport

00:0e.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000a000-0000afff
	Memory behind bridge: d0000000-d1ffffff
	Prefetchable memory behind bridge: 00000000c0000000-00000000cfffffff
	Capabilities: [40] Power Management version 2
	Capabilities: [48] MSI: Enable+ Count=1/2 Maskable- 64bit+
	Capabilities: [58] HyperTransport: MSI Mapping Enable- Fixed-
	Capabilities: [80] Express Root Port (Slot+), MSI 00
	Capabilities: [100] Virtual Channel
	Kernel driver in use: pcieport

00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
	Flags: fast devsel
	Capabilities: [80] HyperTransport: Host or Secondary Interface

00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101]
	Flags: fast devsel

00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102]
	Flags: fast devsel

00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103]
	Flags: fast devsel
	Kernel driver in use: k8temp

01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Redwood PRO [Radeon HD 5500 Series] [1002:68d9] (prog-if 00 [VGA controller])
	Subsystem: XFX Pine Group Inc. Device [1682:3059]
	Flags: bus master, fast devsel, latency 0, IRQ 44
	Memory at c0000000 (64-bit, prefetchable) [size=256M]
	Memory at d1000000 (64-bit, non-prefetchable) [size=128K]
	I/O ports at a000 [size=256]
	Expansion ROM at d0000000 [disabled] [size=128K]
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Legacy Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [150] Advanced Error Reporting
	Kernel driver in use: radeon

01:00.1 Audio device [0403]: ATI Technologies Inc Redwood HDMI Audio [Radeon HD 5600 Series] [1002:aa60]
	Subsystem: XFX Pine Group Inc. Device [1682:aa60]
	Flags: bus master, fast devsel, latency 0, IRQ 45
	Memory at d1020000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Legacy Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [150] Advanced Error Reporting
	Kernel driver in use: snd_hda_intel

05:06.0 Multimedia audio controller [0401]: Ensoniq 5880B [AudioPCI] [1274:5880] (rev 02)
	Subsystem: Ensoniq Sound Blaster 16PCI 4.1ch [1274:8001]
	Flags: bus master, slow devsel, latency 32, IRQ 16
	I/O ports at b000 [size=64]
	Capabilities: [dc] Power Management version 1
	Kernel driver in use: snd_ens1371

05:07.0 SCSI storage controller [0100]: DTC Technology Corp. Domex 536 [134a:0001]
	Flags: medium devsel, IRQ 11
	I/O ports at b400 [size=32]


I also noted that the sound card is still wrongly identified as well.  It should be a Sound Blaster.

But I still need my scanner to work.  No other distro has failed me in this area before.  Something needs to be done about this very soon.

Can anyone help me?

Sorry for not getting back earlier to you. I'm currently trying to find out which driver is supposed to drive your card.

Thanks very much.  I sure glad your helping.  I really hate to change distros again.  I just need that scanner to work.

By the way, isn't there a difference between the Domex brand it is and the DTC Technology Corp. Domex that is listed above?

Never mind.  The D in DTC stands for Domex.  Duh.  I had forgotten.

It seems as if the driver for your card -- dmx3191d -- simply isn't built and packaged in the Fedora kernels:

nils@gibraltar:~/devel/git/fedora/kernel (master)> grep CONFIG_SCSI_DMX3191D *config*
config-generic:# CONFIG_SCSI_DMX3191D is not set

I haven't found any reference why this is the case, this has been the case as far as git history reaches back, nobody else seems to have missed it either. I'll change the component to kernel so the kernel team can look why this is the case. I guess it may just be an oversight, in which case it should be easily fixable.

Thanks, Nils.

Isn't there just a common database of hardware information that everyone uses for their kernel builds?

The discovery doesn't recognize my sound card either; a Creative Labs CT4750 with Creative chip CT5880-DCQ.  There is no way in God's green Earth that should be recognized as an Ensoniq.  I've never had the problem before either.

Worse yet is the fact that Fedora keeps wanting to install all sorts of programs that my computer does not support whenever I install anything much at all.  For instance, bluetooth and tablet and NIC stuff.

I just don't understand why Fedora is having so much problem in these basic areas.

I'm not aware of a common hardware database used for determining which drivers to build and which not. Do you have any issues with your sound card? In my experience it's not uncommon for some Soundblaster models to be recognized as Ensoniq because they use the same chipsets (and this seems to be the case here -- its subsystem lists as "Ensoniq Sound Blaster 16PCI 4.1ch [1274:8001]").

As to packages being installed supporting hardware you don't have, it may be in part because Fedora wants hardware be supported out of the box, without the user having to install additional software (just speculation on my behalf). Discussion about whether that's good or bad, which alternatives exist, etc. is off-topic in this bug report, though.

I've enabled the driver the the SCSI card.  It seems it was inadvertently turned off with an old commit.

Thanks, Josh.  Will that show up in the next kernel update?

Thanks, Nils.  The card does not use an Ensoniq chip.  It actually uses the "Creative CT5880 DQ" chip, as it is stamped right on it.  The preeminent brand would be Creative Labs and not Ensoniq. Besides,Creative Technology bought Ensoniq at one time.  And while they might have shared some chips at some point, this appears not to be the case on this card.  Just saying.  In any case, thanks much.

kernel-3.8.6-203.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.8.6-203.fc18

Thanks for the info.  Now all I have to do is wait for an update from 17 to 18 I guess.

Package kernel-3.8.6-203.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 kernel-3.8.6-203.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5368/kernel-3.8.6-203.fc18
then log in and leave karma (feedback).

kernel-3.8.6-203.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

It turns out that the kernel change evidently made the Domex card recognizable.  However, the scanner still fails to have a proper communication channel because it continues to freeze up the system whenever accessed.

If using Simple Scan the system will freeze after a few seconds after opening.  If using Scanner Tool it brings up GIMP which causes a system freeze when selecting to scan.

Is this still a kernel problem?

Thanks.

Any one?

With the latest kernel updates and upgrades, the scanner still does not work.  Xsane says there is no hardware, and sand-find-scanner reports that no scsi scanners were found.

Everytime I use one of the scanner-related software programs, the whole system freezes and requires a computer reset.

Now that the Domex card is recognized correctly, why doesn't the kernel see all scsi devices?

Added 2 gigs of RAM for a total of 4.  Changed nothing else but kept up on any upgrades available.

Tried to run the scanner tool and got the GIMP to start up ready to scan.  Tried to scan and the system froze again, requiring a reset.

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Just fedup'd to 19 and found that hardward lister found that there is a scanner attached to the Domex scsi card (correctly identified now), but it says that "this device has not been claimed" for the scanner.

Also, if I run xsane, it tries to find the scanner and freezes the system.

But I see this as some progress, since I had never seen the scanner listed before.

What is the next step to solving this problem?

Just found that the latest kernel update may have been at fault for Hardward Lister to no longer see the scanner.

Looks like it might be possible that someone messed up the kernel update?

Created attachment 780079 [details]
Domex card seen but not Umax scanner

Created attachment 780080 [details]
Turned scanner off and on during a reboot

The new attachments show clearly that the kernel change had indeed made the Domex card recognizable.  However, the same issue is now seen with the Umax scanner.  And it can only be seen if turned on fresh during a reboot.

What do you guys think about that?  Does the kernel need to recognize the scanner now, and is that not in the current kernel?

I am currently using Fedora 19 and Xfce 4.10.1. I had Firefox and Thunderbird open on my desktop.

I decided to rerun Hardware Lister to see if it still saw the scanner at all.  As soon as I selected the Refresh button, the scanner light came on and the system froze up without mouse or keyboard active, requiring a computer reset.

This seems important, so I am adding it here.

Created attachment 785046 [details]
Hardware is found but not claimed

I've attached a screenshot from the latest attempt.

Thank you.

Scanner still not "claimed".

I'll handle the userspace side (sane-backends e.a.) in bug #1028549 for now, the kernel side seems to be resolved. Closing this one.