From patchwork Mon Jan 16 12:40:54 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Karsten Jeppesen X-Patchwork-Id: 136273 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 200D61007D1 for ; Mon, 16 Jan 2012 23:42:14 +1100 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1Rmlrv-00042w-13; Mon, 16 Jan 2012 12:40:59 +0000 Received: from nm12-vm3.bullet.mail.ne1.yahoo.com ([98.138.91.142]) by merlin.infradead.org with smtp (Exim 4.76 #1 (Red Hat Linux)) id 1Rmlrs-00042i-1f for linux-mtd@lists.infradead.org; Mon, 16 Jan 2012 12:40:56 +0000 Received: from [98.138.90.48] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jan 2012 12:40:55 -0000 Received: from [98.138.226.163] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jan 2012 12:40:54 -0000 Received: from [127.0.0.1] by omp1064.mail.ne1.yahoo.com with NNFMP; 16 Jan 2012 12:40:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 874194.69900.bm@omp1064.mail.ne1.yahoo.com Received: (qmail 84150 invoked by uid 60001); 16 Jan 2012 12:40:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1326717654; bh=xfFBCkUlCsY/44ALo9ynC1hftEeaInf2uj/4lv8KL+8=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mkBK9/ieMpm/dRGjjX1snaPKSROhvWPgNlfVZMLctOJAdbfQhI4s9+uH9L4PWhdot0ModzricIxnBScLEqtD+jee3JnPSvwkzq/IknECAPfS35+oGi0CpLd5ZxePUkSr4VMIzBn6/1JhJKTOI0QcEdumeMf2AFVGgd9HD3/W5kk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6rbQ+oaHMZnhYRZyzoDQjhqdMAI8o52guFwRzHNbxqPuV37Uvhh8o56avQPSU4K6roANNqEwFQgtSv/SYeuVRR6kMTSQAQriiYeqXXbzFR3EzGHuMhtoUcSMcNBQbVL4jH28GjlVZTpzoS3Q4whq7ss8lqbzqeuk0HuDfmFsiks=; X-YMail-OSG: eEYuRGwVM1m3mNkUUW8jBozmleSGnvRCX4eXWIUsrpIENg9 lToBivZXxkU.5Ip53oDCKYwLn6vI7vIT6m1VIEB9HzscHB2oNEeHfyAO3PYj tlxltFlv.eC.AclpJr6Zlr2ueA7rzp_ht38aoctSHB1I2yKYxb41gmaGxAM3 0Rxapu2Gm.GAaupMlRGJ1saD8srlQo8eSM.jIVs.5CoJnUtB.H6umzpT2SOy btMc6o9G8RcdCGvrHKvtmSyY3.McTxqTZslBRV6inCe.9gVJm3110ccHyKVe b0MgLAte3qO75s0r_1CMR3jES4ekH7Tb_XGY1587sMVC0GhnMZCW42CsPyjy Rh3jc65gU_6Tm75_oifvFIYi5vDl2xsrzin_XZsswk4E52EXNn4OcQnPpCO9 6GyBInEmjnPbMqPX6..8Vqg1IpjnKkFYGb36O3cOJFIL2qOKGg_w6Y4XocL9 6SFiylAiok1t5StfcoL_xdeGLyTwpvct0A.neXA-- Received: from [217.198.210.234] by web121506.mail.ne1.yahoo.com via HTTP; Mon, 16 Jan 2012 04:40:54 PST X-Mailer: YahooMailWebService/0.8.115.331698 References: <1326376049.44121.YahooMailNeo@web121502.mail.ne1.yahoo.com> <1326630286.2201.3.camel@koala> <1326701907.78896.YahooMailNeo@web121503.mail.ne1.yahoo.com> <1326709475.14299.34.camel@sauron.fi.intel.com> Message-ID: <1326717654.83444.YahooMailNeo@web121506.mail.ne1.yahoo.com> Date: Mon, 16 Jan 2012 04:40:54 -0800 (PST) From: Karsten Jeppesen Subject: Re: Corrupted UBIFS, bad CRC To: "dedekind1@gmail.com" In-Reply-To: <1326709475.14299.34.camel@sauron.fi.intel.com> MIME-Version: 1.0 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -1.5 (-) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-1.5 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (arm9263[at]yahoo.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.138.91.142 listed in list.dnswl.org] -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.2 FREEMAIL_REPLYTO_END_DIGIT Reply-To freemail username ends in digit (karsten jeppesen ) 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (arm9263[at]yahoo.com) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -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: ubifs X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Karsten Jeppesen 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 Hi Artem, OO something bad happened here. We must have lost track of each other. What I sent you was ***NOT*** produced by our standard 2.6.32.8 kernel. I spent quite some efforts in adapting the new 3.2.0  kernel. I wrote that in my original email, but you may have drifted off to the emails from November. To make life easier for you I assumed you would rather look at data including the newest stuff rather than backported stuff. Debug was enabled and included as was any other information you asked for in the submission template. And again: This is kernel 3.2.0 and all nondestructive tests were run with no errors. The originating emails for this issue were both sent on Thusday January 12th 2012 Other notes: We use 2 variants of FLASH - both NOR.  Spansion 29GL256P and 29GL512P I found the datasheets and the 29GL256P says 32word/64 byte write buffer and the 29GL512P says the same. When I attach the FLASH all ubiattach reports is: UBI: attaching mtd4 to ubi0 UBI: physical eraseblock size:   131072 bytes (128 KiB) UBI: logical eraseblock size:    130944 bytes UBI: smallest flash I/O unit:    1 UBI: VID header offset:          64 (aligned 64) UBI: data offset:                128 UBI: max. sequence number:       17653 UBI: attached mtd4 to ubi0 UBI: MTD device name:            "User" UBI: MTD device size:            28 MiB UBI: number of good PEBs:        230 UBI: number of bad PEBs:         0 UBI: number of corrupted PEBs:   0 UBI: max. allowed volumes:       128 UBI: wear-leveling threshold:    4096 UBI: number of internal volumes: 1 UBI: number of user volumes:     1 UBI: available PEBs:             0 UBI: total number of reserved PEBs: 230 UBI: number of PEBs reserved for bad PEB handling: 0 UBI: max/mean erase counter: 31/5 UBI: image sequence number:  1704669600 UBI: background thread "ubi_bgt0d" started, PID 18731 But no  max_write_size was reported. I take it that UBI debug has to be enabled as well for the system to report that - right? Sorry for the confusion about the 3.2.0 kernel as opposed to the earlier 2.6.32.8 but I was as I wrote trying to take the backporting out of the equation, Karsten ----- Original Message ----- From: Artem Bityutskiy To: Karsten Jeppesen Cc: ubifs Sent: Monday, January 16, 2012 11:24 AM Subject: Re: Corrupted UBIFS, bad CRC On Mon, 2012-01-16 at 00:18 -0800, Karsten Jeppesen wrote: > Hi Artem, > > Of course I can. Anything I can do to help. > > I put it on one of my outside servers and I put as well the /dev/mtd4 as the ubi0_0 you asked for: > > > and > Thanks. I've taken a look by using mtdram. You have a strange corruption: 144 bytes of 0xFFs, then 32 bytes of zeroes, and then all 0xFFs. This looks like some oddity of your NOR flash. My theory is that your flash has write buffer and its size is 256 or larger. Anyway, first of all - start with pulling the latest ubifs-v2.6.32 tree - I've added few changes there very recently which fix UBI/UBIFS debugging messages. Also, please, enable UIBFS debugging compilation option. From now on I assume you have done this. Also I assume that you are aware that you need to look at dmesg to see all the UBIFS messages. There is some test in the MTD web site which explains this. Next: if I hack UBIFS like this: Then I can mount your image successfully. What is 'mtd->writebufsize' in your setup? You need to find out the right size and teach your driver to report it correctly. UBI reports max_write_size when you attach the MTD device. E.g., with mtdram I have the following: [493058.328443] UBI DBG (pid 18798): io_init: min_io_size      1 [493058.328444] UBI DBG (pid 18798): io_init: max_write_size  64 With my hack it is 256, of course. The mtdram module which I use hard-codes it to 64. diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 6c3fb5a..58a49e7 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -691,6 +691,8 @@ static int io_init(struct ubi_device *ubi)         ubi_assert(ubi->min_io_size % ubi->hdrs_min_io_size == 0);         ubi->max_write_size = ubi->mtd->writebufsize; +      ubi->max_write_size = 256; +         /*         * Maximum write size has to be greater or equivalent to min. I/O         * size, and be multiple of min. I/O size.