[ An English translation should follow, but this messgae is big
so it will take some time. ]
Bonjour � tous,
Comme je l'imagine un certain nombre de personnes sur cette
liste, je viens de m'inscrire afin de voir si vous pouviez
m'aider � r�soudre un probl�me �pineux que me pose mon
SpeedTouch, et plus pr�cis�ment, son instabilit�.
Si vous �tes tr�s press� et que vous avez un dimanche apr�s-midi
ou un lundi bien remplis, vous pouvez directement aller lire les
� Questions � en bas de ce message.
Pour r�sumer, tout marche bien. J'utilise la derni�re version du
pilote, le noyau 2.4.17 avec le patch n_hdlc, le tout sur une
Slackware 8 maintenue � jour et bien configur�e. modem_run
d�marre sans probl�me, pppd dialogue avec Wanadoo sans histoires,
les pppoa2 font leur boulot, et les 608 Kbps s'�coulent sans
difficult�. Le r�ve, quoi. :-)
Malheureusement, il ne dure que cinq � dix minutes en moyenne, au
bout desquelles modem_run -v 1 m'affiche une s�rie de
� Received interrupts, len = 0 �
de nombre variable, et peut-�tre proportionnel au temps qu'a dur�
la connection. En moyenne, ce nombre tourne autour d'une dizaine
de message de ce genre. Ils sont ensuite suivis du fatal
� Error reading interrupts �
apr�s lequel il me faut relancer modem_run et pppd. Si j'�tais
seul � utiliser cette machine, cela ne pr�senterait pas un
probl�me urgent : je me suis habitu� � avoir un xterm dans un
recoin et � faire [haut][haut][entr�e][haut][haut][entr�e] de
temps � autre... :-/ Malheureusement, je pars loin (tr�s loin)
d'ici lundi prochain, et c'est ma famille qui doit se servir de
cette machine. Et c'est elle qui paye l'abonnement. Bref, il
faudrait que tout soit automatis� d'ici huit jours. Argh.
Bien s�r, � d�faut de solution, je pr�vois de faire un script en
boucle infinie qui relance modem_run chaque fois qu'il tr�buche.
Mais je pr�f�rerais r�soudre ce probl�me pour de bon, si possible.
SYMPT�MES
Comme je l'ai dit, le script d�gage g�n�ralement aux bout d'une
dizaine de minutes. Cel� ne m'emp�che pas d'�tablir de temps �
autre des records, avec des dur�es de trente minutes voire d'une
heure.
Un moyen quasi-s�r de d�gager la connexion, c'est de bloquer la
machine pendant quelques instants, par exemple lors de
l'insertion d'un CD, ou en basculant de X vers un terminal virtuel
(CtrlAltF1). Dans ces cas, la connexion d�gage presque � coup s�r.
Je ne vous l'ai pas encore dit, mais j'utilise le module
'usb-uhci'. Le module 'uhci' est en effet beaucoup plus instable
sur ma machine. D'une part, il lui faut environ une minute pour
envoyer le microcode dans le modem (au d�but, je pensais m�me
qu'il ne marchait pas du tout) et d'autre part, les � Error
reading interrupts � se produisent en parall�le d'un gel complet
de la machine.
Bref, le probl�me serait d� � un mat�riel l�g�rement bogu�, un
noyau par encore parfait et � un driver un peu trop aggressif que
cela ne m'�tonnerait pas.
LES LOGS
Ah �a, on peut dire qu'ils grossissent vite. En voici des
extraits significatifs, qui donnent une id�e de ce qu'il se passe.
Je les ai reformat�s un peu pour qu'ils soient lisibles, mais du
coup �a prend plus de lignes. La machine s'appelle 'maya'. J'ai
pipeaut� IP, juste au cas o�.
On commence par une connexion qui marche :
/var/log/debug
>
> Jan 6 12:05:37 maya pppd[669]: sent
> [IPCP ConfReq id=0x2 <addr 256.257.258.259>
> <ms-dns1 193.252.19.3> <ms-dns3 193.252.19.4>]
> Jan 6 12:05:37 maya pppd[669]: rcvd
> [IPCP ConfAck id=0x2 <addr 256.257.258.259>
> <ms-dns1 193.252.19.3> <ms-dns3 193.252.19.4>]
> Jan 6 12:05:37 maya pppd[669]: rcvd
> [LCP EchoReq id=0x0 magic=0x5458f22d]
> Jan 6 12:05:37 maya pppd[669]: sent
> [LCP EchoRep id=0x0 magic=0x702b472a]
/var/log/messages
>
> Jan 6 12:05:37 maya pppd[669]:
> local IP address 256.257.258.259
> Jan 6 12:05:37 maya pppd[669]:
> remote IP address 256.257.258.1
> Jan 6 12:05:37 maya pppd[669]:
> primary DNS address 193.252.19.3
> Jan 6 12:05:37 maya pppd[669]:
> secondary DNS address 193.252.19.4
Bien que tout semble marcher correctement, il y a encore des
aspects imparfaits dans le pilote, il me semble. Voyons par
exemple ce que je retrouve dans le syslog quelques secondes
avant, probablement pendant la mise � jour du microcode :
/var/log/syslog
>
> Jan 6 12:05:06 maya kernel: usb_control/bulk_msg: timeout
> Jan 6 12:05:06 maya kernel:
> usbdevfs: USBDEVFS_BULK failed
> dev 9 ep 0x85 len 512 ret -110
> Jan 6 12:05:09 maya kernel: usb_control/bulk_msg: timeout
> Jan 6 12:05:22 maya last message repeated 3 times
Je sais que la documentation en parle comme �tant parfaitement
normal, mais je ne peux m'emp�cher de penser que �a a un lien de
parent� avec les � Error reading interrupts �.
Il n'emp�che que la liaison fonctionne et que je peux enfin
m'�lancer en un surf de folie sur les autoroutes des neiges...
Malheureusement, je dois (ou devrais) �tre Champion en Descente
Haute Vitesse, parce que la course s'arr�te 3'36" plus tard. :-(
Voyons ce que l'on logue alors en une petite seconde :
/var/log/syslog
>
> Jan 6 12:09:13 maya kernel: usb-uhci.c:
> interrupt, status 2, frame# 1759
> Jan 6 12:09:13 maya kernel: hub.c:
> already running port 1 disabled by hub (EMI?),
> re-enabling...
> Jan 6 12:09:13 maya kernel: hub.c:
> already running port 1 disabled by hub (EMI?),
> re-enabling...
> Jan 6 12:09:13 maya kernel: usbdevfs:
> process 672 (pppoa2) did not claim
> interface 1 before use
> Jan 6 12:09:13 maya kernel: usbdevfs:
> process 667 (modem_run) did not claim
> interface 0 before use
> Jan 6 12:09:13 maya pppd[669]:
> Child process /usr/local/bin/pppoa2 -vpi 8
> -vci 35 (pid 670) terminated with signal 2
> Jan 6 12:09:13 maya pppd[669]:
> Couldn't attach to PPP unit 0: Invalid argument
> Jan 6 12:09:13 maya pppd[669]:
> Couldn't attach to PPP unit 0: Invalid argument
> Jan 6 12:09:13 maya pppd[669]:
> Couldn't create new ppp unit:
> Inappropriate ioctl for device
> Jan 6 12:09:13 maya pppd[669]:
> Couldn't create new ppp unit:
> Inappropriate ioctl for device
> Jan 6 12:09:13 maya kernel: usb.c:
> USB device 10 (vend/prod 0x6b9/0x4061)
> is not claimed by any active driver.
> Jan 6 12:09:13 maya kernel: usb-uhci.c: uhci_submit_urb:
> pipesize for pipe c0038a80 is zero
> Jan 6 12:09:13 maya kernel: usb-uhci.c: uhci_submit_urb:
> pipesize for pipe c0038a80 is zero
> Jan 6 12:09:13 maya pppd[669]:
> Couldn't get channel number: Input/output error
> Jan 6 12:09:13 maya pppd[669]:
> Couldn't get channel number: Input/output error
Et l'on continue ainsi pendant de nombreuses lignes. � pipesize
is zero �, � Couldn't get channel number �, � Couldn't create new
ppp unit �, etc. Et pour conclure ce syslog, on termine par une
grosse s�rie de :
/var/log/syslog
>
> Jan 6 12:09:14 maya pppd[669]:
> Child process /usr/local/bin/pppoa2 -vpi 8
> -vci 35 (pid 720) terminated with signal 2
> Jan 6 12:09:14 maya pppd[669]:
> Child process /usr/local/bin/pppoa2 -vpi 8
> -vci 35 (pid 714) terminated with signal 2
> Jan 6 12:09:14 maya pppd[669]:
> Child process /usr/local/bin/pppoa2 -vpi 8
> -vci 35 (pid 712) terminated with signal 2
> ...
Et pendant ce temps l�, que nous indiquait les 'messages' ?
/var/log/messages
>
> Jan 6 12:09:13 maya kernel: usb.c: USB disconnect on device 9
> Jan 6 12:09:13 maya pppoa2[672]: Error reading usb urb
> Jan 6 12:09:13 maya pppd[669]: Modem hangup
> Jan 6 12:09:13 maya pppd[669]: Connection terminated.
> Jan 6 12:09:13 maya pppd[669]: Connect time 3.7 minutes.
> Jan 6 12:09:13 maya pppd[669]:
> Sent 20125 bytes, received 47911 bytes.
�a, c'est de la connexion ADSL ! :-(
Bon, manifestement, un des probl�mes, en tout cas au niveau du
sur-remplissage des logs, c'est que pppd red�marre trop
rapidement les pppoa2 :
/var/log/messages
>
> Jan 6 12:09:13 maya pppoa2[675]:
> Starting PPPoA2 ( merged version includes new
> ATM/AAL5 stack ) 1_0
> Jan 6 12:09:13 maya pppoa2[675]:
> I'm the parent process,
> I handle the endpoint 0x07
> Jan 6 12:09:13 maya pppoa2[675]: Where is this crappy modem ?!
O� qu'il est ? H� ben il arrive, mais un peu tard...
/var/log/messages
>
> Jan 6 12:09:13 maya kernel: hub.c:
> USB new device connect on bus1/1,
> assigned device number 10
Et de toutes fa�ons, �a ne change pas grand chose.
/var/log/messages
>
> Jan 6 12:09:13 maya pppoa2[678]:
> Starting PPPoA2 ( merged version includes new
> ATM/AAL5 stack ) 1_0
> Jan 6 12:09:13 maya pppoa2[678]:
> I'm the parent process,
> I handle the endpoint 0x07
> Jan 6 12:09:13 maya pppoa2[680]:
> I'm the children process,
> I handle the endpoint 0x87
> Jan 6 12:09:13 maya pppoa2[680]: Error reading usb urb
> ...
Et �a, gr�ce � pppd qui effectue ses 25 tentatives de connections
� toute vitesse, on en a plein les log. Et �videmment les
programmes finissent par se m�langer les pinceaux...
/var/log/messages
>
> Jan 6 12:09:13 maya pppoa2[683]: pusb_claim_interface 1 failed
> ...
> Jan 6 12:09:13 maya pppoa2[686]: Error reading from pppd
> ...
Et pour finir, ext�nu�, notre brave pppd prend sa retraite :
/var/log/messages
>
> Jan 6 12:09:14 maya pppd[669]: Exit.
Et on est reparti pour un [haut][haut][entr�e]
[haut][haut][entr�e] dans le xterm...
TIENS ?! Relisant /var/log/messages, je m'aper�ois de quelque
chose d'int�ressant !
/var/log/messages
>
> Jan 6 13:05:55 maya kernel: usb.c:
> USB disconnect on device 10
> Jan 6 13:05:55 maya kernel: hub.c:
> USB new device connect on bus1/1,
> assigned device number 11
> ...
> Jan 6 13:21:39 maya kernel: usb.c:
> USB disconnect on device 11
> Jan 6 13:21:39 maya kernel: hub.c:
> USB new device connect on bus1/1,
> assigned device number 12
Comme quoi ce n'est pas vraiment la faute du pilote, puisque plus
rien ne tourne � ce moment l� (ni modem_run, ni pppd, ni pppoa2) !
Ce qui ne m'emp�che pas de vous demander, maintenant que j'ai
r�dig� cet �norme mail, si vous n'auriez pas des id�es pour g�rer
plus proprement cet � USB disconnect �, afin de relancer
modem_run et pppd par derri�re, et surtout pour �viter � pppd de
remplir les logs juste apr�s un � USB disconnect �.
Pour terminer le tour d'horizon des logs, un dernier coup d'oeil
sur 'debug' nous permet de voir pppd effectuer toutes ses
tentatives vou�es � l'�chec :
/var/log/debug
>
> Jan 6 12:09:13 maya pppd[669]: using channel 102
> Jan 6 12:09:13 maya pppd[669]: using channel 103
> Jan 6 12:09:13 maya kernel:
> usbdevfs: usb_submit_urb returned -90
> Jan 6 12:09:13 maya kernel:
> usbdevfs: usb_submit_urb returned -90
> Jan 6 12:09:13 maya pppd[669]: using channel 104
> Jan 6 12:09:13 maya kernel:
> usbdevfs: usb_submit_urb returned -90
> ...
> Jan 6 12:09:14 maya pppd[669]:
> Waiting for 25 child processes...
> Jan 6 12:09:14 maya pppd[669]: script /usr/local/bin/pppoa2
> -vpi 8 -vci 35, pid 720
> Jan 6 12:09:14 maya pppd[669]: script /usr/local/bin/pppoa2
> -vpi 8 -vci 35, pid 718
> ...
> Jan 6 12:09:14 maya pppd[669]: Script /usr/local/bin/pppoa2
> -vpi 8 -vci 35 finished (pid 718),
> status = 0x0
> Jan 6 12:09:14 maya pppd[669]: Script /usr/local/bin/pppoa2
> -vpi 8 -vci 35 finished (pid 717),
> status = 0x0
> ...
> Jan 6 12:09:14 maya pppd[669]: Script /usr/local/bin/pppoa2
> -vpi 8 -vci 35 finished (pid 683),
> status = 0xff00
QUESTIONS
Le consensus ici semble �tre que le pilote en mode utilisateur
est meilleur que le pilote en mode noyau. Pensez-vous que je
devrais quand m�me tenter de l'essayer ? Sachant que je n'ai pas
trop le temps, et que la stabilit� de la machine est plus
importante que la stabilit� de la connection ADSL ?
Il semble d'autre part, je le d�couvre en m�me temps que je
r�dige ce mail, que le probl�me soit li� � des � d�connections �
intempestives du modem. Ce modem �tant le premier p�riph�rique
USB que j'aie entre les mains, que ce soit sous Linux ou sous
Windows, est-ce que vous avez des explications sur ce que sont
ces d�connections, et comment je peux � lutter � contre elles, ou
du moins apprendre � vivre avec ?
Tout autre commentaire est le bienvenu, et merci d'avoir consacr�
du temps � lire ce long message !
--
[EMAIL PROTECTED]
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se d�sinscrire : mailto:[EMAIL PROTECTED]?subject=unsubscribe
