peut etre simplement un probleme d'alimentation du modem speedtouch, fait qui au bout de 5 � dix minutes cause l'arret total du modem (dans le cas de window), ceci a surtout lieu sur les anciennes carte meres dont l'alimentation en directe par la carte n'est pas suffisante, il faut donc rajouter un hub USB avec autoalimentation ce qui regle le probleme
----- Original Message ----- From: "boa13" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, January 06, 2002 3:25 PM Subject: [speedtouch] [fr] Error reading interrupts > > [ 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 > > > Liste de diffusion modem ALCATEL SpeedTouch USB Pour se d�sinscrire : mailto:[EMAIL PROTECTED]?subject=unsubscribe
