[OpenBSD]

[FAQ-Index] [Zum Kapitel 1 - Einführung in OpenBSD] [Zum Kapitel 3 - Wo man OpenBSD herbekommt]

2 - Andere Informationsquellen zu OpenBSD

Inhaltsverzeichnis

2.1 - Interessante Webseiten

Die offizielle Website des OpenBSD-Projekts findest du unter http://www.OpenBSD.org/de/.

Hier kannst du viele wertvolle Informationen über alle Aspekte des OpenBSD-Projekts finden.

Das OpenBSD Journal ist ein Neuigkeiten- und Meinungsportal, das auf OpenBSD fokussiert ist.

OpenBSDsupport.org ist eine Seite, die benutzerverwaltete Dokumentationen von unterschiedlicher Qualität sammelt. Häufig werden aber Themen abgedeckt, die nicht in dieser FAQ oder anderen offiziellen Dokumenten behandelt werden.

Viele Benutzer haben Webseiten und Homepages mit OpenBSD-spezifischen Informationen erstellt. Wie mit allem im Internet wird eine gute Suchmaschine dein Leben einfacher machen - so wie es auch mit einer gesunden Dosis an Skepsis der Fall ist. Wie immer gilt: Gib keine Befehle blindlings in deinen Computer ein, die du nicht verstehst.

2.2 - Mailinglisten

Das OpenBSD-Projekt betreibt mehrere populäre Mailinglisten, die die Benutzer abonnieren und lesen sollten. Um eine Mailingliste zu abonnieren, schicke eine E-Mail an majordomo@openbsd.org. Diese Adresse ist ein automatischer Abonnementservice. Im Textkörper der Nachricht sollte in einer einzigen Zeile der Befehl stehen, um sich in die gewünschte Liste einzutragen. Zum Beispiel:

subscribe announce

Der Mailinglistendienst wird dir antworten und dich um Bestätigung bitten, sodass andere nicht in der Lage sind, dich mit einer Flut von unerwünschten E-Mails zu überschwemmen. Die Nachricht beinhaltet mehrere verschiedene Optionen für die Bestätigung; dazu gehören ein Listserver-Webseitenlink und die Möglichkeit, der Bestätigungs-E-Mail oder majordomo@openbsd.org zu antworten. Verwende die Option, die für dich am einfachsten ist. Du wirst feststellen, dass alle drei Varianten ebenfalls eine einzigartige und zeitlich begrenzte Identitätsnummer beinhalten (z. B. A56D-70D4-52C3), um zu gewährleisten, dass du tatsächlich die Person bist, die den Mailinglisteneintrag angefordert hat (das ist wirklich »opt-in«).

Nach deiner Bestätigung wirst du sofort in die Liste eingetragen und der Mailinglistendienst schickt dir eine Erfolgsbestätigung.

Um dich wieder von einer Liste abzumelden, schickst du eine Nachricht an majordomo@openbsd.org. Sie könnte etwa so aussehen:

unsubscribe announce

Solltest du Schwierigkeiten mit dem Mailinglistensystem haben, dann lies zunächst die Anweisungen und Hinweise. Wenn du eine E-Mail mit dem Textkörper »help« an majordomo@openbsd.org schickst, bekommt du sie als Antwort zugesendet.

Dein Abonnement der OpenBSD-Mailinglisten kann ebenfalls über das Webinterface auf http://lists.openbsd.org verwaltet werden.

Einige der beliebtesten OpenBSD-Mailinglisten sind:

Bevor du eine Frage auf misc oder einer anderen Mailingliste stellst, überprüfe bitte zunächst, ob deine Frage nicht schon in den Archiven auftaucht, da die meisten Fragen schon einmal gestellt wurden. Auch wenn du das Problem zum ersten Mal siehst, ist es anderen doch oftmals schon begegnet. Wurden die Mailinglisten vielleicht schon letzte Woche damit überschwemmt, freuen sich die Leser sicher nicht auf eine Wiederholung. Falls du eine Frage stellst, die möglicherweise mit Hardware zu tun hat, füge immer eine dmesg(8) mit ein!

Du kannst einige Archive, andere Mailinglistenrichtlinien und weitere Informationen auf der Mailinglistenseite finden.

Eine inoffizielle Mailingliste, die insbesondere für neue Anwender von OpenBSD interessant sein könnte, ist die Liste mit dem Namen OpenBSD Newbies.

2.3 - Manualseiten

OpenBSD wird von einer ausführlichen Dokumentation in Form von Manualseiten und weiteren, längeren Artikeln begleitet, die sich auf spezielle Anwendungen beziehen. Besonders viel Wert wird darauf gelegt sicherzustellen, dass die Manualseiten aktuell und genau sind. In allen Fällen werden die Manualseiten als maßgebliche Informationsquelle für OpenBSD angesehen.

Um die Manualseiten lesen zu können, müssen die man42.tgz- und misc42.tgz-Dateisets installiert sein.

Hier eine Liste der nützlichsten Manualseiten für Anfänger:

Einführung

Für fortgeschrittenere Anwender

Die OpenBSD-Manualseiten sind im Web über http://www.openbsd.org/cgi-bin/man.cgi und auch auf deinem eigenen Computer zu finden, wenn du das man42.tgz-Dateiset installierst.

Im Allgemeinen kannst du die Manualseite eines dir namentlich bekannten Befehls erreichen, indem du man Befehl eingibst. Zum Beispiel zeigt dir man vi die Manualseite des Vi-Editors an. Solltest du den genauen Namen des Befehls nicht wissen oder man Befehl nicht die gewünschte Manualseite bringt, kannst du mittels apropos irgendwas oder man -k irgendwas nach dem Namen des Befehls suchen, wobei »irgendwas« möglicherweise in der von dir gesuchten Manualseite enthalten sein sollte. Zum Beispiel:

# apropos "time zone" tzfile (5) - time zone information zdump (8) - time zone dumper zic (8) - time zone compiler

Die Zahlen in Klammern deuten auf das Kapitel, in dem sich die Manualseite befindet. In einigen Fällen enthalten die Manualseiten den gleichen Befehl in verschieden Kapiteln. Ein Beispiel: Du möchtest das Format der Konfigurationsdatei des Cron-Daemons nachlesen. Wenn du einmal weißt, in welchem Kapitel sich die gewünschte Manualseite befindet, kannst du mittels man x Befehl (x ist die Kapitelnummer) die gewünschte Seite direkt aufrufen.

# man -k cron cron (8) - clock daemon crontab (1) - maintain crontab files for individual users crontab (5) - tables for driving cron # man 5 crontab

Zusätzlich zu den Unix-Manualseiten gibt es noch einen weiteren Dokumentensatz (enthalten im misc42.tgz-Dateiset). Dieser befindet sich im Verzeichnis /usr/share/doc. Wenn du auch die Textdistribution installiert hast, dann kannst du jedes Dokument mittels make im entsprechenden Verzeichnis formatieren. Das Unterverzeichnis psd beinhaltet die »Programmer's Supplementary Documents«-Distribution. Im Unterverzeichnis smm liegt das »System Manager's Manual«. Im Unterverzeichnis usd findest du die »UNIX User's Supplementary Documents«-Distribution. Du kannst make in den drei Distributionsunterverzeichnissen aufrufen oder ein spezielles Kapitel einer Distribution auswählen und dort ein make in dessen Unterverzeichnis ausführen.

Einige der Unterverzeichnisse sind leer. Standardmäßig werden die Dokumente im Postscriptformat ausgegeben, das sich für den Ausdruck eignet. Die Postscriptausgabe kann sehr groß werden - etwa 250 - 300 % Zuwachs an Größe. Ohne Postscriptdrucker oder -anzeige kannst du die Dokumente auch für die Betrachtung auf einer Terminalanzeige formatieren. Jedes Dokumentenunterverzeichnis hat ein Ziel für die Erstellung von ASCII-Kopien dieser Dokumente (genannt paper.txt), welches mit make(1) generiert werden kann. Zum Beispiel:

# cd /usr/share/doc/usd/04.csh # make paper.txt # more paper.txt

Bedenke, dass Superuser-Privilegien benötigt sein können, um die Dokumente in diesen Verzeichnissen zu erstellen. Der Aufruf von make clean löscht alle Dokumente, die von vorherigen make-Aufrufen erstellt worden sind. Siehe /usr/share/doc/README für weitere Details über die Dokumente in /usr/share/doc/.

Die Unix-Manualseiten sind im Allgemeinen aktueller und vertrauenswürdiger als die formatierten Dokumente, die aber manchmal kompliziertere Anwendungen in größerem Detailumfang als die Manualseiten erklären.

Für viele Anwender ist eine ausgedruckte Manualseite nützlich. Hier folgen die Richtlinien, um eine Manualseite auszudrucken.

Wie kann ich einen Manualseitenquelltext anzeigen lassen (d. h. eine Datei, deren Name mit einer Zahl endet [wie tcpdump.8])?

Dies gilt für den gesamten Source-Tree. Die Manualseiten befinden sich unformatiert im Verzeichnisbaum und werden automatisch mit CVS aktualisiert. Um sich diese Seiten anzusehen:

# nroff -Tascii -mandoc <Datei> | more

Wie bekomme ich eine reine Manualseite ohne Formatierung oder Escapesequenzen?

Dies ist nützlich, um die Manualseite ohne nicht druckbare Zeichen zu erhalten.
Beispiel:

# man <Befehl> | col -b

Wie erhalte ich eine postscriptformatierte, druckreife Ausgabe einer Manualseite?

Beachte, dass <Datei> die Manualseitenquelltextdatei ist (wahrscheinlich eine Datei, die mit einer Zahl endet [z. B. tcpdump.8]). Die Postscriptversionen der Manualseiten sehen sehr gut aus. Sie können ausgedruckt oder am Bildschirm mit einem Programm wie gv (GhostView) betrachtet werden. GhostView kannst du in unserer Packagekollektion finden. Benutze die folgenden nroff(1)-Befehlsoptionen, um eine Postscriptversion aus einer OpenBSD-Systemmanualseite zu erstellen:

# nroff -Tps -mandoc <Datei> > Ausgabedatei.ps

Wie erstelle ich komprimierte Ausgaben der Manualseiten?

Für Leute, die ihr System vom Quelltext aus erzeugen, gibt es einige Optionen, um Manualseiten zu entwickeln. Diese Optionen können in /etc/mk.conf (vielleicht muss diese Datei erst angelegt werden) geschrieben und somit in die Systemerzeugung mit integriert werden. Eine besonders gebräuchliche Option ist, komprimierte Manualseiten zu erzeugen, um Plattenspeicher sparen zu können. Diese Dateien können unter Verwendung des Befehls »man« auf üblichen Weg angezeigt werden. Um diese Option zu setzen, füge Folgendes in /etc/mk.conf ein:

MANZ=yes
Eine andere nützliche Option ist, während der Systemkompilierung die Manualseiten im Postscriptformat sowie als ASCII-Text entwickeln zu lassen. Dafür muss nur die Option MANPS=yes in /etc/mk.conf gesetzt werden. Siehe mk.conf(5) für weitere Einzelheiten.

Was sind Infodateien?

Einige Teile der Dokumentation für OpenBSD liegt in Infodateien vor - typischerweise befinden sie sich im /usr/share/info-Verzeichnis. Dies ist eine alternative Form der Dokumentation, die von GNU angeboten wird. Viele dieser Dateien sind aktueller als die Manualseiten von GNU und können mit dem info(1)-Befehl betrachtet werden. Um zum Beispiel die Informationen über den GNU-Compiler gcc(1) anzusehen, gib Folgendes ein:

# info gcc
Nach der Verwendung von info wirst du unsere Manualseiten zu schätzen wissen!

Wie bekomme ich farbige Manualseiten im XTerm?

Die standardmäßige Konfigurationsdatei für xterm(1) zeigt keine farbigen Manualseiten an. Um farbige Ausgabe zu erhalten, kopiere die Datei /etc/X11/app-defaults/XTerm-color in dein Heimatverzeichnis und benenne sie in .Xdefaults um. Sei vorsichtig, damit du nicht irgendwelche aktuellen Einstellungen in .Xdefaults überschreibst. Diese Datei beinhaltet alle Einstellungen, um Farbe im XTerm zu aktivieren. Allerdings müssen diese drei Zeilen auskommentiert werden, bevor sie funktionieren können:

!*VT100*colorULMode: on !*VT100*underLine: off !*VT100*colorBDMode: on
Der Rest der Datei erlaubt dir, Farben für verschiedene Einstellungen zu wählen. Relevant für die Manualseiten sind:
*VT100*colorUL: yellow *VT100*colorBD: white
Mit diesen Einstellungen werden die Manualseiten recht hell dargestellt, daher ändere sie nach deinen Bedürfnissen. Wir empfehlen Rot für »colorUL« und Magenta für »colorBD«. Es ist ebenfalls ein Manualseitenbetrachter für X11 namens xman verfügbar, welcher eine alternative (grafische) Oberfläche für die Manualseiten bietet.

Wie schreibe ich meine eigene Manualseite?

Falls du eine eigene Manualseite für dein selbstentwickeltes Programm schreiben möchtest, kannst du die Anleitung verwenden, die in mdoc.samples(7) zur Verfügung gestellt wird. Ein weiterer handlicher Referenzguide wird in mdoc(7) bereitgestellt.

2.4 - Fehlerberichte

Bevor du »Fehler!« schreist solltest du sicherstellen, dass du es tatsächlich mit einem zu tun hast. Falls du stattdessen nicht verstehst, wie etwas in OpenBSD funktioniert und auch das Problem nicht mit Hilfe der Manualseiten oder der OpenBSD-Website lösen kannst, verwende die Mailinglisten (für gewöhnlich misc@openbsd.org), um nach Hilfe zu fragen. Falls dies deine erste OpenBSD-Erfahrung ist, sei realistisch: Du wirst vermutlich keinen unbekannten Fehler gefunden haben. Bedenke auch, dass fehlerhafte Hardware einen Softwarefehler vortäuschen kann. Bitte überprüfe den aktuellen Zustand deiner Hardware, bevor du entscheidest, dass du einen »Fehler« gefunden hast.

Bevor du schließlich einen Fehler berichtest, solltest du http://www.openbsd.org/de/report.html lesen.

Richtige Fehlerberichte sind eine der wichtigsten Aufgaben von Endbenutzern. Sehr detaillierte Informationen werden benötigt, um die schwersten Fehler zu diagnostizieren. Entwickler erhalten häufig Fehlerberichte per E-Mail wie diesen:

From: joeuser@example.com To: bugs@openbsd.org Subject: HELP!!! I have a PC and it won't boot!!!!! It's a 486!!!!!

Hoffentlich verstehen die meisten Menschen, warum solche Fehlerberichte gelöscht werden. Jeder Fehlerbericht sollte detaillierte Informationen enthalten. Wenn ein normaler Benutzer wirklich die Untersuchung seines Fehlers wünscht, dann sollte sein Fehlerbericht in etwa so aussehen:

From: smartuser@example.com To: bugs@openbsd.org Subject: 3.3-beta panics on a SPARCStation2 OpenBSD 3.2 installed from an official CD-ROM installed and ran fine on this machine. After doing a clean install of 3.3-beta from an FTP mirror, I find the system randomly panics after a period of use, and predictably and quickly when starting X. This is the dmesg output: OpenBSD 3.3-beta (GENERIC) #9: Mon Mar 17 12:37:18 MST 2003 deraadt@sparc.openbsd.org:/usr/src/sys/arch/sparc/compile/GENERIC real mem = 67002368 avail mem = 59125760 using 200 buffers containing 3346432 bytes of memory bootpath: /sbus@1,f8000000/esp@0,800000/sd@1,0 mainbus0 (root): SUNW,Sun 4/75 cpu0 at mainbus0: CY7C601 @ 40 MHz, TMS390C602A FPU; cache chip bug - trap page uncached cpu0: 64K byte write-through, 32 bytes/line, hw flush cache enabled memreg0 at mainbus0 ioaddr 0xf4000000 clock0 at mainbus0 ioaddr 0xf2000000: mk48t02 (eeprom) timer0 at mainbus0 ioaddr 0xf3000000 delay constant 17 auxreg0 at mainbus0 ioaddr 0xf7400003 zs0 at mainbus0 ioaddr 0xf1000000 pri 12, softpri 6 zstty0 at zs0 channel 0 (console i/o) zstty1 at zs0 channel 1 zs1 at mainbus0 ioaddr 0xf0000000 pri 12, softpri 6 zskbd0 at zs1 channel 0: reset timeout zskbd0: no keyboard zstty2 at zs1 channel 1: mouse audioamd0 at mainbus0 ioaddr 0xf7201000 pri 13, softpri 4 audio0 at audioamd0 sbus0 at mainbus0 ioaddr 0xf8000000: clock = 20 MHz dma0 at sbus0 slot 0 offset 0x400000: rev 1+ esp0 at sbus0 slot 0 offset 0x800000 pri 3: ESP100A, 25MHz, SCSI ID 7 scsibus0 at esp0: 8 targets sd0 at scsibus0 targ 1 lun 0: <SEAGATE, ST1480 SUN0424, 8628> SCSI2 0/direct fixed sd0: 411MB, 1476 cyl, 9 head, 63 sec, 512 bytes/sec, 843284 sec total sd1 at scsibus0 targ 3 lun 0: <COMPAQPC, DCAS-32160, S65A> SCSI2 0/direct fixed sd1: 2006MB, 8188 cyl, 3 head, 167 sec, 512 bytes/sec, 4110000 sec total le0 at sbus0 slot 0 offset 0xc00000 pri 5: address 08:00:20:13:10:b9 le0: 16 receive buffers, 4 transmit buffers cgsix0 at sbus0 slot 1 offset 0x0: SUNW,501-2325, 1152x900, rev 11 wsdisplay0 at cgsix0 wsdisplay0: screen 0 added (std, sun emulation) fdc0 at mainbus0 ioaddr 0xf7200000 pri 11, softpri 4: chip 82072 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec root on sd0a rootdev=0x700 rrootdev=0x1100 rawdev=0x1102 This is the panic I got when attempting to start X: panic: pool_get(mclpl): free list modified: magic=78746572; page 0xfaa93000; item addr 0xfaa93000 Stopped at Debugger+0x4: jmpl [%o7 + 0x8], %g0 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb> trace pool_get(0xfaa93000, 0x22, 0x0, 0x1000, 0x102, 0x0) at pool_get+0x2c0 sosend(0x16, 0xf828d800, 0x0, 0xf83b0900, 0x0, 0x0) at sosend+0x608 soo_write(0xfac0bf50, 0xfac0bf70, 0xfac9be28, 0xfab93190, 0xf8078f24, 0x0) at soo_write+0x18 dofilewritev(0x0, 0xc, 0xfac0bf50, 0xf7fff198, 0x1, 0xfac0bf70) at dofilewritev+0x12c sys_writev(0xfac87508, 0xfac9bf28, 0xfac9bf20, 0xf80765c8, 0x1000, 0xfac0bf70) at sys_writev+0x50 syscall(0x79, 0xfac9bfb0, 0x0, 0x154, 0xfcffffff, 0xf829dea0) at syscall+0x220 slowtrap(0xc, 0xf7fff198, 0x1, 0x154, 0x1, 0xfac87508) at slowtrap+0x1d8 ddb> ps PID PPID PGRP UID S FLAGS WAIT COMMAND 27765 8819 29550 0 3 0x86 netio xconsole 1668 29550 29550 0 3 0x4086 poll fvwm 15447 29550 29550 0 3 0x44186 poll xterm 8819 29550 29550 35 3 0x4186 poll xconsole 1238 29550 29550 0 3 0x4086 poll xclock 29550 25616 29550 0 3 0x4086 pause sh 1024 25523 25523 0 3 0x40184 netio XFree86 *25523 25616 25523 35 2 0x44104 XFree86 25616 30876 30876 0 3 0x4086 wait xinit 30876 16977 30876 0 3 0x4086 pause sh 16977 1 16977 0 3 0x4086 ttyin csh 5360 1 5360 0 3 0x84 select cron 14701 1 14701 0 3 0x40184 select sendmail 12617 1 12617 0 3 0x84 select sshd 27515 1 27515 0 3 0x184 select inetd 1904 1 1904 0 2 0x84 syslogd 9125 1 9125 0 3 0x84 poll dhclient 7 0 0 0 3 0x100204 crypto_wa crypto 6 0 0 0 3 0x100204 aiodoned aiodoned 5 0 0 0 3 0x100204 syncer update 4 0 0 0 3 0x100204 cleaner cleaner 3 0 0 0 3 0x100204 reaper reaper 2 0 0 0 3 0x100204 pgdaemon pagedaemon 1 0 1 0 3 0x4084 wait init 0 -1 0 0 3 0x80204 scheduler swapper Thank you!

In report.html finden sich weitere Informationen über die Erstellung und Einsendung von Fehlerberichten. Detaillierte Informationen über deine Hardware sind absolut notwendig, wenn du glaubst, dass der Fehler irgendwie mit deiner Hardware oder deiner Hardwarekonfiguration zusammenhängen könnte. Normalerweise ist die Ausgabe von dmesg(8) in dieser Hinsicht ausreichend. Eine detaillierte Beschreibung deines Problems ist notwendig. Dmesg beschreibt deine Hardware, der Text erklärt warum Smart User denkt, das System sei defekt (3.2 lief noch bestens), wie dieser Absturz erzeugt wurde (indem er X gestartet hat) und die Ausgabe der Debuggerbefehle ps und trace. In diesem Fall hat Smart User die Informationen bereitgestellt, die er über serielle Konsole bekommen hat. Wenn du das nicht tun kannst, bist du gezwungen, mittels Stift und Papier die Informationen vom Absturz aufzuzeichnen (das Beispiel oben war im Übrigen ein echtes Problem und die oben bereitgestellten Informationen führten dazu, dass dieses Problem, das Sun4c-Systeme betraf, behoben werden konnte).

Wenn Smart User ein funktionierendes OpenBSD-System gehabt hätte, von dem aus er einen Fehlerbericht abschicken wolle, dann hätte er sendbug(1) verwendet, um den Fehlerbericht zu verfassen und zum GNATS-Problemerfassungssystem zu senden. Wenn dein System nicht startet, dann kannst du sendbug(1) selbstverständlich nicht verwenden - du solltest es aber nutzen, wann immer du kannst. Du wirst noch zusätzliche Informationen, wie z. B. was geschah und deine genaue Konfiguration einfügen müssen und wie man das Problem reproduzieren kann. Der sendbug(1)-Befehl benötigt eine Verbindung zum Internet und einen funktionsfähigen MTA, um den Fehlerbericht per E-Mail versenden zu können. Beachte, dass der Mailserver ein auf spamd(8) basiertes Greylisting verwendet, sodass es eine halbe Stunde oder länger dauern kann, bevor der Mailserver deinen Fehlerbericht akzeptiert. Habe also bitte Geduld!

Nach der Einsendung eines Fehlerberichts per sendbug(1) wirst du per E-Mail über den Status informiert. Du kannst auch von Entwicklern kontaktiert werden, die dich nach weiteren Informationen fragen oder dich bitten, Patches zu testen. Des Weiteren kannst du dir auch die Archive der bugs@openbsd.org-Mailingliste ansehen - Details dazu gibt es auf der Mailinglistenseite. Du kannst auch den Status des Fehlerberichts auch im Bugtrackingsystem online abfragen.

Weitere Möglichkeiten, wie man nützliche Informationen für Entwickler anbringen kann

Hier sind ein paar zusätzliche Tipps:

Die Panicmessage verloren?
Unter bestimmten Umständen kannst du die ersten Zeilen vom Panic verlieren, die den Grund für den Panic angeben. Dies ist eine sehr wichtige Nachricht - du solltest sie daher ebenfalls berichten. Du kannst diese wiederbekommen, indem du den Befehl »show panic« in ddb> wie folgt verwendest:

ddb> show panic 0: kernel: page fault trap, code=0 ddb>

In diesem Fall war die Panicmessage »Kernel: page fault trap, code=0«.

Besonderer Hinweis für SMP-Systeme:
Du solltest einen Trace von jedem Prozessor als Teil deines Berichts holen:

ddb{0}> trace pool_get(d05e7c20,0,dab19ef8,d0169414,80) at pool_get+0x226 fxp_add_rfabuf(d0a62000,d3c12b00,dab19f10,dab19f10) at fxp_add_rfabuf+0xa5 fxp_intr(d0a62000) at fxp_intr+0x1e7 Xintr_ioapic0() at Xintr_ioapic0+0x6d --- interrupt --- idle_loop+0x21: ddb{0}> machine ddb 1 Stopped at Debugger+0x4: leave ddb{1}> trace Debugger(d0319e28,d05ff5a0,dab1bee8,d031cc6e,d0a61800) at Debugger+0x4 i386_ipi_db(d0a61800,d05ff5a0,dab1bef8,d01eb997) at i386_ipi_db+0xb i386_ipi_handler(b0,d05f0058,dab10010,d01d0010,dab10010) at i386_ipi_handler+0x 4a Xintripi() at Xintripi+0x47 --- interrupt --- i386_softintlock(0,58,dab10010,dab10010,d01e0010) at i386_softintlock+0x37 Xintrltimer() at Xintrltimer+0x47 --- interrupt --- idle_loop+0x21: ddb{1}>

Wiederhole machine ddb x gefolgt von trace für jeden einzelnen Prozessor in deiner Maschine.

[FAQ-Index] [Zum Kapitel 1 - Einführung in OpenBSD] [Zum Kapitel 3 - Wo man OpenBSD herbekommt]

[zurück] www@openbsd.org
$OpenBSD: faq2.html,v 1.70 2007/11/12 20:29:59 saad Exp $