索引

获取Trac账户 创建错误报告 软件错误 服务错误 内核错误 内核调试- KDL 系统日志 屏幕调试 硬件错误 下一步？

报告错误

由于我们的开发人员不可能测试每种硬件组合和每种不同的系统交互方式，所以我们依赖于用户，通过用户来给予我们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 (x86_gcc2, x86_64). The downloadable images are named accordingly, for a self-built image you should know how you built it.

• 描述您所遇到的问题。尽量把问题讲得精确和明白：详细的描述系统的行为反馈，和您期望的反馈。

• 描述出现该错误所需要的操作步骤。这将会有助于开发者重现该错误，并对其进行修复和完善。

• 附带你所掌握的尽可能多的信息。如果是一个GUI错误，或者其中的程序错误，尽量使用 PRINT 键来截取当时的屏幕图像。

程序错误

When an application crashed, you can either save a report or write a core file (both saved to the Desktop) that you can attach to a bugreport, or you can evoke the Debugger.

服务错误

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 the Debugger will be started in text-mode, its output appearing directly on screen. Likely you will still be able to move the mouse, which will overwrite the white and Debugger 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 or write-core for a core file, and then press the power button once to try shutting cleanly down. If the power button doesn't work, there are also the commands shutdown and reboot.

内核错误

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

• 系统自动进入了内核调试状态（KDL），屏幕上方显示为白色，并且打印出几行文本。文本第二行显示为“Welcome to Kernel Debugging Land...”，而第一行则声明了进入内核调试状态的实时原因。

• 系统自动重新启动。

• 系统完全冻结。您无法移动鼠标，并且屏幕中无任何程序显示。在此情况下，重要的是测试能否使用快捷键 ALT SysReq D 进入内核调试状态（在多数键盘上，SysReq 是 PRINT 键）。然后等待至少一分钟，查看系统反应状态。

• 系统无法实现正确引导。它可能自动重启，或停止在某个步骤（例如，某个启动图标）。对于后一种情况，可以尝试使用快捷键 ALT SysReq D。

• 整个系统或者部分硬件无法正确运行。例如，系统运行缓慢，出现错误，或者完全无法运行。如果某个硬件完全无法工作，首要的是检查Haiku目前是否支持该硬件（例如，在邮件列表或论坛中进行询问）。

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

内核调试 - KDL

If the system hasn't entered KDL by itself, you can do that intentionally by invoking the keyboard shortcut ALT SysReq D (SysReq being the Print key, normally).
Note that in KDL your keyboard may not work. PS/2 keyboards always do, with USB keyboards it depends on the type of USB controller (UHCI/EHCI). Generally, the keyboard should be plugged into the port directly, not via any hubs. In some circumstances, the keyboard only works if one has entered KDL via the keyboard shortcut at least once. USB OHCI is not supported at the moment.

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

bt (等同 sc)		打印回溯信息（即堆栈抓取）。如果系统自主进入内核KDL 状态，通常会自动打印回溯信息。如果没有显示，或者部分内容超出范围（如，堆栈跟踪太长，以至于超出屏幕），您可以输入该指令；并且您只能通过抓取屏幕截图为开发者提供相关信息。
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 会话），最新的输出信息可能无法写入日志文件。

引导程序的 Debug menu 中的Enable debug syslog 选项可以使系统日志持久存在。如果启用了引导菜单中的 Save syslog from previous session during boot 选项（默认情况下启用），您可以在 /boot/system/var/log/previous_syslog 中找到最近登陆会话的系统日志。
如果您无法启动并获取最近的日志文件 previous_syslog，您需要在引导时按下 SHIFT 进入引导程序菜单。
在引导程序的 Debug menu 中，您可以找到 Display syslog from previous session 和 Save syslog from previous session 两个入口。前者将系统日志显示于屏幕，后者允许您将其保存到硬盘。需要注意的是，目前只有 FAT32 卷支持保存该文件。如果您使用 USB 磁盘，但是插入晚了，可能它将不被识别；您可以重置机器，然后再次进入引导程序菜单。但是还要注意：不要无故的启动任何操作系统，否则数据将会丢失。

屏幕调试

屏幕调试输出仅对调试特殊问题有用，而且自身也有（定时）问题。若非必须，不要使用它。
只有当 Haiku 引导机器失败，而且 Debug syslog option 出于某些原因无法使用，它才具有重要意义。 在Haiku的引导徽标出现之前，按下 SHIFT 进入引导程序菜单。 选择 Select safe mode options。 在接近屏幕底部，[ ] Enable on screen debug output 将会列出。（注意：如果尝试启动Haiku，您可以启用另一个选项。如果 Haiku 只有在启用多个选项时才可以启动，您在错误报告中一定要给出这些选项。）
最后，选择 Return to main menu 和 Continue booting。
在屏幕上将会显示一页或者多页文本，只有最后几行才需要附带到您的错误报告。更多信息，参阅 引导程序。

硬件错误

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

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

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

下一步

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

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