public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Unreadable UBIFS partition after power cuts
Date: Thu, 15 Jan 2015 08:28:38 +0100	[thread overview]
Message-ID: <54B76C26.6010809@denx.de> (raw)
In-Reply-To: <150521CB44B50A4A98049E9C7BAFB0F30D9B8760@DETENEXMB01.delta.corp>

Hello Anton,

Am 14.01.2015 18:12, schrieb Anton Habegger:
> Hello Heiko
>
>> Am 14.01.2015 13:52, schrieb Anton Habegger:
>>> Hello
>>>
>>> We have a PPC MPC5125 device with 64MB NOR flash. The U-boot has to load the kernel and initramfs from a UBIFS partition.
>>> Recently we made an upgrade from U-Boot version V2010.12 to version V2014.10. Now after some regression tests with power cuts, we got an UBIFS state, which is unreadable for U-Boot  version  V2014.10. If I do a tftpboot an mount the UBIFS with linux, there is no problem. It is also very >>strange, that if I downgrade the U-Boot to V2010.12, then it is also no problem with the partition and everything is readable. I tend to say there is probably a regression with the most recent U-Boot version. But I don't know where I can start to find it. I enabled also the DEBUG define, but there >>appears no additional debug message concerning UBIFS. How can I debug this?
>
>> You can enable:
>
>> #undef CONFIG_UBI_SILENCE_MSG
>> #define CONFIG_MTD_DEBUG
>> #define CONFIG_MTD_DEBUG_VERBOSE 1
>
> Now I got output, thank you. I have to investigate more to get a better picture.

Thanks!

>> With which Linux version do you test? U-Boot is synced with linux 3.15 ... so, if you can test it with a kernel >= 3.15 this would be great!
>
> Our device is running with 2.6.34, with the patches from git://git.infradead.org/users/dedekind/ubifs-v2.6.34.git. I'm also able to open mount the image with linux 3.13  (Ubuntu 14.04/x86_64) and the mtdram module.
> As soon the image is once mounted (and recovered) either with 2.6.34 or 3.13, the U-Boot V2014.10 can load it as well.
>
> Here the dmesg output mount with linux 3.13 which succeeds:
> [189672.868677] UBI: attaching mtd0 to ubi0
> [189672.869154] UBI: scanning is finished
> [189672.870359] UBI: attached mtd0 (name "mtdram test device", size 63 MiB) to ubi0
> [189672.870363] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 130944 bytes
> [189672.870366] UBI: min./max. I/O unit sizes: 1/64, sub-page size 1
> [189672.870367] UBI: VID header offset: 64 (aligned 64), data offset: 128
> [189672.870369] UBI: good PEBs: 504, bad PEBs: 0, corrupted PEBs: 0
> [189672.870371] UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
> [189672.870373] UBI: max/mean erase counter: 280/161, WL threshold: 4096, image sequence number: 2041090957
> [189672.870374] UBI: available PEBs: 0, total reserved PEBs: 504, PEBs reserved for bad PEB handling: 0
> [189672.870489] UBI: background thread "ubi_bgt0d" started, PID 50742
> [189689.698048] UBIFS: background thread "ubifs_bgt0_0" started, PID 50750
> [189689.698157] UBIFS: recovery needed
> [189689.699949] UBIFS: recovery completed

This two lines arer interesting ... I see this message also in U-Boot code:

./fs/ubifs/super.c in mount_ubifs() ...

Why does this output not come in U-Boot?
Maybe it is worth to look into this place too ...

bye,
Heiko
> [189689.700308] UBIFS: mounted UBI device 0, volume 0, name "flash"
> [189689.700313] UBIFS: LEB size: 130944 bytes (127 KiB), min./max. I/O unit sizes: 8 bytes/64 bytes
> [189689.700316] UBIFS: FS size: 61674624 bytes (58 MiB, 471 LEBs), journal size 8249472 bytes (7 MiB, 63 LEBs)
> [189689.700318] UBIFS: reserved for root: 0 bytes (0 KiB)
> [189689.700321] UBIFS: media format: w4/r0 (latest is w4/r0), UUID 370BF56B-8A90-443C-B344-BF6BA00A8634, small LPT model
>
>>> Here the output from U-Boot V2014.10:
>>>
>>> => ubi part fs
>>> UBI: attaching mtd1 to ubi0
>>> UBI: scanning is finished
>>> UBI: attached mtd1 (name "mtd=0", size 63 MiB) to ubi0
>>> UBI: PEB size: 131072 bytes (128 KiB), LEB size: 130944 bytes
>>> UBI: min./max. I/O unit sizes: 1/64, sub-page size 1
>>> UBI: VID header offset: 64 (aligned 64), data offset: 128
>>> UBI: good PEBs: 504, bad PEBs: 0, corrupted PEBs: 0
>>> UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
>>> UBI: max/mean erase counter: 280/161, WL threshold: 4096, image
>>> sequence number: 2041090957
>>> UBI: available PEBs: 0, total reserved PEBs: 504, PEBs reserved for
>>> bad PEB handling: 0 => ubifsmount ubi:flash => ubifsls
>>> 	    53549  Mon Dec 01 11:34:08 2014  setup.xml
>>> 	     2051  Wed Nov 19 09:05:49 2014  LOG_Default_000001.csv
>>> 	filldir: Error in ubifs_iget(), ino=44049 ret=ffffffea!
>
>> seems a problem in ubifs_iget() fs/ubifs/super.c ... it returns -EINVAL please debug into this function for a starting point.
>
> Thank you for the hint. I will start from there.
>
> Anton
> ********************************************************************************************************************************
> This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain
> confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
> [Delta Energy Systems]
> ********************************************************************************************************************************
>
>

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

  reply	other threads:[~2015-01-15  7:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-14 12:52 [U-Boot] Unreadable UBIFS partition after power cuts Anton Habegger
2015-01-14 14:57 ` Heiko Schocher
2015-01-14 17:12   ` Anton Habegger
2015-01-15  7:28     ` Heiko Schocher [this message]
2015-01-16 15:10       ` Anton Habegger
2015-01-16 15:21         ` Anton Habegger
2015-01-16 15:42         ` Bill Pringlemeir
2015-01-16 17:47           ` Anton Habegger
2015-01-17 16:06             ` Anton Habegger
2015-01-18 10:07               ` Heiko Schocher
2015-01-19 11:29                 ` Anton Habegger
2015-01-20  7:26                   ` Heiko Schocher
  -- strict thread matches above, loose matches on Subject: below --
2015-01-16 15:38 Anton Habegger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54B76C26.6010809@denx.de \
    --to=hs@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox