<a href="ubi.html#L_attachmtd">here</a>).</p>
-<h3>Enable debugging</h3>
-
-<p>Enable UBI debugging support in the configuration menu
-(the "<b>UBI debugging</b>" check-box). When debugging is enabled, UBI
-prints more information about errors, and adds extra assertions in the code
-which may help to catch bugs.</p>
-
-<p>Note, if you enable the <b>UBI debugging</b> option, UBIFS will not flood
-syslog with its messages. It will just do some light-weight self-checks, and
-it will be more verbose in case of errors. The overhead of having <b>only</b>
-debugging enabled is very low. But if you enable other UBI debugging options,
-the situation changes (see below).</p>
-
-<p>In many cases, it is enough to just enable debugging. But sometimes it is
-also useful to enable extra-self checks, which make sure internal data
-structures are consistent and may catch the problem much earlier then it would
-have been noticed otherwise. Please, mark the "<b>Extra self-checks</b>"
-check-box to enable the self-checks. Self-checks make UBI considerably slower.
-For example, UBI attach time may become very long.</p>
-
<h3>Debugging messages</h3>
<p>Sometimes it is necessary to make UBI print about what it is doing. You may
-enable various UBI debugging messages in the "<b>Additional UBI debugging
-messages</b> configuration menu. When the messages are enabled, UBI prints a
-lot to the kernel ring buffer and this makes it slower. The following section
-describes few tricks and techniques which might be useful when debugging with
-kernel messages.</p>
-
-<h3><a name="L_how_debug_printks">Capturing debugging messages</a></h3>
-
-<p>The Linux kernel has internal ring buffer where all the debugging prints go.
-User-space applications like <code>syslogd</code> usually read data from the
-ring buffer, do further processing and the prints usually end up in the system
-log file. When the UBI debugging messages are enabled, it prints huge amount of
-messages. What happens is that the user-space processes are unable to fetch
-them from the ring buffer with this pace so most of the messages are just lost.
-Namely, they are just over-written with newer message (the buffer is a "ring").
-There are 2 ways to gather all the messages:</p>
-
-<ol>
- <li>use serial console;</li>
- <li>use very large ring buffer.</li>
-</ol>
-
-<p>The first method is usually appropriate when debugging on a small embedded
-platform connected to a PC via serial line. What you have to be aware of is
-that the messages are printed to the serial console synchronously, which means
-that the system is blocked and waiting for the print operation to be finished.
-So if there are many prints, the system speed becomes limited to the serial
-console baud rate. And obviously, it is recommended to use higher baud rates,
-e.g. 115200.</p>
-
-<p>The UBI debugging messages have "debugging" level 7 and they are usually not
-printed to the console. You may use <code>dmesg -n8</code> command to make all
-kernel messages to go to the console. Another possibility is to boot the kernel
-with <code>ignore_loglevel</code> option, in which makes the kernel print all
-messages to the console unconditionally.</p>
-
-<p>The second method is more appropriate when debugging on a machine with a lot
-of RAM, for example on a desktop PC with a flash emulator. Just make your ring
-buffer large, e.g. 64MiB by booting the kernel with <code>log_buf_len=64M</code>
-option. This will most probably make the ring buffer fit enough messages to
-identify the problem. And because the messages are printed to RAM, this is way
-quicker than the first method.</p>
-
+enable various UBI debugging messages using the "dynamic debug" Linux kernel
+infrastructure. Please, refer to the corresponding
+<a href="ubifs.html#L_debug_msgs">UBIFS section</a> for more information. Below
+is a similar table for UBI.</p>
+
+<table border="2" cellpadding="4" cellspacing="0">
+<tr>
+ <td><b>Message Type</b></td>
+ <td><b>Magic string</b></td>
+</tr>
+<tr>
+ <td>All messages (very noisy)</td>
+ <td>format "UBI DBG" +pf'</td>
+</tr>
+<tr>
+ <td>General messages</td>
+ <td>format "UBI DBG gen" +pf'</td>
+</tr>
+<tr>
+ <td>EBA messages</td>
+ <td>format "UBI DBG eba" +pf'</td>
+</tr>
+<tr>
+ <td>Wear-levelling messages</td>
+ <td>format "UBI DBG wl" +pf'</td>
+</tr>
+<tr>
+ <td>Input/output messages</td>
+ <td>format "UBI DBG io" +pf'</td>
+</tr>
+<tr>
+ <td>Attach messages</td>
+ <td>format "UBI DBG bld" +pf'</td>
+</tr>
+</table>
+
+
+<h3>Extra self-checks</h3>
+
+<p>UBI contains various internal self-check functions which are often
+very useful for debugging or testing. Please, refer the corresponding
+<a href="ubifs.html#L_how_debug_self_checks">UBIFS self-checks</a>
+section for more information, because UBI extra self-checks are very
+similar, just a bit simpler. Here is a similar table for UBI.</p>
+
+<table border="2" cellpadding="4" cellspacing="0">
+<tr>
+ <td><b>Check type</b></td>
+ <td><b>File name</b></td>
+</tr>
+<tr>
+ <td>General checks.</td>
+ <td><code>chk_gen</code></td>
+</tr>
+<tr>
+ <td>I/O checks. Does things like verifying that eraseblocks contain
+ only 0xFF bytes after erasure, verifies that all writes go to an empty
+ flash area, verifies each writes by reading the data back and comparing
+ to the original.</td>
+ <td><code>chk_io</code></td>
+</tr>
+</table>
<h2><a name="L_how_send_bugreport">How do I send an UBI bug report?</a></h2>
-<p>Before sending a bug report:</p>
-<ul>
- <li>make sure you use up-to-date UBI; pull the latest UBI patches
- from corresponding UBIFS back-port trees if needed, see
- <a href="../doc/ubifs.html#L_source">here</a> (we do not maintain separate UBI
- back-ports trees, and UBIFS trees also contain all UBI updates); no one
- is interested in digging already fixed problems;</li>
-
- <li>make sure you have compiled kernel symbols in
- (<code>CONFIG_KALLSYMS_ALL=y</code> in <code>.config</code>);</li>
-
- <li>enable UBI debugging (<code>CONFIG_MTD_UBI_DEBUG=y</code>
- in <code>.config</code>); please, mark only the "<b>UBI debugging</b>"
- check-box and do not mark other debugging sub-options like "UBI
- debugging messages" unless you know what you are doing.</li>
-
- <li>include all the messages UBI prints, not only those you see at
- the console, but also those you see when running <code>dmesg</code>; or
- before running your UBI test, which reproduces the error, just
- invoke <code>dmesg -n8</code> command to make all kernel messages
- to go to the console; another possibility is to boot the kernel
- with <code>ignore_loglevel</code> option, in which makes the kernel
- print all messages to the console unconditionally;
- <a href="ubi.html#L_how_debug">this</a> section contains some
- more information about how the messages can be collected.</li>
-
- <li>provide UBI configuration from you your <code>.config</code>
- file, or just attach whole file;</li>
-
- <li>describe your flash device, attach the "<code>mtdinfo&nbsp;-a</code>"
- output (or the less useful "<code>cat&nbsp;/proc/mtd</code>" output);</li>
-
- <li>specify which kernel version you are using; if your kernel is not
- the latest one, please, explicitly tell whether you updated UBI by
- pulling one of the back-port trees or not; if you did not, you will
- probably be asked to do this, depending on the problem;</li>
-
- <li>describe how the problem can be reproduced;</li>
-</ul>
-
-<p>Please, attach all the bug-related messages including the UBI messages from
-the kernel ring buffer, which may be collected using the <code>dmesg</code>
-utility or using <code>minicom</code> with serial console capturing. Please,
-describe how the problem can be reproduced (if it can be). The bug report
-should be sent to the <a href="../mail.html">MTD mailing list</a>. Please,
-<b>do not</b> send private e-mails to UBI authors, always CC the mailing
-list!</p>
+<p>Basically the same way as an
+<a href="ubifs.html#L_how_send_bugreport">UBIFS bug report</a></p>.
<INCLUDE file="../inc/footer.tmpl" />
projects / mtd-www.git / commitdiff