From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from a.ns.miles-group.at ([95.130.255.143] helo=radon.swed.at) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Z2FUE-0008Jt-AB for linux-mtd@lists.infradead.org; Tue, 09 Jun 2015 09:06:23 +0000 Message-ID: <5576AC73.1030104@nod.at> Date: Tue, 09 Jun 2015 11:05:55 +0200 From: Richard Weinberger MIME-Version: 1.0 To: t kevin Subject: Re: Data integrity check after UBIFORMAT? Bad image sequence number error. References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: "linux-mtd@lists.infradead.org" List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Am 09.06.2015 um 10:52 schrieb t kevin: > Hi Richard > > Thanks for the reply. See inline comments below. > > 2015-06-09 16:20 GMT+08:00 Richard Weinberger : >> On Tue, Jun 9, 2015 at 10:02 AM, t kevin wrote: >>> Hi, >>> >>> We are using kernel 2.6.36 and mtd-util-1.5.1 on our box. >>> During system upgrade, very very occasionally ( 1 in 100, maybe? ) I >>> get this error at ubiattach after ubiformat. >>> >>> [ 1632.520000] UBI: attaching mtd8 to ubi0 >>> [ 1632.520000] UBI: physical eraseblock size: 131072 bytes (128 KiB) >>> [ 1632.530000] UBI: logical eraseblock size: 126976 bytes >>> [ 1632.530000] UBI: smallest flash I/O unit: 2048 >>> [ 1632.540000] UBI: sub-page size: 512 >>> [ 1632.540000] UBI: VID header offset: 2048 (aligned 2048) >>> [ 1632.550000] UBI: data offset: 4096 >>> [ 1633.190000] UBI error: process_eb: bad image sequence number >>> 559476870 in PEB 635, expected 139654706 >>> >>> I understand ubiformat generate a random sequence number and write the >>> sequence number to all PEB. So it seems an expected sequence number >>> somehow is not written into nand flash correctly. >> >> Are you sure about that? >> Can it be that 559476870 is the seq number of the old image and the >> new one is too small? >> This is one of the main reasons why we have that number, such that >> UBI can detect a partial written image. >> > I don't really know what "559476870" is. We don't track image sequence > number : ( Please start tracking them. UBI prints the number while attaching. If the old number remains after an update, you update was most likely not complete. And you can start investigate. >>> So I changed my upgrade sequence like below >>> >>> ubiformat ubi.img /dev/mtdx >>> ubiattach /dev/mtdx >>> >>> if [ "$?" != "0" ] >>> #do ubiformat again >>> ubiformat ubi.img /dev/mtdx >> >> You format it while it is attached? >> > > I'll do re-format only when ubiattach returns fail and then I know > there is something wrong during ubiformat. So by that time it's not > attached. Right you are. :) >>> My question are, >>> 1. What could possibly be wrong that caused the ubiformat fail? >> >> It can be a faulty MTD driver, a usage error, everything. >> >>> 2. Is there a way to verify the data integrity after a UBIFORMAT >>> process? Something like "mtd verify" function. >> >> I fear the answer is "no". >> > > As I mentioned, the error is very rare, but it did happen multiple > times. So we are considering data integrity check. I suspect that sometimes not the whole MTD partition is written. Just in case, does your MTD driver pass all mtd and UBI tests? Thanks, //richard