From patchwork Sun Aug 22 18:30:32 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Artem Bityutskiy X-Patchwork-Id: 62393 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 91544B6EFE for ; Mon, 23 Aug 2010 04:32:05 +1000 (EST) Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1OnFJa-0004Ws-6N; Sun, 22 Aug 2010 18:30:42 +0000 Received: from mail-fx0-f49.google.com ([209.85.161.49]) by bombadil.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1OnFJW-0004WZ-1W for linux-mtd@lists.infradead.org; Sun, 22 Aug 2010 18:30:39 +0000 Received: by fxm12 with SMTP id 12so3156544fxm.36 for ; Sun, 22 Aug 2010 11:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=3cjJOx54CnNlvzVM0/Xr2cduuekgLaH0GvVKClpxH90=; b=q9dc82husaMg5QKvR1zQhPR6oJ6NaJ8FGJQ6dmYX7JFZYLoGilVYc2RH2w8HdzRJ9j WGHiQaFUcBk9vlVd3UMZ32wB5sSyJM+mQZeKNyncbY1EB05ZCvMHQO9riUyGGaAYP/E4 QeyABdwobYR2sGxaoT7lHiPIsYs+HV824BCgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; b=wB6JxCR5Bgh10yAUsAEbkdsn5X+QFxUq70qFQDqmAWCJmGp/VlClPXxdL9AiWz3Xqc aZ1f+MTlv+7rubWHoceaXufum4qckfdmjuG85mtPoeZPrnTwVP+++4LKf6qSB6GWkMUK kq5LDxEkHK7/ruKMVgyLOEFDKWdnW1qvCW+6I= Received: by 10.223.104.136 with SMTP id p8mr3156354fao.105.1282501835005; Sun, 22 Aug 2010 11:30:35 -0700 (PDT) Received: from [192.168.255.16] (a91-152-69-107.elisa-laajakaista.fi [91.152.69.107]) by mx.google.com with ESMTPS id r4sm2112356faa.19.2010.08.22.11.30.33 (version=SSLv3 cipher=RC4-MD5); Sun, 22 Aug 2010 11:30:34 -0700 (PDT) Subject: Re: ubi_eba_init_scan: cannot reserve enough PEBs From: Artem Bityutskiy To: "Matthew L. Creech" In-Reply-To: <1280243535.3021.29.camel@localhost.localdomain> References: <1280121714.14917.40.camel@localhost> <1280243535.3021.29.camel@localhost.localdomain> Date: Sun, 22 Aug 2010 21:30:32 +0300 Message-ID: <1282501832.16502.97.camel@brekeke> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 (2.30.2-4.fc13) X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20100822_143038_277571_8B23BB00 X-CRM114-Status: GOOD ( 31.31 ) X-Spam-Score: 2.1 (++) X-Spam-Report: SpamAssassin version 3.3.1 on bombadil.infradead.org summary: Content analysis details: (2.1 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is freemail (dedekind1[at]gmail.com) 2.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (dedekind1[at]gmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.161.49 listed in list.dnswl.org] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: linux-mtd@lists.infradead.org X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dedekind1@gmail.com List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On Tue, 2010-07-27 at 18:12 +0300, Artem Bityutskiy wrote: > > Certainly. I enabled all the relevant UBI and UBIFS debugging options > > that I saw, along with internal self-checks, but there's still not a > > whole lot of output. Full console dump is attached - this is a > > different device than the first, but exhibits the same problem. > > I'm sure your ring buffer contains more information. This is one of the > reasons I gave you the above link - it explains that not all messages go > to console and how to get all meassages. Try to use dmesg. In UBIFS code > I see that 'ubifs_read_node()' calls 'dbg_dump_node()' which should dump > the node. > > But '255' is 0xFF, so probably UBIFS read all 0xFF. This may be an UBIFS > bug, or some corruption, difficult to say. For some reason the place > where a valid znode should live is erased. > > May be if I have a NAND dump of your broken device I can look at it, but > do not promise anything, and I'm also on holiday :-) Could you please dump LEB 5586 and check whether it is really erased or not? Please, apply the following patch: From feb1616809b0bebeaf0cb596fdb5d715f6d75700 Mon Sep 17 00:00:00 2001 From: Artem Bityutskiy Date: Sun, 22 Aug 2010 21:27:30 +0300 Subject: [PATCH] UBIFS: improve error reporting when reading bad node When an error happens during validation of read node, the typical situation is that the LEB we read is unmapped (due to some bug). It is handy to include the mapping status into the error message. Signed-off-by: Artem Bityutskiy --- fs/ubifs/io.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c index bcf5a16..9432431 100644 --- a/fs/ubifs/io.c +++ b/fs/ubifs/io.c @@ -815,7 +815,8 @@ int ubifs_read_node(const struct ubifs_info *c, void *buf, int type, int len, return 0; out: - ubifs_err("bad node at LEB %d:%d", lnum, offs); + ubifs_err("bad node at LEB %d:%d, LEB mapping status %d", lnum, offs, + ubi_is_mapped(c->ubi, lnum)); dbg_dump_node(c, buf); dbg_dump_stack(); return -EINVAL;