Fail to mount cloned disk image with fastmap.
Richard Weinberger
richard at nod.at
Fri Aug 16 15:59:28 EDT 2013
Am 16.08.2013 21:46, schrieb Bill Pringlemeir:
> On 15 Aug 2013, richard.weinberger at 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.
Guessing is not good. We like hard facts. :-)
>> 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.
Yep.
Now the parameter is a Boolean.
MODULE_PARM_DESC(fm_autoconvert, "Set this parameter to enable fastmap automatically on images without a fastmap.");
>> 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.
Now I'm really interested in the image to analyze it.
>>> 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.
Please no mangled images.
Will send you a private mail in a few minutes.
> 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,
Yes! I'm interested in fastmap issues.
So far fastmap has not much users and as it is an experimental feature
I expect issues. ;)
> 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.
Please make sure that your backport works correctly.
Did you run ubi-tests on it?
Thanks,
//richard
> 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
>
More information about the linux-mtd
mailing list