libieee1284 / Bugs / #2 libieee1284 fails to work with linux-2.6.22-rc{1..5}

Nobody/Anonymous - 2007-06-21

Logged In: NO

I forgot to include an email address to contact me, so here you go: philipp@sadleder.de

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-06-29

Logged In: NO

A bit more debug output:

(this is on linux 2.6.22-rc6

LIBIEEE1284_DEBUG=123 sane-find-scanner -p

# 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.
# Also you need support for SCSI Generic (sg) in your operating system.
# If using Linux, try "modprobe sg".

# 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.
/dev/parport0 is accessible
==> ieee1284_open
==> init_port
Got -7 from ppdev init
<== -7
<== -7 (propagated)
==> ieee1284_open
==> init_port
Got -7 from ppdev init
<== -7
<== -7 (propagated)
==> ieee1284_open
==> init_port
Got -7 from ppdev init
<== -7
<== -7 (propagated)
==> ieee1284_open
==> init_port
Got -7 from ppdev init
<== -7
<== -7 (propagated)
==> ieee1284_open
==> init_port
Got -7 from ppdev init
<== -7
<== -7 (propagated)
==> ieee1284_open
==> init_port
Got -7 from ppdev init
<== -7
<== -7 (propagated)

# No Mustek parallel port scanners found. If you expected something
# different, make sure the scanner is correctly connected to your computer
# and you have apropriate access rights.

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

# You may want to run this program as root to find all devices. Once you
# found the scanner devices, be sure to adjust access permissions as
# necessary.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-07-01

Logged In: NO

the same with 2.6.21.5 kernel on archlinux
[root@Johannes johannes]# LIBIEEE1284_DEBUG=123 sane-find-scanner -p

# 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.
# Also you need support for SCSI Generic (sg) in your operating system.
# If using Linux, try "modprobe sg".

found USB scanner (vendor=0x04fc, product=0x0561) at libusb:004:005
found USB scanner (vendor=0x067b, product=0x2303) at libusb:004:004
# Your USB scanner was (probably) detected. It may or may not be supported by
# SANE. Try scanimage -L and read the backend's manpage.
/dev/parport0 is accessible
We can use ioperm()
/dev/port is accessible
==> ieee1284_open
==> init_port
Got 0 from ppdev init
<== 0
==> claim
<== E1284_SYS
==> ieee1284_open
==> init_port
Got 0 from ppdev init
<== 0
==> claim
<== E1284_SYS
==> ieee1284_open
==> init_port
Got 0 from ppdev init
<== 0
==> claim
<== E1284_SYS
==> ieee1284_open
==> init_port
Got 0 from ppdev init
<== 0
==> claim
<== E1284_SYS
==> ieee1284_open
==> init_port
Got 0 from ppdev init
<== 0
==> claim
<== E1284_SYS
==> ieee1284_open
==> init_port
Got 0 from ppdev init
<== 0
==> claim
<== E1284_SYS

# No Mustek parallel port scanners found. If you expected something
# different, make sure the scanner is correctly connected to your computer
# and you have apropriate access rights.

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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-07-01

Logged In: NO

A duplicate bug is reported at http://bugs.archlinux.org/task/7438?histring=parport

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-07-01

Logged In: NO

under ubuntu 7.04 final with kernel 2.6.20 it works

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-07-01

Logged In: NO

now i can ensure that it is kernel specific (or an arch linux problem with the kernel 2.6.21.5 configuration)

becouse i just changed the kernel on the same distro (arch linux) from 2.6.20.10 to 2.6.21.5 and with the 2.6.20.10 it worked veryl well with the 2.6.21.5 it doesn't work (the problem which is reported)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-07-03

Logged In: NO

If you create /etc/ieee1284 with this content:

[root@drake char]# cat /etc/ieee1284.conf
# Needed for mustek_pp and some other parallel port Sane backends
disallow method ppdev
[root@drake char]#
(That is, disable use of ppdev)

Everything works fine

I've noticed & reported same error in Fedora 7:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246406

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-07-03

Logged In: NO

yes that works but another stupid question how is it possible to use the parport as a normal user ? (setting permissions for /dev/parport0 /dev/ports doesn't work)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-07-04

Logged In: NO

Files ppdev.h and parport.h included in CVS sligthly differs from kernels 2.6.21 and up.

kernel file drivers/char/ppdev.c has been stable until 2.6.21.5 . Newer kernel version changed their behaviour. Same applies to include/linux/parport.h and in general to all parport layer

libieee1284 fails in claim() returning E1284_SYS (System Call Error).
Failed line is "ioctl(port->fd, PPCLAIM)" from access_ppdev.c

Studing ppdev.c seems that parport_claim_or_block() fails. Need further study

Reported at bugzilla Fedora and Linux-kernel mailing list

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-07-09

Logged In: NO

Are there any news on that bug?
Could someone please link to the discussion on LKML?
It would be great if we can link all information to that problem to help resolving it as fast as possible.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-07-10

Logged In: NO

Unfortunately no news.

kernel 2.6.21 is an first attemp to change the parport layer. My feeling is that
no real interest exists in testing until 2.6.22 is up and new parport layer fully
implemented
( I use 2.6.21.5, no time to download and test a 2.6.22rcX version, sorry )

The error seems to be in handling claim() ioctl at parport.c module (called
from ppdev.c ), but is so difficult to trace... and as I saw, parport layer in
2.6.21 seems to be unstable and in process of change ( too many changes for
this version IMHO )

At these moment you have two "solutions"
- Remove /lib/modules/$kversion/drivers/char/ppdev.ko module
- If your app uses libieee1284, disable use of ppdev by mean of /etc/ieee1284.conf

The (sort) lkml discusion is here:
http://marc.info/?l=linux-kernel&m=118336819012256&w=2

Juan Antonio

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-07-11

Logged In: NO

Thanks Juan Antonio for keeping the others updated.
The LKML discussion suddenly stopped, which is unfortunate.

I'd like to help in resolving that issue, but booting with the suggested boot options to disable isapnp didn't change anything on my system.

Best regards,

Philipp

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-08-03

Logged In: NO

/proc on on 2.6.22.1

# ls -la /proc/sys/dev/parport
total 0
dr-xr-xr-x 0 root root 0 2007-08-03 08:21 .
dr-xr-xr-x 0 root root 0 2007-08-03 08:19 ..
dr-xr-xr-x 0 root root 0 2007-08-03 08:25 default
dr-xr-xr-x 0 root root 0 2007-08-03 08:25 parport0

on 2.6.18
# ls -la /proc/sys/dev/parport/
total 0
dr-xr-xr-x 4 root root 0 Aug 3 08:29 .
dr-xr-xr-x 7 root root 0 Aug 3 08:29 ..
dr-xr-xr-x 2 root root 0 Aug 3 08:29 default
dr-xr-xr-x 3 root root 0 Aug 3 08:29 parport0

src/detect.c, function check_proc_type (void)

if (stat ("/proc/sys/dev/parport", &st) == 0 &&
S_ISDIR (st.st_mode) &&
st.st_nlink > 2)

This test fail on st.st_nlink > 2 for kernels with new proc interface for parport.

patch:

% 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");

--
krak3n

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-08-03

Logged In: NO

Hi krak3n,

you made my day, thanks.
Your patch works for me, even if I don't see the difference between the listings of /proc/sys/dev/parport on .18 and .22

Now we have to get the solution upstream or into distributions.

Best regards,

Philipp

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-08-06

Logged In: NO

difference between .18 and .22 is in number of links (column 2 .. next to privileges and before owner). This represents number of links (for normal directory minimum 2 links exist, one for "." second for "..", this number must be more then 2 for parport directory if there exist "file" for parport (or default). Library checks this value, but ?kernel? is wrong for proc filesystem, for all files/directories zero is reported for link count. If this is feature for new kernel proc interface, this is silly feature.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-08-14

Logged In: NO

I'm unsure, but think that the change to forceing nlink to 0 on dirs and 1 on files at /proc was due to several link count problems in incorrectly (un)registering several devices.

I'm trying to find the lkml thread discussion on it.
In the meantime, I've sent your patch and disscusion to lkml and redhat bugzilla

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-08-23

Logged In: NO

The mentioned patch went into Debian unstable in libieee1284 (0.2.10-8) [1].

Best regards,

Philipp

[1] http://packages.debian.org/changelogs/pool/main/libi/libieee1284/libieee1284_0.2.10-8/changelog#versionversion0.2.10-8

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Nobody/Anonymous - 2007-09-11

Logged In: NO

As the ChangeLog shows [1], Tim Waugh took the patch into CVS. Great.
Now we only need a release to get it into distributions.

[1] http://libieee1284.cvs.sourceforge.net/libieee1284/libieee1284/ChangeLog?revision=1.155&view=markup

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

libieee1284 fails to work with linux-2.6.22-rc{1..5}

Group

Searches

Help

#2 libieee1284 fails to work with linux-2.6.22-rc{1..5}

Discussion