When the adsl line hangs, sometimes you have to reload firmware of the alcatel modem with modem_run. This doesn't work with speedtouce 1.3, but did with 1.2b. Looks like speedtouch developers aren't going to fix this problem, because the bug was reported on september 2004. It could be very useful to restore the 1.2b ebuild, since it worked perfectly. Reproducible: Always Steps to Reproduce: 1. load firmware with modem_run 2. rmmod uhci-hcd (or ehci) 3. insmod uhci-hcd (or ehci) 4. load firmware with modem_run Actual Results: modem_run won't load firmware, and program exits immediately Expected Results: modem_run should exit after c.a. 10 seconds of firmware loading Portage 2.0.52-r1 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.13.2 i686) ================================================================= System uname: 2.6.13.2 i686 AMD Athlon(TM) XP 2400+ Gentoo Base System version 1.6.13 dev-lang/python: 2.3.3-r1, 2.4.1-r1 sys-apps/sandbox: 1.2.1-r2 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.4.3-r4, 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo" LANG="it_IT" LC_ALL="it_IT" LINGUAS="it" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X alsa apm avi berkdb bitmap-fonts cdparanoia cdr crypt cups curl dvd dvdread eds emboss encode fam flac foomaticdb fortran gdbm gif gphoto2 gpm gtk gtk2 guile hal imagemagick imlib ipv6 java jpeg kde libg++ libwww mad matrox mikmod mmx mmxext motif mp3 mpeg mysql ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline real samba sdl slang spell sse ssl svga tcpd tetex tiff truetype truetype-fonts type1-fonts v4l v4l2 vorbis xine xml2 xmms xv xvid zlib video_cards_matrox linguas_it userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS
For kernels >=2.6.10, the kernel-space driver is more appropriate: http://gentoo-wiki.com/HOWTO_Speedtouch_modem (An ebuild for this has been written, and will be submitted to bugzilla very shortly...)
what is the exact version? we have several 1.2b dead versions in http://www.gentoo.org/cgi-bin/viewcvs.cgi/net-dialup/speedtouch/ .
(In reply to comment #1) > For kernels >=2.6.10, the kernel-space driver is more appropriate: > http://gentoo-wiki.com/HOWTO_Speedtouch_modem > > (An ebuild for this has been written, and will be submitted to bugzilla very > shortly...) I think speedtouch-1.2b should be restored until the new method described in that article is included in speedtouch ebuild.
(In reply to comment #2) > what is the exact version? > we have several 1.2b dead versions in > http://www.gentoo.org/cgi-bin/viewcvs.cgi/net-dialup/speedtouch/ . I guess every 1.2b (latest is best I think) is good enough. This bug is submitted in sourceforge project page of speedtouch, and people say 1.2b works well.
The bash patch at http://translate.google.com/translate?u=http%3A%2F%2Flinuxfr.org%2Fforums%2F12%2F4648.html&langpair=fr%7Cen&hl=en should be easy to test. I suppose it should be added to /etc/init.d/speedtouch The original French URL is http://linuxfr.org/forums/12/4648.html
The ebuild for kernels >=2.6.10 has been posted as bug #110665
According to http://linuxfr.org/forums/12/4648.html, there is a solution to this problem: # cleaning the mutex ipcs -a | grep 0xdeadbeef >/dev/null 2>&1 if [ $? = 0 ]; then ipcrm -S 0xdeadbeef ; fi Can anyone confirm that? Is really 0xdeadbeef the key of that semaphore? If it works, I believe the code should be modified as follows: (ipcs -s | grep ^0xdeadbeef &>/dev/null) && ipcrm -S 0xdeadbeef
Created attachment 71764 [details, diff] speedtouch.diff I confirm that the semaphore exists, and that the fix works. Enclosed is a tested, working patch.
fixed in -r3
