lseek32 and lseek64
Richard Genoud
richard.genoud at gmail.com
Mon Sep 10 08:59:02 EDT 2012
2012/9/10 Cheney Chen <cheneychencl2012 at gmail.com>:
> You are right. ubiformat is used on mtd devices. This bug was found a few
> month ago, now I'm available and this bug is reported. But I make a mistake
> for ubiformat /dev/ubi0_0. I just retry it again and print some log for you.
>
> # mtd utility original file's bin
> # ./ubiformat /dev/mtd/mtd13
> ubiformat: mtd13 (nand), size 6375342080 bytes (5.9 GiB), 1520 eraseblocks
> of 4194304 bytes (4.0 MiB), min. I/O size 16384 bytes
> libscan: scanning eraseblock 512 -- 33 % complete libmtd: error!: cannot
> seek mtd13 to offset 18446744071562067968
> error 22 (Invalid argument)
> ubiformat: error!: failed to scan mtd13 (/dev/mtd/mtd13)
>
> # add my patch as bin
> # ./ubiformat /dev/mtd/mtd13
> ubiformat: mtd13 (nand), size 6375342080 bytes (5.9 GiB), 1520 eraseblocks
> of 4194304 bytes (4.0 MiB), min. I/O size 16384 bytes
> libscan: scanning eraseblock 1519 -- 100 % complete
> ubiformat: 1495 eraseblocks are supposedly empty
> ubiformat: 22 bad eraseblocks found, numbers: 166, 313, 359, 556, 623, 624,
> 625, 626, 627, 628, 877, 1313, 1317, 1353, 1512, 1513, 1514, 1515
> , 1516, 1517, 1518, 1519
> ubiformat: warning!: 3 of 1498 eraseblocks contain non-ubifs data
> ubiformat: continue? (yes/no) yes
> ubiformat: warning!: only 0 of 1498 eraseblocks have valid erase counter
> ubiformat: erase counter 0 will be used for all eraseblocks
> ubiformat: note, arbitrary erase counter value may be specified using -e
> option
> ubiformat: continue? (yes/no) yes
> ubiformat: use erase counter 0 for all eraseblocks
> ubiformat: formatting eraseblock 1519 -- 100 % complete
>
> The attachment is my patch as a reference.
Please, cc the linux-mtd ML in your emails.
I had a look at your patch, and maybe something like that is better:
diff --git a/ubi-utils/libubigen.c b/ubi-utils/libubigen.c
index 9eaa7f5..d2a949b 100644
--- a/ubi-utils/libubigen.c
+++ b/ubi-utils/libubigen.c
@@ -279,7 +279,7 @@ int ubigen_write_layout_vol(const struct
ubigen_info *ui, int peb1, int peb2,
memset(outbuf + ui->data_offs + ui->vtbl_size, 0xFF,
ui->peb_size - ui->data_offs - ui->vtbl_size);
- seek = peb1 * ui->peb_size;
+ seek = (off_t) peb1 * ui->peb_size;
if (lseek(fd, seek, SEEK_SET) != seek) {
sys_errmsg("cannot seek output file");
goto out_free;
@@ -293,7 +293,7 @@ int ubigen_write_layout_vol(const struct
ubigen_info *ui, int peb1, int peb2,
goto out_free;
}
- seek = peb2 * ui->peb_size;
+ seek = (off_t) peb2 * ui->peb_size;
if (lseek(fd, seek, SEEK_SET) != seek) {
sys_errmsg("cannot seek output file");
goto out_free;
because off_t is 64bits if _FILE_OFFSET_BITS=64, wich is the case by
default in common.mk
could you test it ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: utils.patch
Type: application/octet-stream
Size: 1752 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120910/e06cb728/attachment-0001.obj>
More information about the linux-mtd
mailing list