Bonjour. Le 29/10/07, Eric Noulard <[EMAIL PROTECTED]> a écrit : > > Le 29/10/07, Arquer Stephane<[EMAIL PROTECTED]> a écrit : > > L'utilisation du client tsp_gdisp provoque une erreur du driver de la > carte réseau. > > Les messages d'erreur sont: > > " etherlink: unit elnk1 tx fragments exhausted, truncated packet!" > > " Still waiting for mbuf cluster." > > Ceux-ci proviennent du code Rtems. > > Probablement que la demande de la liste des samples > genere un paquet IP trop gros et que le nombre de fragments IP autorisés > > (quand le paquet est trop gros il y a fragmentation > http://en.wikipedia.org/wiki/IP_fragmentation > pour que ça rentre dans le MTU) > > dans RTEMS est "un peu faible" par rapport à la > > > > > Peux-tu me dire s'il y des changements au niveau de la communication par > rapport au client tsp_stdout ? > > Oui il y en a. > Notamment tsp_gdisp doit avoir la mauvaise idée de faire > une requête tsp_request_info qui a pour effet de demander > l'envoi de la liste complète des symboles samplable > c'est-à-dire 1000 en ce qui concerne le stub server.
Je confirme de mémoire qu'il fait cela. Ce qui est dommage car on lui passe le fichier XML en paramètre donnant ce qui a à tracer. Tu peux vérifier que tsp_gdisp reste bloqué après cette requête > en positionnant STRACE_DEBUG à 15 côté tsp_gdisp. Par contre tu peux essayer avec TARGA, qui lui ne demande pas forcément toute la liste au début, mais juste quand tu fais le "File=>New" Yves
_______________________________________________ Tsp-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tsp-devel
