From 1e95d579e3f10fab6a50b7fb68533881d061a403 Mon Sep 17 00:00:00 2001 From: Artem Bityutskiy Date: Sun, 15 Jul 2012 21:34:33 +0300 Subject: [PATCH] UBI: FAQ: update the UBI debugging information Signed-off-by: Artem Bityutskiy --- faq/ubi.xml | 174 +++++++++++++++++++------------------------------- faq/ubifs.xml | 8 +-- 2 files changed, 67 insertions(+), 115 deletions(-) diff --git a/faq/ubi.xml b/faq/ubi.xml index 8af461e..fa988ed 100644 --- a/faq/ubi.xml +++ b/faq/ubi.xml @@ -818,123 +818,77 @@ mtd1: 04000000 00004000 "NAND simulator partition" here).

-

Enable debugging

- -

Enable UBI debugging support in the configuration menu -(the "UBI debugging" 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.

- -

Note, if you enable the UBI debugging 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 only -debugging enabled is very low. But if you enable other UBI debugging options, -the situation changes (see below).

- -

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 "Extra self-checks" -check-box to enable the self-checks. Self-checks make UBI considerably slower. -For example, UBI attach time may become very long.

-

Debugging messages

Sometimes it is necessary to make UBI print about what it is doing. You may -enable various UBI debugging messages in the "Additional UBI debugging -messages 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.

- -

Capturing debugging messages

- -

The Linux kernel has internal ring buffer where all the debugging prints go. -User-space applications like syslogd 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:

- -
    -
  1. use serial console;
    2. -
  2. use very large ring buffer.
    3. -
- -

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.

- -

The UBI debugging messages have "debugging" level 7 and they are usually not -printed to the console. You may use dmesg -n8 command to make all -kernel messages to go to the console. Another possibility is to boot the kernel -with ignore_loglevel option, in which makes the kernel print all -messages to the console unconditionally.

- -

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 log_buf_len=64M -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.

- +enable various UBI debugging messages using the "dynamic debug" Linux kernel +infrastructure. Please, refer to the corresponding +UBIFS section for more information. Below +is a similar table for UBI.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Message TypeMagic string
All messages (very noisy)format "UBI DBG" +pf'
General messagesformat "UBI DBG gen" +pf'
EBA messagesformat "UBI DBG eba" +pf'
Wear-levelling messagesformat "UBI DBG wl" +pf'
Input/output messagesformat "UBI DBG io" +pf'
Attach messagesformat "UBI DBG bld" +pf'
+ + +

Extra self-checks

+ +

UBI contains various internal self-check functions which are often +very useful for debugging or testing. Please, refer the corresponding +UBIFS self-checks +section for more information, because UBI extra self-checks are very +similar, just a bit simpler. Here is a similar table for UBI.

+ + + + + + + + + + + + + + +
Check typeFile name
General checks.chk_gen
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.chk_io

How do I send an UBI bug report?

-

Before sending a bug report:

- - -

Please, attach all the bug-related messages including the UBI messages from -the kernel ring buffer, which may be collected using the dmesg -utility or using minicom with serial console capturing. Please, -describe how the problem can be reproduced (if it can be). The bug report -should be sent to the MTD mailing list. Please, -do not send private e-mails to UBI authors, always CC the mailing -list!

+

Basically the same way as an +UBIFS bug report

. diff --git a/faq/ubifs.xml b/faq/ubifs.xml index ff4e36c..352e2fc 100644 --- a/faq/ubifs.xml +++ b/faq/ubifs.xml @@ -1201,7 +1201,7 @@ a standard PC with the nandsim NAND simulator. Please, refer the available fake MTD devices. -

Debugging messages

+

Debugging messages

Sometimes it is necessary to make UBIFS print about what it is doing. You may enable various UBIFS debugging messages using the "dynamic debug" Linux kernel @@ -1403,10 +1403,8 @@ for UBIFS power-cut testing.

before running your UBIFS test, which reproduces the error, just invoke dmesg -n8 command to make all kernel messages to go to the console; another possibility is to boot the kernel - with ignore_loglevel option, in which makes the kernel - print all messages to the console unconditionally; - this section contains - some more information about how the messages can be collected; + with ignore_loglevel option, which makes the kernel + print all messages to the console unconditionally;
  • describe your flash device, attach the "mtdinfo -a" output (or the less useful "cat /proc/mtd" output);
    • -- 2.49.0