Communication avec un Sun Fire V240 via port série.
Grunt
J'ai récupéré un Sun Fire V240, avec lequel je tente désespérément de
communiquer via le port "Serial Management".
Le câble est un câble DB9 <=> RJ-45 de Cisco (les câbles bleus), derrière
lequel j'ai connecté un adaptateur USB-DB9 (reconnu comme /dev/ttyUSB0
par Linux).
J'utilise GTKTerm, configuré comme indiqué par la documentation Sun: 8
bits de données, 1 bit de stop, pas de contrôle de flux, pas de contrôle
de parité.
Quand je démarre le serveur, il envoie des données qui semblent
"bruitées" sur le port série. Je ne parviens pas à trouver la vitesse de
communication, qui a pu être modifiée avant que je n'obtienne ce serveur.
Voici un essai effectué à 9600 bit/s:
http://grunt.fdn.fr/Sun/9600-bauds.txt
À 19200 bit/s, j'obtiens ceci:
http://grunt.fdn.fr/Sun/19200-bauds.txt
Ce sont les sorties brutes en hexadécimal, étant donné qu'en ASCII je
n'ai qu'une purée de caractères illisibles.
Je ne parviens pas à avoir une sortie claire, compréhensible, sur le port
série. Ni même à déterminer la vitesse à laquelle le serveur communique,
ou encore à obtenir une réaction claire quand j'envoie un signal "BREAK".
En bref, je piétine sur place depuis plusieurs semaines, sans obtenir de
résultats clairs.
J'ai essayé plusieurs vitesses, de 300 bauds à 115200 bauds, en obtenant
à chaque fois, soit rien, soit du bruit avec des morceaux de donnée
dedans.
J'ai aussi pensé à un problème lié à l'adaptateur USB-série, mais en me
branchant directement sur le port série d'une autre machine, ça ne change
rien.
J'ai également essayé de placer une carte graphique (Ati Rage II) sur un
des ports PCI interne, mais rien ne s'affiche à l'écran.
J'ai aussi essayé de réinitialiser toute la configuration du serveur en
enlevant puis en remettant la pile interne, sans changement notable.
Y a-t-il un moyen de détecter automatiquement la configuration du serveur?
L'utilisation d'un adaptateur DB9-USB peut elle poser un problème?
Est-il possible de retourner à la configuration d'usine du serveur?
J'espère un jour parvenir à ce fameux prompt "OK" et pouvoir enfin
m'amuser pour de bon ;)
Merci d'avance.
Luc Habert
> Voici un essai effectu� � 9600 bit/s:
> http://grunt.fdn.fr/Sun/9600-bauds.txt
Il me parait assez clair que tu as les bons param�tres de vitesse et stop
bits, sinon, tu n'aurais pas des suites de plusieurs caract�res plausibles.
Je n'ai h�las pas d'id�e de comment r�soudre le probl�me, � part des
indications g�n�riques du style essayer un autre cable (mais j'y crois peu,
pour du 9600 bauds, n'importe quoi devrait faire l'affaire), et cater
directement /dev/ttyUSB0 plut�t que d'utiliser un machin � la gtkterm (tu
utilises stty pour r�gler les param�tres).
JKB
Re: Communication avec un Sun Fire V240 via port? série.,
Luc Habert ?crivait dans fr.comp.sys.sun :
> Grunt :
>
>> Voici un essai effectué à 9600 bit/s:
>> http://grunt.fdn.fr/Sun/9600-bauds.txt
>
> Il me parait assez clair que tu as les bons paramètres de vitesse et stop
> bits, sinon, tu n'aurais pas des suites de plusieurs caractères plausibles.
> Je n'ai hélas pas d'idée de comment résoudre le problème, à part des
> indications génériques du style essayer un autre cable (mais j'y crois peu,
> pour du 9600 bauds, n'importe quoi devrait faire l'affaire), et cater
> utilises stty pour régler les paramètres).
Personnellement, j'utilise minicom dans problème. Je ne suis pas
convaincu que le câble Cisco soit le même que le câble Sun (contrôle
de flux). J'utilise aussi des adaptateurs USB/RS232 mais _croisés_.
Autre chose à voir : certaines machines Sun (au hasard U60, mais les
U420R le faisaient aussi) émettent du série _différentiel_ par
défaut. Ça se règle par un cavalier sur la carte mère. Je ne sais
pas si c'est le cas de la 240, mais ma 420 d'origine donnnait à peu
près le même bruit de télétransmission sur ma VT100.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Luc Habert
> Personnellement, j'utilise minicom dans probl�me. Je ne suis pas
> convaincu que le c�ble Cisco soit le m�me que le c�ble Sun (contr�le
> de flux). J'utilise aussi des adaptateurs USB/RS232 mais _crois�s_.
Si c'�tait un probl�me de crois� vs non crois�, �a voudrait dire que les
deux Tx seraient branch�s l'un sur l'autre, et je ne vois pas comment il
pourrait obtenir quelque chose sur le Rx. Je me trompe?
> Autre chose � voir : certaines machines Sun (au hasard U60, mais les
> U420R le faisaient aussi) �mettent du s�rie _diff�rentiel_ par
> d�faut. �a se r�gle par un cavalier sur la carte m�re. Je ne sais
> pas si c'est le cas de la 240, mais ma 420 d'origine donnnait � peu
> pr�s le m�me bruit de t�l�transmission sur ma VT100.
Ah oui, si le port s�rie USB re�oit du 7.5V au lieu de 15V, �a ne parait pas
absurde qu'il pige des bits de travers.
JKB
Luc Habert ?crivait dans fr.comp.sys.sun :
>
>> Personnellement, j'utilise minicom dans problème. Je ne suis pas
>> convaincu que le câble Cisco soit le même que le câble Sun (contrôle
>
> Si c'était un problème de croisé vs non croisé, ça voudrait dire que les
> deux Tx seraient branchés l'un sur l'autre, et je ne vois pas comment il
> pourrait obtenir quelque chose sur le Rx. Je me trompe?
Non, vous ne vous trompez pas (encore que le matériel Sun m'a
toujours étonné...). Je disais ça parce qu'il n'y a aucune raison
qu'un câble Cisco soit branché de la même façon qu'un câble Sun.
J'ai ici un câble pour un modem SDSL (je ne sais plus lequel,
c'était le modem d'un client), qui est bien un RJ45 pour faire
passer un protocole série et qui n'a strictement rien à voir avec le
câble d'origine Sun que je branche sur mes T1000. Je n'ai par contre
jamais essayé de brancher ce câble sur mes Sun.
>> Autre chose à voir : certaines machines Sun (au hasard U60, mais les
>> U420R le faisaient aussi) émettent du série _différentiel_ par
>> défaut. Ça se règle par un cavalier sur la carte mère. Je ne sais
>> pas si c'est le cas de la 240, mais ma 420 d'origine donnnait à peu
>> près le même bruit de télétransmission sur ma VT100.
>
> Ah oui, si le port série USB reçoit du 7.5V au lieu de 15V, ça ne parait pas
> absurde qu'il pige des bits de travers.
N'est-il pas ? ;-)
Dominique ROUSSEAU
>>> Personnellement, j'utilise minicom dans probl�me. Je ne suis pas
>>> convaincu que le c�ble Cisco soit le m�me que le c�ble Sun (contr�le
>>> de flux). J'utilise aussi des adaptateurs USB/RS232 mais _crois�s_.
>>
>> deux Tx seraient branch�s l'un sur l'autre, et je ne vois pas comment il
>> pourrait obtenir quelque chose sur le Rx. Je me trompe?
>
> toujours �tonn�...). Je disais �a parce qu'il n'y a aucune raison
> qu'un c�ble Cisco soit branch� de la m�me fa�on qu'un c�ble Sun.
En dehors du fait que j'ai eu plusieurs fois l'occasion d'utiliser des
cables Cisco (ceux avec un rj45 � un bout et un db9 � l'autre, moul�s)
sur des Sun �quip�es d'un port s�rie en rj45.
(des Netra et des V220, pour autant que je me souvienne)
Par contre, je ne sais plus si j'�tais en controle de flux mat�riel ou
pas.
Grunt
Voilà où j'en suis, après quelques tests:
- Avec GTKTerm, j'obtiens les résultats que j'ai postés précédemment
(http://grunt.fdn.fr/Sun/ ).
- Avec Cutecom, je ne reçois que des caractères nuls (0x00), en grand
nombre.
- Avec minicom, cu et screen, je ne reçois rien.
J'utilise screen avec la commande suivante:
screen -m /dev/ttyUSB0 9600 8n1 (je n'ai pas de .screenrc)
Du coup, j'en reste à GTKTerm, même si je me doute bien que ce n'est pas
la solution idéale.
J'écarte la possibilité que la machine émette en série différentiel,
étant donné que le résultat change en fonction du logiciel que j'utilise,
donc le problème n'est pas matériel.
La documentation trouvée sur le Web (chez Sun et ailleurs) est assez
muette sur ce type de problèmes, et sur les différents paramètres
(matériels et logiciels) à utiliser.
Je penche pour un obscur problème de type de terminal, qui serait plus ou
moins bien rattrapé par les GUI (vu que, et Cutecom, et GTKTerm,
affichent quelque chose) et qui casserait tout sur les outils en CLI.
Pour information, j'utilise l'émulateur de terminal Konsole, dans lequel
j'appelle cu, screen et minicom depuis bash. Ce n'est peut-être pas une
bonne idée?
Luc Habert
> J'�carte la possibilit� que la machine �mette en s�rie diff�rentiel,
> �tant donn� que le r�sultat change en fonction du logiciel que j'utilise,
> donc le probl�me n'est pas mat�riel.
Bah il peut y avoir plusieurs probl�mes empil�s.
Fais juste un�:
stty -F /dev/ttyUSB0
cat /dev/ttyUSB0 > blah
et regarde blah avec un �diteur de texte qui se d�brouille bien avec les
caract�res de controle.
JKB
Re: Communication avec un Sun Fire V240 via port série.,
Grunt ?crivait dans fr.comp.sys.sun :
Si le câble est bon (je veux bien croire que votre câble Cisco
fonctionne), minicom donne de parfaits résulats. Les paramètres 9600
8n1 sont bons (ce sont les paramètres par défaut). Sans contôle de
flux, ça doit passer. Pouvez-vous remettre les paramètres de
l'openprom à leurs valeurs par défaut ?
Grunt
Je suis parvenu à un résultat positif avec minicom \o/
En 9600, 8N1, et surtout sans contrôle de flux (ni hard, ni soft).
minicom ne fonctionne que si je ne passe pas par l'adaptateur USB, je
vais donc éviter de l'utiliser et continuer à me brancher directement sur
le vrai port série d'une machine qui en a un.
C'est un peu la même purée qu'avec GTKTerm:
http://grunt.fdn.fr/Sun/9600-8N1-minicom-sans_controle_de_flux.txt
Détail qui peut avoir son importance: quand le signal est "brouillé", on
a malgré tout des motifs qui se répètent. Autrement dit, le "bruit" n'est
pas aléatoire, donc ce n'est pas du bruit.
Avant chaque message "SC Alert", j'ai la séquence "5)..", que je retrouve
ailleurs suivie de caractères qui ne sont pas affichables.
Là où je devrais avoir:
"SC Alert: SC Request to send Break to host"
J'ai:
"..(.(.K...M.I", dont je retrouve des morceaux identiques (même en hexa)
ailleurs.
L'hypothèse d'un mauvais contact, d'un câble abîmé (j'en ai essayé deux),
et plus généralement d'un problème ou d'une incompatibilité matérielle,
est donc exclue, non?
Cela vaut-il la peine que je me prenne la tête sur les signaux reçus
(recherche d'un décalage constant, d'une "logique" dans les caractères
non affichables), ou pas?
> Pouvez-vous remettre les paramètres de l'openprom
> à leurs valeurs par défaut ?
>
> JKB
Je ne sais pas faire, et je n'ai pas trouvé comment faire. J'ai enlevé la
pile à côté de la puce "OBP", puis l'ai remise après une dizaine de
minutes. Est-ce suffisant? Il y a aussi la carte à puce de configuration
du système, en façade, mais je n'ai aucun équipement avec lequel je
puisse tenter d'agir dessus.
JKB
Non, c'est faux. Minicom fonctionne très bien avec un adaptateur
USB/RS232. J'utilise ça tous les jours ou presque. Quel est
l'adaptateur en question ? Personnellement, j'en ai testé de deux
types (à partir d'une machine sous Linux) et les deux fonctionnent
parfaitement moyennant un câble RS232 croisé. Ça fait donc PC,
adaptateur USB/RS232, câble croisé, adaptateur RS232/RJ45,
processeur de service.
> C'est un peu la même purée qu'avec GTKTerm:
> http://grunt.fdn.fr/Sun/9600-8N1-minicom-sans_controle_de_flux.txt
>
> Détail qui peut avoir son importance: quand le signal est "brouillé", on
> a malgré tout des motifs qui se répètent. Autrement dit, le "bruit" n'est
> pas aléatoire, donc ce n'est pas du bruit.
>
> Avant chaque message "SC Alert", j'ai la séquence "5)..", que je retrouve
> ailleurs suivie de caractères qui ne sont pas affichables.
> Là où je devrais avoir:
> "SC Alert: SC Request to send Break to host"
> J'ai:
> "..(.(.K...M.I", dont je retrouve des morceaux identiques (même en hexa)
> ailleurs.
Ce ne seraient pas par hasard les codes contrôlant l'affichage des
VT100 ? Je ne les ai plus en tête, mais je vois dans les caractères
non affichables des retours à la ligne.
> L'hypothèse d'un mauvais contact, d'un câble abîmé (j'en ai essayé deux),
> et plus généralement d'un problème ou d'une incompatibilité matérielle,
> est donc exclue, non?
>
> Cela vaut-il la peine que je me prenne la tête sur les signaux reçus
> (recherche d'un décalage constant, d'une "logique" dans les caractères
> non affichables), ou pas?
Minicom en émulation VT100 devrait résoudre le problème.
>> Pouvez-vous remettre les paramètres de l'openprom
>> à leurs valeurs par défaut ?
>>
>> JKB
> Je ne sais pas faire, et je n'ai pas trouvé comment faire. J'ai enlevé la
> pile à côté de la puce "OBP", puis l'ai remise après une dizaine de
> minutes. Est-ce suffisant? Il y a aussi la carte à puce de configuration
> du système, en façade, mais je n'ai aucun équipement avec lequel je
> puisse tenter d'agir dessus.
À mon avis, les paramètres sont les bons, votre problème est un
problème de configuration du client.
Cordialement,
Grunt
Oui, ce sont des retours à la ligne, qui s'affichent correctement dans
Minicom: les "SC Alert" sont bien précédés de retour à la ligne quand ça
tombe en marche.
>> L'hypothèse d'un mauvais contact, d'un câble abîmé (j'en ai essayé
>> deux), et plus généralement d'un problème ou d'une incompatibilité
>> matérielle, est donc exclue, non?
>>
>> Cela vaut-il la peine que je me prenne la tête sur les signaux reçus
>> (recherche d'un décalage constant, d'une "logique" dans les caractères
>> non affichables), ou pas?
>
> Minicom en émulation VT100 devrait résoudre le problème.
>
Pour être précis, je n'ai que "VT102" et "ANSI" comme type d'émulation.
>>> Pouvez-vous remettre les paramètres de l'openprom
>>> à leurs valeurs par défaut ?
>>>
>>> JKB
>> Je ne sais pas faire, et je n'ai pas trouvé comment faire. J'ai enlevé
>> la pile à côté de la puce "OBP", puis l'ai remise après une dizaine de
>> minutes. Est-ce suffisant? Il y a aussi la carte à puce de
>> configuration du système, en façade, mais je n'ai aucun équipement avec
>> lequel je puisse tenter d'agir dessus.
>
> À mon avis, les paramètres sont les bons, votre problème est un
> problème de configuration du client.
Les nombreux paramètres relatifs aux modems, dont Minicom est truffé,
peuvent-ils interférer?
Dans "modem et appel", j'ai une série de chaîne de caractères
manifestement destinées aux anciens modems. Ces séquences de contrôles
peuvent-elles être envoyées par minicom de façon automatique, brouillant
ainsi la communication?
Pour information, j'ai configuré minicom en mettant "~^M~", ainsi que le
recommande cette page:
<http://www.idevelopment.info/data/Unix/Solaris/
SOLARIS_UsingSerialConsoles.shtml>
Y a-t-il d'autres paramètres à modifier?
Cordialement,
Rémi.
JKB
Re: Communication avec un Sun Fire V240 via port série.,
Grunt ?crivait dans fr.comp.sys.sun :
<snip>
> Oui, ce sont des retours à la ligne, qui s'affichent correctement dans
> Minicom: les "SC Alert" sont bien précédés de retour à la ligne quand ça
> tombe en marche.
<snip>
>>
>> À mon avis, les paramètres sont les bons, votre problème est un
>> problème de configuration du client.
>
> Les nombreux paramètres relatifs aux modems, dont Minicom est truffé,
> peuvent-ils interférer?
> Dans "modem et appel", j'ai une série de chaîne de caractères
> manifestement destinées aux anciens modems. Ces séquences de contrôles
> peuvent-elles être envoyées par minicom de façon automatique, brouillant
> ainsi la communication?
Non. Minicom est poli, il n'initialise le modem que lorsque vous le
demandez.
> Pour information, j'ai configuré minicom en mettant "~^M~", ainsi que le
> recommande cette page:
><http://www.idevelopment.info/data/Unix/Solaris/
> SOLARIS_UsingSerialConsoles.shtml>
> Y a-t-il d'autres paramètres à modifier?
Je ne me suis jamais préoccupé des paramètres autres que ceux du
port série. Pour information, voici les paramètres qui fonctionnent :
Paramètres de communication: 9600 8N1
Réglages de terminal: VT102, BS
Le modem n'a pas à être initialisé car vous utilisez la ligne série
_sans_ modem (les touches H et M sont inutiles dans votre cas).
La configuration du port série (option O) est chez moi :
Port série : /dev/ttyUSB0
Débit/Parité/Bits : 9600 8N1
Contrôle de flux matériel : Oui
Contrôle de flux logiciel : Non
Tiens, je croyais qu'il ne fallait pas avoir de contrôle de flux de
mémoire, mais en tout cas, ça fonctionne et j'arrive à me connecter
à la console de ma Blade 2000.
Grunt
> ...
> Non. Minicom est poli, il n'initialise le modem que lorsque vous
> le demandez.
> ...
> Le modem n'a pas à être initialisé car vous utilisez la ligne
>série
> _sans_ modem (les touches H et M sont inutiles dans votre cas). La
> configuration du port série (option O) est chez moi :
>
> Port série : /dev/ttyUSB0
> Débit/Parité/Bits : 9600 8N1
> Contrôle de flux matériel : Oui
> Contrôle de flux logiciel : Non
>
Pour ma part j'utilise :
Contrôle de flux matériel : Non
Contrôle de flux logiciel : Oui
J'ai essayé d'activer/désactiver les deux types de contrôle de flux, sans
résultat: c'est avec ces paramètres que ça marche le moins mal.
Le contrôle de flux matériel fait planter minicom quand j'envoie un
"break", que ce soit avec ou sans contrôle de flux logiciel.
Et je n'obtiens strictement rien avec l'adaptateur USB (modèle:
ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port )
Est-il possible que mon port série soit "de mauvaise qualité"?
J'ai envisagé à un problème de différence de potentiel entre la masse du
serveur et celle du PC, mais en les branchant sur la même multiprise avec
la même terre, ça ne fonctionne pas mieux.
Autre chose: la réponse du serveur me parvient parfois avec plusieurs
minutes de retard. J'ai par exemple une demande de login, je tape un
login au hasard, j'attends, et la réponse "Invalid login" met beaucoup
trop de temps à arriver.
--
Cordialement\n Rémi
Luc Habert
> Et je n'obtiens strictement rien avec l'adaptateur USB (mod�le:
> ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port )
>
> Est-il possible que mon port s�rie soit "de mauvaise qualit�"?
J'ai le m�me mod�le, et l'ai plut�t trouv� bon (il comprend aussi le RS422
alors que ce n'est pas les m�mes potentiels).
> J'ai envisag� � un probl�me de diff�rence de potentiel entre la masse du
> serveur et celle du PC, mais en les branchant sur la m�me multiprise avec
> la m�me terre, �a ne fonctionne pas mieux.
Normalement, il y a un transfo d'isolation dans les alims (si, m�me avec des
alims � d�coupage), donc la prise de terre ne devrait rien y changer. Ce qui
pourrait mettre la zone dans les masses, �a serait d'autres connexions
(r�seau, son, ...), mais a priori, les cibles ont aussi des transfos
d'isolation dans leurs alims...
> Autre chose: la r�ponse du serveur me parvient parfois avec plusieurs
> minutes de retard.
Un buffer quelque part?
JKB
Re: Communication avec un Sun Fire V240 via port série.,
Grunt ?crivait dans fr.comp.sys.sun :
>> ...
>> Non. Minicom est poli, il n'initialise le modem que lorsque vous
>> le demandez.
> Bon, ça c'est déjà une bonne nouvelle.
>
>> ...
>> Le modem n'a pas à être initialisé car vous utilisez la ligne
>>série
>> _sans_ modem (les touches H et M sont inutiles dans votre cas). La
>> configuration du port série (option O) est chez moi :
>>
>> Port série : /dev/ttyUSB0
>> Débit/Parité/Bits : 9600 8N1
>> Contrôle de flux matériel : Oui
>> Contrôle de flux logiciel : Non
>>
> Pour ma part j'utilise :
> Contrôle de flux matériel : Non
> Contrôle de flux logiciel : Oui
> J'ai essayé d'activer/désactiver les deux types de contrôle de flux, sans
> résultat: c'est avec ces paramètres que ça marche le moins mal.
> Le contrôle de flux matériel fait planter minicom quand j'envoie un
> "break", que ce soit avec ou sans contrôle de flux logiciel.
>
> Et je n'obtiens strictement rien avec l'adaptateur USB (modèle:
> ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port )
J'ai exactement le même et il fonctionne parfaitement (sur un câble
croisé et au cul de ma Blade 2000).
> Est-il possible que mon port série soit "de mauvaise qualité"?
> J'ai envisagé à un problème de différence de potentiel entre la masse du
> serveur et celle du PC, mais en les branchant sur la même multiprise avec
> la même terre, ça ne fonctionne pas mieux.
>
> Autre chose: la réponse du serveur me parvient parfois avec plusieurs
> minutes de retard. J'ai par exemple une demande de login, je tape un
> login au hasard, j'attends, et la réponse "Invalid login" met beaucoup
> trop de temps à arriver.
Ça me semble long. Je ne vois pas comme ça (et il est tard ;-) ). Je
vais mettre ça entre deux neurones et voir si ça me rappelle quelque
chose. Désolé...
Grunt
Quelqu'un qui s'y connaît beaucoup en Sun a vu la bête, et a fini par
identifier le problème:
En fait, c'est l'ALOM et l'OBP qui causaient sur le même port série, le
ttya. Le "bruit" c'était quand ils parlaient en même temps.
À force d'essais, il est parvenu à rediriger l'entrée et la sortie de
l'OBP sur le deuxième port série (ttyb), et je peux maintenant
communiquer correctement avec mon serveur. Ça marche du tonnerre :)
Merci à tous de vous être penchés sur mon problème.
Bonne journée :)
--
Cordialement\n Rémi