报告错误

由于我们的开发人员不可能测试每种硬件组合和每种不同的系统交互方式，所以我们依赖于用户，通过用户来给予我们Haiku的运行情况。由于Haiku还很年轻，您在使用时很有可能会遇到错误。我们非常感谢您能够分出时间来提交这些错误报告。我们可以共同一步一步的提高Haiku的性能。

为了确保我们的错误跟踪系统的有效性，遵守共同的错误报告规范是很有必要的。

获取Trac账户

为了提交任务单，您需要在Haiku 的错误跟踪系统中注册一个账户。
新建账户时，您需要提供自己的电子邮箱 ，否则您将不具备基本的任务单修改权限。完成之后，您必须要保证检查您的垃圾邮箱，因为所有重要的验证邮件可能都会被发送到那里。

创建错误报告

在报告一个错误之前，请您确保该错误报告之前不存在。你可以使用查找功能来查找其是否存在。
在确定它是一个独特的错误之后，您需要尽可能的找出有关的详细信息：

尝试在当前版本的Haiku系统中重现您的问题。有许多用于测试的预编译镜像都是可用的。
包括基本的信息，例如以何种方式测试 Haiku（利用真实的硬件，VMware，还是 QEMU）。
Mention which revision you are running. You can find this information in About Haiku... 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.
描述您所遇到的问题。尽量把问题讲得精确和明白：详细的描述系统的行为反馈，和您期望的反馈。
描述出现该错误所需要的操作步骤。这将会有助于开发者重现该错误，并对其进行修复和完善。
附带你所掌握的尽可能多的信息。如果是一个GUI错误，或者其中的程序错误，尽量使用 PRINT 键来截取当时的屏幕图像。

程序错误

如果程序发生崩溃，您需要从弹出的警告窗口中启动调试程序。它将会打开一个运行gdb（GNUdebugger）的终端窗口。输入 bt，您将会创建一个有关调试信息的“回溯”，然后您需要把它完整的复制出来（包括您输入 bt 命令之前终端中显示的内容），附加到错误报告中。

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.
Besides everything being more ugly and inconvenient, basically the same applies as for application bugs. Most importantly procure a back trace (bt 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.
Depending on what exactly crashed, you can try to save a crash report on the Desktop with save-report and then press the power button once to try shutting cleanly down.

内核错误

内核错误通常都是危害效果最大的错误，同时也是最难调试的错误。下面几种情形，通常都可能是内核或者驱动问题：

系统自动进入了内核调试状态（KDL），屏幕上方显示为白色，并且打印出几行文本。文本第二行显示为“Welcome to Kernel Debugging Land...”，而第一行则声明了进入内核调试状态的实时原因。
系统自动重新启动。
系统完全冻结。您无法移动鼠标，并且屏幕中无任何程序显示。在此情况下，重要的是测试能否使用快捷键 ALT SysReq D 进入内核调试状态（在多数键盘上，SysReq 是 PRINT 键）。然后等待至少一分钟，查看系统反应状态。
系统无法实现正确引导。它可能自动重启，或停止在某个步骤（例如，某个启动图标）。对于后一种情况，可以尝试使用快捷键 ALT SysReq D。
整个系统或者部分硬件无法正确运行。例如，系统运行缓慢，出现错误，或者完全无法运行。如果某个硬件完全无法工作，首要的是检查Haiku目前是否支持该硬件（例如，在邮件列表或论坛中进行询问）。

需要注意的是，只有最后这种情况与硬件相关，而所有其他的问题也可能由硬件驱动中的错误引起。如果您对引起该问题的硬件或相关的驱动有所疑问，您可以检查删除/禁用该硬件或驱动是否会产生影响。例如，如果您怀疑无线网络有问题，您会发现 BIOS 中有可禁用它的选项。如果其中没有该选项，您可以从安装的 Haiku 中删除相关的无线网络驱动（参见引导程序）。

内核调试 - KDL

如果系统没有自动的进入内核调试状态，您也可以有意识的使用 ALT SysReq D 快捷键手动进入。
需要注意的是，在内核调试状态，您的键盘可能会无法工作。PS/2 键盘通常都能够正常工作；对于 UHCI 控制器连接的 USB 键盘，您至少需要使用快捷键进入内核调试状态一次，它才可用。但是对于 USB OCHI，目前还未实现支持。

KDL 本身是 shell 中的一类。它可以执行命令，打印系统信息。下面是一些感兴趣的命令：

bt (aka sc)		打印回溯信息。如果系统自主进入内核调试状态，通常需要输入该命令。
ints		显示已处理和未处理的硬件中断。
co (aka continue)		离开内核调试状态；如果可能的话，继续正常的系统操作。
reboot		立即重启系统。您将会丢失所有未保存的数据，甚至包括那些已经保存，但是还未写入硬盘的数据。

获取更多信息，请参阅欢迎使用内核调试工具。

KDL输出信息将会写入到串行端口（如果您拥有另一台与之相连接的计算机，您可以通过中断程序重定向输出信息）和系统日志。如果您无法离开KDL，它将无法写入系统日志文件。尽管如此，还有一个系统引导调试选项，允许您捕获系统信息（参阅下文）。

您可以从KDL输出中生成 QR 代码，而它们可以通过智能手机或相似设备转换为文本内容。有关如何使用该功能从 KDL 获取数据，详情参考 QR Encode your KDL Output 。

系统日志

这是从无法引导的系统中获取信息的首选方法。
系统日志（syslog，system log 的缩写）中包含了关于系统问题的有用信息，包括 KDL 会话的输出信息。通常将它附带到有关内核问题的报告中是个不错的主意。系统日志将会写入文件 /boot/system/var/log/syslog。由于写入文件需要系统处于运行状态，因此当内核出现问题时（尤其是，系统自动重启，或者无法持续 KDL 会话），最新的输出信息可能无法写入日志文件。

The option Enable debug syslog in the boot loader's Debug menu makes the syslog persistent. If the option Save syslog from previous session during boot is activated in the boot loader options (as it is by default), you'll find the syslog of your last session as /boot/system/var/log/previous_syslog.
If you're not able to boot to get to the previous_syslog, you have to enter the boot loader menu by holding down SHIFT while booting.
In the boot loader's Debug menu you should find the entries Display syslog from previous session and Save syslog from previous session. 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. Note: Don't accidentally boot any operating system or the data will be lost.

屏幕调试

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.
This is only relevant when Haiku fails to boot on your machine and the Debug syslog option doesn't work for some reason. Before the Haiku boot logo appears, hold SHIFT to enter the boot loader menu. Select Select safe mode options. Near the bottom, [ ] Enable on screen debug output 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.)
Finally select Return to main menu and then Continue booting.
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 Boot Loader.

硬件错误

在处理有关硬件/驱动的问题时，您需要在报告中附带下面的信息：

- listdev		给出所有硬件的详细列表，包括提供商和 PCI ID；类似于Linux下的 lshw 和 lspci 。
- listusb -v		假如是有关 USB 的问题，它类似于Linux下的 lsusb。
- open /var/log/syslog		Haiku的主要系统日志，类似于引导过程中的屏幕调试信息。您可以使用 open 命令在文本编辑器中获取到系统日志中相关的部分。
- listimage \| grep drivers/		列出所有使用的驱动。
- ints		只在内核调试状态可用（参阅下文）。它用显示中断使用情况。不可能有许多由不同硬件共享的中断。
- 屏幕调试输出（引导时间选项的安全模式）。

前四个命令需要在终端中进行输入。在命令后添加 > output.txt ，然后输出的信息将会重定向到“output.txt”文本文件，您可以将其附带到您的错误报告或者邮件。

下一步

在您提交错误报告之后，开发人员将会检查您的错误，然后尝试进行修复。但是需要注意的是，我们所有的人员都是志愿者，有时候一个错误报告可能会很长时间没有人来进行回复。如果可以的话，添加新的信息将会有助于早点修复错误，但是请不要添加非描述性的评论来将“炒热”该错误。

切记，提交错误报告不是花很少时间写个报告，然后就结束了。如果您提交了一个错误，然后您就是Haiku开发过程中的一员。开发人员在解决您的错误过程中可能会遇到问题，因此请你一定要始终关注该错误，然后回答相关的问题。如果该问题没有“fixed”，你的任务就没有“done”。