Nous essayons de connecter deux téléviseurs Hyper-V via un port série. Hyper-V expose le port série sous forme de tuyau nommé dans le système hôte et implémente l'extrémité du serveur du tuyau nommé. En conséquence, pour les connecter, nous devons écrire un client Named-Tuyau qui se connecte à la fois à la VMS et à copie les données d'avant en arrière.
Nous avons écrit une telle application . Malheureusement, Si nous connectons deux hypertères et que nous les échangeons, la transmission réussit parfois, mais dans de nombreux cas, les erreurs de rapports de fin de réception, ou la transmission juste des blocages. De même, si nous utilisons le lien pour gérer un débogueur du noyau, il semble également suspendre souvent.
Qu'est-ce qui pourrait être la cause de la perte de données? Quelles précautions doivent être prises lors de la connexion des tuyaux nommés de manière à une telle manière?
EDIT : Nous avons travaillé autour du problème, en utilisant kdsrv.exe . Le port COM du debuggee continue d'être exposé à travers un tuyau nommé, cependant, le débogueur End parle à KDserSER via TCP.
3 Réponses :
Je n'ai pas essayé de connecter VM via la série, mais j'ai connecté vm et hôte via USB (via le réseau) et il fonctionne. S'il est nécessaire que votre logiciel établisse une connexion série, essayez de tester via des émulateurs série avec le travail via TCP \ IP.
Merci pour la proposition. Malheureusement, la vraie application est le débogueur du noyau ici, qui ne fonctionnera pas avec aucun type de réseau dans la machine invité.
La perte de données n'est pas due aux tuyaux nommés. Il s'agit des ports COM (émulés et physiques) pouvant perdre des données puisqu'ils fonctionnent avec un petit tampon dans le UART.
Le tuyau nommé reçoit toutes les données écrites sur le port COM. Votre programme lit les données du tuyau nommé et l'écrit à un autre tuyau nommé. C'est ici que la perte de données peut provenir si vous écrivez trop rapidement, le débordement UART UART DE REVENTION PORT DE PORT DE REÇU COMPAISE AVEC PERTE DE DONNÉES.
Vous devrez peut-être ajouter un délai pour éviter de dépasser le débit en bauds attendu par le côté de la réception.
En outre, vous manquez Pour vos problèmes KD, vous devrez peut-être ajouter ResetEvent () Appels dans votre programme.
réinitialise = 0 à la chaîne de connexion.
Merci pour la suggestion. LOOGILISATION Le transfert aide un peu; Une simple "copie foo.txt COM1:" peut désormais transmettre avec succès toutes les données. Malheureusement, l'hyperterm est toujours des blocages dans la communication Zmodem. Il doit donc rester une perte de données quelque part. Quant à ResetEventEvent: où est-il spécifiquement manquant? ASYNC IO est défini pour réinitialiser correctement les événements dans ReadFile et WrardFile. Testera réinitialisé = 0 demain.
Ma mauvaise gâterie. Il n'y a pas besoin de réinitient.
Cette réponse ne résout pas complètement le problème, uniquement partiellement. Néanmoins, c'est la meilleure réponse que nous avons eue, alors je l'attribue à la prime. Voir mon édition pour la façon dont nous avons travaillé autour du problème.
Je pense que la suggestion de John est correcte - si vous utilisez une CPU lente pour imiter deux VM, les pilotes du système d'exploitation pour le port série sont fortement dérivés de la version à grande vitesse. La suggestion de John est donc de définir le côté entrée / sortie de la liaison série sur la vitesse la plus lente possible. C'est-à-dire que vous ne pouvez pas utiliser un débit en bauds élevé pour la communication série INTER-VM. Au lieu de cela, vous devez utiliser la vitesse la plus lente possible, de sorte que le pilote Guest VM prendra cette queue et utiliser la version plus lente du pilote. Mais votre machine physique doit avoir une vitesse de processeur suffisante pour exécuter deux VM simultanément, pour éviter la "dérive d'émulation" du pilote série.
Eh bien, juste mon devinez, mais il y a une version virtuelle de votre problème, apparemment pas de problèmes qui l'exécutent:
Mais le billet de bogue suivant pour Virtualbox décrit de nombreuses similitudes à votre problème:
https://www.virtualbox.org/ticket/1548
et la lecture de la fin indique apparemment que la solution a à voir avec le code source interne de Virtualbox. Peut-être que c'est le problème hyper-v?