Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

My old parallel port scanner stopped working since kernel 2.6.21. This seems to
happen due to a bug in libieee1284 or the kernel itself. The connection to the
scanner can't be established anymore. This happens with every kernel >= 2.6.21
and every libieee1284 version in the portage tree.
I 've found a site where the problem is discussed, but no solution has been
found for this.

Here is the link:
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg177585.html

Reproducible: Always

so narrow it down between it being a userspace API breakage from kernel headers
or the kernel being broken

boot a 2.6.20 kernel and install 2.6.20 headers and rebuild libieee1284 and see
if it works

if that does, upgrade your kernel only and see if libieee1284 still works

So...i followed your instructions and here are the results:
(i used libieee1284 in the unstable version 0.2.10 because it's the most recent
version in portage)

gentoo-sources-2.6.20-r8
linux-headers-2.6.17-r2
libieee1284-0.2.10
--> scanner works

gentoo-sources-2.6.21-r4
linux-headers-2.6.17-r2
libieee1284-0.2.10
-->scanner doesn't work

seems that changes have been made to the kernel

great ... for posterity sake, could you also test:
gentoo-sources-2.6.20-r8
linux-headers-2.6.21+
libieee1284-0.2.10

OK... here the results for:
gentoo-sources-2.6.20-r8
linux-headers-2.6.21
libieee1284-0.2.10

functional ;)

ok... after investigating this problem, i found out that since kernel 2.6.21
the sysctl interface in procfs (/proc/sys/) had some changes in it. One of them
was the hardlink count of dirs and files. From .21 onwards, all dirs under
/proc/sys will have hardlink count = 0 and all files = 1. So, this means that
libieee1284 should be fixed because i tests this values.
The patch to libieee1284 can be found in here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1739643&group_id=29314&atid=395778

just to clear things up, this is the original patch that makes this behavior
"normal" aka "the expected behavior from kernel":
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=77b14db502cb85a031fe8fde6c85d52f3e0acb63
(see function proc_sys_refresh_inode)

Created an attachment (id=133223) [details]
libieee1284-0.2.11.ebuild

Problem solved with version 0.2.11, found on the SourceForge site.

added to the tree ... do not post ebuilds as attachments if you didnt change
anything, just say "renaming the old ebuild worked for the new version"