Description of problem:
Sane backend mustek_pp doesn't work if ppdev kernel module is loaded
Version-Release number of selected component (if applicable):
[root@drake sane.d]# uname -a
Linux drake.micasa.es 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 15:37:31 EDT 2007 i686
athlon i386 GNU/Linux
[root@drake sane.d]# rpm -qf /usr/bin/sane-find-scanner
Steps to Reproduce:
1. Get a fresh Fedora 7 install, with latest kernel (2.6.21-1.3228.fc7)
2. Configure sane to use any mustek_pp based scanner
3. sane-find-scanner -p won't locate the scanner, unless you do a
"rmmod ppdev" and prevents kernel from reload module
if ppdev module is loaded, scanner won't be found.
with kernels 2.6.20 ppdev works fine
mustek_pp scanner should be found on every kernel version
http://bugs.archlinux.org/task/7438 shows same bug.
reports on same error
libieee1284_test output on fail:
[root@drake sane.d]# libieee1284_test
Found 3 ports:
From documentation at:
Create file /etc/ieee1284.conf
[root@drake char]# cat /etc/ieee1284.conf
# Needed for mustek_pp and some other parallel port Sane backends
disallow method ppdev
Now everything works fine.
That is: to use libieee1284 library, you need to disable ppdev usage with 2.6.21
Not sure if kernel (ppdev) bug (works w/o changes in 2.6.20 kernels) or
The ppdev driver hasn't changed in at least six months prior to fc7 release.
What could have caused this, I don't know...
Bugzilla didn't update the assignment, so this was still assigned to the wrong
"The ppdev driver hasn't changed in at least six months prior to fc7 release."
Well, this is not exactly true...
I've reported this bug to linux-kernel and sent some traces there. See thread
ppdev - libieee1284.so conflicts with 2.6.21" in kernel-list at vger
An stupid question trying to recompile ppdev
I've downloaded kernel-2.6.21-1.3228.fc7.src.rpm, and tried to apply backpatch
to ppdev.c ... and found that -at least- ppdev.c and parport.h are the same ones
than in 2.6.20 version... but git says that these files have change to use new
port-dev in parport struct in 2.6.21
¿Am I doing something wrong? ¿Or perhaps these changes are newer than Fedora's
Just updated to new fedora's kernel 184.108.40.206-27.fc7.
ppdev-libieee1284 conflict still remains
From libieee1284 bugtracker:
Seems that the change on how to handle directoriy inode link count
in procfs makes libieee1284 fail. A trivial patch to libieee1284/src/detect.c
% diff -u detect.c.orig detect.c
--- detect.c.orig 2007-08-03 09:27:29.000000000 +0200
+++ detect.c 2007-08-03 09:27:46.000000000 +0200
@@ -69,8 +69,7 @@
int which = 0;
struct stat st;
if (stat ("/proc/sys/dev/parport", &st) == 0 &&
- S_ISDIR (st.st_mode) &&
- st.st_nlink > 2)
+ S_ISDIR (st.st_mode))
which = PROC_SYS_DEV_PARPORT_CAPABLE;
debugprintf ("This system has /proc/sys/dev/parport\n");
I've asked lkml if this is a bug on procfs or a new unnoticed (for me) feature
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.
I am CC'ing myself to this bug and will try and assist you in resolving it if I can.
There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?
If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
As you can see in the link to sourceforge's libieee1284 project,
this is not really a kernel bug, just a libiee1284 one
Tim Waugh ( twaugh at redhat dot com ) has already fixed it in their
libieee1284 CVS. We need to contact him to release a new rpm version
to finally get it solved in Fedora distro
So yes, it's time to close this bug or reassign to Tim
Thanks for the info Juan. I'm changing the bug category then which will
hopefully prompt Tim to push the update in time for F8.
0.2.11 built for Fedora 8. Keeping this open for the F-7 update.
libieee1284-0.2.11-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
libieee1284-0.2.11-1.fc7.i386.rpm from fedora testing repository works fine for
me: problem solved (at least with kernel 220.127.116.11-76.fc7 )
Thanks for your work
:) Closing then...
libieee1284-0.2.11-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.