DE60009335T2

DE60009335T2 - Verfahren und vorrichtung zur fernüberprüfung von rechnersoftware und ausschaltung von fehlern

Info

Publication number: DE60009335T2
Application number: DE60009335T
Authority: DE
Inventors: Georgios Chrysanthakopoulos; Nels John FULLER; S. Kenneth RENERIS
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1999-12-02
Filing date: 2000-09-07
Publication date: 2004-08-12
Anticipated expiration: 2020-09-08
Also published as: WO2001040940A3; WO2001040940A2; AU7352800A; EP1234235B1; DE60009335D1; EP1234235A2; HK1046968B; ATE262698T1; HK1046968A1

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung bezieht sich allgemein auf die Verwendung eines seriellen Bus' als eine Einrichtung für die Fehlersuche in einem Computerprogramm. Insbesondere gibt die Erfindung ein Verfahren und eine Vorrichtung zum Verwenden eines seriellen Bus, wie beispielsweise eines Bus vom Typ IEEE 1394 an, um von einem Host-Computer von fern Software, die in einem oder mehreren Ziel-Computern abläuft, von Fehlern zu befreien.
HINTERGRUND DER ERFINDUNG
Computer-Fehlersucher sind üblicherweise verwendete Programme, die Programmierer bei der Identifizierung und Korrektur von Fehlern in Software unterstützen, die gerade geprüft wird. Fehlersucher können dazu verwendet werden, Speicherorte zu prüfen, sie schreiten durch Rechnerbefehle und manipulieren zahlreiche Register und Softwarevariable in gesteuerter Weise.
Während einige Fehlersucher dazu verwendet werden, Software von Fehlern zu befreien, die im selben Rechner vorhanden sind, wie der Fehlersucher, erfordern andere Umgebungen die Verwendung eines Fehlersuchers, der an einem ersten Rechner wirksam ist, um Software von Fehlern zu befreien, die in einem zweiten Rechner abläuft. In solchen Umgebungen wird eine Hardwareverbindung, wie beispielsweise eine serielle Verbindung, dazu verwendet, Fehlersuchbefehle zu übertragen und die Fehlersuchergebnisse von Software rückzumelden, die im zweiten Rechner geprüft wird. Die letztgenannte Anordnung wird allgemein als "Fern"-Fehlersuche bezeichnet.
Wie in 2 gezeigt, ist beispielsweise ein Host-Rechner 101 mit einem Ziel-Rechner 102 über eine Hardwareverbindung 103, beispielsweise eine serielle Schnittstelle (z. B. RS-232C) verbunden, die von seriellen Anschlüssen 101A und 102A an jedem Rechner gebildet wird. Ein im Test befindliches Programm 102C wird durch die Verwendung eines Ziel-Fehlersuchers 102B und eines Host-Fehlersuchers 101B von Fehlern befreit. Ein Programmierer kann durch Befehle im Programm 102C schreiten, indem er Befehle an den Host-Fehlersucher 101B gibt, der wiederum die Befehle an den Ziel-Fehlersucher 102B zur Ausführung innerhalb des im Test befindlichen Programms 102C überträgt. Die Fehlersuchergebnisse (z. B. die Werte von Variablen oder Speicherstellen) werden zum Host-Fehlersucher 101B rückgeführt und auf einer Anzeige vorrichtung 104 angezeigt. Das Programm kann beispielsweise ein Anwendungsprogramm oder ein Betriebssystem sein.
In der Architektur von 2 "drückt" der Ziel-Fehlersucher 102B typischerweise Daten zum Host-Fehlersucher 101B und verwendet somit Prozessorzeit am Ziel-Rechner 102 und ruft Nebenwirkungen hervor, die normalerweise bei Fehlen des Fehlersuchers nicht beobachtet werden würden. Da Rechner mit komplizierteren Hardwareschnittstellen ausgerüstet werden, werden konventionelle serielle Anschlüsse, wie 101A und 102A mehr und mehr verlassen und durch komplizierte Schnittstellen ersetzt, wie beispielsweise den Universal Serial Bus (USB) und den IEEE-1394-Bus. Konventionelle Fern-Fehlersucher sind an diese neue Technik nicht angepasst worden, die deutlich höherer Zugriffsgeschwindigkeiten und weitere Merkmale bieten (z. B. isochrone und asynchrone Übertragungsfähigkeiten).
Die Architektur von 2 erlaubt es einem Programmierer typischerweise, nur einen einzigen Ziel-Rechner gleichzeitig nach Fehlern zu durchsuchen, da der Host-Rechner mit dem Ziel-Rechner 102 über einen eigenen Hardwareanschluss und Hardwarequellen 103 verbunden ist, die nicht mit anderen Ziel-Rechnern geteilt werden. Wenn mehrere Zielmaschinen gleichzeitig nach Fehlern durchsucht werden sollen, muss für jeden Ziel-Rechner ein gesonderter, zugewiesener Hardwareanschluss vorgesehen sein, was den Fehlersuchvorgang kompliziert macht.
Übliche Fern-Fehlersuchschemata basieren auf Einzelzeichen, was im Allgemeinen weniger effizient ist, als Schemata auf Paketbasis. Die Verwendung solcher Schemata auf Einzelzeichenbasis an Bussen auf Paketbasis, wie IEEE 1394 würde den Vorteil der wesentlich größeren Bandbreite, die bei der letztgenannten Art Bus verfügbar ist, nicht ausnutzen.
Eine konventionelle Fehlersuchschnittstelle für die Fern-Fehlersuche ist aus US 5 978 902 bekannt.
ÜBERSICHT ÜBER DIE ERFINDUNG
Die Erfindung wird von den Gegenständen der unabhängigen Ansprüche angegeben.
Bevorzugte Ausführungsformen werden von den abhängigen Ansprüchen angegeben.
Die vorliegende Erfindung gibt ein Mittel zur Fern-Fehlersuche in Software über einen Paket-Serienbus zwischen einem Host-Rechner und einem Ziel-Rechner an. Ein Host-Fehlersucher im Host-Rechner steht mit einem Kern-Fehlersucher im Ziel-Rechner unter Verwendung eines seriellen Bus' (Serienbus), wie beispielsweise dem IEEE 1394-Bus, in Verbindung. Speicheradressen im Ziel-Rechner werden auf einen physikalischen Adressraum des Serienbus abgebildet, und ein Kern-Fehlersucher im Ziel-Rechner fragt den Speicherabbildungsbereich ab, um zu ermitteln, ob der Host-Fehlersucher eine Fehlersuchfunktion abgerufen hat.
Wenn der Kern-Fehlersucher ermittelt, dass der Host-Rechner eine gewisse Fehlersuchfunktion abgerufen hat, speichert der Kern-Fehlersucher eine Antwort in den Speicherabbildungsbereich für den abzurufenden Host-Fehlersucher. Wenn der Host-Fehlersucher den Inhalt gewisser Speicherstellen im Ziel-Rechner abfragt, speichert der Kern-Fehlersucher einen Zeiger auf die Speicherstellen, und der Host-Fehlersucher fragt direkt den Inhalt der Speicherstellen über den Serienbus ohne weitere Intervention durch die Zielmaschine und ohne Unterbrechung der Ziel-CPU ab. Mehrere Zielmaschinen (z. B. bis zu 62) können unter Verwendung eines einzigen Kabels bei Busgeschwindigkeit von 400 Megabit pro Sekunde nach Fehlern durchsucht werden, was sehr viel schneller ist, als üblicherweise erreicht werden kann.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein schematisches Blockschaltbild einer üblichen Almzweck-Digitalrechnerumgebung, die dazu verwendet werden kann, zahlreiche Aspekte der vorliegenden Erfindung zu realisieren.
2 ist ein schematisches Blockschaltbild eines Systems, das übliche Techniken zur Fern-Fehlersuche in einem Programm 102C an einem Ziel-Rechner 102 ausführt.
3 ist ein schematisches Blockschaltbild eines Systems und eines Verfahrens, die zahlreiche erfindungsgemäße Prinzipien verwenden, wobei Software, die in mehreren Zielmaschinen abläuft, unter Verwendung eines Host-Fehlersuchers nach Fehlern durchsucht wird, der über einen Serienbus unter Verwendung von Speicher abgebildeten Adressen in jeder Zielmaschine kommuniziert.
4 zeigt Schritte eines Verfahrens, das dazu verwendet werden kann, die Fern-Fehlersuche zwischen einem Host-Rechner und einem Ziel-Rechner auszuführen.
5 zeigt, wie ein gemeinsamer Speicherbereich 501 an einem Ziel-Rechner auf Adressen in einem Serienbus-Adressraum 502 abgebildet werden kann.
6 zeigt einen beispielhaften Protokollstapel zur Verbindung eines Serienbus mit höherlagigen Softwareschichten in jedem Rechner.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
1 ist ein schematisches Diagramm einer üblichen Allzweck-Digitalrechnerumgebung, die zur Realisierung zahlreicher Aspekte der vorliegenden Erfindung verwendet werden kann. Ein Rechner 100 enthält eine Prozessoreinheit 110, einen Systemspeicher 120 und einen Systembus 103, der zahlreiche Systemkomponenten, einschließlich des Systemspeichers, mit der Prozessoreinheit 110 verbindet. Der Systembus 130 kann irgendeiner aus mehreren Arten Busstrukturen sein, einschließlich eines Speicherbus oder Speichersteuerers, eines Peripheriebus und eines örtlichen Bus, der irgendeine aus einer Vielzahl Busarchitekturen verwendet. Der Systemspeicher 120 enthält einen Festspeicher (ROM) 140 und einen Arbeitsspeicher (RAM) 150.
Ein Eingabe-/Ausgabe-Grundsystem (BIOS) 160, das die Grundroutinen enthält, die den Informationsaustausch zwischen Elementen innerhalb des Rechners 100 unterstützen, wie beispielsweise beim Hochfahren, ist im ROM 140 gespeichert. Der Rechner 100 enthält auch ein Festplattenlaufwerk 170 zum Lesen aus und Schreiben in eine Festplatte (nicht gezeigt), ein Diskettenlaufwerk 180 zum Lesen aus oder Schreiben in eine entnehmbare Diskette 190 und ein Optikplattenlaufwerk 191 zum Lesen aus oder Schreiben in eine entnehmbare Optikplatte 192, wie beispielsweise eine CD-ROM oder anderes optisches Medium. Das Festplattenlaufwerk 170, das Diskettenlaufwerk 180 und das Optikplattenlaufwerk 191 sind jeweils mit dem Systembus 130 durch eine Festplattenlaufwerkschnittestelle 192, eine Diskettenlaufwerkschnittstelle 193 bzw. eine Optikplattenlaufwerkschnittstelle 194 verbunden. Die Laufwerke und ihre zugehörigen rechnerlesbaren Medien ermöglichen eine nicht-flüchtige Speicherung von rechnerlesbaren Befehlen, Datenstrukturen, Programmmodulen und anderen Daten für den Rechner 100. Der Fachmann erkennt, das andere Arten rechnerlesbaren Medien, die Daten speichern können, auf die ein Rechner zugreifen kann, wie beispielsweise Magnetkassetten, Flash-Speicherkarten, digitale Videoplatten, Bernoulli-Kassetten, Arbeitsspeicher (RAMs), Festspeicher (ROMs) und dgl. in der beispielhaften Betriebsumgebung ebenfalls verwendet werden können.
Auf der Festplatte, der Diskette 190, der optischen Platte 192, dem ROM 140 oder RAM 150 können mehrere Programmmodule gespeichert sein, einschließlich eines Betriebssystems 195, einer oder mehrerer Anwendungsprogramme 196, anderer Programmmodule 197 und Programmdaten 198. Insbesondere speichert der RAM 150 von Zeit zu Zeit zahlreiche Treiber, wie in der Technik bekannt ist. Ein Benutzer kann Befehle und Informationen in den Rechner 100 über Eingabe- oder Wählvorrichtungen eingeben, beispielsweise eine Tastatur 101 und eine Zeigervorrichtung 102. Die Zeigervorrichtung 102 kann eine Maus, ein Berührungsfeld, ein Berührungsschirm, eine Sprachsteuerung und -aktivierung oder andere ähnliche Vorrichtung sein. Andere (nicht gezeigte) Eingabevorrichtungen können ein Mikrofon, ein Joystick, ein Spielfeld, eine Satellitenschüssel, ein Scanner oder dgl. sein. Diese und andere Eingabevorrichtungen sind häufig mit der Prozessoreinheit 110 über einen seriellen Schnittstellenanschluss 106 verbunden, der mit dem Systembus verbunden ist, können aber auch über andere Schnittstellen verbunden sein, wie beispielsweise einen parallelen Anschluss, einen Spielanschluss oder einen Universal-Serienbus (USB). Ein Monitor 107 oder andere Art Anzeigevorrichtung ist ebenfalls mit dem Systembus 130 über eine Schnittstelle verbunden, beispielsweise einen Videoadapter 108. Zusätzlich zum Monitor enthaltend PCs üblicherweise weitere äußere Ausgabevorrichtungen (nicht gezeigt), wie Lautsprecher und Drucker.
Eine IEEE 1394-Schnittstelle 140 kann ebenfalls vorgesehen sein. Die IEEE 1394-Schnittstelle 140 koppelt einen IEEE 1394-verträglichen Serienbus 145 an den Systembus 130 oder ähnlichen Übertragungsbus. Der IEEE 1394-verträgliche Serienbus 145 ermöglicht es bekanntlich mehreren Vorrichtungen 150 mit dem Rechner 100 und miteinander unter Verwendung serieller Hochgeschwindigkeitskanäle zu kommunizieren. Der IEEE 1394-Serienbusstandard beruht großteils auf der international angenommenen ISO/IEC 1312 (ANSI/IEEE 1212) CSR Architecture Specification und der IEEE1394-1995 Serial Bus Specification, deren Offenbarung hier durch Bezugnahme eingeschlossen ist. Zusätzliche Busse, wie beispielsweise der PCI-Bus, können im Rechner 100 vorgesehen und mit dem IEEE 1394 und anderen Bussen gekoppelt sein.
Ein typischer Serienbus mit der Architektur eines IEEE 1394-Standard besteht aus mehreren Knoten, die über Punkt-zu-Punkt-Verbindungen, beispielsweise Kabel, miteinander verbunden sind, die jeweils einen einzelnen Knoten des Serienbus mit einem anderen Knoten des Serienbus verbinden. Die Knoten haben adressierbare Einheiten, die unabhängig rückgestellt und identifiziert werden können. Knoten sind logische Einheiten, jede mit einer eigenen Adresse. Jeder Knoten bildet einen sog. Konfigurations-ROM (Festspeicher), nachfolgend als Konfigurationsspeicher bezeichnet, und ein standardisierter Satz Steuerregister kann durch Software abgefragt werden, die im Rechnersystem beheimatet ist.
Der Rechner 100 kann in einer vernetzten Umgebung unter Verwendung logischer Verbindungen zu einem oder mehreren entfernten Rechnern, wie beispielsweise einem entfernten Rechner 109, arbeiten. Der entfernte Rechner 109 enthält typischerweise wenigstens einige der oben in Bezug auf den Rechner 100 beschrieben Elemente, obgleich nur eine Speichervorrichtung 111 in 1 dargestellt worden ist. Die in 1 gezeigten logischen Verbindungen umfas sen ein Ortsbereichsnetz (LAN) 112 und ein Weitbereichsnetz (WAN) 113. Solche vernetzten Umgebungen sind in Büros, unternehmensweiten Rechnernetzen, Intranetzen und dem Internet allgemein üblich.
Wenn in einer LAN-vernetzten Umgebung, ist der Rechner 100 mit dem örtlichen Netz 112 über eine Netzschnittstelle oder Adapter 114 verbunden. Wenn in einer vernetzten WAN-Umgebung verwendet, können der Rechner 100 und der entfernte Rechner 109 jeweils ein Modem 115 oder andere Mittel zur Einrichtung einer Verbindung über ein Breitbereichsnetz 113, wie das Internet, enthalten. Das Modem 115, das intern oder extern sein kann, ist mit dem Systembus 130 über den seriellen Schnittstellenanschluss 106 verbunden. In einer vernetzten Umgebung können bezüglich des Rechners 110 gezeigte Programmmodule oder Teile derselben in einer entfernten Speichervorrichtung gespeichert sein.
Man erkennt, dass die gezeigten Netzverbindungen beispielhaft sind und andere Mittel zur Einrichtung einer Übertragungsverbindung zwischen den Rechnern verwendet werden können. Die Existenz eines von zahlreichen bekannten Protokollen, wie beispielsweise TCP/IP, "ETHERNET", FTP, HTTP und dgl., wird vorausgesetzt, und das System kann in einer Kunde-Server-Konfiguration betrieben werden, um es einem Benutzer zu gestatten, Webseiten von einem Web-Server abzufragen. Unten zu beschreibende Prozeduren der vorliegenden Erfindung können innerhalb der Umgebung des in 1 gezeigten Rechners 100 ablaufen. Obgleich die Erfindung allgemein bei einem Rechner anwendbar ist, der in Übereinstimmung mit dem IEEE 1394-Standard arbeitet, soll die Erfindung hierauf nicht beschränkt sein.
3 zeigt ein beispielhaftes System von Vorrichtungen, die über einen Serienbus in Übereinstimmung mit zahlreichen erfinderischen Prinzipien miteinander kommunizieren. Wie in 3 gezeigt, ist ein Host-Rechner 301 mit einem oder mehreren Ziel-Rechnern 302 und 305 über einen Serienbus 303 gekoppelt. Wie oben erläutert, kann der Serienbus 303 ein Bus sein, der dem IEEE 1394-Standard entspricht. Ein solcher Bus enthält ein erstes Differenzsignalpaar zum Leiten eines ersten Signals, ein zweites Differenzsignalpaar zum Leiten eines zweiten Signals und ein Paar Stromversorgungsleitungen. Zusammen bilden die Verbindungen 303 die Verkabelung des Serienbus', und mehrere Knoten (Rechner oder andere Vorrichtungen) bilden die Funktionalität des Serienbus. Jeder Knoten am Bus kann einen oder mehrere Anschlüsse haben, obgleich in 3 angenommen wird, dass nur ein Anschluss pro Knoten (Rechner) gezeigt ist.
Jeder Ziel-Rechner 302 und 305 und Host-Rechner 301 enthält eine Schnittstellenkarte (Elemente 301A, 302A und 305A), die jedem Rechner erlaubt, Befehle und Daten auf dem Serien bus 303, beispielsweise dem IEEE 1394-Serienbus zu senden und zu empfangen. In einer Ausführungsform können solche Karten handelübliche Schnittstellenkarten sein, die intern mit dem allgemein bekannten PCI-Bus kompatibel sind, die von vielen PCs verwendet werden. Die Schnittstellenkarten werden durch die Verwendung von Softwaretreibern manipuliert, wie beispielsweise in 6 gezeigt ist.
Kurz Bezug nehmend auf 6 ist ein beispielhafter Protokollstapel zur Verbindung des Bus' mit Softwareschichten höherer Niveaus in jedem Rechner gezeigt. Der Protokollstapel enthält eine IEEE 1394-verträgliche Hardwareschicht 601, einen IEEE 1394-verträglichen Bustreiber 602 und einen oder mehrere Vorrichtungstreiber 603. Spezielle Ausführungsformen der Hardwareschichten 601 sind in der Technik allgemein bekannt und hängen typischerweise von der speziellen realisierten Vorrichtung ab. Vorrichtungstreiber 603 umfassen Rechnerbefehle, die Busfunktionen steuern, wie beispielsweise eine Busrücksetzung, Sendung und Empfang von Information auf dem Bus, Lesen aus und in Speicherstellen von Knoten am Bus und die Zuweisung von Bushilfsmitteln (z. B. isochrone Kanäle). Vorrichtungstreiber 603 überbrücken die Protokolllücke zwischen dem IEEE 1394-Protokoll und jegliches Protokoll ist daran durch seine entsprechende Vorrichtung angehängt.
Der Bustreiber 603 verwaltet Verbindungen zwischen dem physikalischen Bus und Protokollschichten höherer Niveaus. In einer Ausführungsform enthält der 1394-verträgliche Bustreiber eine Open Host Controller Interface (OHCI)-Treiberausführung 605 des IEEE 1394-Verbindungsschichtprotokolls. Die OHCI ist in der 1394 Open Host Controller Interface-Beschreibung erläutert. Diese Schnittstelle kann alle definierten 1394-Paketformate unter Verwendung von Direktspeicherzugriff (DMA) senden und empfangen, um Pakete in den Speicher des Host-Rechners einzuschreiben. In 6 sind auch zahlreiche Schnittstellen 607 bis 609 zwischen den Protokollschichten 601 bis 603 dargestellt. Die Schnittstellen 607 bis 609 bestimmen die Arten von Daten, die zwischen Schichten ausgetauscht werden können, sowie die Austauschfolge.
Wieder Bezug nehmend auf 3 wird die Fern-Fehlersuche über einen Serienbus in Übereinstimmung mit zahlreichen erfindungsgemäßen Prinzipien erläutert. Die nachfolgende Erläuterung nimmt an, dass ein in Prüfung befindliches Rechnerprogramm 302D auf einem einzigen Ziel-Rechner 302 nach Fehlern zu durchsuchen ist. Im Anschluss an den Einzelzielfall werden weitere Details einer Fehlersuchumgebung mit mehreren Zielen erläutert.
Wie in 3 gezeigt, kommuniziert der Host-Fehlersucher 301B mit einem Kern-Fehlersucher 302C, der sich am Ziel-Rechner 302 befindet, um das in Untersuchung befindliche Programm 302D nach Fehlern zu durchsuchen. Der Kern-Fehlersucher ist, wie sein Name sagt, vorzugsweise als Teil des Kernbetriebssystems enthalten, das im Ziel-Rechner 302 abläuft, und kann durch einen Softwareschalter oder anderen Mechanismus gestartet werden, wenn die Zielmaschine in Betrieb gesetzt wird. Ein gemeinsamer Speicherbereich 302B wird auf einen physikalischen Adressraum im Serienbusspeicherraum abgebildet (z. B. ein 48-Bit-Adressraum), so dass der Host-Rechner 301 in die Lage versetzt ist, Direktdaten in den Speicher innerhalb des Ziel-Rechners 302 einzuschreiben. Die 1394-OHCI kann so programmiert sein, dass sie 1394 Lese- und Schreibtransaktionen als Auslesungen und Einschreibungen am Host-Speicherraum akzeptiert. In dieser Betriebsart arbeitet die 1394-OHCI als eine Busbrücke vom 1394-Bus in den Host-Rechnerspeicher. Wenn mehrere Zielmaschinen verwendet werden, werden getrennte 48-Bit-Adressräume verwendet, da ein physikalischer Knotenidentifizierer weiter angibt, welcher von mehreren Knoten am Bus durch die anhängige 48-Bit-Adresse angesprochen wird.
In einer Ausführungsform enthält der gemeinsame Speicherbereich 302B ein Statuskennzeichen X, einen Anforderungspufferbereich Y und einen Anforderungsbestätigungsbereich Z. Die Größe dieser Bereiche und die verwendeten speziellen Kennzeichen oder Variablen können je nach Ausführungsform variieren.
Die anfängliche Speicherabbildung kann unter Verwendung eines Initialisierungskodes im Kern-Fehlersucher ausgeführt werden. Beispielsweise kann eine kleine Gruppe Zeichen als Teil einer Hardware-Abstraktionsschicht (HAL) einer dynamisch verbundenen Bibliothek (HAL.DLL)-Abbildung zugeordnet werden. Wenn der Kern startet, tätigt er einen Anruf an die HAL-Fehlersuchinitialisierungsfunktion, die dann den statischen Pufferspeicher (geladen als Teil des HAL.DLL-Abbildes) auf eine physikalische Adresse unter Verwendung der physikalischen Adresse MmGet abbildet. Sobald die physikalische Adresse bestimmt ist (sie könnte irgendwo sein, da das HAL-DLL-Abbild irgendwo im Speicher geladen sein könnte), kündigt der Ziel-Fehlersucher dieses unter Verwendung isochroner Nur-Kopf-Pakete an. Die Abbildung auf den 1394-Adressraum kann nur durch den 1394-OHCI-Host-Steuerer erfolgen, der die physikalischen Adresse 0-xxx auf 1394-Adresse 0-xxx abbildet, wobei xxx oben im physikalischen Speicher liegt. Sobald die physikalische Adresse bekannt ist, sind somit die 1394-Adressen ebenfalls bekannt.
Wenn der Host-Fehlersucher 301B zu einem Speicherplatz am Ziel-Rechner 302 zugreifen muss (z. B. zum Inhalt einer Variablen im in Prüfung befindlichen Programm 302D), schreibt er eine Fehlersuch-Anforderung in den gemeinsamen Speicheranforderungsbereich Y durch Aussendung eines Befehls über den Serienbus zum Einschreiben in diesen Bereich. Wie unten in größerem Detail erläutert wird, kann der Host-Rechner 301 die Adresse des Bereichs Y bestimmen, indem er sie aus einem "Ankündigungs"-Paket extrahiert, das periodisch vom Kern-Fehlersucher 302C übertragen wird. Der Kern-Fehlersucher 302C prüft periodisch den Anforderungsbereich Y, und wenn er entdeckt, dass vom Host-Fehlersucher 301B eine Anforderung gespeichert worden ist, ruft er die Fehlersuch-Anforderung ab, verarbeitet die Anforderung, speichert die Ergebnisse des Fehlersuchvorgangs in den Anforderungs-Bestätigungsbereich Z und setzt das Statuskennzeichen X auf "Erfolg". Anschließend ermittelt der Host-Fehlersucher 301B, dass das Erfolgskennzeichen gesetzt worden ist, und liest die Fehlersuchergebnisse direkt über den Serienbus aus dem Speicherabbildungsbereich 302B.
In einer Art Fehlersuchvorgang kann der Kern-Fehlersucher 302C in den Anforderungs-Bestätigungsbereich Z die Startspeicheradresse eines Bereichs speichern, der Gegenstand einer Fehlersuchanforderung ist. Anschließend kann der Host-Fehlersucher 301B direkt den Inhalt nachfolgender Speicherplätze in dem Bereich über den Bus 303 lesen, ohne dass der Ziel-Fehlersucher 302C eingreift oder teilnimmt. Wenn nur ein einziger Datenwert benötigt wird, kann der Kern-Fehlersucher 302C stattdessen den Datenwert (anstelle einer Adresse) in den Anforderungs-Bestätigungsbereich Z speichern, so dass ein Lesevorgang gespart wird (d. h. der Host-Fehlersucher könnte direkt den Wert lesen anstelle die Adresse des Wertes zu lesen). Beide Lösungen sind in Übereinstimmung mit Variationen der Erfindung möglich. Manche Fehlersuchvorgänge (z. B. "Gehe zum nächsten Befehl" oder dgl.) mögen das Lesen von Daten aus dem gemeinsamen Datenbereich nicht erfordern, anstelle zu bestätigen, dass das "Erfolgs"-Kennzeichen gesetzt wurde.
In gewissen Ausführungsformen werden Zustandsmanipulationen der Kern-Fehlersuchmaschine ausgeführt, indem Befehle durchlaufen werden, die zum Fern-Fehlersucher gesandt werden. Die Befehlsliste kann in Abhängigkeit von der Ausführungsform variieren und kann unabhängig von der Ausführungsform 1394 sein. Alle 1394-spezifischen Details können unter einem gewissen Abstraktionsniveau verborgen sein, so dass ein bereits existierender Kern und Host-Fehlersuchkode verwendet werden könnte, wie er ist. Zahlreiche Befehle, wie Einzelschritt, Lesen und Schreiben an I/O-Registern, Start der normalen Ausführung, Unterbrechung (Pausenausführung) und andere können eingeschlossen sein, wie es üblich ist.
Wenn die Fehlersuche freigegeben ist, werden physikalische Zugriffsfilter (eine 1394 OHCI-spezifische Funktion) an der Zielmaschine freigegeben, um es anderen Knoten zu ermöglichen, den Speicher der Zielmaschine zu lesen. Dieses kann ausgeführt werden, indem ein Register (das physikalische Anforderungsfilterregister) an der 1394 OHCI-Busschnittstellenkarte des Ziel-Rechners eingestellt wird, um anzugeben, dass es anderen Busknoten (z. B. dem Host-Rechner) erlaubt ist, direkt Speicherplätze an der Zielmaschine auszulesen, die innerhalb des 48-Bit-Adressraums des 1394-Bus abgebildet sind. Um Fehlersuchanforderungen zum Zielsystem zu übertragen, kann der Host-Fehlersucher asynchrone Schreibblockanforderungen zum Speicher an dem physikalischen Adressversatz (eine 1394-Norm) asynchron einschreiben, die im Ankündigungspaket beschrieben ist. Weitere Details der Einschreib- und Abbildungsschritte werden unten beschrieben.
Weil der Kern-Fehlersucher 302C bei der Bewegung von Daten aus dem in Untersuchung befindlichen Programm 302D (oder irgendeinem Speicherraum im Ziel-Rechner 302) wenig oder nicht teilnimmt, wird das Betriebssystem des Ziel-Rechners 302 wenig oder gar nicht beeinflusst. Es sind keine Unterbrechungen am Ziel-Rechner erforderlich, um die Fehlersuchanforderung zu bedienen, und im Gegensatz zu konventionellen Fehlersuchtechniken brauchen keine aktuellen Fehlersuchdaten vom Ziel ausgesandt werden. Statt dessen sendet das Ziel vorzugsweise kleine Pakete aus, die die physikalischen Speicheradresse enthalten, wo die Daten liegen, und die Host-Maschine nimmt sie auf. Wie unten in größerem Detail erläutert wird, beruht eine Ausführungsform der Erfindung auf der Verwendung eines zugewiesenen, isochronen Datenkanals, der im voraus für die Kommunikation zwischen dem Host-Rechner 301 und dem Ziel-Rechner 302 zugewiesen ist.
Der allgemeine Fall der Fehlerdurchsuchung eines Programms in einer einzigen Zielmaschine kann auf eine Ausführungsform ausgedehnt werden, bei der zwei oder mehr Zielmaschinen von einem einzigen Host-Rechner nach Fehlern durchsucht werden. Wie beispielsweise in 3 gezeigt, enthält jede von mehreren Zielmaschinen 302 und 305 einen gesonderten Kern-Fehlersucher und einen gemeinsamen Speicherbereich und steht mit dem Host-Fehlersucher 301B über einen getrennten, zuvor zugewiesenen Kanal in Verbindung (z.B. einen isochronen Datenkanal, der durch Übereinkunft festgelegt wurde oder vor dem Beginn der Fehlersuche ausgewählt wurde). Auf diese Weise kann der Host-Fehlersucher 301B gleichzeitig mehrere Rechnerprogramme über ein einziges Kabel beobachten und nach Fehlern durchsuchen, wodurch der Fehlersuchvorgang sehr vereinfacht wird.
Gemäß einer Variante der Erfindung sendet der Kern-Fehlersucher periodisch ein "Ankündigungs"-Paket auf einen vorbestimmten isochronen Kanal auf dem Serienbus, der vom Host-Fehlersucher erfasst und dazu verwendet wird, eine Nachrichtenverbindung zwischen zwei Rechnern einzurichten. Die "Ankündigungs"-Pakete geben die physikalische Adresse des gemeinsamen Speicherbereichs an, so dass der Host-Fehlersucher Fehlersuchanforderungen einschreiben und Fehlersuchergebnisse aus diesem Bereich des Ziel-Rechners aufnehmen kann. Durch Verwendung isochroner Kanäle für die Nachrichtenübermittlung braucht weder der Host-Rechner noch der Ziel-Rechner von der Busadresse des anderen Bescheid wissen, so dass eine Übertragung begonnen werden kann, selbst wenn keine "Abzählung" durch die zwei Rechner stattfindet.
Es wird nun auf 4 Bezug genommen, die Schritte eines Verfahrens zeigt, das dazu verwendet werden kann, eine Fernfehlersuche zwischen einem Host-Rechner und einem Ziel-Rechner durchzuführen. Es wird angenommen, dass der Host-Rechner und der Ziel-Rechner zu unterschiedlichen Zeiten hochgefahren werden, so dass die Reihenfolge, in der sie hochgefahren werden, im Voraus nicht bekannt ist. Die im Host-Fehlersucher ausgeführten Schritte (z. B. Element 301B von 3) sind in der linken Hälfte von 4 dargestellt, während die im Kern-Fehlersucher (z. B. Element 302C von 3) ausgeführten Schritte in der rechten Hälfte von 4 dargestellt sind.
Beginnend im Schritt 401 wird der Host-Fehlersucher am Host-Rechner geladen (es ist anzumerken, dass im Schritt 411 stattdessen als erster der Ziel-Rechner mit dem Kern-Fehlersucher geladen werden könnte). Im Schritt 402 lauscht der Host-Fehlersucher nach "Ankündigungs"-Paketen vom Kern-Fehlersucher, der im Ziel-Rechner wirksam ist. Wenn der Kern-Fehlersucher noch nicht geladen worden ist, wartet der Host-Fehlersucher weiter, bis der Kern-Fehlersucher ggf. gestartet ist und "Ankündigungs"-Pakete zu senden beginnt. Der Kern-Fehlersucher als erster geladen wurde, werden seine periodischen "Ankündigungs"-Pakete ggf. durch den Host-Fehlersucher nach seinem Laden erfasst.
Die "Ankündigungs"-Pakete können einmal pro Sekunde oder in jedem anderen günstigen Intervall gesendet werden, dessen Details für die Erfindung nicht kritisch sind. Der isochrone Kanal, auf dem der Kern-Fehlersucher die "Ankündigungs"-Pakete sendet, kann zuvor in einer Konfigurationsdatei beim Systemstartvorgang eingerichtet werden, so dass mehrere Zielmaschinen verschiedene isochrone Kanäle für den Sendevorgang verwenden. Alternativ kann der spezielle Kanal von Hand ausgewählt werden (z. B. unter Verwendung eines Befehlsschalters), oder automatisch unter Verwendung eines Zuweisungsschemas.
Es sei nun die rechte Seite von 4 betrachtet. Es sei angenommen, dass der Kern-Fehlersucher im Schritt 411 geladen wird und im Schritt 412 mit der Aussendung von "Ankündigungs"-Paketen beginnt. Gemäß einer Ausführungsform der Erfindung enthält jedes "Ankündigungs"-Paket die physikalische Adresse des gemeinsamen Speicherbereichs im Ziel-Rechner, in den Adressen im IEEE 1394-Adressraum abgebildet worden.
Wie beispielsweise in 5 gezeigt, enthält der physikalische Adressraum 501 des Ziel-Rechners einen ersten Bereich 501A, in dem der Kern-Fehlersucher sitzt; einen Speicherabbil dungsbereich 501B, der physikalische Adresse mit gewissen Adressen 502 im Serienbusadressraum teilt; und ein im Test befindliches Programm 501C. Der Speicherabbildungsbereich 501 wird bei der Initialisierung durch den Kern-Fehlersucher zugewiesen, und die physikalische Adresse des Bereichs wird durch den Kern-Fehlersucher bestimmt, nachdem er geladen wurde, und die "Ankündigungs"-Pakete eingefügt, so dass der Host-Fehlersucher weiß, wo er Fehlersuchwerte lesen und schreiben muss. Mit anderen Worten, die Startadresse des Speicherabbildungsbereichs 501B, der auf die entsprechenden Stellen 502 im Busadressraum abgebildet ist, wird in "Ankündigungs"-Pakete 501 eingefügt, um den Host-Fehlersucher zu informieren, wo der gemeinsame Speicherbereich liegt.
Es kann möglich sein, den gemeinsamen Speicherbereich an einer festen, vorbestimmten Stelle durch Übereinkunft anzuordnen. Alternativ wird bei zahlreichen Ausführungsformen das vorgenannte Schema verwendet, weil unterschiedliche Betriebssystemkonfigurationen die Kernkomponenten an unterschiedlichen Stellen laden können. Daher ist die Fähigkeit, den gemeinsamen Speicherbereich zu bewegen, zuverlässiger und schafft weniger Abhängigkeiten.
Es wird wieder auf 4 Bezug genommen. Die vom Kern-Fehlersucher gesendeten "Ankündigungs"-Pakete werden ggf. vom Host-Fehlersucher im Schritt 403 erfasst. In einer Ausführungsform ist die primäre Übertragungseinrichtung zwischen dem Ziel und dem Host eine isochrone Kanalrundsendung. Manche Serienbusse, einschließlich des IEEE-1394, unterstützen isochrone Datenkanäle (jeweils auf einen "Kontext" abgebildet), um eine zeitbeschränkte Paketübertragung über den Serienbus zu ermöglichen. Innerhalb des Paketkopfes eines jeden isochronen IEEE-1394-Pakets befindet sich eine Kanalnummer von 6 Bit. Empfänger "lauschen" nach Paketen, die auf einer speziellen Kanalnummer übertragen werden. Isochronströmungspakete können auf einem Kanal gesendet werden, für den die Bandbreite zugewiesen worden ist; es ist gleichzeitig immer nur einem "Sprecher" erlaubt, während eines isochronen Zyklus zu senden.
Gemäß einem Aspekt der Erfindung sind mehrere unabhängige DMA-isochrone Kontexte am 1394-Steuerer sowohl an der Ziel- als auch an der Host-Maschine vorhanden. Der OHCI-1394-Treiber des Ziel-Rechners kann Kontext "0" reservieren, so dass er nicht für andere Zwecke verwendet wird. Der OHCI-1394-Zielsystemtreiber wird durch Lesen eines Registerwertes unterrichtet, den Kontext nicht zu verwenden.
Im Schritt 404 extrahiert der Host-Fehlersucher die physikalische Adresse des gemeinsamen Speicherbereichs aus dem "Ankündigungs"-Paket und behält ihn für weitere Fehlersuchvorgänge. Unter der Annahme, dass ein Programmierer einen Fehlersuchbefehl abgegeben hat, beispielsweise einen Befehl, den Inhalt zahlreicher Speicherstellen am Ziel-Rechner zu entleeren, schreibt im Schritt 405 der Host-Fehlersucher die Fehlersuchanforderung in den gemeinsamen Speicherbereich 501B des Ziel-Rechners (genauer gesagt einen Anforderungspufferbereich 502B auf dem Serienbus, der auf den Speicher des Ziel-Rechners Speicher abgebildet ist). Bewegt man sich zur rechten Seite von 4, ermittelt der Kern-Fehlersucher diese Fehlersuchanforderung im Schritt 413 durch periodisches Abfragen dieser Speicheradresse (Schritt 414), und wenn die Anforderung ermittelt wird, wird die Anforderung im Schritt 415 bedient.
Die Fehlersuchanforderung könnte zahlreiche Arten an Fehlersuchvorgängen enthalten, beispielsweise das Übergehen zum nächsten Befehl im in Prüfung befindlichen Programm; das Wiedergewinnen des Wertes eines Registers oder einer Speicheradresse; oder das Ausleeren des Inhalts einer Gruppe, um Beispiele zu nennen. Wenn der Fehlersuchvorgang Daten vom Ziel-Rechner anfordert, kann der Kern-Fehlersucher die Anforderung bedienen, indem er den angeforderten Datenwert in den Anforderungsbestätigungspuffer 502C (siehe 5) speichert, was den Datenwert für den Host-Fehlersucher verfügbar macht, weil er im gemeinsamen Speicherbereich gespeichert ist. Alternativ brauchen manche Fehlersuchvorgänge die Wiedergewinnung eines Datenwertes nicht erfordern.
Um den Inhalt einer Datengruppe auszuleeren, kann der Kern-Fehlersucher die physikalische Adresse, bei der die Gruppe beginnt, in den Anforderungsbestätigungspuffer 502C speichern, und der Host-Fehlersucher kann direkt Speicherauslesungen über den Serienbus ausführen, was an diesem Ort beginnt, und damit den Eingriff (und unnütze Verarbeitung) durch den Kern-Fehlersucher verhindert.
Nachdem der Kern-Fehlersucher die Anforderung bedient, setzt er dann im Schritt 416 das Statuskennzeichen 502A auf "Erfolg", was im Schritt 406 durch den Host-Fehlersucher erfasst wird. (Der Host-Fehlersucher kann periodisch den gemeinsamen Speicherplatz abfragen, um auf die Anwesenheit des "Erfolg"-Kennzeichens zu warten). Dann wiederbeschafft der Fehlersucher im Schritt 407 den Fehlersuchwert (sofern vorhanden) aus dem Anforderungsbestätigungspufferbereich 502C (5), und wenn der Wert eine Adresse repräsentiert, verwendet er ihn, um Datenwerte wiederzubeschaffen, beginnend an jener Adresse, direkt über den Serienbus im Schritt 508. Schließlich setzt im Schritt 409 der Host-Fehlersucher das Statuskennzeichen zurück und kehrt zum Schritt 405 zurück.
Nachfolgend wird detaillierter erklärt, wie der Kern-Fehlersucher an der Zielmaschine initialisiert und konfiguriert werden kann, unter der Annahme, dass IEEE-1394-Serienbus als Kommunikationsmedium mit einem PCI-Bus im Zusammenwirken mit einem beispielhaften Betriebssystem verwendet wird, das von Microsoft Corporation auf dem Markt angeboten wird. Andere Techniken können von anderen Betriebssystemen und Busstrukturen verwendet werden.
Die nachfolgenden BOOT.INI-Optionen können vorgesehen, um es dem Hochgeschwindigkeitsserienbus zu ermöglichen, am Ziel-Rechner Fehler zu suchen:
/DEBUGBUS = <Busname> – bezeichnet Fehlersuchbus (1394, USB, usw.
/CHANNEL 0 xx bezeichnet 1394-Rundrufkanal zur Verwendung
/BUSPARAMS = <Busnummer>.<devicet>.<function>@<BAR> (optional)
bezeichnet PCI-Adressierinformation und BAR, um den Steuerer damit zu programmieren.
Die größte Herausforderung ist die Identifizierung und Konfigurierung, um den Bus-Host-Steuerer und das Booten zeitzusteuern. Dieses muss bei der Phase-0-Initialisierung getan werden, wodurch die verfügbaren Anwendungsprogrammierschnittstellen (Apis) von der Hardwareabstraktionsschicht-(HAL-)Bibliothek begrenzt werden, die ein großer Satz Routinen ist, die als eine Bibliothek geladen ist und für gewisse Systemhardwarekonfigurationen spezifisch ist. Es kommen zwei Methoden in Betracht:

1. Ablauf einer Fehlersuchanwendung, wenn das Betriebssystem gebootet hat, was es dem Benutzer erlaubt, den gewünschten Bus-Host-Steuerer zu spezifizieren. Unter Verwendung von PnP wird dann die PCI-Busnummer, die Schlitznummer, Funktion und BAR des API für diese Vorrichtung erlangt und dann zur BOOT.INI-Optionenlinie hinzugefügt.
2. Wenn diese Anwendung nicht ausgeführt wird, sondern die Optionenline /DEBUG/DEBUGBUS=1394 angibt, werden die PCI-Busse im System zur Initialisierungszeit durchquert, wobei nach dem generischen Klassenkode für OHCI-1394-Host-Steuerer gesucht wird. Dieses kann kodiert sein, so dass alle anderen Busse die gleichen Abzählfunktionen verwenden können. Exportierte HAL-Funktionen HalGetBusDataByOffset und HalSetBusDataByO=ffset können verwendet werden.
Sobald wenigstens ein 1394-Steuerer gefunden ist, findet der Kern-Fehlersucherkode die Base Address Register und verwendet sie, um den Host-Steuerer zu initialisieren. Eine gewisse Form von Kommunikation ist zwischen dem Kern-1394-Fehlersucher und dem WDM-Stapel erforderlich, so dass das Versorgungsmanagement und PnP koordiniert werden können, sobald das Betriebssystem lädt. Eine vorgeschlagene exportierte Kernroutine wird unten angegeben:

Die folgenden Schritte beschreiben das Ziel-Fehler-Sucher-Initialisierungsprotokoll:

1. Initialisiere den Host-Steuerer, initialisiere 1 TX-Isochron-DMA-Inhalt. Der erste TX DMA-Inhalt wird verwendet.
2. Gib alle Bits am Physical-Access-Filter-Register frei (Zielsysteme, bei denen die Fehlersuche freigegeben ist, sind nicht sicher).
3. Initialisiere das Speichersegment, das über das physikalische DMA dem Bus ausgesetzt ist. Initialisiere den physikalischen Zugriffsbereich des Fehlersuchers.
4. Erzwinge Wurzel, so dass der Ziel-Fehlersucher der Wurzelknoten des 1394-Bus' wird. Dies wird getan, um sicherzustellen, dass Zyklusstartpakete auf den Bus gesandt werden, wodurch isochrone Verbindungen möglich werden. Wenn die Wurzelerzwingung nach einer gewisser Anzahl erneuter Versuche ausfällt, hält der Ziel-Fehlersucher an und nimmt an, dass ein möglicher Knoten Wurzel- und Zyklushaupt ist.
5. Starte Wiederhole Aussendungen (auf dem zugewiesenen isochronen Kanal) des "Ankündigungs"-Pakets, einschließlich der Adresse des physikalischen Fehlersuchzugriffsbereichs. Das Paket wird gesandt, wenn KdPolIBreakIn aufgerufen wird.

Wenn der Abruf auftritt, läuft der Ziel-Fehlersucher durch einen Grundtest, um sicherzustellen, dass der 1394-Steuerer sich in der richtigen Betriebsart befindet. Wenn nicht, programmiert er dynamisch die notwendigen Register um, um es dem Ziel zu ermöglichen, Pakete zu empfangen und rundzusenden.
Die Host-Maschine kann i386kd.exe und einen virtuellen Host-Fehlersuchtreiber (1394vdbg.sys) verwenden, um Zugang zum 1394-Bus zu erhalten und mit der Zielmaschine zu kommunizieren. Der virtuelle Treiber sollte laufen, bevor i386kd.exe nach Fehlern suchen kann. Der Host-Fehlersucher kann eine virtuelle Vorrichtungsunterstützung vom 1394-Bustreiber verwenden, um einen virtuellen Vorrichtungstreiber zu laden, der Zugang zum 1394-Bus erlaubt. Die virtuelle Vorrichtungs-API kann verwendet werden, um den Host-Fehlersucher von der PnP-Aufzählung von Ziel-Rechnern unabhängig zu machen und ihn gegen Bus-PnP-Ereignissen abzuschirmen. Sie ermöglicht auch dem Host-Fehlersucher den Zugang zu jedem Knoten auf dem Bus, indem sie im Wesentlichen einen Durchgangbetrieb direkt zur Verbindungsschicht liefert.
Es gibt zwei Wege, den virtuellen Fehlersucher-Vorrichtungstreiber zu laden:

1. Für einen Registereintrag hinzu unter [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{6BDD1FC1-810F-11D0-BEC7-08002BE2092F}\0000\Virtual Device List]; oder
2. Gib in IOCTL_IEEE1392_API-REQUEST an die 1394-Bussymbolverbindung, mit Anforderungs->Anforderungsnummer = IEEE1394_API_ADD_VIRTUAL_DEVICE.

Die folgenden Schritte beschreiben eine Lösung für den virtuellen Host-Fehlersuchertreiber:

1. Schaffe ein Vorrichtungsobjekt und eine symbolische Verbindung für jeden 1394-Kanal. Dieses wird als die Kanalvorrichtung bezeichnet.
2. Wenn ein IRP_MJ_CREATE an der Kanalvorrichtung ausgeführt wird, weise den isochronen Kanal und die erforderliche Bandbreite für Pakete fester Länge zu unter Verwendung von 1394-Bus-DDIs.
3. Kennzeichne die Vorrichtung als im LOOKING_FOR_DEBUGGER_MODE befindlich.
4. Weise Busquellen zu unter Verwendung von REQUEST_ALLOCATE_RESOURCES_DDI. Der Hörbetrieb ist Paket-basierendes, zirkulares DMA ohne Kopfteile.
5. Bringe N Deskriptoren an der Quelle und beginne mit dem Hören. Höre am Anfang nur auf leere Kopfteile, die die Fehlersucheranwesenheit ankündigen.
6. Wenn ein Fehlersucherpaket empfangen wird, kopiere und speichere die Kopfteilinformation, die für die Übertragung zum Fehlersucher verwendet wird. Lösche das LOOKING_FOR_DEBUGGER_MODE-Kennzeichen und tritt in den Datenempfangsbetrieb ein.

An diesem Punkt ist der Host-Fehlersucher bereit IRPs von der Fehlersucheranwendung zu lesen oder zu schreiben.
Sobald das i386kd die Kanalvorrichtungs-Symbolverbindung geöffnet hat und einen Ansatzpunkt wiedergefunden hat, ist der Vorgang der gleiche, wie bei der Verwendung des seriellen Anschlusses: WriteFile/ReadFile-APIs können dazu verwendet werden, Daten auf den 1394-Bus zu senden und davon zu empfangen.
Der Ziel-Fehlersucher kann den folgenden isochronen Paketkopf verwenden, um seine Anwesenheit anzukündigen:
Dieser Kopf kann etwa alle Sekunde ausgesandt werden, solang der Ziel-Fehlersucher aktiv ist, und in ein isochrones 1394-Paket eingeschlossen werden, wobei das Etikettenfeld auf 0 gesetzt ist. Dieses erlaubt es dem Host, alle Pakete mit Etikett 0 herauszufiltern, nachdem er den Fehlersucher entdeckt und er nur nach Datenpaketen lauscht. Dieser Kopf kann auch in Datenpaketen verwendet werden.
In manchen Ausführungsformen werden vom Ziel-Fehlersucher wirklich keine Daten gesandt. Stattdessen sendet Ziel-Fehlersucher lediglich eine Streu-Sammel-Liste der Datenadresse, die den Ort der Daten im physikalischen Speicher des Ziel-Rechners angibt. Das folgende Paketformat kann dazu verwendet werden, den Ort der Daten mitzuteilen:
Das obige Paket ist mit nur drei Streu-Sammel-Elementen angegeben, um das existierende NT-Fehlersuchprotokoll unterzubringen, das drei Teile eines Kern-Fehlersucherpakets definiert:

1. Paketkopf – Paketinformation fester Länge und CRC
2. Mitteilungskopf – Variable Länge
3. Mitteilungsdaten (optional) – Variable Länge

Unter Verwendung des obigen Formats ist die Bandbreitenverwendung auf dem Bus minimiert, da für jegliche Datenübertragung das Ziel nur 80 Bytes sendet. Datenpakete verwenden vorzugsweise Etikett = 2, um sie vom Kopf nur "Ankündigungs"-Pakete zu unterscheiden und es dem Host-Rechner zu ermöglichen, jeden Pakettyp zu filtern.
Nach einer Busrücksetzung kann der Knoten ID des Ziel-Fehlersuchers wechseln. Wenn dies geschieht, ist der Host-Rechner nicht in der Lage, mit dem Ziel zu kommunizieren, sofern er nicht den neuen Knoten ID des Ziels wieder findet. Es ist anzumerken, dass die traditionelle 1394-Aufzählung hier keine Anwendung findet. Man kann nicht annehmen, dass das Konfigurations-ROM des Ziels gelesen werden kann, um das GUID wiederzufinden. Stattdessen das Ziel das Etikett an den Ankündigungspakten von 0 auf 2, um so an der Filterung im Host vorbeizukommen. Dieses erreicht das Folgende:

1. Keine Notwendigkeit einer langwierigen Aufzählung, die nicht immer einwandfrei arbeitet.
2. Keine Notwendigkeit, dass die Host-Maschine den Datenempfangsbetrieb anhält und mit dem Lauschen nach Ankündigungspaketen beginnt.
3. Automatische Entdeckung einer neuen Ziel-ID.

Nach 3 Sekunden schaltet das Ziel das Etikett zurück auf 0, so dass die Filterung nicht mehr überbrückt wird. Die Host-Maschine setzt einen Zeitgeber, nachdem eine Busrücksetzung erfasst wird, und wenn das Ziel nicht innerhalb von 3 Sekunden entdeckt wird, wird sie gezwungen, den Datenempfangsbetrieb zu verlassen und in den LOOKING_FOR_TARGET-Betrieb einzutreten.
Für Übertragungsanforderungen an das Zielsystem sendet der Host-Fehlersucher asynchrone Schreibblockanforderungen an den Speicher an den Physical Address Offset, der im Ankündigungspaket beschrieben ist, der auf den gemeinsamen physikalischen Bereich im Zielspeicher zeigt. Das Speichersegment (das Teil des Fehlersucherabbildes war) wird unter Verwendung der MmGetPhysicalAddress abgebildet. Der Adressbereich kann das folgende physikalische Layout verwenden:
Die nachfolgende Datenstruktur definiert ein Paketformat, das vom Host-Fehlersucher verwendet werden kann, wenn er in den HostRequest-Speicherraum einschreibt:
ZIEL-KERN-FUNKTIONEN
Die folgenden Kern- und HAL-Funktionen können verwendet werden, um eine Fehlersuche auf PCI-Basis und speziell auf Basis 1394 zu unterstützen:
HAL-Funktionen
Routine-Beschreibung:
Diese Routine zählt die Bussteuerung von DebugParameters.BusType ab unter Verwendung des geeigneten ClassCode (generische Abzählung). Wenn PCI-Adressierinformation auf dem Optionenstrang gefunden wurde, der vom Lader passiert wurde, wird dieses verwendet und wird direkt zu dieser Bus-Nummer gegangen, Schlitz, Funktion zur Einstellung dieser Steuerung.
Argumente:
DebugParameters – Liefert Fehlersuchparameter, die vom Optionenstrang automatisch analysiert werden.
LoaderBlock – Liefert einen Zeiger an den LOADER_PARAMETER_BLOCK, der vom Betriebssystemlader durchlaufen wird.
Rückkehrwert:
Keiner
Routine-Beschreibung
Diese Routine verwendet die PCI-Adressierinformation, um den PCI-Konfigurationsraum zu adressieren, und unter Verwendung von HAL-apis den für die Fehlersuche verwendeten Host-Steuerer freizugeben.
Argumente:
DebugParameters – Liefert Fehlersuchparameter, die vom Optionenstrang analysiert werden.
Rückkehrwert:
Kernfunktionen
Routine-Beschreibung:
Diese Routine initialisiert den tragbaren Kern-Fehlersucher für alles andere als den seriellen Anschluss.
Argumente:
LoaderBlock – Liefert einen Zeiger zum LOADER_PARAMETER_BLOCK, der vom Betriebssystemlader beschrieben wird.
StopInDebugger – Liefert einen Boole'schen Wert, der bestimmt, ob eine Fehlersuchmitteilung und eine Bruchstelle erzeugt werden.
Rückkehrwert:
keiner
Routine-Beschreibung:
Diese Funktion wird aufgerufen, um zum Fehlersucher zuzugreifen und den geeigneten PCI-Bussteuerer zu sperren/freizugeben/abzufragen.
Argumente:
Operation – Auszuführende Operation. Sie kann sein Freigabe, Sperrung oder Abfrage
Length – Größe in Bytes des versorgten Datenpuffers. Modifizierung auf wahre Länge ist erforderlich.
Data – Datenpuffer zur Rückführung von Dateninformation (DEBUG_PARAMETERS-Struktur)
Rückkehrwert:
1394-spezifische Funktionen
Was oben beschrieben worden ist, ist lediglich für die Anwendung der Prinzipien der vorliegenden Erfindung illustrativ. Andere Anordnungen und Verfahren können vom Fachmann geschaffen werden, ohne vom Umfang der vorliegenden Erfindung abzuweichen. Jedes der erfindungsgemäßen Verfahren kann in Software ausgeführt werden, die auf Rechnerplatten oder anderen Rechner-lesbaren Medien zur Ausführung in einem Host- oder Ziel-Rechner gespeichert werden können. Während als Übertragungskanal ein elektrisches Medium beschrieben worden ist, können die Prinzipien auch bei Verwendung von Hochfrequenz- oder Faseroptik oder anderen Medien angewendet werden. Kein Anspruch sollte als im Einrichtung-plus-Funktion-Format liegend interpretiert werden. Nummerierte Schritte in Verfahrensansprüche sollten nicht so interpretiert werden, dass sie eine bestimmte Reihenfolge der Schritte verlangen.

Claims

Verfahren für die Fern-Fehlersuche in einem Computerprogramm auf einem Zielcomputer (302; 305) in einem System, das einen Host-Computer und den Ziel-Computerumfasst, die über ein Kommunikationsmedium (303) verbunden sind, das einen gemeinsamen Adressraum mit dem Ziel-Computer unterstützt, wobei das Verfahren die folgenden Schritte umfasst: 1) Zuweisen eines gemeinsamen Speicherbereiches (302B, 305B) in dem Ziel-Computer und Abbilden des gemeinsamen Speicherbereiches auf einen Adressraum des Kommunikationsmediums; 2) Speichern einer Fehlersuch-Anforderung von dem Host-Computer in dem gemeinsamen Speicherbereich auf dem Ziel-Computer; und 3) Abrufen der Fehlersuch-Anforderung aus dem gemeinsamen Speicherbereich und Abarbeiten der Fehlersuch-Anforderung in dem Ziel-Computer.
Verfahren nach Anspruch 1, wobei die Schritte 1) bis 3) unter Verwendung eines IEEE-1394-kompatiblen seriellen Busses als das Kommunikationsmedium umgesetzt werden.
Verfahren nach Anspruch 1, das des Weiteren die folgenden Schritte umfasst: 4) Setzen eines Flag in dem gemeinsamen Speicherbereich, das anzeigt, dass die Fehlersuch-Anforderung abgearbeitet worden ist, in dem Ziel-Computer; und 5) Erfassen, dass das Flag gesetzt worden ist, und in Reaktion darauf, Abrufen eines oder mehrerer Daten-Werte aus dem Ziel-Computer in dem Host-Computer.
Verfahren nach Anspruch 3, wobei Schritt 5) unter Verwendung eines Bus-Lesebefehls durchgeführt wird, der einen oder mehrere Daten-Werte aus einem physikalischen Adressraum anfordert, der von dem Ziel-Computer und dem Kommunikationsmedium gemeinsam genutzt wird.
Verfahren nach Anspruch 1, wobei Schritt 3) in einem Kernelmodus-Debugger auf dem Ziel-Computer durchgeführt wird.
Verfahren nach Anspruch 5, wobei Schritt 3) durchgeführt wird, ohne Interrupts auf dem Ziel-Computer zu erzeugen.
Verfahren nach Anspruch 5, das des Weiteren den Schritt des Setzens eines physikalischen Filterregisters auf dem Ziel-Computer umfasst, das es dem Host-Computer ermöglicht, Daten direkt von Speicherstellen in dem Ziel-Computer zu lesen.
Verfahren nach Anspruch 1, das des Weiteren die folgenden Schritte umfasst: Senden eines "Ankündigungs"-Pakets, das eine Adresse des gemeinsamen Speicherbereiches enthält, von dem Ziel-Computer, und Verwenden der Adresse des gemeinsamen Speicherbereiches aus dem "Ankündigungs"-Paket in dem Host-Computer, um eine Speicherstelle für die in Schritt 2) gespeicherte Fehlersuch-Anforderung zu bestimmen.
Verfahren nach Anspruch 8, wobei beim Schritt des Sendens des "Ankündigungs"-Pakets ein Isochron-Datenkanal auf dem Kommunikationsmedium verwendet wird.
Verfahren nach Anspruch 1, das des Weiteren den Schritt des Wiederholens der Schritte 1) bis 3) für eine Vielzahl von Ziel-Rechnern umfasst, die das Kommunikationsmedium gemeinsam nutzen.
Verfahren nach Anspruch 10, das des Weiteren den Schritt des Verwendens eines separaten Isochron-Datenkanals auf dem Kommunikationsmedium zur Kommunikation mit jedem der Vielzahl von Ziel-Rechnern umfasst.
Verfahren nach Anspruch 1, wobei die Schritte 1) bis 3) unter Verwendung eines paketbasierten seriellen Busses, der Isochron-Datenkanäle unterstützt, als das Kommunikationsmedium durchgeführt werden.
System für die Fern-Fehlersuche in einem Computerprogramm, das in Kombination umfasst: einen Ziel-Computer (302; 305), auf dem die Fehlersuche in dem Computerprogramm durchgeführt werden soll; einen Host-Computer (301), auf dem die Fehlersuche ferngesteuert wird; und ein Kommunikationsmedium (303), das mit dem Ziel-Computer und dem Host-Computer verbunden ist, dadurch gekennzeichnet, dass: der Ziel-Computer einen gemeinsamen Speicherbereich (302B; 305B) umfasst, der auf einem Adressraum des Kommunikationsmediums abgebildet ist, so dass Adressen in dem Speicherbereich direkt für den Host-Computer zugänglich sind, ohne Interrupts auf dem Ziel-Computer zu erzeugen; und dass der Host-Computer eine Fehlersuch-Anforderung in dem gemeinsamen Speicherbereich auf dem Ziel-Computer speichert und Fehlersuch-Ergebnisse abruft, indem er einen Datenwert aus dem gemeinsamen Speicherbereich auf dem Ziel-Computer liest.
System nach Anspruch 13, wobei das Kommunikationsmedium einen IEEE-1394-kompatiblen seriellen Bus umfasst.
System nach Anspruch 13, wobei der Ziel-Computer ein Flag in dem gemeinsamen Speicherbereich setzt, um anzuzeigen, dass die Fehlersuch-Anforderung abgearbeitet worden ist, und wobei der Host-Computer erfasst, dass das Flag gesetzt worden ist, und in Reaktion darauf einen oder mehrere Daten-Werte aus dem Ziel-Computer abruft.
System nach Anspruch 15, wobei der Host-Computer einen Bus-Lesebefehl verwendet, der einen oder mehrere Daten-Werte aus einem physikalischen Adressraum anfordert, der von dem Ziel-Computer und dem Kommunikationsmedium gemeinsam genutzt wird.
System nach Anspruch 13, wobei der Ziel-Computer einen Kernelmodus-Debuggerumfasst, der Daten-Werte abruft und in dem gemeinsamen Speicherbereich auf dem Ziel-Computer speichert, um die Fehlersuch-Anforderung abzuarbeiten.
System nach Anspruch 17, wobei der Kernelmodus-Debugger die Fehlersuch-Anforderung abarbeitet, ohne Interrupts auf dem Ziel-Computer zu erzeugen.
System nach Anspruch 17, wobei der Ziel-Computer ein physikalisches Filterregister auf dem Ziel-Computer setzt, das es dem Host-Computer ermöglicht, Daten direkt von Speicherstellen in dem Ziel-Computer zu lesen.
System nach Anspruch 13, wobei der Ziel-Computer ein "Ankündigungs"-Paket sendet, das eine Adresse des gemeinsamen Speicherbereiches enthält, und wobei der Host-Computer die Adresse des gemeinsamen Speicherbereiches aus dem "Ankündigungs"-Paket verwendet, um eine Speicherstelle für die Fehlersuch-Anforderung zu bestimmen.
System nach Anspruch 20, wobei der Ziel-Computer das "Ankündigungs"-Paket unter Verwendung eines Isochron-Datenkanals auf dem Kommunikationsmedium sendet.
System nach Anspruch 13, das des Weiteren einen zweiten Ziel-Computer umfasst, der ein zweites Computerprogramm umfasst, in dem Fehlersuche durchzuführen ist, wobei der zweite Ziel-Computer ebenfalls über das Kommunikationsmedium mit dem Host-Computer verbunden ist; wobei der zweite Ziel-Computer einen zweiten gemeinsamen Speicherbereich umfasst, der auf dem Adressraum des Kommunikationsmediums abgebildet ist, so dass Adressen in dem zweiten Speicherbereich direkt für den Host-Computer zugänglich sind, ohne Interrupts auf dem zweiten Ziel-Computer zu erzeugen; und wobei der Host-Computer eine zweite Fehlersuch-Anforderung in dem zweiten gemeinsamen Speicherbereich auf dem zweiten Ziel-Computer speichert und zweite Fehlersuch-Ergebnisse abruft, indem er einen zweiten Daten-Wert aus dem zweiten gemeinsamen Speicherbereich auf dem zweiten Ziel-Computer liest.
System nach Anspruch 22, wobei der erste Ziel-Computer einen erste Isochron-Datenkanal auf dem Kommunikationsmedium nutzt, um mit dem Host-Computer zu kommunizieren; und wobei der zweite Ziel-Computer einen zweiten Isochron-Datenkanal auf dem Kommunikationsmedium verwendet, um mit dem Host-Computer zu kommunizieren.
System nach Anspruch 13, wobei das Kommunikationsmedium einen paketbasierten seriellen Bus umfasst, der Isochron-Datenkanäle unterstützt.
Computerlesbares Medium, das Computerbefehle umfasst, die, wenn sie durch einen Ziel-Computer ausgeführt werden, auf dem Fehlersuche in einem Programm durchgeführt wird, die folgenden Schritte durchführen: 1) Zuweisen eines gemeinsamen Speicherbereiches in dem Ziel-Computer und Abbilden des gemeinsamen Speicherbereiches auf einen Adressraum eines Kommunikationsmediums, mit dem der Ziel-Computer verbunden ist; 2) Erfassen, dass eine Fehlersuch-Anforderung für das Programm in dem gemeinsamen Speicherbereich auf dem Ziel-Computer gespeichert worden ist; 3) Speichern eines Fehlersuch-Ergebnisses in dem gemeinsamen Speicherbereich auf dem Ziel-Computer, so dass es von einem anderen Computer über das Kommunikationsmedium abgerufen werden kann, ohne die CPU des Ziel-Computers zu unterbrechen.
Computerlesbares Medium nach Anspruch 25, wobei die Computerbefehle, wenn sie ausgeführt werden, des Weiteren den Schritt des Durchführens von Senden eines "Ankündigungs"Paketes, das die Speicherstelle des gemeinsamen Speicherbereiches anzeigt, über das Kommunikationsmedium durchführen.
Computerlesbares Medium nach Anspruch 26, wobei die Computerbefehle, wenn sie ausgeführt werden, das "Ankündigungs"Paket über einen Isochron-Datenkanal des Kommunikationsmediums senden.
Computerlesbares Medium, das Computerbefehle umfasst, die, wenn sie durch einen Host-Computer ausgeführt werden, von dem Fern-Fehlersuche in einem Computerprogramm durchgeführt wird, das auf einen Ziel-Computer läuft, die folgenden Schritte durchführen: 1) Erfassen eines gemeinsamen Speicherbereiches in dem Ziel-Computer, der auf einem Adressraum eines Kommunikationsmediums abgebildet ist, mit dem der Ziel-Computer verbunden ist; 2) Speichern einer Fehlersuch-Anforderung in dem gemeinsamen Speicherbereich in dem Ziel-Computer durch Ausgeben eines Befehls, der direkt in den gemeinsamen Speicherbereich schreibt; und 3) Abrufen von Fehlersuch-Ergebnissen aus dem gemeinsamen Speicherbereich durch Ausgeben eines Befehls, der direkt einen oder mehrere Daten-Werte aus dem gemeinsamen Speicherbereich liest.
Computerlesbares Medium nach Anspruch 28, wobei die Computerbefehle, wenn sie ausgeführt werden, den gemeinsamen Speicherbereich erfassen, indem eine Adresse des gemeinsamen Speicherbereiches aus einem "Ankündigungs"-Paket extrahiert wird, das durch den Ziel-Computer gesendet wird.
Computerlesbares Medium nach Anspruch 29, wobei die Computerbefehle, wenn sie ausgeführt werden, die Adresse des gemeinsamen Speicherbereichs aus einem "Ankündigungs"-Paket extrahieren, das über einen Isochron-Datenkanal des Kommunikationsmediums gesendet wird.