Update of user guide and welcome page and their translations.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38032 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Joachim Seemer
@@ -4,25 +4,27 @@
|
||||
<head>
|
||||
<!--
|
||||
*
|
||||
* Copyright 2008-2009, Haiku. All rights reserved.
|
||||
* Copyright 2008-2010, Haiku. All rights reserved.
|
||||
* Distributed under the terms of the MIT License.
|
||||
*
|
||||
* Authors:
|
||||
* Niels Reedijk and Matt Madia who wrote http://dev.haiku-os.org/wiki
|
||||
* Niels Reedijk, Matt Madia and Ingo Weinhold who wrote
|
||||
* http://dev.haiku-os.org/wiki/ and http://dev.haiku-os.org/wiki/ReportingBugs
|
||||
* Humdinger <[email protected]>
|
||||
* Translators:
|
||||
* Matthias
|
||||
* Humdinger
|
||||
*
|
||||
-->
|
||||
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
|
||||
<meta name="robots" content="all" />
|
||||
<title>Fehler melden</title>
|
||||
<title>Bugs melden</title>
|
||||
<link rel="stylesheet" type="text/css" href="../Haiku-doc.css" />
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<div id="banner">
|
||||
<div><span>User Guide</span></div>
|
||||
<div><span>User guide</span></div>
|
||||
</div>
|
||||
|
||||
<div class="nav">
|
||||
@@ -48,48 +50,108 @@
|
||||
<div id="content">
|
||||
<div>
|
||||
|
||||
<h1>Fehler melden</h1>
|
||||
<table class="index" id="index" summary="index">
|
||||
<tr class="heading"><td>Bugs melden</td></tr>
|
||||
<tr class="index"><td><a href="#account">Zugang zu Trac</a><br />
|
||||
<a href="#report">Bugreport erstellen</a><br />
|
||||
<a href="#app">Bugs in Anwendungen</a><br />
|
||||
<a href="#server">Bugs in Servern</a><br />
|
||||
<a href="#kernel">Bugs im Kernel</a><br />
|
||||
<a href="#kdl">Kernel Debugging Land - KDL</a><br />
|
||||
<a href="#syslog">Syslog</a><br />
|
||||
<a href="#onscreen">Debug Ausgabe auf dem Bildschirm</a><br />
|
||||
<a href="#hardware">Bugs von Hardware/Treiber</a><br />
|
||||
<a href="#next">Bug gemeldet, und dann?</a></td></tr>
|
||||
</table>
|
||||
|
||||
<p>Da es für die Haiku-Entwickler unmöglich ist, jede denkbare Hardware-Kombination oder jede mögliche Anwendungsweise eines Programmes zu testen, ist es eine große Hilfe, wenn erkannte Fehler von Anwendern gemeldet werden. Da Haiku noch nicht vollständig ausgereift ist - aktuell befindet es sich in der Alpha-Phase - ist es nicht unwahrscheinlich, dass Fehler auftreten. Nur mit Hilfe der Anwender können wir Haiku Stück für Stück perfektionieren.</p>
|
||||
<p>Um unseren "Bugtracker" - also die Liste aller gefundenen Fehler - effektiv zu halten, ist es notwendig, eine grundlegende Etikette, die "<a href="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">Bug Tracker Etiquette</a>" zu wahren.</p>
|
||||
<h1>Bugs melden</h1>
|
||||
|
||||
<h2>Wie man einen Zugang zum Trac erhält</h2>
|
||||
<p>Um ein Fehler-Ticket einzureichen, muss man registrierter Benutzer beim <a href="http://dev.haiku-os.org/register" title="Register at Haiku's Bugtracker">Bugtracker</a> sein.<br /> Um sich anzumelden ist eine <b>gültige E-Mail Adresse</b> notwendig. Sollte nach dem Anmelden keine Bestätigungsmail erhalten werden, lohnt es sich, seinen <b>Spam-Filter</b> zu überprüfen.</p>
|
||||
<p>Da es für die Haiku-Entwickler unmöglich ist, jede denkbare Hardware-Kombination oder jede mögliche Anwendungsweise eines Programms zu testen, ist es eine große Hilfe, wenn Fehler gemeldet werden. Da Haiku noch recht jung ist, sind Bugs nicht Ungewöhnliches. Nur mit Hilfe der Anwender können wir Haiku gemeinsam Stück für Stück perfektionieren.</p>
|
||||
<p>Damit unser "Bugtracker" - also die Liste aller gefundenen Fehler - effektiv funktioniert, ist eine grundlegende <a href="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">Bug Tracker Etiquette</a> zu wahren.</p>
|
||||
|
||||
<h2>Einen Fehlerbericht erstellen</h2>
|
||||
<p>Ehe man einen Fehler meldet, sollte man sich <a href="http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority">sicher sein</a>, dass er nicht schon gemeldet wurde. Hierzu kann auch die <a href="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">Suchfunktion</a> verwendet werden.<br />
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="account" name="accout">Zugang zu Trac</a></h2>
|
||||
<p>Um ein Fehler-Ticket aufzugeben, muss man registrierter Benutzer beim <a href="http://dev.haiku-os.org/register" title="Registerierung bei Haikus Bugtracker">Bugtracker</a> sein.<br /> Um sich anzumelden ist eine <b>gültige E-Mail Adresse</b> notwendig. Sollte nach dem Anmelden keine Bestätigungsmail ankommen, sollte man mal seinen <b>Spam-Ordner</b> überprüfen.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="report" name="report">Bugreport erstellen</a></h2>
|
||||
<p>Bevor man einen Fehler meldet, sollte man sich <a href="http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority">sicher sein</a>, dass das nicht schon geschehen ist. Hierzu kann auch die <a href="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">Suchfunktion</a> verwendet werden.<br />
|
||||
Nach dieser Überprüfung sollte man so genau wie möglich den Fehler beschreiben:</p>
|
||||
<ul>
|
||||
<li><p>Wie wurde Haiku verwendet (auf echter Hardware oder virtualisiert unter VMWare, QEMU oder ähnlichem)</p></li>
|
||||
<li><p>Welche Versionsnummer des <acronym title="Subversion, the source code management system we use">SVN</acronym> wurde verwendet?. Die Nummer ist auch unter '<i>About This System...</i>' im Deskbar-Menü abzulesen.</p></li>
|
||||
<li><p>Der Fehler sollte so präzise wie möglich beschrieben werden. Wie war das tatsächliche Verhalten im Gegensatz zum Erwarteten?</p></li>
|
||||
<li><p>Wann ist der Fehler aufgetreten? Welche Schritte führten dazu? Nur so können die Entwickler den Fehler nachstellen und erkennen.</p></li>
|
||||
<li><p>An den Fehlerbericht sollten so viele Informationen wie möglich angehängt werden. Log-Dateien oder Bildschirmphotos (die Taste <span class="key">PRINT</span> speichert den Bildschirm als <acronym title="Portable Network Graphics image format">PNG</acronym> im Verzeichnis <span class="path">/boot/home/</span>) sind sehr hilfreich.</p></li>
|
||||
<li><p>Der Fehler sollte mit einer aktuellen Version von Haiku zu reproduzierbar sein. Zum Testen gibt es installierbare <a href="http://haiku-files.org/">Images</a>.</p></li>
|
||||
<li><p>Wie wurde Haiku verwendet (auf echter Hardware oder virtualisiert unter VMWare, QEMU oder ähnlichem)?</p></li>
|
||||
<li><p>Welche Versionsnummer aus dem <acronym title="Subversion, unser Source Code Management System">SVN</acronym> wurde verwendet? Die Version ist auch unter <span class="menu">About Haiku...</span> im Deskbar Menü zu finden. Wie genau Haiku kompiliert wurde (gcc2, gcc4, gcc2hybrid, gcc4hybrid), ist ebenfalls von Interesse. Die runterladbaren Images sind entsprechend benannt; Leute, die sich ihr Haiku selber zusammenbauen, sollten wissen wie sie das gemacht haben.</p></li>
|
||||
<li><p>Der Fehler sollte so präzise wie möglich beschrieben werden. Welches Verhalten wurde erwartet und was wurde statt dessen beobachtet?</p></li>
|
||||
<li><p>Wann tritt der Fehler auf? Nur mit einer Schritt-für-Schritt Anleitung können die Entwickler den Bug nachstellen und beheben.</p></li>
|
||||
<li><p>An den Fehlerbericht sollten so viele Informationen wie möglich angehängt werden. Handelt es sich um einen Bug in der grafischen Oberfläche oder einer der Anwendungen, ist ein Bildschirmfoto mittels der <span class="key">DRUCK</span> Taste hilfreich.</p></li>
|
||||
</ul>
|
||||
|
||||
<h3>Fehler in Anwendungen</h3>
|
||||
<p>Wenn eine Anwendung unerwartet abstürzt, sollte man den "Debugger" aus dem erscheinenden Hinweisfenster aufrufen. Ein <span class="cli">bt</span> im daraufhin startenden Terminal erstellt einen sogenannten "backtrace" der mit an die Fehlermeldung angehängt werden sollte.</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="app" name="app">Bugs in Anwendungen</a></h2>
|
||||
<p>Stürzt eine Anwendung ab, sollte man den Debugger aus dem erscheinenden Hinweisfenster aufrufen. Dadurch wird ein Terminal mit gdb (dem GNU Debugger) geöffnet. Gibt man dort <span class="cli">bt</span> ein, wird ein sogenannter "backtrace" erstellt, der komplett (auch mit dem Teil bevor <span class="cli">bt</span> eingegeben wurde) mit an die Fehlermeldung angehängt werden sollte.</p>
|
||||
|
||||
<h3>Fehler auf Grund Hardware</h3>
|
||||
<p>Wenn ein Fehler gemeldet wird, der Hardware oder Treiber betrifft, sollten mindestens diese Informationen an den Fehlerbericht angehängt werden:</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="server" name="server">Bugs in Servern</a></h2>
|
||||
<p>Stürzen lebenswichtige Server wie der App Server, der Registrar oder der Input Server ab, bekommt man nicht den gewöhnlichen Crash-Hinweis zu sehen. Stattdessen wird der gesamte Bildschirm weiß und der gdb wird gestartet, der seine Ausgabe direkt auf den Bildschirm schreibt. Unter Umständen kann man immer noch die Maus bewegen, die daraufhin das Weiß und die gdb Ausgabe übermalt. Noch laufende Anwendungen wie ProcessController oder die Uhr in der Deskbar, tun das vielleicht auch noch.<br />
|
||||
Außer dass alles etwas unansehnlicher und unbequemer ist, gilt eigentlich das gleiche wie für Bugs in Anwendungen. Am wichtigsten ist das sichern eines "backtrace" mittels <span class="cli">bt</span>. Weil man den Text ja nicht mehr irgendwohin kopieren kann, müsste man die Ausgabe per Kamera festhalten.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kernel" name="kernel">Bugs im Kernel</a></h2>
|
||||
<p>Fehler im Kernel haben normalerweise die schwersten Auswirkungen und sind zugleich am schwierigsten zu debuggen. Es gibt unterschiedliche Symptome, die auf ein Problem von Kernel oder Treiber hindeuten:</p>
|
||||
<ul>
|
||||
<li><span class="cli">listdev</span> - eine detaillierte Auflistung aller vorhandener Hardware inklusive "vendor id" und "pci id"; ähnlich den Befehlen <span class="cli">lshw</span> und <span class="cli">lspci</span> unter Linux.</li>
|
||||
<li><span class="cli">listusb -v</span> - bei einem Fehler im Zusammenhang mit USB; ähnlich dem Befehlt <span class="cli">lsusb</span>.</li>
|
||||
<li><span class="cli">open /var/log/syslog</span> - die zentrale Log-Datei in Haiku. Mit dem Befehl <span class="cli">open</span> kann das Log auf eine sinnvolle Länge gekürzt werden.</li>
|
||||
<li><span class="cli">listimage | grep drivers/</span> - eine Auflistung aller verwendeter Treiber.</li>
|
||||
<li><span class="cli">ints</span> - nur im <i>Kernel Debugging Land</i> (siehe weiter unten) möglich. Es zeigt eine Liste aller verwendeter "Interrupts".</li>
|
||||
<li><p>Das System betritt selbständig das Kernel Debugging Land (KDL) . Der obere Teil des Bildschirms wird weiß und einige Zeilen Text erscheinen. Die zweite Zeile verkündet "<i>Welcome to Kernel Debugging Land...</i>", die darüber beschreibt den unmittelbaren Grund für die Reise ins KDL.</p></li>
|
||||
<li><p>Das System führt einen spontanen Neustart aus.</p></li>
|
||||
<li><p>Das System friert komplett ein. Die Maus lässt sich nicht mehr bewegen und Anwendungen aktualisieren ihre Oberfläche nicht mehr. Ein wichtiger Test in so einer Situation ist, ob man das KDL noch mit der Tastenkombination <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> (<span class="key">SysReq</span> ist dabei meist die <span class="key">DRUCK</span> Taste) erreichen kann. Man sollte zumindest eine Minute warten, ob sich was tut.</p></li>
|
||||
<li><p>Das System fährt nicht mehr richtig hoch. Unter Umständen führt es spontan einen Neustart durch oder bleibt an einer Stelle stecken, vielleicht bei einem bestimmten Symbol des Boot Bildschirms. In letzterem Falle sollte man auch mal ein <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> versuchen.</p></li>
|
||||
<li><p>Das ganze System oder eine bestimmte Hardwarekomponente funktioniert nicht richtig. Es könnte beispielsweise nur sehr langsam laufen, Fehler könnten auftreten oder etwas funktioniert überhaupt nicht. Verweigert eine Hardwarekomponente die Arbeit komplett, sollte man natürlich erst mal checken, ob Haiku sie momentan überhaupt treibermäßig unterstützt, indem man zum Beispiel auf der Mainlingliste oder im Forum nachfragt.</p></li>
|
||||
</ul>
|
||||
<p>Die genannten Befehle sind im Terminal einzugeben. Mit dem Anhang "<span class="cli"> > output.txt</span>" an den Befehl wird dessen Ausgabe in die Datei output.txt gespeichert, die dann an den Fehlerbericht angehängt werden kann.</p>
|
||||
<p>Während nur der letzte Punkt explizit auf eine Hardware-Ursache eingeht, können auch alle anderen Symptome auf Fehler in einem Hardware Treiber hindeuten. Hat man einen Verdacht welche Hardware oder entsprechender Treiber mit dem Problem zu tun haben könnte, sollte man prüfen ob das Entfernen oder Deaktivieren von Hardware oder Treiber Abhilfe schafft. Wenn man das Problem beispielsweise beim WLAN vermutet, könnte diese Funktion vielleicht im BIOS ausgeschaltet werden. Wenn nicht, kann man auch den entsprechenden Treiber aus dem System entfernen (in <span class="path">/boot/system/add-ons/kernel/drivers/bin</span>).</p>
|
||||
|
||||
<h3>Kernel Debugging Land - KDL</h3>
|
||||
<p>Wenn grundlegende Systemkomponenten abgestürzt sind, dann friert das System ein und es wird das KDL aufgerufen. Man kann auch absichtlich dorthin wechseln durch Drücken von <span class="key">ALT</span><span class="key">SysReq</span><span class="key">D</span> (<span class="key">SysReq</span> ist in den meisten Fällen die Taste <span class="key">PRINT</span>).</p>
|
||||
<ul>
|
||||
<li><span class="cli">co</span> - beendet das KDL und das System läuft - soweit möglich - normal weiter.</li>
|
||||
<li><span class="cli">int</span> - zeigt die verwendeten Interrupts (wie oben beschrieben).</li>
|
||||
<li><span class="cli">bt</span> - zeigt einen backtrace wo genau der Fehler aufgetreten ist.</li>
|
||||
</ul>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kdl" name="kdl">Kernel Debugging Land - KDL</a></h3>
|
||||
<p>Stürzt das System nicht von selbst ins KDL, kann man das auch absichtlich mit der Tastenkombination <span class="key">ALT</span><span class="key">SysReq</span><span class="key">D</span> erreichen.<br />
|
||||
Im KDL kann es passieren, dass die Tastatur nicht mehr funktioniert. PS/2 Tastaturen gehen immer, USB Tastaturen an UHCI Controllern nur wenn man vorher schonmal per Tastenkombination das KDL betreten hat. USB OHCI wird zur Zeit noch gar nicht unterstützt.</p>
|
||||
<p>Das KDL ist eine Art Konsole. Es lassen sich Befehle eingeben, die Informationen über das System ausgeben. Folgende Befehle sind von besonderen Interesse:</p>
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td><span class="cli">bt</span> (auch "sc")</td><td> </td><td>Zeigt einen "backtrace" wo genau der Fehler aufgetreten ist. Ist das System von selbst ins KDL gefallen, sollte man diesen Befehl unbedingt ausführen.</td></tr>
|
||||
<tr><td><span class="cli">ints</span></td><td> </td><td>Zeigt die unbenutzten und verwendeten Interrupts.</td></tr>
|
||||
<tr><td class="onelinetop"><span class="cli">co</span> (auch "continue")</td><td> </td><td>Verlässt den Kernel Debugger und das System läuft - soweit möglich - normal weiter.</td></tr>
|
||||
<tr><td><span class="cli">reboot</span></td><td> </td><td>Führt einen unmittelbaren Neustart durch. Alle ungespeicherten Daten gehen verloren und selbst was man gespeichert hat, aber noch nicht auf die Platte geschrieben wurde, ist weg.</td></tr>
|
||||
</table>
|
||||
<p>Weitere Infos gibt es im Artikel <a href="http://www.haiku-os.org/documents/dev/welcome_to_kernel_debugging_land">Welcome to Kernel Debugging Land</a> (Englisch).</p>
|
||||
<p>Die Ausgaben im KDL werden zum seriellen Port geschickt (falls man einen hat und ein entsprechendes Nullmodemkabel samt zweiten Rechner, kann man die Ausgaben in einem Terminalprogramm aufnehmen). Außerdem werden sie ins Syslog geschrieben. Wenn man das KDL allerdings nicht verlassen kann, wird auch nichts ins Syslog geschrieben. Es gibt aber eine Bootloader Debug Option, die das trotzdem möglich macht (siehe weiter unten).</p>
|
||||
|
||||
<h2>Fehler gemeldet, und dann?</h2>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="syslog" name="syslog">Syslog</a></h3>
|
||||
<p><b>Dies ist die beste Methode Informationen über ein nicht-bootendes System zu gewinnen.</b><br />
|
||||
Das Syslog (kurz für System Log) enthält wertvolle Infos was im System abläuft, einschließlich der Ausgaben einer KDL Sitzung. Man sollte es immer an einen Trac Ticket hängen wenn es etwas mit dem Kernel zu tun haben könnte. Das Syslog befindet sich in der Datei <span class="path">/boot/common/var/log/syslog</span>. Um in eine Datei schreiben zu können, braucht man ein funktionierendes System. Tritt ein Problem im Kernel auf (insbesondere bei spontanen Neustarts und nicht-fortsetzbaren KDL Sitzungen), kann es daher passieren dass es die letzten Ausgaben nicht mehr ins Syslog schaffen.</p>
|
||||
<p>Durch die Option <span class="menu">Enable debug syslog</span> im <span class="menu">Debug menu</span> des Bootloaders wird das Syslog im Speicher etwas langlebiger. Das ist standardmäßig aktiviert. "Etwas langlebiger" bedeutet, dass es einen Reset überlebt und direkt danach noch im Bootloader verfübar ist. Bootet man allerdings ein Betriebssystem (zumindest bei Haiku, wahrscheinlich aber bei allen), werden diese Informationen zerstört. Man muss beim Neustart also unbedingt das Bootloader Menü mittels gedrückter <span class="key">SHIFT</span> Taste aufrufen.<br />
|
||||
Dort sollte man im <span class="menu">Debug menu</span> jetzt die Einträge <span class="menu">Display syslog from previous session</span> und <span class="menu">Save syslog from previous session</span> sehen. Ersterer zeigt das Syslog direkt auf dem Bildschirm an, mit letzterem lässt es sich speichern. Momentan geht das nur auf FAT32 formatierten Medien. Möchte man dafür einen USB-Stick benutzen, den man allerdings erst zu spät reingesteckt hat und der deswegen nicht erkannt wurde, kann man den Rechner nochmals resetten und das Bootloader Menü erneut aufrufen. Es gilt aber immer noch: Bootet man ausversehen ein Betriebssystem, sind die Syslog Daten weg.</p>
|
||||
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="onscreen" name="onscreen">Debug Ausgabe auf den Bildschirm</a></h3>
|
||||
<p><b>Die Ausgabe auf dem Bildschirm ist nur bei ganz bestimmten Situationen sinnvoll und hat bekanntermaßen Timing-Probleme. Es sollte also wirklich nur im Notfall benutzt werden.</b><br />
|
||||
Das ist zum Beispiel der Fall wenn Haiku nicht ganz hochfährt und Bootloader's <span class="menu">Debug syslog option</span> irgendwie nicht funktioniert. Noch bevor das Haiku Bootlogo erscheint, die <span class="key">SHIFT</span> Taste gedrückt halten, um das Bootloader Menü aufzurufen. Von hier in das Menü <span class="menu">Select safe mode options</span> wechseln und dort weiter unten <span class="menu">[ ] Enable on screen debug output</span> aktivieren. (Die anderen Optionen kann man auch mal probieren, um zu versuchen Haiku erfolgreich zu booten. Wenn Haiku nur mit einer oder mehreren aktivierten Optionen hochfahren kann, sollte man natürlich erwähnen welche das sind.)<br />
|
||||
Abschließend geht man auf <span class="menu">Return to main menu</span> und dann <span class="menu">Continue booting</span>.<br />
|
||||
Auf dem Bildschirm werden einige Seiten Text ausgegeben, von denen aber nur die letzten paar für einen Bugreport interessant sind. Der Userguide hat noch weitere Infos zum <a href="../../../userguide/de/bootloader.html">Boot Loader</a>.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="hardware" name="hardware">Bugs von Hardware/Treiber</a></h2>
|
||||
<p>Wenn ein Fehler gemeldet wird, der Hardware oder Treiber betrifft, sollten folgende Informationen als Textdateien an den Fehlerbericht angehängt werden:</p>
|
||||
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td>- <span class="cli">listdev</span></td><td> </td><td>Eine detaillierte Auflistung aller vorhandener Hardware inklusive "vendor id" und "pci id"; ähnlich den Befehlen <span class="cli">lshw</span> und <span class="cli">lspci</span> unter Linux.</td></tr>
|
||||
<tr><td>- <span class="cli">listusb -v</span></td><td> </td><td>Bei Fehlern im Zusammenhang mit USB, ähnlich dem Befehlt <span class="cli">lsusb</span> unter Linux.</td></tr>
|
||||
<tr><td>- <span class="cli">open /var/log/syslog</span></td><td> </td><td>Die zentrale Log-Datei von Haiku. Mit dem Befehl <span class="cli">open</span> kann das Log im Texteditor auf eine sinnvolle Länge gekürzt werden.</td></tr>
|
||||
<tr><td class="onelinetop">- <span class="cli">listimage | grep drivers/</span></td><td> </td><td>Eine Auflistung aller verwendeten Treiber.</td></tr>
|
||||
<tr><td>- <span class="cli">ints</span></td><td> </td><td>Nur im <i>Kernel Debugging Land</i> (siehe weiter oben). Es zeigt eine Liste aller verwendeter "Interrupts". Wenn sich mehrere Geräte zuviele von ihnen teilen, ist das schlecht.</td></tr>
|
||||
<tr><td colspan="3">- "On screen debug output" (die Bootloader Debug Option zur Ausgabe auf dem Bildschirm).</td></tr>
|
||||
</table>
|
||||
|
||||
<p>Die ersten vier dieser Befehle sind im Terminal einzugeben. Mit dem Zusatz "<span class="cli"> > output.txt</span>" an den Befehl wird dessen Ausgabe in die Datei "output.txt" gespeichert, die dann an den Fehlerbericht angehängt werden kann.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="next" name="next">Bug gemeldet, und dann?</a></h2>
|
||||
<p>Nachdem ein Fehler gemeldet wurde wird sich ein Entwickler ihm annehmen und bewerten. Da es sich bei allen Entwicklern um Freiwillige handelt, die in ihrer Freizeit programmieren, kann es durchaus etwas dauern, bis man eine Rückmeldung erhält. Je mehr Informationen man einer Fehlermeldung beifügt oder nachreicht, um so leichter ist es für den Programmierer, diesen zu beheben.</p>
|
||||
<p>Wenn man einen Fehler gemeldet hat ist es damit nicht abgeschlossen, eigentlich ist es erst der Anfang und man wird Teil des Entwicklungs-Prozesses von Haiku. Es ist durchaus möglich und eigentlich auch zu erwarten, dass sich ein Entwickler meldet, um näheres zu den Umständen des Fehler-Reports zu erfahren. Hier gilt wieder: je mehr man dem Entwickler helfen kann, um so leichter tut er sich mit der Fehlerbehebung. Erst wenn der Fehler als 'fixed' - also behoben - markiert ist, kann man sich zurücklehnen, mit dem guten Gefühl etwas beigetragen zu haben.</p>
|
||||
|
||||
|
||||
@@ -4,11 +4,12 @@
|
||||
<head>
|
||||
<!--
|
||||
*
|
||||
* Copyright 2008-2009, Haiku. All rights reserved.
|
||||
* Copyright 2008-2010, Haiku. All rights reserved.
|
||||
* Distributed under the terms of the MIT License.
|
||||
*
|
||||
* Authors:
|
||||
* Niels Reedijk and Matt Madia who wrote http://dev.haiku-os.org/wiki
|
||||
* Niels Reedijk, Matt Madia and Ingo Weinhold who wrote
|
||||
* http://dev.haiku-os.org/wiki/ and http://dev.haiku-os.org/wiki/ReportingBugs
|
||||
* Humdinger <[email protected]>
|
||||
*
|
||||
-->
|
||||
@@ -46,49 +47,109 @@
|
||||
<div id="content">
|
||||
<div>
|
||||
|
||||
<table class="index" id="index" summary="index">
|
||||
<tr class="heading"><td>Reporting bugs</td></tr>
|
||||
<tr class="index"><td><a href="#account">Getting a Trac account</a><br />
|
||||
<a href="#report">Creating a bug report</a><br />
|
||||
<a href="#app">Application bugs</a><br />
|
||||
<a href="#server">Server bugs</a><br />
|
||||
<a href="#kernel">Kernel bugs</a><br />
|
||||
<a href="#kdl">Kernel Debugging Land - KDL</a><br />
|
||||
<a href="#syslog">Syslog</a><br />
|
||||
<a href="#onscreen">On screen debug output</a><br />
|
||||
<a href="#hardware">Hardware/Driver bugs</a><br />
|
||||
<a href="#next">What's next?</a></td></tr>
|
||||
</table>
|
||||
|
||||
<h1>Reporting bugs</h1>
|
||||
|
||||
<p>Since our developers are unable to test every hardware combination, nor every different way of interacting with the operating system, we are relying on users to give us some input on how things work at their end. Since Haiku is still quite young, it's very likely that you will encounter bugs. We thank you for taking the time to report these. Together we can improve Haiku, bit by bit.</p>
|
||||
<p>To keep our bugtracker effective, it's essential to abide by the <a href="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">Bug Tracker Etiquette</a>.</p>
|
||||
|
||||
<h2>Getting a Trac account</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="account" name="accout">Getting a Trac account</a></h2>
|
||||
<p>To file a ticket, you need to have an account at <a href="http://dev.haiku-os.org/register" title="Register at Haiku's Bugtracker">Haiku's Bugtracker</a>.<br />
|
||||
When creating a new account, be certain to <b>provide your email address</b> as it is necessary to obtain basic ticket modification privileges. Be sure to <b>check your spam folder</b> shortly afterwards, as the all important verification mail often ends up there.</p>
|
||||
|
||||
<h2>Creating a bug report</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="report" name="report">Creating a bug report</a></h2>
|
||||
<p>Before reporting a bug, please <a href="http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority">make sure</a> that it does not yet exist. You can also use the <a href="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">search</a> function for this.<br />
|
||||
After you have established that it's a unique bug, make your information as accurate as possible:</p>
|
||||
<ul>
|
||||
<li><p>Attempt to reproduce your issue on the current revision of Haiku. Pre-built images for testing purposes are <a href="http://haiku-files.org/">available</a>.</p></li>
|
||||
<li><p>Include basic information such as how you are testing Haiku (on real hardware, on VMWare, on QEMU, etc.).</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in '<i>About This System...</i>' from the Deskbar menu.</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in <span class="menu">About Haiku...</span> from the Deskbar menu. Also mention what kind of Haiku build you are testing (gcc2, gcc4, gcc2hybrid, gcc4hybrid). The downloadable images are named accordingly, for a self-built image you should know how you built it.</p></li>
|
||||
<li><p>Describe the problem you are experiencing. Try to be as accurate as you can: describe the actual behavior, and the behavior you expected.</p></li>
|
||||
<li><p>Describe what steps you need to perform in order to expose the bug. This will help developers reproduce the bug.</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to make a screen shot (the <span class="key">PRINT</span> key saves a <acronym title="Portable Network Graphics image format">PNG</acronym> in <span class="path">/boot/home/</span>).</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to take a screenshot by pressing the <span class="key">PRINT</span> key.</p></li>
|
||||
</ul>
|
||||
|
||||
<h3>Software Bugs</h3>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. Entering <span class="cli">bt</span> into the launched debug Terminal, you create a "backtrace" that you should copy into your bug report.</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="app" name="app">Application bugs</a></h2>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. This will open a Terminal window with gdb (the GNU debugger) running in it. Entering <span class="cli">bt</span>, you create a "backtrace" that you should copy in its entirety (including the part before you entered the <span class="cli">bt</span> command) and attach it to the ticket.</p>
|
||||
|
||||
<h3>Hardware Bugs</h3>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information:</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="server" name="server">Server bugs</a></h2>
|
||||
<p>When vital servers like the app server, the registrar or the input server crash, you won't see the usual crash alert. Instead the whole screen will be cleared white and a gdb session will be started, its output appearing directly on screen. Likely you will still be able to move the mouse, which will overwrite the white and gdb output on screen. Applications still running (like ProcessController or the clock in the Deskbar) might also draw over the debugger output on screen.<br />
|
||||
Besides everything being more ugly and inconvenient, basically the same applies as for application bugs. Most importantly procure a back trace (<span class="cli">bt</span> command). You may need to take a picture of the screen with a digital camera, since you won't be able to copy the text anywhere.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kernel" name="kernel">Kernel bugs</a></h2>
|
||||
<p>Kernel bugs are usual the ones with the most severe effects while at the same time being the hardest to debug. There are different kinds of symptoms, which most likely point to a kernel or driver issue:</p>
|
||||
<ul>
|
||||
<li><span class="cli">listdev</span> - a detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</li>
|
||||
<li><span class="cli">listusb -v</span> - assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</li>
|
||||
<li><span class="cli">open /var/log/syslog</span> - the primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</li>
|
||||
<li><span class="cli">listimage | grep drivers/</span> - lists all used drivers.</li>
|
||||
<li><span class="cli">ints</span> - only available within <i>Kernel Debugging Land</i> (see below). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</li>
|
||||
<li><p>The system enters kernel debugging land (KDL) on its own volition. The upper part of the screen is cleared white and several lines of text are printed on it. The second line says "<i>Welcome to Kernel Debugging Land...</i>", the one above it states the immediate reason for entering KDL.</p></li>
|
||||
<li><p>The system reboots spontaneously.</p></li>
|
||||
<li><p>The system freezes completely. You can't move the mouse and no application draws anything anymore. An important test in that situation is, whether you still can enter KDL via the shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards). Wait at least a minute to see, if anything happens.</p></li>
|
||||
<li><p>The system doesn't boot up correctly. It may reboot spontaneously or stop at some point (e.g. at some icon of the boot screen). In the latter case also try <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.</p></li>
|
||||
<li><p>The whole system or some piece of hardware doesn't behave correctly. For example, it could be very slow, errors occur, or something doesn't work at all. If some hardware doesn't work at all, the first obvious check is whether Haiku supports it at all at the moment (e.g. ask on a mailing list or a forum).</p></li>
|
||||
</ul>
|
||||
<p>You enter these commands into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
<p>Note that while only the last point seems to indicate hardware relation, all the other symptoms could be caused by a bug in a hardware driver as well. If you have a suspicion what piece of hardware or corresponding driver might have to do with the problem, check whether removing/disabling the hardware or the driver makes a difference. For example, if you suspect Wifi you may find that your BIOS has an option to disable it. Or if not, you could remove the responsible Wifi driver from your Haiku installation (in <span class="path">/boot/system/add-ons/kernel/drivers/bin</span>).</p>
|
||||
|
||||
<h3>Kernel Debugging Land - KDL</h3>
|
||||
<p>When some very low level system component crashed, you may end up in the kernel debugger. It can also be entered deliberately with <span class="key">ALT</span><span class="key">SysReq</span><span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards).</p>
|
||||
<ul>
|
||||
<li><span class="cli">co</span> - will exit KDL and continue normal system operation, if possible.</li>
|
||||
<li><span class="cli">int</span> - will show interrupt usage (as described above).</li>
|
||||
<li><span class="cli">bt</span> - shows a backtrace, detailing where exactly the crash happened.</li>
|
||||
</ul>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kdl" name="kdl">Kernel Debugging Land - KDL</a></h3>
|
||||
<p>If the system hasn't entered KDL by itself, you can do that intentionally by invoking the keyboard shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.<br />
|
||||
Note that in KDL your keyboard may not work. PS/2 keyboards always do, USB keyboards connected via UHCI controllers do only, if one has entered KDL via the keyboard shortcut at least once. USB OHCI is not supported at the moment.</p>
|
||||
<p>KDL itself is a kind of a shell. One can execute commands that print information about the system. The following commands might be of interest:</p>
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td><span class="cli">bt</span> (aka sc)</td><td> </td><td>Prints a back trace. If the system entered KDL on its on volition, always enter that one.</td></tr>
|
||||
<tr><td><span class="cli">ints</span></td><td> </td><td>Shows the handled and unhandled hardware interrupts.</td></tr>
|
||||
<tr><td class="onelinetop"><span class="cli">co</span> (aka continue)</td><td> </td><td>Leaves the kernel debugger and continues normal operation of the system, if that is possible.</td></tr>
|
||||
<tr><td><span class="cli">reboot</span></td><td> </td><td>Reboots the system immediately. You will lose all unsaved data and even those that have been saved, but have not yet been written back to disk.</td></tr>
|
||||
</table>
|
||||
<p>For more information, see the article <a href="http://www.haiku-os.org/documents/dev/welcome_to_kernel_debugging_land">Welcome to Kernel Debugging Land</a>.</p>
|
||||
<p>The KDL output is written to the serial port (if you have one, a respective cable, and a second computer to connect with, you can capture the output there via a terminal program) and to the syslog. If you can't leave KDL it won't be written to the syslog file, though. There's a boot loader debug option that allows you to capture it nonetheless (see below).</p>
|
||||
|
||||
<h2>What's next?</h2>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="syslog" name="syslog">Syslog</a></h3>
|
||||
<p><b>This is the preferred method for gaining information from a non-booting system.</b><br />
|
||||
The syslog (short for system log) contains valuable information about what has happened in your system, including the output of KDL sessions. It's usually a good idea to attach it to the kernel related Trac ticket. The syslog is written to the file <span class="path">/boot/common/var/log/syslog</span>. Since writing to a file requires a working system, the most recent output might not have made it to the syslog when a kernel problem occurs (particularly on spontaneous reboots or uncontinuable KDL sessions).</p>
|
||||
<p>The option <span class="menu">Enable debug syslog</span> in the boot loader's <span class="menu">Debug menu</span> makes the syslog somewhat persistent in memory. By default the option is enabled. "Somewhat persistent" means that it survives a reset and will still be accessible when you enter the boot loader menu directly afterwards. Booting an operating system (Haiku definitely, others likely) destroys the information, though. So you have to enter the boot loader menu by holding down <span class="key">SHIFT</span> while booting.<br />
|
||||
In the boot loader's <span class="menu">Debug menu</span> you should now find the entries <span class="menu">Display syslog from previous session</span> and <span class="menu">Save syslog from previous session</span>. The former displays the syslog on screen, the latter allows you to save it as a file to disk. Note that at the moment only FAT32 volumes are supported for saving the file. If you want to use a USB stick, but have plugged it in too late so that it isn't recognized yet, you can reset the machine and re-enter the boot loader menu. But again: Don't accidentally boot any operating system or the data will be lost.</p>
|
||||
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="onscreen" name="onscreen">On screen debug output</a></h3>
|
||||
<p><b>The on-screen debug output is useful only for debugging very specific issues and is known to have (timing) issues. Don't use it, if you don't have to.</b><br />
|
||||
This is only relevant when Haiku fails to boot on your machine and the <span class="menu">Debug syslog option</span> doesn't work for some reason. Before the Haiku boot logo appears, hold <span class="key">SHIFT</span> to enter the boot loader menu. Select <span class="menu">Select safe mode options</span>. Near the bottom, <span class="menu">[ ] Enable on screen debug output</span> will be listed. (Note: The other options could be enabled in an attempt to boot Haiku. If Haiku will boot only when one or more options are activated, be sure to mention which ones.)<br />
|
||||
Finally select <span class="menu">Return to main menu</span> and then <span class="menu">Continue booting</span>.<br />
|
||||
One or more pages of text will display on the screen, only the last few lines need to be included on your ticket. There's more information on the <a href="../../../userguide/en/bootloader.html">Boot Loader</a>.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="hardware" name="hardware">Hardware/Driver bugs</a></h2>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information as text files:</p>
|
||||
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td>- <span class="cli">listdev</span></td><td> </td><td>A detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">listusb -v</span></td><td> </td><td>Assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">open /var/log/syslog</span></td><td> </td><td>The primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</td></tr>
|
||||
<tr><td class="onelinetop">- <span class="cli">listimage | grep drivers/</span></td><td> </td><td>Lists all used drivers.</td></tr>
|
||||
<tr><td>- <span class="cli">ints</span></td><td> </td><td>Only available within <i>Kernel Debugging Land</i> (see above). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</td></tr>
|
||||
<tr><td colspan="3">- On screen debug output (a safe mode boot time option).</td></tr>
|
||||
</table>
|
||||
|
||||
<p>The first four commands are entered into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="next" name="next">What's next?</a></h2>
|
||||
<p>After the bug has been reported, a developer will look at your bug and try to classify it. Remember, we are all volunteers, and as such, sometimes a bug report might go unanswered for a while. Adding new information when it becomes available usually helps getting a bug picked up quicker, but do not try to 'bump' the bug up by adding
|
||||
non-descriptive comments.</p>
|
||||
<p>Remember, reporting a bug is not something you spend a little time on and then you are done. If you reported a bug, then you are part of the Haiku development process. Developers might come up with questions while they are trying to fix your bug. Please stay around to answer these. Consider your participation 'done' when the bug is marked
|
||||
|
||||
@@ -4,11 +4,12 @@
|
||||
<head>
|
||||
<!--
|
||||
*
|
||||
* Copyright 2008-2009, Haiku. All rights reserved.
|
||||
* Copyright 2008-2010, Haiku. All rights reserved.
|
||||
* Distributed under the terms of the MIT License.
|
||||
*
|
||||
* Authors:
|
||||
* Niels Reedijk and Matt Madia who wrote http://dev.haiku-os.org/wiki
|
||||
* Niels Reedijk, Matt Madia and Ingo Weinhold who wrote
|
||||
* http://dev.haiku-os.org/wiki/ and http://dev.haiku-os.org/wiki/ReportingBugs
|
||||
* Humdinger <[email protected]>
|
||||
* Translators:
|
||||
* miguel~1.mx
|
||||
@@ -22,7 +23,7 @@
|
||||
<body>
|
||||
|
||||
<div id="banner">
|
||||
<div><span>Guía del usuario</span></div>
|
||||
<div><span>User guide</span></div>
|
||||
</div>
|
||||
|
||||
<div class="nav">
|
||||
@@ -47,50 +48,111 @@
|
||||
|
||||
<div id="content">
|
||||
<div>
|
||||
<div class="box-info">The translation of this page isn't yet complete. Until it is, unfinished parts use the English original.</div>
|
||||
|
||||
<table class="index" id="index" summary="index">
|
||||
<tr class="heading"><td>Reportar fallos</td></tr>
|
||||
<tr class="index"><td><a href="#account">Getting a Trac account</a><br />
|
||||
<a href="#report">Creating a bug report</a><br />
|
||||
<a href="#app">Application bugs</a><br />
|
||||
<a href="#server">Server bugs</a><br />
|
||||
<a href="#kernel">Kernel bugs</a><br />
|
||||
<a href="#kdl">Kernel Debugging Land - KDL</a><br />
|
||||
<a href="#syslog">Syslog</a><br />
|
||||
<a href="#onscreen">On screen debug output</a><br />
|
||||
<a href="#hardware">Hardware/Driver bugs</a><br />
|
||||
<a href="#next">What's next?</a></td></tr>
|
||||
</table>
|
||||
|
||||
<h1>Reportar fallos</h1>
|
||||
|
||||
<p>Ya que nuestros desarrolladores no pueden verificar todas las combinaciones de hardware, ni todas las posibles maneras de interactuar con el sistema operativo, confiamos que los usuarios nos den retroalimentación sobre cómo funcionan las cosas de su lado. Dado que Haiku todavía es muy joven, muy probablemente encontrará fallos. Le agradecemos por tomarse el tiempo para reportarlos. Juntos podemos mejorar a Haiku, bit a bit.</p>
|
||||
<p>Para mantener nuestro rastreador de fallos efectivo, es esencial supeditarse a la <a href="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">Etiqueta del rastreador de fallos</a>.</p>
|
||||
|
||||
<h2>Obtener una cuenta de Trac</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="account" name="accout">Getting a Trac account</a></h2>
|
||||
<p>Para llenar un reporte, necesita tener una cuenta en <a href="http://dev.haiku-os.org/register" title="Register at Haiku's Bugtracker">el Rastreador de fallos de Haiku</a>.<br />
|
||||
Cuando se cree una cuenta nueva, asegurese de <b>proporcionar su correo electrónico</b> pues es necesario obtener privilegios de modificación básica del reporte. Asegúrese de <b>comprobar su carpeta de correo no deseado (spam)</b> brevemente después, ya que a menudo toda verificación de correo importante termina allí.</p>
|
||||
|
||||
<h2>Crear un reporte de fallo</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="report" name="report">Creating a bug report</a></h2>
|
||||
<p>Antes de reportar un fallo, por favor <a href="http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority">asegúrese</a> que aún no exista. Puede también usar la función de <a href="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">búsqueda</a> para esto.<br />
|
||||
Tras haber establecido que es un fallo nuevo, haga su información tan puntual como sea posible:</p>
|
||||
<ul>
|
||||
<li><p>Attempt to reproduce your issue on the current revision of Haiku. Pre-built images for testing purposes are <a href="http://haiku-files.org/">available</a>.</p></li>
|
||||
<li><p>Incluya información básica tal como dónde está probando a Haiku (sobre hardware real, en VMWare, en QEMU, etc.).</p></li>
|
||||
<li><p>Mencione cuál revisión de <acronym title="Subversion, the source code management system we use">SVN</acronym> esté corriendo. Puede encontrar esta información en '<i>About This System...</i>' (Acerca de este sistema) desde el menú Deskbar.</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in <span class="menu">About Haiku...</span> from the Deskbar menu. Also mention what kind of Haiku build you are testing (gcc2, gcc4, gcc2hybrid, gcc4hybrid). The downloadable images are named accordingly, for a self-built image you should know how you built it.</p></li>
|
||||
<li><p>Describa el problema que esté experimentando. Intente ser tan preciso como pueda: describa el comportamiento actual, y el comportamiento esperado.</p></li>
|
||||
<li><p>Describa qué pasos necesita realizar para exponer el fallo. Esto ayudará a los desarrolladores a reproducir el fallo.</p></li>
|
||||
<li><p>Adjunte tanta información como tenga. Si es un fallo de interfaz de usuario, o un fallo en una de las aplicaciones, intente hacer una captura de pantalla (la tecla <span class="key">Impr pant</span> guarda un <acronym title="Portable Network Graphics image format">PNG</acronym> en <span class="path">/boot/home/</span>).</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to take a screenshot by pressing the <span class="key">PRINT</span> key.</p></li>
|
||||
</ul>
|
||||
|
||||
<h3>Fallos de software</h3>
|
||||
<p>Cuando falla una aplicación, debería invocar el depurador desde la alerta que aparece. Al ingresar <span class="cli">bt</span> dentro de la terminal de depuración ejecutada, se crea un "backtrace" que debiera copiarse dentro del reporte de fallo.</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="app" name="app">Application bugs</a></h2>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. This will open a Terminal window with gdb (the GNU debugger) running in it. Entering <span class="cli">bt</span>, you create a "backtrace" that you should copy in its entirety (including the part before you entered the <span class="cli">bt</span> command) and attach it to the ticket.</p>
|
||||
|
||||
<h3>Fallos de hardware</h3>
|
||||
<p>Cuando se enfrente a fallos relacionados con hardware/controladores, debería adjuntarse la siguiente información:</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="server" name="server">Server bugs</a></h2>
|
||||
<p>When vital servers like the app server, the registrar or the input server crash, you won't see the usual crash alert. Instead the whole screen will be cleared white and a gdb session will be started, its output appearing directly on screen. Likely you will still be able to move the mouse, which will overwrite the white and gdb output on screen. Applications still running (like ProcessController or the clock in the Deskbar) might also draw over the debugger output on screen.<br />
|
||||
Besides everything being more ugly and inconvenient, basically the same applies as for application bugs. Most importantly procure a back trace (<span class="cli">bt</span> command). You may need to take a picture of the screen with a digital camera, since you won't be able to copy the text anywhere.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kernel" name="kernel">Kernel bugs</a></h2>
|
||||
<p>Kernel bugs are usual the ones with the most severe effects while at the same time being the hardest to debug. There are different kinds of symptoms, which most likely point to a kernel or driver issue:</p>
|
||||
<ul>
|
||||
<li><span class="cli">listdev</span> - un listado detallado de su hardware, incluyendo las IDs de fabricante y dispositivo PCI, similar a los comandos <span class="cli">lshw</span> y <span class="cli">lspci</span> de Linux.</li>
|
||||
<li><span class="cli">listusb -v</span> - asumiendo que el conflicto se relacione con USB, de manera similar a <span class="cli">lsusb</span>.</li>
|
||||
<li><span class="cli">open /var/log/syslog</span> - el historial de sucesos de sitema primario utilizado por Haiku, análogamente a la pantalla de depuración durante el arranque. Con el comando <span class="cli">open</span> se puede acortar la parte relevante de los sucesos de sistema en un editor de textos.</li>
|
||||
<li><span class="cli">listimage | grep drivers/</span> - lista todos los controladores utilizados.</li>
|
||||
<li><span class="cli">ints</span> - sólo disponible en la <i>Tierra de depuración del núcleo</i> (ve debajo). Muestra el uso de interrupciones. No debería haber demasiados que se compartan por dispositivos diferentes.</li>
|
||||
<li><p>The system enters kernel debugging land (KDL) on its own volition. The upper part of the screen is cleared white and several lines of text are printed on it. The second line says "<i>Welcome to Kernel Debugging Land...</i>", the one above it states the immediate reason for entering KDL.</p></li>
|
||||
<li><p>The system reboots spontaneously.</p></li>
|
||||
<li><p>The system freezes completely. You can't move the mouse and no application draws anything anymore. An important test in that situation is, whether you still can enter KDL via the shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards). Wait at least a minute to see, if anything happens.</p></li>
|
||||
<li><p>The system doesn't boot up correctly. It may reboot spontaneously or stop at some point (e.g. at some icon of the boot screen). In the latter case also try <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.</p></li>
|
||||
<li><p>The whole system or some piece of hardware doesn't behave correctly. For example, it could be very slow, errors occur, or something doesn't work at all. If some hardware doesn't work at all, the first obvious check is whether Haiku supports it at all at the moment (e.g. ask on a mailing list or a forum).</p></li>
|
||||
</ul>
|
||||
<p>Se pueden ingresar estos comandos en la Terminal. Agregue un <span class="cli"> > output.txt</span> tras un comando, y se hará una operación de tubería dentro de un texto llamado "output.txt" que se puede adjuntar al reporte de fallos o correo electrónico.</p>
|
||||
<p>Note that while only the last point seems to indicate hardware relation, all the other symptoms could be caused by a bug in a hardware driver as well. If you have a suspicion what piece of hardware or corresponding driver might have to do with the problem, check whether removing/disabling the hardware or the driver makes a difference. For example, if you suspect Wifi you may find that your BIOS has an option to disable it. Or if not, you could remove the responsible Wifi driver from your Haiku installation (in <span class="path">/boot/system/add-ons/kernel/drivers/bin</span>).</p>
|
||||
|
||||
<h3>Tierra de depuración del núcleo - KDL</h3>
|
||||
<p>Cuando algún componente de sistema de muy bajo nivel deja de funcionar, se puede terminar en el depurador de núcleo (KDL por sus siglas en inglés, Kernel Debugging Land). También puede ingresarse deliberadamente con <span class="key">ALT</span> <span class="key">PetSis</span> <span class="key">D</span> (siendo <span class="key">PetSis</span> el mismo botón que <span class="key">Impr pant</span> en la mayoría de los teclados).</p>
|
||||
<ul>
|
||||
<li><span class="cli">co</span> - saldrá de KDL y continuará la operación del sistema, si es posible.</li>
|
||||
<li><span class="cli">int</span> - mostrará el uso de interrupciones (como se describió arriba).</li>
|
||||
<li><span class="cli">bt</span> - muestra el "backtrace", detallando dónde exactamente sucedió el fallo.</li>
|
||||
</ul>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kdl" name="kdl">Kernel Debugging Land - KDL</a></h3>
|
||||
<p>If the system hasn't entered KDL by itself, you can do that intentionally by invoking the keyboard shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.<br />
|
||||
Note that in KDL your keyboard may not work. PS/2 keyboards always do, USB keyboards connected via UHCI controllers do only, if one has entered KDL via the keyboard shortcut at least once. USB OHCI is not supported at the moment.</p>
|
||||
<p>KDL itself is a kind of a shell. One can execute commands that print information about the system. The following commands might be of interest:</p>
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td><span class="cli">bt</span> (aka sc)</td><td> </td><td>Prints a back trace. If the system entered KDL on its on volition, always enter that one.</td></tr>
|
||||
<tr><td><span class="cli">ints</span></td><td> </td><td>Shows the handled and unhandled hardware interrupts.</td></tr>
|
||||
<tr><td class="onelinetop"><span class="cli">co</span> (aka continue)</td><td> </td><td>Leaves the kernel debugger and continues normal operation of the system, if that is possible.</td></tr>
|
||||
<tr><td><span class="cli">reboot</span></td><td> </td><td>Reboots the system immediately. You will lose all unsaved data and even those that have been saved, but have not yet been written back to disk.</td></tr>
|
||||
</table>
|
||||
<p>For more information, see the article <a href="http://www.haiku-os.org/documents/dev/welcome_to_kernel_debugging_land">Welcome to Kernel Debugging Land</a>.</p>
|
||||
<p>The KDL output is written to the serial port (if you have one, a respective cable, and a second computer to connect with, you can capture the output there via a terminal program) and to the syslog. If you can't leave KDL it won't be written to the syslog file, though. There's a boot loader debug option that allows you to capture it nonetheless (see below).</p>
|
||||
|
||||
<h2>¿Qué sigue?</h2>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="syslog" name="syslog">Syslog</a></h3>
|
||||
<p><b>This is the preferred method for gaining information from a non-booting system.</b><br />
|
||||
The syslog (short for system log) contains valuable information about what has happened in your system, including the output of KDL sessions. It's usually a good idea to attach it to the kernel related Trac ticket. The syslog is written to the file <span class="path">/boot/common/var/log/syslog</span>. Since writing to a file requires a working system, the most recent output might not have made it to the syslog when a kernel problem occurs (particularly on spontaneous reboots or uncontinuable KDL sessions).</p>
|
||||
<p>The option <span class="menu">Enable debug syslog</span> in the boot loader's <span class="menu">Debug menu</span> makes the syslog somewhat persistent in memory. By default the option is enabled. "Somewhat persistent" means that it survives a reset and will still be accessible when you enter the boot loader menu directly afterwards. Booting an operating system (Haiku definitely, others likely) destroys the information, though. So you have to enter the boot loader menu by holding down <span class="key">SHIFT</span> while booting.<br />
|
||||
In the boot loader's <span class="menu">Debug menu</span> you should now find the entries <span class="menu">Display syslog from previous session</span> and <span class="menu">Save syslog from previous session</span>. The former displays the syslog on screen, the latter allows you to save it as a file to disk. Note that at the moment only FAT32 volumes are supported for saving the file. If you want to use a USB stick, but have plugged it in too late so that it isn't recognized yet, you can reset the machine and re-enter the boot loader menu. But again: Don't accidentally boot any operating system or the data will be lost.</p>
|
||||
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="onscreen" name="onscreen">On screen debug output</a></h3>
|
||||
<p><b>The on-screen debug output is useful only for debugging very specific issues and is known to have (timing) issues. Don't use it, if you don't have to.</b><br />
|
||||
This is only relevant when Haiku fails to boot on your machine and the <span class="menu">Debug syslog option</span> doesn't work for some reason. Before the Haiku boot logo appears, hold <span class="key">SHIFT</span> to enter the boot loader menu. Select <span class="menu">Select safe mode options</span>. Near the bottom, <span class="menu">[ ] Enable on screen debug output</span> will be listed. (Note: The other options could be enabled in an attempt to boot Haiku. If Haiku will boot only when one or more options are activated, be sure to mention which ones.)<br />
|
||||
Finally select <span class="menu">Return to main menu</span> and then <span class="menu">Continue booting</span>.<br />
|
||||
One or more pages of text will display on the screen, only the last few lines need to be included on your ticket. There's more information on the <a href="../../../userguide/es/bootloader.html">Boot Loader</a>.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="hardware" name="hardware">Hardware/Driver bugs</a></h2>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information as text files:</p>
|
||||
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td>- <span class="cli">listdev</span></td><td> </td><td>A detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">listusb -v</span></td><td> </td><td>Assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">open /var/log/syslog</span></td><td> </td><td>The primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</td></tr>
|
||||
<tr><td class="onelinetop">- <span class="cli">listimage | grep drivers/</span></td><td> </td><td>Lists all used drivers.</td></tr>
|
||||
<tr><td>- <span class="cli">ints</span></td><td> </td><td>Only available within <i>Kernel Debugging Land</i> (see above). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</td></tr>
|
||||
<tr><td colspan="3">- On screen debug output (a safe mode boot time option).</td></tr>
|
||||
</table>
|
||||
|
||||
<p>The first four commands are entered into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="next" name="next">What's next?</a></h2>
|
||||
<p>Después que un fallo se ha reportado, un desarrollador verá el reporte e intentará clasificarlo. Recuerde, todos somos voluntarios, y por ello, algunas veces un fallo pudiera estar sin responderse por un tiempo. Agregar nueva información cuando esté disponible usualmente ayuda a que se escoja un fallo más rápidamente, pero no intente 'levantar' el fallo agregando comentarios no descriptivos.</p>
|
||||
<p>Recuerde, reportar un fallo no es algo en lo que tome un poquito de tiempo y sea todo. Si se reporta un fallo, se vuelve parte del proceso de desarrollo de Haiku. Los desarrolladores podrían llegar con preguntas mientras intentan arreglar el fallo reportado. Por favor, permanezca atento para responderlas. Considere su participación 'terminada' cuando el fallo se marque como 'arreglado'.</p>
|
||||
|
||||
|
||||
@@ -4,11 +4,12 @@
|
||||
<head>
|
||||
<!--
|
||||
*
|
||||
* Copyright 2008-2009, Haiku. All rights reserved.
|
||||
* Copyright 2008-2010, Haiku. All rights reserved.
|
||||
* Distributed under the terms of the MIT License.
|
||||
*
|
||||
* Authors:
|
||||
* Niels Reedijk and Matt Madia who wrote http://dev.haiku-os.org/wiki
|
||||
* Niels Reedijk, Matt Madia and Ingo Weinhold who wrote
|
||||
* http://dev.haiku-os.org/wiki/ and http://dev.haiku-os.org/wiki/ReportingBugs
|
||||
* Humdinger <[email protected]>
|
||||
* Translators:
|
||||
* Loïc
|
||||
@@ -23,7 +24,7 @@
|
||||
<body>
|
||||
|
||||
<div id="banner">
|
||||
<div><span>Guide de l’utilisateur</span></div>
|
||||
<div><span>User guide</span></div>
|
||||
</div>
|
||||
|
||||
<div class="nav">
|
||||
@@ -48,52 +49,117 @@
|
||||
|
||||
<div id="content">
|
||||
<div>
|
||||
<div class="box-info">The translation of this page isn't yet complete. Until it is, unfinished parts use the English original.</div>
|
||||
|
||||
<table class="index" id="index" summary="index">
|
||||
<tr class="heading"><td>Signaler les bogues</td></tr>
|
||||
<tr class="index"><td><a href="#account">Obtenir un compte Trac</a><br />
|
||||
<a href="#report">Créer un rapport de bogue</a><br />
|
||||
<a href="#app">Bogues logiciels</a><br />
|
||||
<a href="#server">Bogues dans les Serveurs</a><br />
|
||||
<a href="#kernel">Bogues du noyau</a><br />
|
||||
<a href="#kdl">Le mode débogage noyau - KDL</a><br />
|
||||
<a href="#syslog">Le journal système</a><br />
|
||||
<a href="#onscreen">Les sorties écran du débogueur</a><br />
|
||||
<a href="#hardware">Bogues liés au matériel ou aux pilotes</a><br />
|
||||
<a href="#next">Et après ?</a></td></tr>
|
||||
</table>
|
||||
|
||||
<h1>Signaler les bogues</h1>
|
||||
|
||||
<p>Comme il est impossible pour nos développeurs de tester toutes les combinaisons de matériel, ni tous les cas de figure pouvant interagir avec le système d'exploitation, nous comptons sur les utilisateurs pour nous dire si les choses fonctionnent pour eux. puisque Haiku est encore tout jeune, il est très probable que vous rencontriez des bogues. Nous vous remercions de bien vouloir prendre le temps de nous les signaler. Ensemble, nous pourrons, petit à petit, améliorer Haiku.</p>
|
||||
<p>Afin que le suivi de nos bogues reste efficace, il est essentiel de respecter l'<a href="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">Étiquette de suivi des bogues</a>.</p>
|
||||
|
||||
<h2>Obtenir un compte Trac</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="account" name="accout">Obtenir un compte Trac</a></h2>
|
||||
<p>Pour remplir un rapport (ticket), vous aurez besoin d’un compte utilisateur sur le <a href="http://dev.haiku-os.org/register" title="Traqueur de bogues de Haiku">Traqueur de bogues de Haiku</a>.<br />
|
||||
Lors de la création d’un nouveau compte, pensez à <b>indiquer votre adresse e-mail</b> afin d’obtenir les privilèges basiques de gestions des tickets. N’oubliez pas de <b>Vérifier votre dossier de pourriel</b> après, car les e-mails de vérifications s’y retrouvent souvent.</p>
|
||||
|
||||
<h2>Créer un rapport de bogue</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="report" name="report">Créer un rapport de bogue</a></h2>
|
||||
<p>Avant de rapporter un bogue, veuillez <a href="http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority">vérifier</a> qu’il n’est pas déjà répertorié. Vous pouvez aussi utiliser la <a href="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">fonction de recherche</a> pour cela.<br />
|
||||
Après vous être assuré que votre bogue est unique, obtenez des informations précises sur votre environnement :</p>
|
||||
<ul>
|
||||
<li><p>Essayez de reproduire votre problème avec la version actuelle d'Haiku. Des <a href="http://haiku-files.org/">images préfabriqués</a> sont disponible à cet usage.</p></li>
|
||||
<li><p>Indiquez comment vous testez Haiku (sur machine réelle, dans VMware, dans Qemu…)</p></li>
|
||||
<li><p>Indiquez quelle révision <acronym title="Subversion, le système de gestion de code source que nous utilisons">SVN</acronym> de Haiku vous utilisez. Vous pouvez trouver des informations à ce sujet dans le menu « <i>About This System…</i> » de la Deskbar.</p></li>
|
||||
<li><p>Indiquez quelle révision <acronym title="Subversion, le système de gestion de code source que nous utilisons">SVN</acronym> de Haiku vous utilisez. Vous pouvez trouver cette information dans le menu « <i>About This System…</i> » de la Deskbar.
|
||||
N'oubliez pas de mentionner de quel type de construction est issu le système Haiku que vous testez (gcc2, gcc4, gcc2hybrid, gcc4hybrid).
|
||||
Les images téléchargeables sont nommés en conséquence. Si vous avez construit l'image vous-même, vous devriez savoir comment vous l'avez compilé.</p></li>
|
||||
<li><p>Décrivez le problème que vous rencontrez. soyez aussi précis que possible : décrivez le comportement réel, et celui que vous attendiez.</p></li>
|
||||
<li><p>Décrivez les actions que vous avez effectuées avant de faire ressortir le bogue. Cela permettra aux développeurs de le reproduire.</p></li>
|
||||
<li><p>Attachez au rapport le plus d’informations possibles. Si le bogue concerne l’interface graphique ou une application, essayez de faire une capture d’écran (la touche <span class="key">IMPR ÉCRAN</span> créera une image <acronym title="Portable Network Graphics image format">PNG</acronym> dans le dossier <span class="path">/boot/home/</span>).</p></li>
|
||||
<li><p>Attachez au rapport le plus d’informations possibles. Si le bogue concerne l’interface graphique ou une application, essayez de faire une capture d’écran à l'aide de la la touche <span class="key">IMPR ÉCRAN</span>.</p></li>
|
||||
</ul>
|
||||
|
||||
<h3>Bogues logiciels</h3>
|
||||
<p>Lorsqu'une application se plante, vous devez appeler le débogueur depuis le message d'alerte qui s'affiche. Saisissez <span class="cli">bt</span> dans le Terminal de débogage qui est lancé. Vous obtiendrez ainsi une trace de la « pile d'appel » (<i>backtrace</i>) que vous devez joindre à votre rapport de bogue.</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="app" name="app">Bogues logiciels</a></h2>
|
||||
<p>Lorsqu'une application se plante, vous devez appeler le débogueur depuis le message d'alerte qui s'affiche.
|
||||
Une fenêtre de Terminal devrait s'ouvrir avec gdb (le débogueur GNU) lancé à l'intérieur.
|
||||
En saisissant <span class="cli">bt</span>, vous obtiendrez ainsi une trace de la « pile d'appel » (<i>backtrace</i>) que vous devez joindre en intégralité (y compris la partie précédant l'appel à la commande <span class="cli">bt</span>) à votre rapport de bogue.</p>
|
||||
|
||||
<h3>Bogues matériels</h3>
|
||||
<p>Lorsque le bogue concerne un matériel ou son pilote, vous devez fournir les renseignements suivants :</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="server" name="server">Bogues dans les serveurs</a></h2>
|
||||
<p>When vital servers like the app server, the registrar or the input server crash, you won't see the usual crash alert. Instead the whole screen will be cleared white and a gdb session will be started, its output appearing directly on screen. Likely you will still be able to move the mouse, which will overwrite the white and gdb output on screen. Applications still running (like ProcessController or the clock in the Deskbar) might also draw over the debugger output on screen.<br />
|
||||
Besides everything being more ugly and inconvenient, basically the same applies as for application bugs. Most importantly procure a back trace (<span class="cli">bt</span> command). You may need to take a picture of the screen with a digital camera, since you won't be able to copy the text anywhere.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kernel" name="kernel">Bogues du noyau</a></h2>
|
||||
<p>Les bogues du noyau sont habituellement ceux qui ont les effets les plus graves, tout en étant les plus difficiles à déboguer. Il existe différents types de symptômes, qui révèlent généralement un problème du noyau ou d'un pilote :</p>
|
||||
<ul>
|
||||
<li><span class="cli">listdev</span> - fait une liste détaillée de votre matériel, en y incluant les identifiants PCI des fournisseurs, à la manière de <span class="cli">lshw</span> ou <span class="cli">lspci</span> dans GNU/Linux .</li>
|
||||
<li><span class="cli">listusb -v</span> - en supposant que c'est un problème lié à l'USB, comme le fait <span class="cli">lsusb</span>.</li>
|
||||
<li><span class="cli">open /var/log/syslog</span> -
|
||||
le système de journal d’événements principal de Haiku, similaire au déboguage sur écran durant le démarrage. En l’ouvrant dabs un éditeur de texte avec la commande <span class="cli">open</span> vous pourrez n’en conserver que la partie utile.</li>
|
||||
<li><span class="cli">listimage | grep drivers/</span> - liste tous les drivers utilisés.</li>
|
||||
<li><span class="cli">ints</span> - seulement disponible dans le <i>mode débogage du noyau</i> (voir ci-dessous). Montre l'utilisation des interruptions.
|
||||
Il ne devrait pas y avoir trop d'interruptions partagées par plusieurs périphériques.</li>
|
||||
<li><p>The system enters kernel debugging land (KDL) on its own volition. The upper part of the screen is cleared white and several lines of text are printed on it. The second line says "<i>Welcome to Kernel Debugging Land...</i>", the one above it states the immediate reason for entering KDL.</p></li>
|
||||
<li><p>Le système redémarre spontanément.</p></li>
|
||||
<li><p>The system freezes completely. You can't move the mouse and no application draws anything anymore. An important test in that situation is, whether you still can enter KDL via the shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards). Wait at least a minute to see, if anything happens.</p></li>
|
||||
<li><p>Le système ne démarre pas correctement. Il peut redémarrer spontanément ou s'arrêter à un moment donné (par exemple au niveau d'une icône de l'écran de démarrage). Dans ce dernier cas vous pouvez essayer aussi <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.</p></li>
|
||||
<li><p>The whole system or some piece of hardware doesn't behave correctly. For example, it could be very slow, errors occur, or something doesn't work at all. If some hardware doesn't work at all, the first obvious check is whether Haiku supports it at all at the moment (e.g. ask on a mailing list or a forum).</p></li>
|
||||
</ul>
|
||||
<p>Ces commandes peuvent être entrées dans le Terminal. Si vous ajoutez <span class="cli"> > sortie.txt</span> après une commande, sa sortie sera redirigée dans un fichier texte nommé « sortie.txt » que vous pourrez attachez à votre rapport de bogue ou e-mail.</p>
|
||||
<p>Note that while only the last point seems to indicate hardware relation, all the other symptoms could be caused by a bug in a hardware driver as well. If you have a suspicion what piece of hardware or corresponding driver might have to do with the problem, check whether removing/disabling the hardware or the driver makes a difference. For example, if you suspect Wifi you may find that your BIOS has an option to disable it. Or if not, you could remove the responsible Wifi driver from your Haiku installation (in <span class="path">/boot/system/add-ons/kernel/drivers/bin</span>).</p>
|
||||
|
||||
<h3>Le mode débogage noyau - KDL</h3>
|
||||
<p>Lorsque certains composants systèmes de bas niveau se plantent, vous pouvez être envoyé dans le débogueur du noyau. Vous pouvez également y entrer volontairement avec <span class="key">ALT</span><span class="key">SYST</span><span class="key">D</span> (<span class="key">SYST</span> correspond à <span class="key">IMPR ÉCRAN</span> sur la plupart des claviers). Attention : l'ordre des touches compte.</p>
|
||||
<ul>
|
||||
<li><span class="cli">co</span> - sortira du KDL et reprendra l’exécution normale, si possible.</li>
|
||||
<li><span class="cli">int</span> - affichera l’utilisation des interruptions (comme décrit ci-dessus).</li>
|
||||
<li><span class="cli">bt</span> - affiche une trace de déboguage (backtrace), indiquant exactement comment le plantage s’est produit.</li>
|
||||
</ul>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kdl" name="kdl">Le mode débogage noyau - KDL</a></h3>
|
||||
<p>Si le système n'entre pas de lui même en mode déboguage du noyau (KDL) vous pouvez le faire volontairement en invoquant le raccourci clavier <span class="key">ALT</span> <span class="key">Syst</span> <span class="key">D</span> Attention : l'ordre des touches compte (<span class="key">SYST</span> correspond à <span class="key">Impr Écran</span> sur la plupart des claviers).
|
||||
Notez bien que votre clavier pourrait ne pas fonctionner en mode déboguage du noyau. Alors que les claviers PS/2
|
||||
ne posent pas de problème, les claviers USB connecté à un controleur UHCI ne fonctionne que si vous être entré au moins une fois en mode débogage à l'aide du raccourci clavier. Pour le moment l'USB OHCI n'est pas supporté.</p>
|
||||
<p>KDL est, par lui-même, une sorte d'interpréteur de commande. On peut exécuter des instructions pour afficher des informations sur le système. Les commandes suivantes pourraient vous intéresser :</p>
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td><span class="cli">bt</span> (alias sc)</td><td> </td><td>Affiche une trace de débogage (backtrace), Faites systematiquement cette commande quand le système entre dans le débogueur de lui même.</td></tr>
|
||||
<tr><td><span class="cli">ints</span></td><td> </td><td>Affichera les interruptions matérielles qui sont gérées, ainsi que celles qui sont ignorées.</td></tr>
|
||||
<tr><td class="onelinetop"><span class="cli">co</span> (alias continue)</td><td> </td><td>Quitte le débogueur pour reprendre, si possible, les opérations normales du système.</td></tr>
|
||||
<tr><td><span class="cli">reboot</span></td><td> </td><td>Redémarre le système immédiatement. Vous perdrez toutes les données non enregistrées, ainsi que celles qui ont été enregistrés, mais qui n'ont pas encore été écrites sur le disque.</td></tr>
|
||||
</table>
|
||||
<p>Pour plus d'information, consultez l'article <a href="http://www.haiku-os.org/documents/dev/welcome_to_kernel_debugging_land">Welcome to Kernel Debugging Land</a>.</p>
|
||||
<p>The KDL output is written to the serial port (if you have one, a respective cable, and a second computer to connect with, you can capture the output there via a terminal program) and to the syslog. If you can't leave KDL it won't be written to the syslog file, though. There's a boot loader debug option that allows you to capture it nonetheless (see below).</p>
|
||||
|
||||
<h2>Et après ?</h2>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="syslog" name="syslog">Le journal système</a></h3>
|
||||
<p><b>This is the preferred method for gaining information from a non-booting system.</b><br />
|
||||
The syslog (short for system log) contains valuable information about what has happened in your system, including the output of KDL sessions. It's usually a good idea to attach it to the kernel related Trac ticket. The syslog is written to the file <span class="path">/boot/common/var/log/syslog</span>. Since writing to a file requires a working system, the most recent output might not have made it to the syslog when a kernel problem occurs (particularly on spontaneous reboots or uncontinuable KDL sessions).</p>
|
||||
<p>The option <span class="menu">Enable debug syslog</span> in the boot loader's <span class="menu">Debug menu</span> makes the syslog somewhat persistent in memory. By default the option is enabled. "Somewhat persistent" means that it survives a reset and will still be accessible when you enter the boot loader menu directly afterwards. Booting an operating system (Haiku definitely, others likely) destroys the information, though. So you have to enter the boot loader menu by holding down <span class="key">SHIFT</span> while booting.<br />
|
||||
In the boot loader's <span class="menu">Debug menu</span> you should now find the entries <span class="menu">Display syslog from previous session</span> and <span class="menu">Save syslog from previous session</span>. The former displays the syslog on screen, the latter allows you to save it as a file to disk. Note that at the moment only FAT32 volumes are supported for saving the file. If you want to use a USB stick, but have plugged it in too late so that it isn't recognized yet, you can reset the machine and re-enter the boot loader menu. But again: Don't accidentally boot any operating system or the data will be lost.</p>
|
||||
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="onscreen" name="onscreen">Les sorties écran du débogueur</a></h3>
|
||||
<p><b>The on-screen debug output is useful only for debugging very specific issues and is known to have (timing) issues. Don't use it, if you don't have to.</b><br />
|
||||
This is only relevant when Haiku fails to boot on your machine and the <span class="menu">Debug syslog option</span> doesn't work for some reason. Before the Haiku boot logo appears, hold <span class="key">SHIFT</span> to enter the boot loader menu. Select <span class="menu">Select safe mode options</span>. Near the bottom, <span class="menu">[ ] Enable on screen debug output</span> will be listed. (Note: The other options could be enabled in an attempt to boot Haiku. If Haiku will boot only when one or more options are activated, be sure to mention which ones.)<br />
|
||||
Finally select <span class="menu">Return to main menu</span> and then <span class="menu">Continue booting</span>.<br />
|
||||
One or more pages of text will display on the screen, only the last few lines need to be included on your ticket. There's more information on the <a href="../../../userguide/fr/bootloader.html">Boot Loader</a>.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="hardware" name="hardware">Bogues liés au matériel ou aux pilotes</a></h2>
|
||||
<p>Lorsque le bogue concerne un matériel ou son pilote, veuillez attacher au rapport, un fichier texte contenant les renseignements suivants :</p>
|
||||
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td>- <span class="cli">listdev</span></td><td> </td><td>Fait une liste détaillée de votre matériel, en y incluant les identifiants des périphériques PCI et de leurs fabriquants, à la manière de <span class="cli">lshw</span> ou <span class="cli">lspci</span> dans GNU/Linux.</td></tr>
|
||||
<tr><td>- <span class="cli">listusb -v</span></td><td> </td><td>Fait comme <span class="cli">lsusb</span> en supposant que c'est un problème lié à l'USB.</td></tr>
|
||||
<tr><td>- <span class="cli">open /var/log/syslog</span></td><td> </td><td>Le journal système principal utilisé par Haiku, semblable à celui de l'écran de débogage pendant le démarrage. Avec la commande <span class="cli">open</span>, vous pouvez modifier ce journal dans un éditeur de texte pour n'en conserver que la partie la plus pertinente.</td></tr>
|
||||
<tr><td class="onelinetop">- <span class="cli">listimage | grep drivers/</span></td><td> </td><td>Liste tous les drivers utilisés.</td></tr>
|
||||
<tr><td>- <span class="cli">ints</span></td><td> </td><td>Seulement disponible dans le <i>mode débogage du noyau</i> (voir ci-dessous). Montre l'utilisation des interruptions.
|
||||
Il ne devrait pas y avoir trop d'interruptions partagées par plusieurs périphériques.</td></tr>
|
||||
<tr><td colspan="3">- Les sorties écran du débogueur (une option de mode sans échec du démarrage).</td></tr>
|
||||
</table>
|
||||
|
||||
<p>Les 4 premières commandes sont à exécuter dans le Terminal. Si vous ajoutez <span class="cli"> > sortie.txt</span> après une commande, sa sortie sera redirigée dans un fichier texte nommé « sortie.txt » que vous pourrez attachez à votre rapport de bogue ou e-mail.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="next" name="next">Et après ?</a></h2>
|
||||
<p>Une fois le bogue rapporté, un développeur le consultera et essayera de le cataloguer. Retenez que tous les développeurs sont des volontaires; un long délai avant réponse peut s’écouler après le rapport de bogue. L’ajout de nouvelles informations une fois celles-ci disponibles peut généralement permettre à un bogue d’être analysé plus rapidement. Néanmoins, n’essayez pas de « faire remonter » un bogue en ajoutant des commentaires non pertinents.</p>
|
||||
<p>N’oubliez pas, le rapport d’un bogue ne se limite pas à sa soumission. Une fois cette tâche faite, vous ferez partie du processus de développement de Haiku. Les développeurs pourront vous poser des question pour essayer de résoudre votre bogue. Merci de rester disponible pour y répondre. Vous pourrez considérer votre travail « terminé » quand le bogue sera marqué comme étant « corrigé ».</p>
|
||||
|
||||
|
||||
@@ -4,11 +4,12 @@
|
||||
<head>
|
||||
<!--
|
||||
*
|
||||
* Copyright 2008-2009, Haiku. All rights reserved.
|
||||
* Copyright 2008-2010, Haiku. All rights reserved.
|
||||
* Distributed under the terms of the MIT License.
|
||||
*
|
||||
* Authors:
|
||||
* Niels Reedijk and Matt Madia who wrote http://dev.haiku-os.org/wiki
|
||||
* Niels Reedijk, Matt Madia and Ingo Weinhold who wrote
|
||||
* http://dev.haiku-os.org/wiki/ and http://dev.haiku-os.org/wiki/ReportingBugs
|
||||
* Humdinger <[email protected]>
|
||||
*
|
||||
-->
|
||||
@@ -47,49 +48,109 @@
|
||||
<div>
|
||||
<div class="box-info">La traduzione di questa pagina non è stata completata. Per questo motivo le parti non tradotte sono visibili in inglese.</div>
|
||||
|
||||
<table class="index" id="index" summary="index">
|
||||
<tr class="heading"><td>Reporting bugs</td></tr>
|
||||
<tr class="index"><td><a href="#account">Getting a Trac account</a><br />
|
||||
<a href="#report">Creating a bug report</a><br />
|
||||
<a href="#app">Application bugs</a><br />
|
||||
<a href="#server">Server bugs</a><br />
|
||||
<a href="#kernel">Kernel bugs</a><br />
|
||||
<a href="#kdl">Kernel Debugging Land - KDL</a><br />
|
||||
<a href="#syslog">Syslog</a><br />
|
||||
<a href="#onscreen">On screen debug output</a><br />
|
||||
<a href="#hardware">Hardware/Driver bugs</a><br />
|
||||
<a href="#next">What's next?</a></td></tr>
|
||||
</table>
|
||||
|
||||
<h1>Reporting bugs</h1>
|
||||
|
||||
<p>Since our developers are unable to test every hardware combination, nor every different way of interacting with the operating system, we are relying on users to give us some input on how things work at their end. Since Haiku is still quite young, it's very likely that you will encounter bugs. We thank you for taking the time to report these. Together we can improve Haiku, bit by bit.</p>
|
||||
<p>To keep our bugtracker effective, it's essential to abide by the <a href="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">Bug Tracker Etiquette</a>.</p>
|
||||
|
||||
<h2>Getting a Trac account</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="account" name="accout">Getting a Trac account</a></h2>
|
||||
<p>To file a ticket, you need to have an account at <a href="http://dev.haiku-os.org/register" title="Register at Haiku's Bugtracker">Haiku's Bugtracker</a>.<br />
|
||||
When creating a new account, be certain to <b>provide your email address</b> as it is necessary to obtain basic ticket modification privileges. Be sure to <b>check your spam folder</b> shortly afterwards, as the all important verification mail often ends up there.</p>
|
||||
|
||||
<h2>Creating a bug report</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="report" name="report">Creating a bug report</a></h2>
|
||||
<p>Before reporting a bug, please <a href="http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority">make sure</a> that it does not yet exist. You can also use the <a href="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">search</a> function for this.<br />
|
||||
After you have established that it's a unique bug, make your information as accurate as possible:</p>
|
||||
<ul>
|
||||
<li><p>Attempt to reproduce your issue on the current revision of Haiku. Pre-built images for testing purposes are <a href="http://haiku-files.org/">available</a>.</p></li>
|
||||
<li><p>Include basic information such as how you are testing Haiku (on real hardware, on VMWare, on QEMU, etc.).</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in '<i>About This System...</i>' from the Deskbar menu.</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in <span class="menu">About Haiku...</span> from the Deskbar menu. Also mention what kind of Haiku build you are testing (gcc2, gcc4, gcc2hybrid, gcc4hybrid). The downloadable images are named accordingly, for a self-built image you should know how you built it.</p></li>
|
||||
<li><p>Describe the problem you are experiencing. Try to be as accurate as you can: describe the actual behavior, and the behavior you expected.</p></li>
|
||||
<li><p>Describe what steps you need to perform in order to expose the bug. This will help developers reproduce the bug.</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to make a screen shot (the <span class="key">PRINT</span> key saves a <acronym title="Portable Network Graphics image format">PNG</acronym> in <span class="path">/boot/home/</span>).</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to take a screenshot by pressing the <span class="key">PRINT</span> key.</p></li>
|
||||
</ul>
|
||||
|
||||
<h3>Software Bugs</h3>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. Entering <span class="cli">bt</span> into the launched debug Terminal, you create a "backtrace" that you should copy into your bug report.</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="app" name="app">Application bugs</a></h2>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. This will open a Terminal window with gdb (the GNU debugger) running in it. Entering <span class="cli">bt</span>, you create a "backtrace" that you should copy in its entirety (including the part before you entered the <span class="cli">bt</span> command) and attach it to the ticket.</p>
|
||||
|
||||
<h3>Hardware Bugs</h3>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information:</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="server" name="server">Server bugs</a></h2>
|
||||
<p>When vital servers like the app server, the registrar or the input server crash, you won't see the usual crash alert. Instead the whole screen will be cleared white and a gdb session will be started, its output appearing directly on screen. Likely you will still be able to move the mouse, which will overwrite the white and gdb output on screen. Applications still running (like ProcessController or the clock in the Deskbar) might also draw over the debugger output on screen.<br />
|
||||
Besides everything being more ugly and inconvenient, basically the same applies as for application bugs. Most importantly procure a back trace (<span class="cli">bt</span> command). You may need to take a picture of the screen with a digital camera, since you won't be able to copy the text anywhere.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kernel" name="kernel">Kernel bugs</a></h2>
|
||||
<p>Kernel bugs are usual the ones with the most severe effects while at the same time being the hardest to debug. There are different kinds of symptoms, which most likely point to a kernel or driver issue:</p>
|
||||
<ul>
|
||||
<li><span class="cli">listdev</span> - a detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</li>
|
||||
<li><span class="cli">listusb -v</span> - assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</li>
|
||||
<li><span class="cli">open /var/log/syslog</span> - the primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</li>
|
||||
<li><span class="cli">listimage | grep drivers/</span> - lists all used drivers.</li>
|
||||
<li><span class="cli">ints</span> - only available within <i>Kernel Debugging Land</i> (see below). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</li>
|
||||
<li><p>The system enters kernel debugging land (KDL) on its own volition. The upper part of the screen is cleared white and several lines of text are printed on it. The second line says "<i>Welcome to Kernel Debugging Land...</i>", the one above it states the immediate reason for entering KDL.</p></li>
|
||||
<li><p>The system reboots spontaneously.</p></li>
|
||||
<li><p>The system freezes completely. You can't move the mouse and no application draws anything anymore. An important test in that situation is, whether you still can enter KDL via the shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards). Wait at least a minute to see, if anything happens.</p></li>
|
||||
<li><p>The system doesn't boot up correctly. It may reboot spontaneously or stop at some point (e.g. at some icon of the boot screen). In the latter case also try <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.</p></li>
|
||||
<li><p>The whole system or some piece of hardware doesn't behave correctly. For example, it could be very slow, errors occur, or something doesn't work at all. If some hardware doesn't work at all, the first obvious check is whether Haiku supports it at all at the moment (e.g. ask on a mailing list or a forum).</p></li>
|
||||
</ul>
|
||||
<p>You enter these commands into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
<p>Note that while only the last point seems to indicate hardware relation, all the other symptoms could be caused by a bug in a hardware driver as well. If you have a suspicion what piece of hardware or corresponding driver might have to do with the problem, check whether removing/disabling the hardware or the driver makes a difference. For example, if you suspect Wifi you may find that your BIOS has an option to disable it. Or if not, you could remove the responsible Wifi driver from your Haiku installation (in <span class="path">/boot/system/add-ons/kernel/drivers/bin</span>).</p>
|
||||
|
||||
<h3>Kernel Debugging Land - KDL</h3>
|
||||
<p>When some very low level system component crashed, you may end up in the kernel debugger. It can also be entered deliberately with <span class="key">ALT</span><span class="key">SysReq</span><span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards).</p>
|
||||
<ul>
|
||||
<li><span class="cli">co</span> - will exit KDL and continue normal system operation, if possible.</li>
|
||||
<li><span class="cli">int</span> - will show interrupt usage (as described above).</li>
|
||||
<li><span class="cli">bt</span> - shows a backtrace, detailing where exactly the crash happened.</li>
|
||||
</ul>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kdl" name="kdl">Kernel Debugging Land - KDL</a></h3>
|
||||
<p>If the system hasn't entered KDL by itself, you can do that intentionally by invoking the keyboard shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.<br />
|
||||
Note that in KDL your keyboard may not work. PS/2 keyboards always do, USB keyboards connected via UHCI controllers do only, if one has entered KDL via the keyboard shortcut at least once. USB OHCI is not supported at the moment.</p>
|
||||
<p>KDL itself is a kind of a shell. One can execute commands that print information about the system. The following commands might be of interest:</p>
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td><span class="cli">bt</span> (aka sc)</td><td> </td><td>Prints a back trace. If the system entered KDL on its on volition, always enter that one.</td></tr>
|
||||
<tr><td><span class="cli">ints</span></td><td> </td><td>Shows the handled and unhandled hardware interrupts.</td></tr>
|
||||
<tr><td class="onelinetop"><span class="cli">co</span> (aka continue)</td><td> </td><td>Leaves the kernel debugger and continues normal operation of the system, if that is possible.</td></tr>
|
||||
<tr><td><span class="cli">reboot</span></td><td> </td><td>Reboots the system immediately. You will lose all unsaved data and even those that have been saved, but have not yet been written back to disk.</td></tr>
|
||||
</table>
|
||||
<p>For more information, see the article <a href="http://www.haiku-os.org/documents/dev/welcome_to_kernel_debugging_land">Welcome to Kernel Debugging Land</a>.</p>
|
||||
<p>The KDL output is written to the serial port (if you have one, a respective cable, and a second computer to connect with, you can capture the output there via a terminal program) and to the syslog. If you can't leave KDL it won't be written to the syslog file, though. There's a boot loader debug option that allows you to capture it nonetheless (see below).</p>
|
||||
|
||||
<h2>What's next?</h2>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="syslog" name="syslog">Syslog</a></h3>
|
||||
<p><b>This is the preferred method for gaining information from a non-booting system.</b><br />
|
||||
The syslog (short for system log) contains valuable information about what has happened in your system, including the output of KDL sessions. It's usually a good idea to attach it to the kernel related Trac ticket. The syslog is written to the file <span class="path">/boot/common/var/log/syslog</span>. Since writing to a file requires a working system, the most recent output might not have made it to the syslog when a kernel problem occurs (particularly on spontaneous reboots or uncontinuable KDL sessions).</p>
|
||||
<p>The option <span class="menu">Enable debug syslog</span> in the boot loader's <span class="menu">Debug menu</span> makes the syslog somewhat persistent in memory. By default the option is enabled. "Somewhat persistent" means that it survives a reset and will still be accessible when you enter the boot loader menu directly afterwards. Booting an operating system (Haiku definitely, others likely) destroys the information, though. So you have to enter the boot loader menu by holding down <span class="key">SHIFT</span> while booting.<br />
|
||||
In the boot loader's <span class="menu">Debug menu</span> you should now find the entries <span class="menu">Display syslog from previous session</span> and <span class="menu">Save syslog from previous session</span>. The former displays the syslog on screen, the latter allows you to save it as a file to disk. Note that at the moment only FAT32 volumes are supported for saving the file. If you want to use a USB stick, but have plugged it in too late so that it isn't recognized yet, you can reset the machine and re-enter the boot loader menu. But again: Don't accidentally boot any operating system or the data will be lost.</p>
|
||||
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="onscreen" name="onscreen">On screen debug output</a></h3>
|
||||
<p><b>The on-screen debug output is useful only for debugging very specific issues and is known to have (timing) issues. Don't use it, if you don't have to.</b><br />
|
||||
This is only relevant when Haiku fails to boot on your machine and the <span class="menu">Debug syslog option</span> doesn't work for some reason. Before the Haiku boot logo appears, hold <span class="key">SHIFT</span> to enter the boot loader menu. Select <span class="menu">Select safe mode options</span>. Near the bottom, <span class="menu">[ ] Enable on screen debug output</span> will be listed. (Note: The other options could be enabled in an attempt to boot Haiku. If Haiku will boot only when one or more options are activated, be sure to mention which ones.)<br />
|
||||
Finally select <span class="menu">Return to main menu</span> and then <span class="menu">Continue booting</span>.<br />
|
||||
One or more pages of text will display on the screen, only the last few lines need to be included on your ticket. There's more information on the <a href="../../../userguide/it/bootloader.html">Boot Loader</a>.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="hardware" name="hardware">Hardware/Driver bugs</a></h2>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information as text files:</p>
|
||||
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td>- <span class="cli">listdev</span></td><td> </td><td>A detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">listusb -v</span></td><td> </td><td>Assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">open /var/log/syslog</span></td><td> </td><td>The primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</td></tr>
|
||||
<tr><td class="onelinetop">- <span class="cli">listimage | grep drivers/</span></td><td> </td><td>Lists all used drivers.</td></tr>
|
||||
<tr><td>- <span class="cli">ints</span></td><td> </td><td>Only available within <i>Kernel Debugging Land</i> (see above). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</td></tr>
|
||||
<tr><td colspan="3">- On screen debug output (a safe mode boot time option).</td></tr>
|
||||
</table>
|
||||
|
||||
<p>The first four commands are entered into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="next" name="next">What's next?</a></h2>
|
||||
<p>After the bug has been reported, a developer will look at your bug and try to classify it. Remember, we are all volunteers, and as such, sometimes a bug report might go unanswered for a while. Adding new information when it becomes available usually helps getting a bug picked up quicker, but do not try to 'bump' the bug up by adding
|
||||
non-descriptive comments.</p>
|
||||
<p>Remember, reporting a bug is not something you spend a little time on and then you are done. If you reported a bug, then you are part of the Haiku development process. Developers might come up with questions while they are trying to fix your bug. Please stay around to answer these. Consider your participation 'done' when the bug is marked
|
||||
|
||||
@@ -4,11 +4,12 @@
|
||||
<head>
|
||||
<!--
|
||||
*
|
||||
* Copyright 2008-2009, Haiku. All rights reserved.
|
||||
* Copyright 2008-2010, Haiku. All rights reserved.
|
||||
* Distributed under the terms of the MIT License.
|
||||
*
|
||||
* Authors:
|
||||
* Niels Reedijk and Matt Madia who wrote http://dev.haiku-os.org/wiki
|
||||
* Niels Reedijk, Matt Madia and Ingo Weinhold who wrote
|
||||
* http://dev.haiku-os.org/wiki/ and http://dev.haiku-os.org/wiki/ReportingBugs
|
||||
* Humdinger <[email protected]>
|
||||
*
|
||||
-->
|
||||
@@ -47,49 +48,109 @@
|
||||
<div>
|
||||
<div class="box-info">The translation of this page isn't yet complete. Until it is, unfinished parts use the English original.</div>
|
||||
|
||||
<table class="index" id="index" summary="index">
|
||||
<tr class="heading"><td>Reporting bugs</td></tr>
|
||||
<tr class="index"><td><a href="#account">Getting a Trac account</a><br />
|
||||
<a href="#report">Creating a bug report</a><br />
|
||||
<a href="#app">Application bugs</a><br />
|
||||
<a href="#server">Server bugs</a><br />
|
||||
<a href="#kernel">Kernel bugs</a><br />
|
||||
<a href="#kdl">Kernel Debugging Land - KDL</a><br />
|
||||
<a href="#syslog">Syslog</a><br />
|
||||
<a href="#onscreen">On screen debug output</a><br />
|
||||
<a href="#hardware">Hardware/Driver bugs</a><br />
|
||||
<a href="#next">What's next?</a></td></tr>
|
||||
</table>
|
||||
|
||||
<h1>Reporting bugs</h1>
|
||||
|
||||
<p>Since our developers are unable to test every hardware combination, nor every different way of interacting with the operating system, we are relying on users to give us some input on how things work at their end. Since Haiku is still quite young, it's very likely that you will encounter bugs. We thank you for taking the time to report these. Together we can improve Haiku, bit by bit.</p>
|
||||
<p>To keep our bugtracker effective, it's essential to abide by the <a href="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">Bug Tracker Etiquette</a>.</p>
|
||||
|
||||
<h2>Getting a Trac account</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="account" name="accout">Getting a Trac account</a></h2>
|
||||
<p>To file a ticket, you need to have an account at <a href="http://dev.haiku-os.org/register" title="Register at Haiku's Bugtracker">Haiku's Bugtracker</a>.<br />
|
||||
When creating a new account, be certain to <b>provide your email address</b> as it is necessary to obtain basic ticket modification privileges. Be sure to <b>check your spam folder</b> shortly afterwards, as the all important verification mail often ends up there.</p>
|
||||
|
||||
<h2>Creating a bug report</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="report" name="report">Creating a bug report</a></h2>
|
||||
<p>Before reporting a bug, please <a href="http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority">make sure</a> that it does not yet exist. You can also use the <a href="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">search</a> function for this.<br />
|
||||
After you have established that it's a unique bug, make your information as accurate as possible:</p>
|
||||
<ul>
|
||||
<li><p>Attempt to reproduce your issue on the current revision of Haiku. Pre-built images for testing purposes are <a href="http://haiku-files.org/">available</a>.</p></li>
|
||||
<li><p>Include basic information such as how you are testing Haiku (on real hardware, on VMWare, on QEMU, etc.).</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in '<i>About This System...</i>' from the Deskbar menu.</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in <span class="menu">About Haiku...</span> from the Deskbar menu. Also mention what kind of Haiku build you are testing (gcc2, gcc4, gcc2hybrid, gcc4hybrid). The downloadable images are named accordingly, for a self-built image you should know how you built it.</p></li>
|
||||
<li><p>Describe the problem you are experiencing. Try to be as accurate as you can: describe the actual behavior, and the behavior you expected.</p></li>
|
||||
<li><p>Describe what steps you need to perform in order to expose the bug. This will help developers reproduce the bug.</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to make a screen shot (the <span class="key">PRINT</span> key saves a <acronym title="Portable Network Graphics image format">PNG</acronym> in <span class="path">/boot/home/</span>).</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to take a screenshot by pressing the <span class="key">PRINT</span> key.</p></li>
|
||||
</ul>
|
||||
|
||||
<h3>Software Bugs</h3>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. Entering <span class="cli">bt</span> into the launched debug Terminal, you create a "backtrace" that you should copy into your bug report.</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="app" name="app">Application bugs</a></h2>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. This will open a Terminal window with gdb (the GNU debugger) running in it. Entering <span class="cli">bt</span>, you create a "backtrace" that you should copy in its entirety (including the part before you entered the <span class="cli">bt</span> command) and attach it to the ticket.</p>
|
||||
|
||||
<h3>Hardware Bugs</h3>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information:</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="server" name="server">Server bugs</a></h2>
|
||||
<p>When vital servers like the app server, the registrar or the input server crash, you won't see the usual crash alert. Instead the whole screen will be cleared white and a gdb session will be started, its output appearing directly on screen. Likely you will still be able to move the mouse, which will overwrite the white and gdb output on screen. Applications still running (like ProcessController or the clock in the Deskbar) might also draw over the debugger output on screen.<br />
|
||||
Besides everything being more ugly and inconvenient, basically the same applies as for application bugs. Most importantly procure a back trace (<span class="cli">bt</span> command). You may need to take a picture of the screen with a digital camera, since you won't be able to copy the text anywhere.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kernel" name="kernel">Kernel bugs</a></h2>
|
||||
<p>Kernel bugs are usual the ones with the most severe effects while at the same time being the hardest to debug. There are different kinds of symptoms, which most likely point to a kernel or driver issue:</p>
|
||||
<ul>
|
||||
<li><span class="cli">listdev</span> - a detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</li>
|
||||
<li><span class="cli">listusb -v</span> - assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</li>
|
||||
<li><span class="cli">open /var/log/syslog</span> - the primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</li>
|
||||
<li><span class="cli">listimage | grep drivers/</span> - lists all used drivers.</li>
|
||||
<li><span class="cli">ints</span> - only available within <i>Kernel Debugging Land</i> (see below). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</li>
|
||||
<li><p>The system enters kernel debugging land (KDL) on its own volition. The upper part of the screen is cleared white and several lines of text are printed on it. The second line says "<i>Welcome to Kernel Debugging Land...</i>", the one above it states the immediate reason for entering KDL.</p></li>
|
||||
<li><p>The system reboots spontaneously.</p></li>
|
||||
<li><p>The system freezes completely. You can't move the mouse and no application draws anything anymore. An important test in that situation is, whether you still can enter KDL via the shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards). Wait at least a minute to see, if anything happens.</p></li>
|
||||
<li><p>The system doesn't boot up correctly. It may reboot spontaneously or stop at some point (e.g. at some icon of the boot screen). In the latter case also try <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.</p></li>
|
||||
<li><p>The whole system or some piece of hardware doesn't behave correctly. For example, it could be very slow, errors occur, or something doesn't work at all. If some hardware doesn't work at all, the first obvious check is whether Haiku supports it at all at the moment (e.g. ask on a mailing list or a forum).</p></li>
|
||||
</ul>
|
||||
<p>You enter these commands into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
<p>Note that while only the last point seems to indicate hardware relation, all the other symptoms could be caused by a bug in a hardware driver as well. If you have a suspicion what piece of hardware or corresponding driver might have to do with the problem, check whether removing/disabling the hardware or the driver makes a difference. For example, if you suspect Wifi you may find that your BIOS has an option to disable it. Or if not, you could remove the responsible Wifi driver from your Haiku installation (in <span class="path">/boot/system/add-ons/kernel/drivers/bin</span>).</p>
|
||||
|
||||
<h3>Kernel Debugging Land - KDL</h3>
|
||||
<p>When some very low level system component crashed, you may end up in the kernel debugger. It can also be entered deliberately with <span class="key">ALT</span><span class="key">SysReq</span><span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards).</p>
|
||||
<ul>
|
||||
<li><span class="cli">co</span> - will exit KDL and continue normal system operation, if possible.</li>
|
||||
<li><span class="cli">int</span> - will show interrupt usage (as described above).</li>
|
||||
<li><span class="cli">bt</span> - shows a backtrace, detailing where exactly the crash happened.</li>
|
||||
</ul>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kdl" name="kdl">Kernel Debugging Land - KDL</a></h3>
|
||||
<p>If the system hasn't entered KDL by itself, you can do that intentionally by invoking the keyboard shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.<br />
|
||||
Note that in KDL your keyboard may not work. PS/2 keyboards always do, USB keyboards connected via UHCI controllers do only, if one has entered KDL via the keyboard shortcut at least once. USB OHCI is not supported at the moment.</p>
|
||||
<p>KDL itself is a kind of a shell. One can execute commands that print information about the system. The following commands might be of interest:</p>
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td><span class="cli">bt</span> (aka sc)</td><td> </td><td>Prints a back trace. If the system entered KDL on its on volition, always enter that one.</td></tr>
|
||||
<tr><td><span class="cli">ints</span></td><td> </td><td>Shows the handled and unhandled hardware interrupts.</td></tr>
|
||||
<tr><td class="onelinetop"><span class="cli">co</span> (aka continue)</td><td> </td><td>Leaves the kernel debugger and continues normal operation of the system, if that is possible.</td></tr>
|
||||
<tr><td><span class="cli">reboot</span></td><td> </td><td>Reboots the system immediately. You will lose all unsaved data and even those that have been saved, but have not yet been written back to disk.</td></tr>
|
||||
</table>
|
||||
<p>For more information, see the article <a href="http://www.haiku-os.org/documents/dev/welcome_to_kernel_debugging_land">Welcome to Kernel Debugging Land</a>.</p>
|
||||
<p>The KDL output is written to the serial port (if you have one, a respective cable, and a second computer to connect with, you can capture the output there via a terminal program) and to the syslog. If you can't leave KDL it won't be written to the syslog file, though. There's a boot loader debug option that allows you to capture it nonetheless (see below).</p>
|
||||
|
||||
<h2>What's next?</h2>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="syslog" name="syslog">Syslog</a></h3>
|
||||
<p><b>This is the preferred method for gaining information from a non-booting system.</b><br />
|
||||
The syslog (short for system log) contains valuable information about what has happened in your system, including the output of KDL sessions. It's usually a good idea to attach it to the kernel related Trac ticket. The syslog is written to the file <span class="path">/boot/common/var/log/syslog</span>. Since writing to a file requires a working system, the most recent output might not have made it to the syslog when a kernel problem occurs (particularly on spontaneous reboots or uncontinuable KDL sessions).</p>
|
||||
<p>The option <span class="menu">Enable debug syslog</span> in the boot loader's <span class="menu">Debug menu</span> makes the syslog somewhat persistent in memory. By default the option is enabled. "Somewhat persistent" means that it survives a reset and will still be accessible when you enter the boot loader menu directly afterwards. Booting an operating system (Haiku definitely, others likely) destroys the information, though. So you have to enter the boot loader menu by holding down <span class="key">SHIFT</span> while booting.<br />
|
||||
In the boot loader's <span class="menu">Debug menu</span> you should now find the entries <span class="menu">Display syslog from previous session</span> and <span class="menu">Save syslog from previous session</span>. The former displays the syslog on screen, the latter allows you to save it as a file to disk. Note that at the moment only FAT32 volumes are supported for saving the file. If you want to use a USB stick, but have plugged it in too late so that it isn't recognized yet, you can reset the machine and re-enter the boot loader menu. But again: Don't accidentally boot any operating system or the data will be lost.</p>
|
||||
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="onscreen" name="onscreen">On screen debug output</a></h3>
|
||||
<p><b>The on-screen debug output is useful only for debugging very specific issues and is known to have (timing) issues. Don't use it, if you don't have to.</b><br />
|
||||
This is only relevant when Haiku fails to boot on your machine and the <span class="menu">Debug syslog option</span> doesn't work for some reason. Before the Haiku boot logo appears, hold <span class="key">SHIFT</span> to enter the boot loader menu. Select <span class="menu">Select safe mode options</span>. Near the bottom, <span class="menu">[ ] Enable on screen debug output</span> will be listed. (Note: The other options could be enabled in an attempt to boot Haiku. If Haiku will boot only when one or more options are activated, be sure to mention which ones.)<br />
|
||||
Finally select <span class="menu">Return to main menu</span> and then <span class="menu">Continue booting</span>.<br />
|
||||
One or more pages of text will display on the screen, only the last few lines need to be included on your ticket. There's more information on the <a href="../../../userguide/jp/bootloader.html">Boot Loader</a>.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="hardware" name="hardware">Hardware/Driver bugs</a></h2>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information as text files:</p>
|
||||
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td>- <span class="cli">listdev</span></td><td> </td><td>A detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">listusb -v</span></td><td> </td><td>Assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">open /var/log/syslog</span></td><td> </td><td>The primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</td></tr>
|
||||
<tr><td class="onelinetop">- <span class="cli">listimage | grep drivers/</span></td><td> </td><td>Lists all used drivers.</td></tr>
|
||||
<tr><td>- <span class="cli">ints</span></td><td> </td><td>Only available within <i>Kernel Debugging Land</i> (see above). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</td></tr>
|
||||
<tr><td colspan="3">- On screen debug output (a safe mode boot time option).</td></tr>
|
||||
</table>
|
||||
|
||||
<p>The first four commands are entered into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="next" name="next">What's next?</a></h2>
|
||||
<p>After the bug has been reported, a developer will look at your bug and try to classify it. Remember, we are all volunteers, and as such, sometimes a bug report might go unanswered for a while. Adding new information when it becomes available usually helps getting a bug picked up quicker, but do not try to 'bump' the bug up by adding
|
||||
non-descriptive comments.</p>
|
||||
<p>Remember, reporting a bug is not something you spend a little time on and then you are done. If you reported a bug, then you are part of the Haiku development process. Developers might come up with questions while they are trying to fix your bug. Please stay around to answer these. Consider your participation 'done' when the bug is marked
|
||||
|
||||
@@ -4,11 +4,12 @@
|
||||
<head>
|
||||
<!--
|
||||
*
|
||||
* Copyright 2008-2009, Haiku. All rights reserved.
|
||||
* Copyright 2008-2010, Haiku. All rights reserved.
|
||||
* Distributed under the terms of the MIT License.
|
||||
*
|
||||
* Authors:
|
||||
* Niels Reedijk and Matt Madia who wrote http://dev.haiku-os.org/wiki
|
||||
* Niels Reedijk, Matt Madia and Ingo Weinhold who wrote
|
||||
* http://dev.haiku-os.org/wiki/ and http://dev.haiku-os.org/wiki/ReportingBugs
|
||||
* Humdinger <[email protected]>
|
||||
*
|
||||
-->
|
||||
@@ -47,49 +48,109 @@
|
||||
<div>
|
||||
<div class="box-info">The translation of this page isn't yet complete. Until it is, unfinished parts use the English original.</div>
|
||||
|
||||
<table class="index" id="index" summary="index">
|
||||
<tr class="heading"><td>Reporting bugs</td></tr>
|
||||
<tr class="index"><td><a href="#account">Getting a Trac account</a><br />
|
||||
<a href="#report">Creating a bug report</a><br />
|
||||
<a href="#app">Application bugs</a><br />
|
||||
<a href="#server">Server bugs</a><br />
|
||||
<a href="#kernel">Kernel bugs</a><br />
|
||||
<a href="#kdl">Kernel Debugging Land - KDL</a><br />
|
||||
<a href="#syslog">Syslog</a><br />
|
||||
<a href="#onscreen">On screen debug output</a><br />
|
||||
<a href="#hardware">Hardware/Driver bugs</a><br />
|
||||
<a href="#next">What's next?</a></td></tr>
|
||||
</table>
|
||||
|
||||
<h1>Reporting bugs</h1>
|
||||
|
||||
<p>Since our developers are unable to test every hardware combination, nor every different way of interacting with the operating system, we are relying on users to give us some input on how things work at their end. Since Haiku is still quite young, it's very likely that you will encounter bugs. We thank you for taking the time to report these. Together we can improve Haiku, bit by bit.</p>
|
||||
<p>To keep our bugtracker effective, it's essential to abide by the <a href="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">Bug Tracker Etiquette</a>.</p>
|
||||
|
||||
<h2>Getting a Trac account</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="account" name="accout">Getting a Trac account</a></h2>
|
||||
<p>To file a ticket, you need to have an account at <a href="http://dev.haiku-os.org/register" title="Register at Haiku's Bugtracker">Haiku's Bugtracker</a>.<br />
|
||||
When creating a new account, be certain to <b>provide your email address</b> as it is necessary to obtain basic ticket modification privileges. Be sure to <b>check your spam folder</b> shortly afterwards, as the all important verification mail often ends up there.</p>
|
||||
|
||||
<h2>Creating a bug report</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="report" name="report">Creating a bug report</a></h2>
|
||||
<p>Before reporting a bug, please <a href="http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority">make sure</a> that it does not yet exist. You can also use the <a href="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">search</a> function for this.<br />
|
||||
After you have established that it's a unique bug, make your information as accurate as possible:</p>
|
||||
<ul>
|
||||
<li><p>Attempt to reproduce your issue on the current revision of Haiku. Pre-built images for testing purposes are <a href="http://haiku-files.org/">available</a>.</p></li>
|
||||
<li><p>Include basic information such as how you are testing Haiku (on real hardware, on VMWare, on QEMU, etc.).</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in '<i>About This System...</i>' from the Deskbar menu.</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in <span class="menu">About Haiku...</span> from the Deskbar menu. Also mention what kind of Haiku build you are testing (gcc2, gcc4, gcc2hybrid, gcc4hybrid). The downloadable images are named accordingly, for a self-built image you should know how you built it.</p></li>
|
||||
<li><p>Describe the problem you are experiencing. Try to be as accurate as you can: describe the actual behavior, and the behavior you expected.</p></li>
|
||||
<li><p>Describe what steps you need to perform in order to expose the bug. This will help developers reproduce the bug.</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to make a screen shot (the <span class="key">PRINT</span> key saves a <acronym title="Portable Network Graphics image format">PNG</acronym> in <span class="path">/boot/home/</span>).</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to take a screenshot by pressing the <span class="key">PRINT</span> key.</p></li>
|
||||
</ul>
|
||||
|
||||
<h3>Software Bugs</h3>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. Entering <span class="cli">bt</span> into the launched debug Terminal, you create a "backtrace" that you should copy into your bug report.</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="app" name="app">Application bugs</a></h2>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. This will open a Terminal window with gdb (the GNU debugger) running in it. Entering <span class="cli">bt</span>, you create a "backtrace" that you should copy in its entirety (including the part before you entered the <span class="cli">bt</span> command) and attach it to the ticket.</p>
|
||||
|
||||
<h3>Hardware Bugs</h3>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information:</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="server" name="server">Server bugs</a></h2>
|
||||
<p>When vital servers like the app server, the registrar or the input server crash, you won't see the usual crash alert. Instead the whole screen will be cleared white and a gdb session will be started, its output appearing directly on screen. Likely you will still be able to move the mouse, which will overwrite the white and gdb output on screen. Applications still running (like ProcessController or the clock in the Deskbar) might also draw over the debugger output on screen.<br />
|
||||
Besides everything being more ugly and inconvenient, basically the same applies as for application bugs. Most importantly procure a back trace (<span class="cli">bt</span> command). You may need to take a picture of the screen with a digital camera, since you won't be able to copy the text anywhere.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kernel" name="kernel">Kernel bugs</a></h2>
|
||||
<p>Kernel bugs are usual the ones with the most severe effects while at the same time being the hardest to debug. There are different kinds of symptoms, which most likely point to a kernel or driver issue:</p>
|
||||
<ul>
|
||||
<li><span class="cli">listdev</span> - a detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</li>
|
||||
<li><span class="cli">listusb -v</span> - assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</li>
|
||||
<li><span class="cli">open /var/log/syslog</span> - the primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</li>
|
||||
<li><span class="cli">listimage | grep drivers/</span> - lists all used drivers.</li>
|
||||
<li><span class="cli">ints</span> - only available within <i>Kernel Debugging Land</i> (see below). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</li>
|
||||
<li><p>The system enters kernel debugging land (KDL) on its own volition. The upper part of the screen is cleared white and several lines of text are printed on it. The second line says "<i>Welcome to Kernel Debugging Land...</i>", the one above it states the immediate reason for entering KDL.</p></li>
|
||||
<li><p>The system reboots spontaneously.</p></li>
|
||||
<li><p>The system freezes completely. You can't move the mouse and no application draws anything anymore. An important test in that situation is, whether you still can enter KDL via the shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards). Wait at least a minute to see, if anything happens.</p></li>
|
||||
<li><p>The system doesn't boot up correctly. It may reboot spontaneously or stop at some point (e.g. at some icon of the boot screen). In the latter case also try <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.</p></li>
|
||||
<li><p>The whole system or some piece of hardware doesn't behave correctly. For example, it could be very slow, errors occur, or something doesn't work at all. If some hardware doesn't work at all, the first obvious check is whether Haiku supports it at all at the moment (e.g. ask on a mailing list or a forum).</p></li>
|
||||
</ul>
|
||||
<p>You enter these commands into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
<p>Note that while only the last point seems to indicate hardware relation, all the other symptoms could be caused by a bug in a hardware driver as well. If you have a suspicion what piece of hardware or corresponding driver might have to do with the problem, check whether removing/disabling the hardware or the driver makes a difference. For example, if you suspect Wifi you may find that your BIOS has an option to disable it. Or if not, you could remove the responsible Wifi driver from your Haiku installation (in <span class="path">/boot/system/add-ons/kernel/drivers/bin</span>).</p>
|
||||
|
||||
<h3>Kernel Debugging Land - KDL</h3>
|
||||
<p>When some very low level system component crashed, you may end up in the kernel debugger. It can also be entered deliberately with <span class="key">ALT</span><span class="key">SysReq</span><span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards).</p>
|
||||
<ul>
|
||||
<li><span class="cli">co</span> - will exit KDL and continue normal system operation, if possible.</li>
|
||||
<li><span class="cli">int</span> - will show interrupt usage (as described above).</li>
|
||||
<li><span class="cli">bt</span> - shows a backtrace, detailing where exactly the crash happened.</li>
|
||||
</ul>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kdl" name="kdl">Kernel Debugging Land - KDL</a></h3>
|
||||
<p>If the system hasn't entered KDL by itself, you can do that intentionally by invoking the keyboard shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.<br />
|
||||
Note that in KDL your keyboard may not work. PS/2 keyboards always do, USB keyboards connected via UHCI controllers do only, if one has entered KDL via the keyboard shortcut at least once. USB OHCI is not supported at the moment.</p>
|
||||
<p>KDL itself is a kind of a shell. One can execute commands that print information about the system. The following commands might be of interest:</p>
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td><span class="cli">bt</span> (aka sc)</td><td> </td><td>Prints a back trace. If the system entered KDL on its on volition, always enter that one.</td></tr>
|
||||
<tr><td><span class="cli">ints</span></td><td> </td><td>Shows the handled and unhandled hardware interrupts.</td></tr>
|
||||
<tr><td class="onelinetop"><span class="cli">co</span> (aka continue)</td><td> </td><td>Leaves the kernel debugger and continues normal operation of the system, if that is possible.</td></tr>
|
||||
<tr><td><span class="cli">reboot</span></td><td> </td><td>Reboots the system immediately. You will lose all unsaved data and even those that have been saved, but have not yet been written back to disk.</td></tr>
|
||||
</table>
|
||||
<p>For more information, see the article <a href="http://www.haiku-os.org/documents/dev/welcome_to_kernel_debugging_land">Welcome to Kernel Debugging Land</a>.</p>
|
||||
<p>The KDL output is written to the serial port (if you have one, a respective cable, and a second computer to connect with, you can capture the output there via a terminal program) and to the syslog. If you can't leave KDL it won't be written to the syslog file, though. There's a boot loader debug option that allows you to capture it nonetheless (see below).</p>
|
||||
|
||||
<h2>What's next?</h2>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="syslog" name="syslog">Syslog</a></h3>
|
||||
<p><b>This is the preferred method for gaining information from a non-booting system.</b><br />
|
||||
The syslog (short for system log) contains valuable information about what has happened in your system, including the output of KDL sessions. It's usually a good idea to attach it to the kernel related Trac ticket. The syslog is written to the file <span class="path">/boot/common/var/log/syslog</span>. Since writing to a file requires a working system, the most recent output might not have made it to the syslog when a kernel problem occurs (particularly on spontaneous reboots or uncontinuable KDL sessions).</p>
|
||||
<p>The option <span class="menu">Enable debug syslog</span> in the boot loader's <span class="menu">Debug menu</span> makes the syslog somewhat persistent in memory. By default the option is enabled. "Somewhat persistent" means that it survives a reset and will still be accessible when you enter the boot loader menu directly afterwards. Booting an operating system (Haiku definitely, others likely) destroys the information, though. So you have to enter the boot loader menu by holding down <span class="key">SHIFT</span> while booting.<br />
|
||||
In the boot loader's <span class="menu">Debug menu</span> you should now find the entries <span class="menu">Display syslog from previous session</span> and <span class="menu">Save syslog from previous session</span>. The former displays the syslog on screen, the latter allows you to save it as a file to disk. Note that at the moment only FAT32 volumes are supported for saving the file. If you want to use a USB stick, but have plugged it in too late so that it isn't recognized yet, you can reset the machine and re-enter the boot loader menu. But again: Don't accidentally boot any operating system or the data will be lost.</p>
|
||||
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="onscreen" name="onscreen">On screen debug output</a></h3>
|
||||
<p><b>The on-screen debug output is useful only for debugging very specific issues and is known to have (timing) issues. Don't use it, if you don't have to.</b><br />
|
||||
This is only relevant when Haiku fails to boot on your machine and the <span class="menu">Debug syslog option</span> doesn't work for some reason. Before the Haiku boot logo appears, hold <span class="key">SHIFT</span> to enter the boot loader menu. Select <span class="menu">Select safe mode options</span>. Near the bottom, <span class="menu">[ ] Enable on screen debug output</span> will be listed. (Note: The other options could be enabled in an attempt to boot Haiku. If Haiku will boot only when one or more options are activated, be sure to mention which ones.)<br />
|
||||
Finally select <span class="menu">Return to main menu</span> and then <span class="menu">Continue booting</span>.<br />
|
||||
One or more pages of text will display on the screen, only the last few lines need to be included on your ticket. There's more information on the <a href="../../../userguide/pt_PT/bootloader.html">Boot Loader</a>.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="hardware" name="hardware">Hardware/Driver bugs</a></h2>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information as text files:</p>
|
||||
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td>- <span class="cli">listdev</span></td><td> </td><td>A detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">listusb -v</span></td><td> </td><td>Assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">open /var/log/syslog</span></td><td> </td><td>The primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</td></tr>
|
||||
<tr><td class="onelinetop">- <span class="cli">listimage | grep drivers/</span></td><td> </td><td>Lists all used drivers.</td></tr>
|
||||
<tr><td>- <span class="cli">ints</span></td><td> </td><td>Only available within <i>Kernel Debugging Land</i> (see above). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</td></tr>
|
||||
<tr><td colspan="3">- On screen debug output (a safe mode boot time option).</td></tr>
|
||||
</table>
|
||||
|
||||
<p>The first four commands are entered into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="next" name="next">What's next?</a></h2>
|
||||
<p>After the bug has been reported, a developer will look at your bug and try to classify it. Remember, we are all volunteers, and as such, sometimes a bug report might go unanswered for a while. Adding new information when it becomes available usually helps getting a bug picked up quicker, but do not try to 'bump' the bug up by adding
|
||||
non-descriptive comments.</p>
|
||||
<p>Remember, reporting a bug is not something you spend a little time on and then you are done. If you reported a bug, then you are part of the Haiku development process. Developers might come up with questions while they are trying to fix your bug. Please stay around to answer these. Consider your participation 'done' when the bug is marked
|
||||
|
||||
@@ -4,11 +4,12 @@
|
||||
<head>
|
||||
<!--
|
||||
*
|
||||
* Copyright 2008-2009, Haiku. All rights reserved.
|
||||
* Copyright 2008-2010, Haiku. All rights reserved.
|
||||
* Distributed under the terms of the MIT License.
|
||||
*
|
||||
* Authors:
|
||||
* Niels Reedijk and Matt Madia who wrote http://dev.haiku-os.org/wiki
|
||||
* Niels Reedijk, Matt Madia and Ingo Weinhold who wrote
|
||||
* http://dev.haiku-os.org/wiki/ and http://dev.haiku-os.org/wiki/ReportingBugs
|
||||
* Humdinger <[email protected]>
|
||||
* Translators:
|
||||
* Michael Smirnov
|
||||
@@ -23,7 +24,7 @@
|
||||
<body>
|
||||
|
||||
<div id="banner">
|
||||
<div><span>Руководство пользователя</span></div>
|
||||
<div><span>User guide</span></div>
|
||||
</div>
|
||||
|
||||
<div class="nav">
|
||||
@@ -48,50 +49,111 @@
|
||||
|
||||
<div id="content">
|
||||
<div>
|
||||
<div class="box-info">The translation of this page isn't yet complete. Until it is, unfinished parts use the English original.</div>
|
||||
|
||||
<table class="index" id="index" summary="index">
|
||||
<tr class="heading"><td>Отчёт об ошибках (багах)</td></tr>
|
||||
<tr class="index"><td><a href="#account">Getting a Trac account</a><br />
|
||||
<a href="#report">Creating a bug report</a><br />
|
||||
<a href="#app">Application bugs</a><br />
|
||||
<a href="#server">Server bugs</a><br />
|
||||
<a href="#kernel">Kernel bugs</a><br />
|
||||
<a href="#kdl">Kernel Debugging Land - KDL</a><br />
|
||||
<a href="#syslog">Syslog</a><br />
|
||||
<a href="#onscreen">On screen debug output</a><br />
|
||||
<a href="#hardware">Hardware/Driver bugs</a><br />
|
||||
<a href="#next">What's next?</a></td></tr>
|
||||
</table>
|
||||
|
||||
<h1>Отчёт об ошибках (багах)</h1>
|
||||
|
||||
<p>Так как наши разработчики не в состоянии проверить все комбинации компьютерных комплектующих и программных средств при их работе в Haiku, то мы полагаемся на пользователей, надеясь, что вы сообщите нам об обнаруженных ошибках, которых, ввиду молодости Haiku, может быть немало. Мы будем благодарны вам за потраченное на составление отчёта время, только вместе мы сможем сделать Haiku лучше.</p>
|
||||
<p>Для продуктивной работы c системой отслеживания ошибок (багтрекером) важно соблюдать принятый в нём <a href="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">этикет</a>.</p>
|
||||
|
||||
<h2>Получение аккаунта в Trac</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="account" name="accout">Getting a Trac account</a></h2>
|
||||
<p>Чтобы создать новый багрепорт, у вас должен быть заведён аккаунт в <a href="http://dev.haiku-os.org/register" title="Регистрация в багтрекере Haiku">багтрекере Haiku</a>.<br />
|
||||
Создавая новый аккаунт <b>обязательно введите адрес электронной почты</b>, так как на него будут приходить все сведения, связанные с изменением багрепорта. Убедитесь, что приходящие с багтрекера письма <b>не помечаются как спам,</b> так как это вполне возможно.</p>
|
||||
|
||||
<h2>Создание отчёта об ошибках</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="report" name="report">Creating a bug report</a></h2>
|
||||
<p>Прежде чем сообщать об ошибке, пожалуйста, <a href="http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Eтекст,+который+вы+ищите&order=priority">убедитесь</a>, что аналогичного багрепорта ещё не существует. Для этого также можно воспользоваться функцией <a href="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">поиска</a>.<br />
|
||||
После того как вы установили, что подобных багрепортов не имеется, то оформите вашу информацию как можно точнее:</p>
|
||||
<ul>
|
||||
<li><p>Attempt to reproduce your issue on the current revision of Haiku. Pre-built images for testing purposes are <a href="http://haiku-files.org/">available</a>.</p></li>
|
||||
<li><p>Включите информацию о том как вы тестируете Haiku (на реальном компьютере, в эмуляторе VMWare, QEMU, и т. д.).</p></li>
|
||||
<li><p>Укажите какую <acronym title="Subversion - система управления версиями, используемая нами">SVN</acronym> ревизию Haiku вы используете. Эту информацию можно найти в '<i>Сведениях о системе (About This System)...</i>' в меню Deskbar.</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in <span class="menu">About Haiku...</span> from the Deskbar menu. Also mention what kind of Haiku build you are testing (gcc2, gcc4, gcc2hybrid, gcc4hybrid). The downloadable images are named accordingly, for a self-built image you should know how you built it.</p></li>
|
||||
<li><p>Опишите проблему, с которой вы столкнулись, попытайтесь описать её наиболее точно: как именно она проявилась, и как правильно должен бы был действовать проблемный объект при её отсутствии.</p></li>
|
||||
<li><p>Расскажите какие шаги нужно выполнить для её возникновения, что поможет разработчикам воспроизвести эту ошибку.</p></li>
|
||||
<li><p>Прикрепите всю имеющуюся информацию. Если это ошибка графического интерфейса или баг в каком-либо приложении, то попытайтесь сделать скриншот (клавиша <span class="key">PrintScreen</span> сохраняет PNG изображение в папке <span class="path">/boot/home/</span>).</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to take a screenshot by pressing the <span class="key">PRINT</span> key.</p></li>
|
||||
</ul>
|
||||
|
||||
<h3>Программные ошибки</h3>
|
||||
<p>Когда приложение аварийно завершилось, вы должны использовать автоматически открывающийся отладчик. Введя в окне терминала с дебагером <span class="cli">bt</span>, вы создаёте "трассировку", которую необходимо скопировать в ваш багрепорт.</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="app" name="app">Application bugs</a></h2>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. This will open a Terminal window with gdb (the GNU debugger) running in it. Entering <span class="cli">bt</span>, you create a "backtrace" that you should copy in its entirety (including the part before you entered the <span class="cli">bt</span> command) and attach it to the ticket.</p>
|
||||
|
||||
<h3>Аппаратные ошибки</h3>
|
||||
<p>Если вы столкнулись с ошибкой работы оборудования и/или драйвера, то вы должны приложить следующую информацию:</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="server" name="server">Server bugs</a></h2>
|
||||
<p>When vital servers like the app server, the registrar or the input server crash, you won't see the usual crash alert. Instead the whole screen will be cleared white and a gdb session will be started, its output appearing directly on screen. Likely you will still be able to move the mouse, which will overwrite the white and gdb output on screen. Applications still running (like ProcessController or the clock in the Deskbar) might also draw over the debugger output on screen.<br />
|
||||
Besides everything being more ugly and inconvenient, basically the same applies as for application bugs. Most importantly procure a back trace (<span class="cli">bt</span> command). You may need to take a picture of the screen with a digital camera, since you won't be able to copy the text anywhere.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kernel" name="kernel">Kernel bugs</a></h2>
|
||||
<p>Kernel bugs are usual the ones with the most severe effects while at the same time being the hardest to debug. There are different kinds of symptoms, which most likely point to a kernel or driver issue:</p>
|
||||
<ul>
|
||||
<li><span class="cli">listdev</span> - подробный список оборудования, включающий ID поставщиков и отдельных устройств, схожа с командами Linux <span class="cli">lshw</span> и <span class="cli">lspci</span>.</li>
|
||||
<li><span class="cli">listusb -v</span> - при ошибке, связанной с USB, аналогична команде <span class="cli">lsusb</span>.</li>
|
||||
<li><span class="cli">open /var/log/syslog</span> - основной системный лог, используемый Haiku, сродни выводимой на экран отладочной информации при загрузке в соответствующем режиме. С командой <span class="cli">open</span> можно вырезать нужную часть лога в текстовом редакторе.</li>
|
||||
<li><span class="cli">listimage | grep drivers/</span> - список всех задействованных драйверов.</li>
|
||||
<li><span class="cli">ints</span> - доступна только в режиме <i>Царства отладки ядра (Kernel Debugging Land - KDL)</i> (см. ниже), отображает используемые прерывания. Не должно быть слишком много устройств, использующих одно прерывание.</li>
|
||||
<li><p>The system enters kernel debugging land (KDL) on its own volition. The upper part of the screen is cleared white and several lines of text are printed on it. The second line says "<i>Welcome to Kernel Debugging Land...</i>", the one above it states the immediate reason for entering KDL.</p></li>
|
||||
<li><p>The system reboots spontaneously.</p></li>
|
||||
<li><p>The system freezes completely. You can't move the mouse and no application draws anything anymore. An important test in that situation is, whether you still can enter KDL via the shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards). Wait at least a minute to see, if anything happens.</p></li>
|
||||
<li><p>The system doesn't boot up correctly. It may reboot spontaneously or stop at some point (e.g. at some icon of the boot screen). In the latter case also try <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.</p></li>
|
||||
<li><p>The whole system or some piece of hardware doesn't behave correctly. For example, it could be very slow, errors occur, or something doesn't work at all. If some hardware doesn't work at all, the first obvious check is whether Haiku supports it at all at the moment (e.g. ask on a mailing list or a forum).</p></li>
|
||||
</ul>
|
||||
<p>Все эти команды вводитятся в терминале, если не указано иное. Если добавить <span class="cli"> > output.txt</span> после команды, то результат её работы сохранится в текстовый файл "output.txt", который можно прикрепить к своему сообщению об ошибках или отправить по электронной почте.</p>
|
||||
<p>Note that while only the last point seems to indicate hardware relation, all the other symptoms could be caused by a bug in a hardware driver as well. If you have a suspicion what piece of hardware or corresponding driver might have to do with the problem, check whether removing/disabling the hardware or the driver makes a difference. For example, if you suspect Wifi you may find that your BIOS has an option to disable it. Or if not, you could remove the responsible Wifi driver from your Haiku installation (in <span class="path">/boot/system/add-ons/kernel/drivers/bin</span>).</p>
|
||||
|
||||
<h3>Царство отладки ядра - KDL</h3>
|
||||
<p>Когда какой-либо системный низкоуровневый компонент вызывает фатальную ошибку, то вы, с большой долей вероятности, окажетесь в отладчике ядра. Также он может быть вызван намеренно при нажатии на клавиши <span class="key">ALT</span>+<span class="key">SysReq</span>+<span class="key">D</span> (клавиша <span class="key">SysReq</span> называется <span class="key">PrintScreen</span> на большинстве клавиатур).</p>
|
||||
<ul>
|
||||
<li><span class="cli">co</span> - выведет систему из KDL и продолжит нормальную работу Haiku, если это возможно.</li>
|
||||
<li><span class="cli">int</span> - отобразит используемые прерывания (как описано выше).</li>
|
||||
<li><span class="cli">bt</span> - покажет трассировку, уточняющую где именно произошла ошибка.</li>
|
||||
</ul>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kdl" name="kdl">Kernel Debugging Land - KDL</a></h3>
|
||||
<p>If the system hasn't entered KDL by itself, you can do that intentionally by invoking the keyboard shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.<br />
|
||||
Note that in KDL your keyboard may not work. PS/2 keyboards always do, USB keyboards connected via UHCI controllers do only, if one has entered KDL via the keyboard shortcut at least once. USB OHCI is not supported at the moment.</p>
|
||||
<p>KDL itself is a kind of a shell. One can execute commands that print information about the system. The following commands might be of interest:</p>
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td><span class="cli">bt</span> (aka sc)</td><td> </td><td>Prints a back trace. If the system entered KDL on its on volition, always enter that one.</td></tr>
|
||||
<tr><td><span class="cli">ints</span></td><td> </td><td>Shows the handled and unhandled hardware interrupts.</td></tr>
|
||||
<tr><td class="onelinetop"><span class="cli">co</span> (aka continue)</td><td> </td><td>Leaves the kernel debugger and continues normal operation of the system, if that is possible.</td></tr>
|
||||
<tr><td><span class="cli">reboot</span></td><td> </td><td>Reboots the system immediately. You will lose all unsaved data and even those that have been saved, but have not yet been written back to disk.</td></tr>
|
||||
</table>
|
||||
<p>For more information, see the article <a href="http://www.haiku-os.org/documents/dev/welcome_to_kernel_debugging_land">Welcome to Kernel Debugging Land</a>.</p>
|
||||
<p>The KDL output is written to the serial port (if you have one, a respective cable, and a second computer to connect with, you can capture the output there via a terminal program) and to the syslog. If you can't leave KDL it won't be written to the syslog file, though. There's a boot loader debug option that allows you to capture it nonetheless (see below).</p>
|
||||
|
||||
<h2>Что дальше?</h2>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="syslog" name="syslog">Syslog</a></h3>
|
||||
<p><b>This is the preferred method for gaining information from a non-booting system.</b><br />
|
||||
The syslog (short for system log) contains valuable information about what has happened in your system, including the output of KDL sessions. It's usually a good idea to attach it to the kernel related Trac ticket. The syslog is written to the file <span class="path">/boot/common/var/log/syslog</span>. Since writing to a file requires a working system, the most recent output might not have made it to the syslog when a kernel problem occurs (particularly on spontaneous reboots or uncontinuable KDL sessions).</p>
|
||||
<p>The option <span class="menu">Enable debug syslog</span> in the boot loader's <span class="menu">Debug menu</span> makes the syslog somewhat persistent in memory. By default the option is enabled. "Somewhat persistent" means that it survives a reset and will still be accessible when you enter the boot loader menu directly afterwards. Booting an operating system (Haiku definitely, others likely) destroys the information, though. So you have to enter the boot loader menu by holding down <span class="key">SHIFT</span> while booting.<br />
|
||||
In the boot loader's <span class="menu">Debug menu</span> you should now find the entries <span class="menu">Display syslog from previous session</span> and <span class="menu">Save syslog from previous session</span>. The former displays the syslog on screen, the latter allows you to save it as a file to disk. Note that at the moment only FAT32 volumes are supported for saving the file. If you want to use a USB stick, but have plugged it in too late so that it isn't recognized yet, you can reset the machine and re-enter the boot loader menu. But again: Don't accidentally boot any operating system or the data will be lost.</p>
|
||||
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="onscreen" name="onscreen">On screen debug output</a></h3>
|
||||
<p><b>The on-screen debug output is useful only for debugging very specific issues and is known to have (timing) issues. Don't use it, if you don't have to.</b><br />
|
||||
This is only relevant when Haiku fails to boot on your machine and the <span class="menu">Debug syslog option</span> doesn't work for some reason. Before the Haiku boot logo appears, hold <span class="key">SHIFT</span> to enter the boot loader menu. Select <span class="menu">Select safe mode options</span>. Near the bottom, <span class="menu">[ ] Enable on screen debug output</span> will be listed. (Note: The other options could be enabled in an attempt to boot Haiku. If Haiku will boot only when one or more options are activated, be sure to mention which ones.)<br />
|
||||
Finally select <span class="menu">Return to main menu</span> and then <span class="menu">Continue booting</span>.<br />
|
||||
One or more pages of text will display on the screen, only the last few lines need to be included on your ticket. There's more information on the <a href="../../../userguide/ru/bootloader.html">Boot Loader</a>.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="hardware" name="hardware">Hardware/Driver bugs</a></h2>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information as text files:</p>
|
||||
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td>- <span class="cli">listdev</span></td><td> </td><td>A detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">listusb -v</span></td><td> </td><td>Assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">open /var/log/syslog</span></td><td> </td><td>The primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</td></tr>
|
||||
<tr><td class="onelinetop">- <span class="cli">listimage | grep drivers/</span></td><td> </td><td>Lists all used drivers.</td></tr>
|
||||
<tr><td>- <span class="cli">ints</span></td><td> </td><td>Only available within <i>Kernel Debugging Land</i> (see above). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</td></tr>
|
||||
<tr><td colspan="3">- On screen debug output (a safe mode boot time option).</td></tr>
|
||||
</table>
|
||||
|
||||
<p>The first four commands are entered into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="next" name="next">What's next?</a></h2>
|
||||
<p>После того как багрепорт отправлен, разработчик рассмотрит вашу ошибку и попытаться классифицировать ее. Помните, что мы все добровольцы, и иногда багрепорт может оставаться без ответа некоторое время. Добавление новой информации к этой ошибке помогает исправить её быстрее, но не пытайтесь увеличить её значимость, добавляя не относящиеся к делу комментарии.</p>
|
||||
<p>Помните, что отправка багрепорта, на который вы потратили некоторое время - это ещё полдела, и желательно чтобы вы следили за его состоянием. Только в этом случае вы внесёте ощутимую часть в процесс развития Haiku. У разработчиков могут возникнуть вопросы, относящиеся к багу во время его исправления, пожалуйста, не игнорируйте их, постаравшись как можно подробней ответить. Считайте свое участие законченным, только когда ошибка приобретёт статус "исправлено (fixed)".</p>
|
||||
|
||||
|
||||
@@ -4,11 +4,12 @@
|
||||
<head>
|
||||
<!--
|
||||
*
|
||||
* Copyright 2008-2009, Haiku. All rights reserved.
|
||||
* Copyright 2008-2010, Haiku. All rights reserved.
|
||||
* Distributed under the terms of the MIT License.
|
||||
*
|
||||
* Authors:
|
||||
* Niels Reedijk and Matt Madia who wrote http://dev.haiku-os.org/wiki
|
||||
* Niels Reedijk, Matt Madia and Ingo Weinhold who wrote
|
||||
* http://dev.haiku-os.org/wiki/ and http://dev.haiku-os.org/wiki/ReportingBugs
|
||||
* Humdinger <[email protected]>
|
||||
*
|
||||
-->
|
||||
@@ -47,49 +48,109 @@
|
||||
<div>
|
||||
<div class="box-info">The translation of this page isn't yet complete. Until it is, unfinished parts use the English original.</div>
|
||||
|
||||
<table class="index" id="index" summary="index">
|
||||
<tr class="heading"><td>Reporting bugs</td></tr>
|
||||
<tr class="index"><td><a href="#account">Getting a Trac account</a><br />
|
||||
<a href="#report">Creating a bug report</a><br />
|
||||
<a href="#app">Application bugs</a><br />
|
||||
<a href="#server">Server bugs</a><br />
|
||||
<a href="#kernel">Kernel bugs</a><br />
|
||||
<a href="#kdl">Kernel Debugging Land - KDL</a><br />
|
||||
<a href="#syslog">Syslog</a><br />
|
||||
<a href="#onscreen">On screen debug output</a><br />
|
||||
<a href="#hardware">Hardware/Driver bugs</a><br />
|
||||
<a href="#next">What's next?</a></td></tr>
|
||||
</table>
|
||||
|
||||
<h1>Reporting bugs</h1>
|
||||
|
||||
<p>Since our developers are unable to test every hardware combination, nor every different way of interacting with the operating system, we are relying on users to give us some input on how things work at their end. Since Haiku is still quite young, it's very likely that you will encounter bugs. We thank you for taking the time to report these. Together we can improve Haiku, bit by bit.</p>
|
||||
<p>To keep our bugtracker effective, it's essential to abide by the <a href="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">Bug Tracker Etiquette</a>.</p>
|
||||
|
||||
<h2>Getting a Trac account</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="account" name="accout">Getting a Trac account</a></h2>
|
||||
<p>To file a ticket, you need to have an account at <a href="http://dev.haiku-os.org/register" title="Register at Haiku's Bugtracker">Haiku's Bugtracker</a>.<br />
|
||||
When creating a new account, be certain to <b>provide your email address</b> as it is necessary to obtain basic ticket modification privileges. Be sure to <b>check your spam folder</b> shortly afterwards, as the all important verification mail often ends up there.</p>
|
||||
|
||||
<h2>Creating a bug report</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="report" name="report">Creating a bug report</a></h2>
|
||||
<p>Before reporting a bug, please <a href="http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority">make sure</a> that it does not yet exist. You can also use the <a href="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">search</a> function for this.<br />
|
||||
After you have established that it's a unique bug, make your information as accurate as possible:</p>
|
||||
<ul>
|
||||
<li><p>Attempt to reproduce your issue on the current revision of Haiku. Pre-built images for testing purposes are <a href="http://haiku-files.org/">available</a>.</p></li>
|
||||
<li><p>Include basic information such as how you are testing Haiku (on real hardware, on VMWare, on QEMU, etc.).</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in '<i>About This System...</i>' from the Deskbar menu.</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in <span class="menu">About Haiku...</span> from the Deskbar menu. Also mention what kind of Haiku build you are testing (gcc2, gcc4, gcc2hybrid, gcc4hybrid). The downloadable images are named accordingly, for a self-built image you should know how you built it.</p></li>
|
||||
<li><p>Describe the problem you are experiencing. Try to be as accurate as you can: describe the actual behavior, and the behavior you expected.</p></li>
|
||||
<li><p>Describe what steps you need to perform in order to expose the bug. This will help developers reproduce the bug.</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to make a screen shot (the <span class="key">PRINT</span> key saves a <acronym title="Portable Network Graphics image format">PNG</acronym> in <span class="path">/boot/home/</span>).</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to take a screenshot by pressing the <span class="key">PRINT</span> key.</p></li>
|
||||
</ul>
|
||||
|
||||
<h3>Software Bugs</h3>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. Entering <span class="cli">bt</span> into the launched debug Terminal, you create a "backtrace" that you should copy into your bug report.</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="app" name="app">Application bugs</a></h2>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. This will open a Terminal window with gdb (the GNU debugger) running in it. Entering <span class="cli">bt</span>, you create a "backtrace" that you should copy in its entirety (including the part before you entered the <span class="cli">bt</span> command) and attach it to the ticket.</p>
|
||||
|
||||
<h3>Hardware Bugs</h3>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information:</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="server" name="server">Server bugs</a></h2>
|
||||
<p>When vital servers like the app server, the registrar or the input server crash, you won't see the usual crash alert. Instead the whole screen will be cleared white and a gdb session will be started, its output appearing directly on screen. Likely you will still be able to move the mouse, which will overwrite the white and gdb output on screen. Applications still running (like ProcessController or the clock in the Deskbar) might also draw over the debugger output on screen.<br />
|
||||
Besides everything being more ugly and inconvenient, basically the same applies as for application bugs. Most importantly procure a back trace (<span class="cli">bt</span> command). You may need to take a picture of the screen with a digital camera, since you won't be able to copy the text anywhere.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kernel" name="kernel">Kernel bugs</a></h2>
|
||||
<p>Kernel bugs are usual the ones with the most severe effects while at the same time being the hardest to debug. There are different kinds of symptoms, which most likely point to a kernel or driver issue:</p>
|
||||
<ul>
|
||||
<li><span class="cli">listdev</span> - a detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</li>
|
||||
<li><span class="cli">listusb -v</span> - assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</li>
|
||||
<li><span class="cli">open /var/log/syslog</span> - the primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</li>
|
||||
<li><span class="cli">listimage | grep drivers/</span> - lists all used drivers.</li>
|
||||
<li><span class="cli">ints</span> - only available within <i>Kernel Debugging Land</i> (see below). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</li>
|
||||
<li><p>The system enters kernel debugging land (KDL) on its own volition. The upper part of the screen is cleared white and several lines of text are printed on it. The second line says "<i>Welcome to Kernel Debugging Land...</i>", the one above it states the immediate reason for entering KDL.</p></li>
|
||||
<li><p>The system reboots spontaneously.</p></li>
|
||||
<li><p>The system freezes completely. You can't move the mouse and no application draws anything anymore. An important test in that situation is, whether you still can enter KDL via the shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards). Wait at least a minute to see, if anything happens.</p></li>
|
||||
<li><p>The system doesn't boot up correctly. It may reboot spontaneously or stop at some point (e.g. at some icon of the boot screen). In the latter case also try <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.</p></li>
|
||||
<li><p>The whole system or some piece of hardware doesn't behave correctly. For example, it could be very slow, errors occur, or something doesn't work at all. If some hardware doesn't work at all, the first obvious check is whether Haiku supports it at all at the moment (e.g. ask on a mailing list or a forum).</p></li>
|
||||
</ul>
|
||||
<p>You enter these commands into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
<p>Note that while only the last point seems to indicate hardware relation, all the other symptoms could be caused by a bug in a hardware driver as well. If you have a suspicion what piece of hardware or corresponding driver might have to do with the problem, check whether removing/disabling the hardware or the driver makes a difference. For example, if you suspect Wifi you may find that your BIOS has an option to disable it. Or if not, you could remove the responsible Wifi driver from your Haiku installation (in <span class="path">/boot/system/add-ons/kernel/drivers/bin</span>).</p>
|
||||
|
||||
<h3>Kernel Debugging Land - KDL</h3>
|
||||
<p>When some very low level system component crashed, you may end up in the kernel debugger. It can also be entered deliberately with <span class="key">ALT</span><span class="key">SysReq</span><span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards).</p>
|
||||
<ul>
|
||||
<li><span class="cli">co</span> - will exit KDL and continue normal system operation, if possible.</li>
|
||||
<li><span class="cli">int</span> - will show interrupt usage (as described above).</li>
|
||||
<li><span class="cli">bt</span> - shows a backtrace, detailing where exactly the crash happened.</li>
|
||||
</ul>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kdl" name="kdl">Kernel Debugging Land - KDL</a></h3>
|
||||
<p>If the system hasn't entered KDL by itself, you can do that intentionally by invoking the keyboard shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.<br />
|
||||
Note that in KDL your keyboard may not work. PS/2 keyboards always do, USB keyboards connected via UHCI controllers do only, if one has entered KDL via the keyboard shortcut at least once. USB OHCI is not supported at the moment.</p>
|
||||
<p>KDL itself is a kind of a shell. One can execute commands that print information about the system. The following commands might be of interest:</p>
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td><span class="cli">bt</span> (aka sc)</td><td> </td><td>Prints a back trace. If the system entered KDL on its on volition, always enter that one.</td></tr>
|
||||
<tr><td><span class="cli">ints</span></td><td> </td><td>Shows the handled and unhandled hardware interrupts.</td></tr>
|
||||
<tr><td class="onelinetop"><span class="cli">co</span> (aka continue)</td><td> </td><td>Leaves the kernel debugger and continues normal operation of the system, if that is possible.</td></tr>
|
||||
<tr><td><span class="cli">reboot</span></td><td> </td><td>Reboots the system immediately. You will lose all unsaved data and even those that have been saved, but have not yet been written back to disk.</td></tr>
|
||||
</table>
|
||||
<p>For more information, see the article <a href="http://www.haiku-os.org/documents/dev/welcome_to_kernel_debugging_land">Welcome to Kernel Debugging Land</a>.</p>
|
||||
<p>The KDL output is written to the serial port (if you have one, a respective cable, and a second computer to connect with, you can capture the output there via a terminal program) and to the syslog. If you can't leave KDL it won't be written to the syslog file, though. There's a boot loader debug option that allows you to capture it nonetheless (see below).</p>
|
||||
|
||||
<h2>What's next?</h2>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="syslog" name="syslog">Syslog</a></h3>
|
||||
<p><b>This is the preferred method for gaining information from a non-booting system.</b><br />
|
||||
The syslog (short for system log) contains valuable information about what has happened in your system, including the output of KDL sessions. It's usually a good idea to attach it to the kernel related Trac ticket. The syslog is written to the file <span class="path">/boot/common/var/log/syslog</span>. Since writing to a file requires a working system, the most recent output might not have made it to the syslog when a kernel problem occurs (particularly on spontaneous reboots or uncontinuable KDL sessions).</p>
|
||||
<p>The option <span class="menu">Enable debug syslog</span> in the boot loader's <span class="menu">Debug menu</span> makes the syslog somewhat persistent in memory. By default the option is enabled. "Somewhat persistent" means that it survives a reset and will still be accessible when you enter the boot loader menu directly afterwards. Booting an operating system (Haiku definitely, others likely) destroys the information, though. So you have to enter the boot loader menu by holding down <span class="key">SHIFT</span> while booting.<br />
|
||||
In the boot loader's <span class="menu">Debug menu</span> you should now find the entries <span class="menu">Display syslog from previous session</span> and <span class="menu">Save syslog from previous session</span>. The former displays the syslog on screen, the latter allows you to save it as a file to disk. Note that at the moment only FAT32 volumes are supported for saving the file. If you want to use a USB stick, but have plugged it in too late so that it isn't recognized yet, you can reset the machine and re-enter the boot loader menu. But again: Don't accidentally boot any operating system or the data will be lost.</p>
|
||||
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="onscreen" name="onscreen">On screen debug output</a></h3>
|
||||
<p><b>The on-screen debug output is useful only for debugging very specific issues and is known to have (timing) issues. Don't use it, if you don't have to.</b><br />
|
||||
This is only relevant when Haiku fails to boot on your machine and the <span class="menu">Debug syslog option</span> doesn't work for some reason. Before the Haiku boot logo appears, hold <span class="key">SHIFT</span> to enter the boot loader menu. Select <span class="menu">Select safe mode options</span>. Near the bottom, <span class="menu">[ ] Enable on screen debug output</span> will be listed. (Note: The other options could be enabled in an attempt to boot Haiku. If Haiku will boot only when one or more options are activated, be sure to mention which ones.)<br />
|
||||
Finally select <span class="menu">Return to main menu</span> and then <span class="menu">Continue booting</span>.<br />
|
||||
One or more pages of text will display on the screen, only the last few lines need to be included on your ticket. There's more information on the <a href="../../../userguide/sv_SE/bootloader.html">Boot Loader</a>.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="hardware" name="hardware">Hardware/Driver bugs</a></h2>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information as text files:</p>
|
||||
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td>- <span class="cli">listdev</span></td><td> </td><td>A detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">listusb -v</span></td><td> </td><td>Assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">open /var/log/syslog</span></td><td> </td><td>The primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</td></tr>
|
||||
<tr><td class="onelinetop">- <span class="cli">listimage | grep drivers/</span></td><td> </td><td>Lists all used drivers.</td></tr>
|
||||
<tr><td>- <span class="cli">ints</span></td><td> </td><td>Only available within <i>Kernel Debugging Land</i> (see above). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</td></tr>
|
||||
<tr><td colspan="3">- On screen debug output (a safe mode boot time option).</td></tr>
|
||||
</table>
|
||||
|
||||
<p>The first four commands are entered into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="next" name="next">What's next?</a></h2>
|
||||
<p>After the bug has been reported, a developer will look at your bug and try to classify it. Remember, we are all volunteers, and as such, sometimes a bug report might go unanswered for a while. Adding new information when it becomes available usually helps getting a bug picked up quicker, but do not try to 'bump' the bug up by adding
|
||||
non-descriptive comments.</p>
|
||||
<p>Remember, reporting a bug is not something you spend a little time on and then you are done. If you reported a bug, then you are part of the Haiku development process. Developers might come up with questions while they are trying to fix your bug. Please stay around to answer these. Consider your participation 'done' when the bug is marked
|
||||
|
||||
@@ -4,11 +4,12 @@
|
||||
<head>
|
||||
<!--
|
||||
*
|
||||
* Copyright 2008-2009, Haiku. All rights reserved.
|
||||
* Copyright 2008-2010, Haiku. All rights reserved.
|
||||
* Distributed under the terms of the MIT License.
|
||||
*
|
||||
* Authors:
|
||||
* Niels Reedijk and Matt Madia who wrote http://dev.haiku-os.org/wiki
|
||||
* Niels Reedijk, Matt Madia and Ingo Weinhold who wrote
|
||||
* http://dev.haiku-os.org/wiki/ and http://dev.haiku-os.org/wiki/ReportingBugs
|
||||
* Humdinger <humdingerb@gmail.com>
|
||||
*
|
||||
-->
|
||||
@@ -47,49 +48,109 @@
|
||||
<div>
|
||||
<div class="box-info">The translation of this page isn't yet complete. Until it is, unfinished parts use the English original.</div>
|
||||
|
||||
<table class="index" id="index" summary="index">
|
||||
<tr class="heading"><td>Reporting bugs</td></tr>
|
||||
<tr class="index"><td><a href="#account">Getting a Trac account</a><br />
|
||||
<a href="#report">Creating a bug report</a><br />
|
||||
<a href="#app">Application bugs</a><br />
|
||||
<a href="#server">Server bugs</a><br />
|
||||
<a href="#kernel">Kernel bugs</a><br />
|
||||
<a href="#kdl">Kernel Debugging Land - KDL</a><br />
|
||||
<a href="#syslog">Syslog</a><br />
|
||||
<a href="#onscreen">On screen debug output</a><br />
|
||||
<a href="#hardware">Hardware/Driver bugs</a><br />
|
||||
<a href="#next">What's next?</a></td></tr>
|
||||
</table>
|
||||
|
||||
<h1>Reporting bugs</h1>
|
||||
|
||||
<p>Since our developers are unable to test every hardware combination, nor every different way of interacting with the operating system, we are relying on users to give us some input on how things work at their end. Since Haiku is still quite young, it's very likely that you will encounter bugs. We thank you for taking the time to report these. Together we can improve Haiku, bit by bit.</p>
|
||||
<p>To keep our bugtracker effective, it's essential to abide by the <a href="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">Bug Tracker Etiquette</a>.</p>
|
||||
|
||||
<h2>Getting a Trac account</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="account" name="accout">Getting a Trac account</a></h2>
|
||||
<p>To file a ticket, you need to have an account at <a href="http://dev.haiku-os.org/register" title="Register at Haiku's Bugtracker">Haiku's Bugtracker</a>.<br />
|
||||
When creating a new account, be certain to <b>provide your email address</b> as it is necessary to obtain basic ticket modification privileges. Be sure to <b>check your spam folder</b> shortly afterwards, as the all important verification mail often ends up there.</p>
|
||||
|
||||
<h2>Creating a bug report</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="report" name="report">Creating a bug report</a></h2>
|
||||
<p>Before reporting a bug, please <a href="http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority">make sure</a> that it does not yet exist. You can also use the <a href="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">search</a> function for this.<br />
|
||||
After you have established that it's a unique bug, make your information as accurate as possible:</p>
|
||||
<ul>
|
||||
<li><p>Attempt to reproduce your issue on the current revision of Haiku. Pre-built images for testing purposes are <a href="http://haiku-files.org/">available</a>.</p></li>
|
||||
<li><p>Include basic information such as how you are testing Haiku (on real hardware, on VMWare, on QEMU, etc.).</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in '<i>About This System...</i>' from the Deskbar menu.</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in <span class="menu">About Haiku...</span> from the Deskbar menu. Also mention what kind of Haiku build you are testing (gcc2, gcc4, gcc2hybrid, gcc4hybrid). The downloadable images are named accordingly, for a self-built image you should know how you built it.</p></li>
|
||||
<li><p>Describe the problem you are experiencing. Try to be as accurate as you can: describe the actual behavior, and the behavior you expected.</p></li>
|
||||
<li><p>Describe what steps you need to perform in order to expose the bug. This will help developers reproduce the bug.</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to make a screen shot (the <span class="key">PRINT</span> key saves a <acronym title="Portable Network Graphics image format">PNG</acronym> in <span class="path">/boot/home/</span>).</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to take a screenshot by pressing the <span class="key">PRINT</span> key.</p></li>
|
||||
</ul>
|
||||
|
||||
<h3>Software Bugs</h3>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. Entering <span class="cli">bt</span> into the launched debug Terminal, you create a "backtrace" that you should copy into your bug report.</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="app" name="app">Application bugs</a></h2>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. This will open a Terminal window with gdb (the GNU debugger) running in it. Entering <span class="cli">bt</span>, you create a "backtrace" that you should copy in its entirety (including the part before you entered the <span class="cli">bt</span> command) and attach it to the ticket.</p>
|
||||
|
||||
<h3>Hardware Bugs</h3>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information:</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="server" name="server">Server bugs</a></h2>
|
||||
<p>When vital servers like the app server, the registrar or the input server crash, you won't see the usual crash alert. Instead the whole screen will be cleared white and a gdb session will be started, its output appearing directly on screen. Likely you will still be able to move the mouse, which will overwrite the white and gdb output on screen. Applications still running (like ProcessController or the clock in the Deskbar) might also draw over the debugger output on screen.<br />
|
||||
Besides everything being more ugly and inconvenient, basically the same applies as for application bugs. Most importantly procure a back trace (<span class="cli">bt</span> command). You may need to take a picture of the screen with a digital camera, since you won't be able to copy the text anywhere.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kernel" name="kernel">Kernel bugs</a></h2>
|
||||
<p>Kernel bugs are usual the ones with the most severe effects while at the same time being the hardest to debug. There are different kinds of symptoms, which most likely point to a kernel or driver issue:</p>
|
||||
<ul>
|
||||
<li><span class="cli">listdev</span> - a detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</li>
|
||||
<li><span class="cli">listusb -v</span> - assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</li>
|
||||
<li><span class="cli">open /var/log/syslog</span> - the primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</li>
|
||||
<li><span class="cli">listimage | grep drivers/</span> - lists all used drivers.</li>
|
||||
<li><span class="cli">ints</span> - only available within <i>Kernel Debugging Land</i> (see below). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</li>
|
||||
<li><p>The system enters kernel debugging land (KDL) on its own volition. The upper part of the screen is cleared white and several lines of text are printed on it. The second line says "<i>Welcome to Kernel Debugging Land...</i>", the one above it states the immediate reason for entering KDL.</p></li>
|
||||
<li><p>The system reboots spontaneously.</p></li>
|
||||
<li><p>The system freezes completely. You can't move the mouse and no application draws anything anymore. An important test in that situation is, whether you still can enter KDL via the shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards). Wait at least a minute to see, if anything happens.</p></li>
|
||||
<li><p>The system doesn't boot up correctly. It may reboot spontaneously or stop at some point (e.g. at some icon of the boot screen). In the latter case also try <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.</p></li>
|
||||
<li><p>The whole system or some piece of hardware doesn't behave correctly. For example, it could be very slow, errors occur, or something doesn't work at all. If some hardware doesn't work at all, the first obvious check is whether Haiku supports it at all at the moment (e.g. ask on a mailing list or a forum).</p></li>
|
||||
</ul>
|
||||
<p>You enter these commands into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
<p>Note that while only the last point seems to indicate hardware relation, all the other symptoms could be caused by a bug in a hardware driver as well. If you have a suspicion what piece of hardware or corresponding driver might have to do with the problem, check whether removing/disabling the hardware or the driver makes a difference. For example, if you suspect Wifi you may find that your BIOS has an option to disable it. Or if not, you could remove the responsible Wifi driver from your Haiku installation (in <span class="path">/boot/system/add-ons/kernel/drivers/bin</span>).</p>
|
||||
|
||||
<h3>Kernel Debugging Land - KDL</h3>
|
||||
<p>When some very low level system component crashed, you may end up in the kernel debugger. It can also be entered deliberately with <span class="key">ALT</span><span class="key">SysReq</span><span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards).</p>
|
||||
<ul>
|
||||
<li><span class="cli">co</span> - will exit KDL and continue normal system operation, if possible.</li>
|
||||
<li><span class="cli">int</span> - will show interrupt usage (as described above).</li>
|
||||
<li><span class="cli">bt</span> - shows a backtrace, detailing where exactly the crash happened.</li>
|
||||
</ul>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kdl" name="kdl">Kernel Debugging Land - KDL</a></h3>
|
||||
<p>If the system hasn't entered KDL by itself, you can do that intentionally by invoking the keyboard shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.<br />
|
||||
Note that in KDL your keyboard may not work. PS/2 keyboards always do, USB keyboards connected via UHCI controllers do only, if one has entered KDL via the keyboard shortcut at least once. USB OHCI is not supported at the moment.</p>
|
||||
<p>KDL itself is a kind of a shell. One can execute commands that print information about the system. The following commands might be of interest:</p>
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td><span class="cli">bt</span> (aka sc)</td><td> </td><td>Prints a back trace. If the system entered KDL on its on volition, always enter that one.</td></tr>
|
||||
<tr><td><span class="cli">ints</span></td><td> </td><td>Shows the handled and unhandled hardware interrupts.</td></tr>
|
||||
<tr><td class="onelinetop"><span class="cli">co</span> (aka continue)</td><td> </td><td>Leaves the kernel debugger and continues normal operation of the system, if that is possible.</td></tr>
|
||||
<tr><td><span class="cli">reboot</span></td><td> </td><td>Reboots the system immediately. You will lose all unsaved data and even those that have been saved, but have not yet been written back to disk.</td></tr>
|
||||
</table>
|
||||
<p>For more information, see the article <a href="http://www.haiku-os.org/documents/dev/welcome_to_kernel_debugging_land">Welcome to Kernel Debugging Land</a>.</p>
|
||||
<p>The KDL output is written to the serial port (if you have one, a respective cable, and a second computer to connect with, you can capture the output there via a terminal program) and to the syslog. If you can't leave KDL it won't be written to the syslog file, though. There's a boot loader debug option that allows you to capture it nonetheless (see below).</p>
|
||||
|
||||
<h2>What's next?</h2>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="syslog" name="syslog">Syslog</a></h3>
|
||||
<p><b>This is the preferred method for gaining information from a non-booting system.</b><br />
|
||||
The syslog (short for system log) contains valuable information about what has happened in your system, including the output of KDL sessions. It's usually a good idea to attach it to the kernel related Trac ticket. The syslog is written to the file <span class="path">/boot/common/var/log/syslog</span>. Since writing to a file requires a working system, the most recent output might not have made it to the syslog when a kernel problem occurs (particularly on spontaneous reboots or uncontinuable KDL sessions).</p>
|
||||
<p>The option <span class="menu">Enable debug syslog</span> in the boot loader's <span class="menu">Debug menu</span> makes the syslog somewhat persistent in memory. By default the option is enabled. "Somewhat persistent" means that it survives a reset and will still be accessible when you enter the boot loader menu directly afterwards. Booting an operating system (Haiku definitely, others likely) destroys the information, though. So you have to enter the boot loader menu by holding down <span class="key">SHIFT</span> while booting.<br />
|
||||
In the boot loader's <span class="menu">Debug menu</span> you should now find the entries <span class="menu">Display syslog from previous session</span> and <span class="menu">Save syslog from previous session</span>. The former displays the syslog on screen, the latter allows you to save it as a file to disk. Note that at the moment only FAT32 volumes are supported for saving the file. If you want to use a USB stick, but have plugged it in too late so that it isn't recognized yet, you can reset the machine and re-enter the boot loader menu. But again: Don't accidentally boot any operating system or the data will be lost.</p>
|
||||
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="onscreen" name="onscreen">On screen debug output</a></h3>
|
||||
<p><b>The on-screen debug output is useful only for debugging very specific issues and is known to have (timing) issues. Don't use it, if you don't have to.</b><br />
|
||||
This is only relevant when Haiku fails to boot on your machine and the <span class="menu">Debug syslog option</span> doesn't work for some reason. Before the Haiku boot logo appears, hold <span class="key">SHIFT</span> to enter the boot loader menu. Select <span class="menu">Select safe mode options</span>. Near the bottom, <span class="menu">[ ] Enable on screen debug output</span> will be listed. (Note: The other options could be enabled in an attempt to boot Haiku. If Haiku will boot only when one or more options are activated, be sure to mention which ones.)<br />
|
||||
Finally select <span class="menu">Return to main menu</span> and then <span class="menu">Continue booting</span>.<br />
|
||||
One or more pages of text will display on the screen, only the last few lines need to be included on your ticket. There's more information on the <a href="../../../userguide/uk/bootloader.html">Boot Loader</a>.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="hardware" name="hardware">Hardware/Driver bugs</a></h2>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information as text files:</p>
|
||||
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td>- <span class="cli">listdev</span></td><td> </td><td>A detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">listusb -v</span></td><td> </td><td>Assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">open /var/log/syslog</span></td><td> </td><td>The primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</td></tr>
|
||||
<tr><td class="onelinetop">- <span class="cli">listimage | grep drivers/</span></td><td> </td><td>Lists all used drivers.</td></tr>
|
||||
<tr><td>- <span class="cli">ints</span></td><td> </td><td>Only available within <i>Kernel Debugging Land</i> (see above). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</td></tr>
|
||||
<tr><td colspan="3">- On screen debug output (a safe mode boot time option).</td></tr>
|
||||
</table>
|
||||
|
||||
<p>The first four commands are entered into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="next" name="next">What's next?</a></h2>
|
||||
<p>After the bug has been reported, a developer will look at your bug and try to classify it. Remember, we are all volunteers, and as such, sometimes a bug report might go unanswered for a while. Adding new information when it becomes available usually helps getting a bug picked up quicker, but do not try to 'bump' the bug up by adding
|
||||
non-descriptive comments.</p>
|
||||
<p>Remember, reporting a bug is not something you spend a little time on and then you are done. If you reported a bug, then you are part of the Haiku development process. Developers might come up with questions while they are trying to fix your bug. Please stay around to answer these. Consider your participation 'done' when the bug is marked
|
||||
|
||||
@@ -4,11 +4,12 @@
|
||||
<head>
|
||||
<!--
|
||||
*
|
||||
* Copyright 2008-2009, Haiku. All rights reserved.
|
||||
* Copyright 2008-2010, Haiku. All rights reserved.
|
||||
* Distributed under the terms of the MIT License.
|
||||
*
|
||||
* Authors:
|
||||
* Niels Reedijk and Matt Madia who wrote http://dev.haiku-os.org/wiki
|
||||
* Niels Reedijk, Matt Madia and Ingo Weinhold who wrote
|
||||
* http://dev.haiku-os.org/wiki/ and http://dev.haiku-os.org/wiki/ReportingBugs
|
||||
* Humdinger <humdingerb@gmail.com>
|
||||
* Translators:
|
||||
* Pengphei Han
|
||||
@@ -22,7 +23,7 @@
|
||||
<body>
|
||||
|
||||
<div id="banner">
|
||||
<div><span>用户指南</span></div>
|
||||
<div><span>User guide</span></div>
|
||||
</div>
|
||||
|
||||
<div class="nav">
|
||||
@@ -47,52 +48,113 @@
|
||||
|
||||
<div id="content">
|
||||
<div>
|
||||
<div class="box-info">The translation of this page isn't yet complete. Until it is, unfinished parts use the English original.</div>
|
||||
|
||||
<table class="index" id="index" summary="index">
|
||||
<tr class="heading"><td>报告错误</td></tr>
|
||||
<tr class="index"><td><a href="#account">Getting a Trac account</a><br />
|
||||
<a href="#report">Creating a bug report</a><br />
|
||||
<a href="#app">Application bugs</a><br />
|
||||
<a href="#server">Server bugs</a><br />
|
||||
<a href="#kernel">Kernel bugs</a><br />
|
||||
<a href="#kdl">Kernel Debugging Land - KDL</a><br />
|
||||
<a href="#syslog">Syslog</a><br />
|
||||
<a href="#onscreen">On screen debug output</a><br />
|
||||
<a href="#hardware">Hardware/Driver bugs</a><br />
|
||||
<a href="#next">What's next?</a></td></tr>
|
||||
</table>
|
||||
|
||||
<h1>报告错误</h1>
|
||||
|
||||
<p>由于我们的开发人员不可能测试每种硬件组合和每种不同的系统交互方式，所以我们依赖于用户，通过用户来给予我们Haiku的运行情况。由于Haiku还很年轻，您在使用时很有可能会遇到错误。我们非常感谢您能够分出时间来提交这些错误报告。我们可以共同的一位一位的提高Haiku的性能。</p>
|
||||
<p>为了确保我们的错误跟踪系统的有效性，遵守共同的<a href="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">错误报告规范</a>是很有必要的。</p>
|
||||
|
||||
<h2>获取Trac账户</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="account" name="accout">Getting a Trac account</a></h2>
|
||||
<p>为了提交任务单，您需要在<a href="http://dev.haiku-os.org/register" title="Register at Haiku's Bugtracker">Haiku的错误跟踪系统</a>中注册一个账户。
|
||||
<br />
|
||||
在新建账户时，你需要<b>提供自己的电子邮箱</b> ，否则您将不具有基本的任务单修改权限。之后，您一定要保证<b>检查您的垃圾邮件文件夹</b>，因为所有重要的验证邮件都会被发送到那儿去。</p>
|
||||
|
||||
<h2>创建错误报告</h2>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="report" name="report">Creating a bug report</a></h2>
|
||||
<p>在报告一个错误之前，请您<a href="http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority">确保</a>该错误报告之前不存在。你可以使用<a href="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">查找</a>功能来查找其是否存在。
|
||||
<br />
|
||||
在确定它是一个独特的错误之后，您需要尽可能的找出有关的详细信息：</p>
|
||||
<ul>
|
||||
<li><p>Attempt to reproduce your issue on the current revision of Haiku. Pre-built images for testing purposes are <a href="http://haiku-files.org/">available</a>.</p></li>
|
||||
<li><p>包括基本的信息，例如以何种方式测试Haiku（利用真实的硬件，VMware，还是QEMU）。</p></li>
|
||||
<li><p>提及您正在运行的系统的 <acronym title="Subversion, the source code management system we use">SVN</acronym> 发布版本。你可以在桌面栏菜单中的 '<i>About This System...</i>' 中找出相关信息。</p></li>
|
||||
<li><p>Mention which revision from <acronym title="Subversion, the source code management system we use">SVN</acronym> you are running. You can find this information in <span class="menu">About Haiku...</span> from the Deskbar menu. Also mention what kind of Haiku build you are testing (gcc2, gcc4, gcc2hybrid, gcc4hybrid). The downloadable images are named accordingly, for a self-built image you should know how you built it.</p></li>
|
||||
<li><p>描述您所遇到的问题。尽量把问题讲得精确和明白：描述详细的系统行为反馈，和您期望的反馈。</p></li>
|
||||
<li><p>描述暴露该错误所需要的操作步骤。这将会有助于开发者重现该错误，并对其进行修复和完善。</p></li>
|
||||
<li><p>附带你所掌握的尽可能多的信息。如果是一个GUI错误，或者图形程序错误，尽量附带出现错误时的屏幕截图。（<span class="key">PRINT</span> 键保存了一个<acronym title="Portable Network Graphics image format">PNG</acronym> 图像到 <span class="path">/boot/home/</span>）。</p></li>
|
||||
<li><p>Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to take a screenshot by pressing the <span class="key">PRINT</span> key.</p></li>
|
||||
</ul>
|
||||
|
||||
<h3>软件错误</h3>
|
||||
<p>如果出现了程序崩溃，您应该从弹出的警告窗口中启动调试程序。 在启动的调试终端中，输入<span class="cli">bt</span>，你将会创建关于调试信息的“回溯”，然后你应该把它复制到您的错误报告中。</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="app" name="app">Application bugs</a></h2>
|
||||
<p>When an application crashed, you should invoke the debugger from the alert that pops up. This will open a Terminal window with gdb (the GNU debugger) running in it. Entering <span class="cli">bt</span>, you create a "backtrace" that you should copy in its entirety (including the part before you entered the <span class="cli">bt</span> command) and attach it to the ticket.</p>
|
||||
|
||||
<h3>硬件错误</h3>
|
||||
<p>如果遇到了硬件或者驱动相关的错误，您应该附带下列信息：</p>
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="server" name="server">Server bugs</a></h2>
|
||||
<p>When vital servers like the app server, the registrar or the input server crash, you won't see the usual crash alert. Instead the whole screen will be cleared white and a gdb session will be started, its output appearing directly on screen. Likely you will still be able to move the mouse, which will overwrite the white and gdb output on screen. Applications still running (like ProcessController or the clock in the Deskbar) might also draw over the debugger output on screen.<br />
|
||||
Besides everything being more ugly and inconvenient, basically the same applies as for application bugs. Most importantly procure a back trace (<span class="cli">bt</span> command). You may need to take a picture of the screen with a digital camera, since you won't be able to copy the text anywhere.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kernel" name="kernel">Kernel bugs</a></h2>
|
||||
<p>Kernel bugs are usual the ones with the most severe effects while at the same time being the hardest to debug. There are different kinds of symptoms, which most likely point to a kernel or driver issue:</p>
|
||||
<ul>
|
||||
<li><span class="cli">listdev</span> - 有关您的硬件的详细列表，包括提供商和PCI ID。类似于Linux下的 <span class="cli">lshw</span> 和 <span class="cli">lspci</span> 。</li>
|
||||
<li><span class="cli">listusb -v</span> - 如果存在USB相关的问题；类似于Linux下的 <span class="cli">lsusb</span>。</li>
|
||||
<li><span class="cli">open /var/log/syslog</span> - Haiku主要的系统日志，近似于在启动期间的屏幕调试。使用 <span class="cli">open</span> 命令，您可以把在文本编辑器中把系统日志中重要的部分裁剪下来。</li>
|
||||
<li><span class="cli">listimage | grep drivers/</span> - 列出所有使用的驱动。</li>
|
||||
<li><span class="cli">ints</span> - 只在 <i>内核调试状态</i> 下才可用（参见下文）。它显示了中断的使用情况，而由不同的硬件所共享的中断并不是很多。</li>
|
||||
<li><p>The system enters kernel debugging land (KDL) on its own volition. The upper part of the screen is cleared white and several lines of text are printed on it. The second line says "<i>Welcome to Kernel Debugging Land...</i>", the one above it states the immediate reason for entering KDL.</p></li>
|
||||
<li><p>The system reboots spontaneously.</p></li>
|
||||
<li><p>The system freezes completely. You can't move the mouse and no application draws anything anymore. An important test in that situation is, whether you still can enter KDL via the shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> (<span class="key">SysReq</span> being <span class="key">PRINT</span> on most keyboards). Wait at least a minute to see, if anything happens.</p></li>
|
||||
<li><p>The system doesn't boot up correctly. It may reboot spontaneously or stop at some point (e.g. at some icon of the boot screen). In the latter case also try <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.</p></li>
|
||||
<li><p>The whole system or some piece of hardware doesn't behave correctly. For example, it could be very slow, errors occur, or something doesn't work at all. If some hardware doesn't work at all, the first obvious check is whether Haiku supports it at all at the moment (e.g. ask on a mailing list or a forum).</p></li>
|
||||
</ul>
|
||||
<p>您在终端中输入这些命令，在每个命令后面添加 <span class="cli"> > output.txt</span> 。 然后命令输出的结果就被重定向到一个称为 “output.txt” 的文本文件；您可以把它附带到您的错误报告或者邮件中。</p>
|
||||
<p>Note that while only the last point seems to indicate hardware relation, all the other symptoms could be caused by a bug in a hardware driver as well. If you have a suspicion what piece of hardware or corresponding driver might have to do with the problem, check whether removing/disabling the hardware or the driver makes a difference. For example, if you suspect Wifi you may find that your BIOS has an option to disable it. Or if not, you could remove the responsible Wifi driver from your Haiku installation (in <span class="path">/boot/system/add-ons/kernel/drivers/bin</span>).</p>
|
||||
|
||||
<h3>内核调试 - KDL</h3>
|
||||
<p>如果某些底层的系统组件发生了崩溃，您可能就会进入了内核调试状态。您也可以有意识的使用 <span class="key">ALT</span><span class="key">SysReq</span><span class="key">D</span>（<span class="key">SysReq</span> 在多数键盘中都是 <span class="key">PRINT</span>）来进入内核调试状态。</p>
|
||||
<ul>
|
||||
<li><span class="cli">co</span> - 如果可能的话，系统将会结束内核调试状态，返回正常的系统操作界面。</li>
|
||||
<li><span class="cli">int</span> - 将会显示中断使用情况（如上所述）。</li>
|
||||
<li><span class="cli">bt</span> - 显示一个调试信息的回溯，详细的给出了崩溃发生的地方。</li>
|
||||
</ul>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="kdl" name="kdl">Kernel Debugging Land - KDL</a></h3>
|
||||
<p>If the system hasn't entered KDL by itself, you can do that intentionally by invoking the keyboard shortcut <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span>.<br />
|
||||
Note that in KDL your keyboard may not work. PS/2 keyboards always do, USB keyboards connected via UHCI controllers do only, if one has entered KDL via the keyboard shortcut at least once. USB OHCI is not supported at the moment.</p>
|
||||
<p>KDL itself is a kind of a shell. One can execute commands that print information about the system. The following commands might be of interest:</p>
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td><span class="cli">bt</span> (aka sc)</td><td> </td><td>Prints a back trace. If the system entered KDL on its on volition, always enter that one.</td></tr>
|
||||
<tr><td><span class="cli">ints</span></td><td> </td><td>Shows the handled and unhandled hardware interrupts.</td></tr>
|
||||
<tr><td class="onelinetop"><span class="cli">co</span> (aka continue)</td><td> </td><td>Leaves the kernel debugger and continues normal operation of the system, if that is possible.</td></tr>
|
||||
<tr><td><span class="cli">reboot</span></td><td> </td><td>Reboots the system immediately. You will lose all unsaved data and even those that have been saved, but have not yet been written back to disk.</td></tr>
|
||||
</table>
|
||||
<p>For more information, see the article <a href="http://www.haiku-os.org/documents/dev/welcome_to_kernel_debugging_land">Welcome to Kernel Debugging Land</a>.</p>
|
||||
<p>The KDL output is written to the serial port (if you have one, a respective cable, and a second computer to connect with, you can capture the output there via a terminal program) and to the syslog. If you can't leave KDL it won't be written to the syslog file, though. There's a boot loader debug option that allows you to capture it nonetheless (see below).</p>
|
||||
|
||||
<h2>下一步？</h2>
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="syslog" name="syslog">Syslog</a></h3>
|
||||
<p><b>This is the preferred method for gaining information from a non-booting system.</b><br />
|
||||
The syslog (short for system log) contains valuable information about what has happened in your system, including the output of KDL sessions. It's usually a good idea to attach it to the kernel related Trac ticket. The syslog is written to the file <span class="path">/boot/common/var/log/syslog</span>. Since writing to a file requires a working system, the most recent output might not have made it to the syslog when a kernel problem occurs (particularly on spontaneous reboots or uncontinuable KDL sessions).</p>
|
||||
<p>The option <span class="menu">Enable debug syslog</span> in the boot loader's <span class="menu">Debug menu</span> makes the syslog somewhat persistent in memory. By default the option is enabled. "Somewhat persistent" means that it survives a reset and will still be accessible when you enter the boot loader menu directly afterwards. Booting an operating system (Haiku definitely, others likely) destroys the information, though. So you have to enter the boot loader menu by holding down <span class="key">SHIFT</span> while booting.<br />
|
||||
In the boot loader's <span class="menu">Debug menu</span> you should now find the entries <span class="menu">Display syslog from previous session</span> and <span class="menu">Save syslog from previous session</span>. The former displays the syslog on screen, the latter allows you to save it as a file to disk. Note that at the moment only FAT32 volumes are supported for saving the file. If you want to use a USB stick, but have plugged it in too late so that it isn't recognized yet, you can reset the machine and re-enter the boot loader menu. But again: Don't accidentally boot any operating system or the data will be lost.</p>
|
||||
|
||||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="onscreen" name="onscreen">On screen debug output</a></h3>
|
||||
<p><b>The on-screen debug output is useful only for debugging very specific issues and is known to have (timing) issues. Don't use it, if you don't have to.</b><br />
|
||||
This is only relevant when Haiku fails to boot on your machine and the <span class="menu">Debug syslog option</span> doesn't work for some reason. Before the Haiku boot logo appears, hold <span class="key">SHIFT</span> to enter the boot loader menu. Select <span class="menu">Select safe mode options</span>. Near the bottom, <span class="menu">[ ] Enable on screen debug output</span> will be listed. (Note: The other options could be enabled in an attempt to boot Haiku. If Haiku will boot only when one or more options are activated, be sure to mention which ones.)<br />
|
||||
Finally select <span class="menu">Return to main menu</span> and then <span class="menu">Continue booting</span>.<br />
|
||||
One or more pages of text will display on the screen, only the last few lines need to be included on your ticket. There's more information on the <a href="../../../userguide/zh_CN/bootloader.html">Boot Loader</a>.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="hardware" name="hardware">Hardware/Driver bugs</a></h2>
|
||||
<p>When dealing with a hardware/driver related bug, you should attach the following information as text files:</p>
|
||||
|
||||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||||
<tr><td>- <span class="cli">listdev</span></td><td> </td><td>A detailed listing of your hardware, including vendor and pci id's, similar to Linux' <span class="cli">lshw</span> and <span class="cli">lspci</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">listusb -v</span></td><td> </td><td>Assuming its a USB related issue, similar to <span class="cli">lsusb</span>.</td></tr>
|
||||
<tr><td>- <span class="cli">open /var/log/syslog</span></td><td> </td><td>The primary system log used by Haiku, akin to on screen debugging during boot. With the <span class="cli">open</span> command you can crop down the relevant part of the syslog in a text editor.</td></tr>
|
||||
<tr><td class="onelinetop">- <span class="cli">listimage | grep drivers/</span></td><td> </td><td>Lists all used drivers.</td></tr>
|
||||
<tr><td>- <span class="cli">ints</span></td><td> </td><td>Only available within <i>Kernel Debugging Land</i> (see above). Shows interrupt usage. There shouldn't be too many that are shared by different devices.</td></tr>
|
||||
<tr><td colspan="3">- On screen debug output (a safe mode boot time option).</td></tr>
|
||||
</table>
|
||||
|
||||
<p>The first four commands are entered into Terminal. Add a <span class="cli"> > output.txt</span> after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.</p>
|
||||
|
||||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||||
<a id="next" name="next">What's next?</a></h2>
|
||||
<p>在您提交了错误报告之后，开发人员将会检查您的错误，然后尝试进行修复。但是需要注意的是，我们所有的人员都是志愿者，有时候一个错误报告可能会很长时间没有人来进行回答。如果可以的话，添加新的信息将会有助于早点修复错误，但是请不要添加非描述性的评论来将“炒热”该错误。</p>
|
||||
<p>切记，提交错误报告不是花些很少的时间写个报告的事。如果您提交了一个错误，然后您属于Haiku开发过程中的一部分。开发人员在解决您的错误过程中可能会遇到问题，因此请你一定要始终关注该错误，然后回答相关的问题。如果该问题没有“fixed”，你的任务就没有“done”。</p>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user