From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 71-19-161-253.dedicated.allstream.net ([71.19.161.253] helo=nsa.nbspaymentsolutions.com) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VAQ15-00025M-BH for linux-mtd@lists.infradead.org; Fri, 16 Aug 2013 19:49:00 +0000 From: Bill Pringlemeir To: richard -rw- weinberger Subject: Re: Fail to mount cloned disk image with fastmap. References: <87a9kjt73h.fsf@nbsps.com> Date: Fri, 16 Aug 2013 15:46:10 -0400 Message-ID: <87wqnlqv0d.fsf@nbsps.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "linux-mtd@lists.infradead.org" List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 15 Aug 2013, richard.weinberger@gmail.com wrote: > On Thu, Aug 15, 2013 at 3:29 PM, Bill Pringlemeir wrote: >> I have back-ported the fastmap code from the 3.0 series to a 2.6.36 >> kernel on an ARM cpu. It has been running for some time without issue >> and the boot time is reduced by 1/2 second. I just ran a test over >> night with 'pppd' capturing packets and likely filled up the disk. >> >> It appears that my kernel does not boot, so I made a clone of the disk >> and then attempt to mount it on my Ubuntu machine with the following, > BTW: What exactly does "my kernel does not boot" mean? > Does it also fail at the said WARN_ON()? > The WARN_ON() can also trigger if made the image in a wrong way. > A truncated image would explain both error messages. Unfortunately, the device where this occurs does not have a serial port for a console. So, the boot sequence stops. My guess was/is that it just can not mount the 'UbiFS rootfs'; just like trying to mount it on the 3.8 nandsim doesn't work. > fm_autoconvert=0 tells UBI to use the fastmap if one is found but > not to automatically convert non-fastmap images to fastmap. I thought of this right after 'send'. At one point there was a '0,1,2' value that could disable fastmap? This must have been a different parameter and I think it has been removed. > Yes, please try to attach the image with MTD_UBI_FASTMAP=n. With no changes to 'mtd3', the non-fast map version seems to boot fine. There is some of the initial kernel logs below. The 'UbiFs' performed a 'recovery' as well. >> additional issues are encountered. But I think that some of the UBI >> issues might be a problem? Can I use some other flash with a bigger >> size so that 'PEBs' can be reserved? >> Of course, I have the disk image and can send additional information. > Can you please upload the image somewhere where I can analyze it? Is there a program to extract the UBI headers? I can send the data, but I will have to look through it for some time to make sure there is nothing I shouldn't give out; downloaded data files, etc. which is probably a trival amount of the total image. I will be away for 2 weeks. It was back ported code and I have just disabled 'fastmap' for now. Are you interested in why the more current code has issues? Or has someone else reported a similar issue? The nand flash controller was an imx25 and I have the NAND driver updates to, commit 657f28f8811c92724db10d18bbbec70d540147d6 mtd: kill MTD_NAND_VERIFY_WRITE I can not take the infra-structure changes, only the chipset bug fixes as we are stuck at 2.6.36 for now. Thanks, Bill Pringlemeir. [ 1.650000] UBI: attaching mtd3 to ubi0 [ 1.650000] UBI DBG (pid 1): ubi_attach_mtd_dev: sizeof(struct ubi_ainf_peb) 48 [ 1.650000] UBI DBG (pid 1): ubi_attach_mtd_dev: sizeof(struct ubi_wl_entry) 20 [ 1.650000] UBI DBG (pid 1): io_init: min_io_size 2048 [ 1.650000] UBI DBG (pid 1): io_init: max_write_size 2048 [ 1.650000] UBI DBG (pid 1): io_init: hdrs_min_io_size 512 [ 1.650000] UBI DBG (pid 1): io_init: ec_hdr_alsize 512 [ 1.650000] UBI DBG (pid 1): io_init: vid_hdr_alsize 512 [ 1.650000] UBI DBG (pid 1): io_init: vid_hdr_offset 512 [ 1.650000] UBI DBG (pid 1): io_init: vid_hdr_aloffset 512 [ 1.650000] UBI DBG (pid 1): io_init: vid_hdr_shift 0 [ 1.650000] UBI DBG (pid 1): io_init: leb_start 2048 [ 1.650000] UBI DBG (pid 1): io_init: max_erroneous 191 [ 1.650000] UBI: physical eraseblock size: 131072 bytes (128 KiB) [ 1.660000] UBI: logical eraseblock size: 129024 bytes [ 1.670000] UBI: smallest flash I/O unit: 2048 [ 1.670000] UBI: sub-page size: 512 [ 1.680000] UBI: VID header offset: 512 (aligned 512) [ 1.690000] UBI: data offset: 2048 [ 2.640000] UBI DBG (pid 1): scan_all: scanning is finished [ 2.640000] UBI: max. sequence number: 9141 [ 2.800000] UBI: attached mtd3 to ubi0 [ 2.800000] UBI: MTD device name: "root" [ 2.800000] UBI: MTD device size: 239 MiB [ 2.800000] UBI: number of good PEBs: 1914 [ 2.800000] UBI: number of bad PEBs: 4 [ 2.800000] UBI: number of corrupted PEBs: 0 [ 2.800000] UBI: max. allowed volumes: 128 [ 2.800000] UBI: wear-leveling threshold: 4096 [ 2.800000] UBI: number of internal volumes: 1 [ 2.800000] UBI: number of user volumes: 1 [ 2.800000] UBI: available PEBs: 0 [ 2.810000] UBI: total number of reserved PEBs: 1914 [ 2.820000] UBI: number of PEBs reserved for bad PEB handling: 19 [ 2.830000] UBI: max/mean erase counter: 51/5 [ 2.840000] UBI: image sequence number: 739038085 [ 2.850000] UBI: background thread "ubi_bgt0d" started, PID 189 [ 2.870000] Freeing init memory: 1176K [ 3.520000] UBIFS: background thread "ubifs_bgt0_3" started, PID 212 [ 3.560000] UBIFS: recovery needed [ 3.770000] UBIFS: recovery completed [ 3.770000] UBIFS: mounted UBI device 0, volume 3, name "rootfs" [ 3.770000] UBIFS: LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes [ 3.770000] UBIFS: FS size: 242565120 bytes (231 MiB, 1880 LEBs), journal size 9033728 bytes (8 MiB, 71 LEBs) [ 3.770000] UBIFS: reserved for root: 4190434 bytes (4092 KiB) [ 3.770000] UBIFS: media format: w4/r0 (latest is w4/r0), UUID 82867E3B-5B71-485C-B911-409531E9DA4B, small LPT model