Skip to contentSkip to conversation

Report: mtd-utils: "Floating point exception" with ubiformat

DISCUSSION hujianyang 2 participants 4 messages Oct 31, 2014 – Nov 7, 2014 Memory technology devices (MTD)

lore
Share & tools
lore

hujianyang

author
#0 lore raw

Hi,

Here is an interesting problem. I used a nand flash driver with wrong partition table and an error like this occurred:

# insmod nandflash.ko
[454096.098834] mtd: partition "ubi1" is out of reach -- disabled

The display of /proc/mtd shows the size of mtd1 is zero:

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 20000000 00020000 "ubi0"
mtd1: 00000000 00000000 "ubi1"
mtd2: 20000000 00020000 "rest"

When performing ubiformat with this mtd1, the utility breaks down with a message:

# ubiformat /dev/mtd1
Floating point exception

I used to think it is because ubiformat can't deal with a zero size MTD device. So I want to add something like a error branch for this. But now I find it is because the "erasesize" in "/sys/class/mtd/mtd1" is zero.

:/sys/class/mtd/mtd1# cat erasesize
0

So function mtd_get_dev_info1() in lib/libmtd.c, line 777

"""
mtd->eb_cnt = mtd->size / mtd->eb_size;
"""

will crash the program because mtd->eb_size is zero.

Do you think it is a valuable problem to deal with? Keep the existing logic is OK. But can we add something in mtd-utils to indicate this error than "Floating point exception"?

Thanks~!

Hu

#1 lore raw
Quoted 3 lines · hujianyang

Do you think it is a valuable problem to deal with? Keep the existing logic is OK. But can we add something in mtd-utils to indicate this error than "Floating point exception"?

I think a work-around in mtd-utils is needed for sure. Because even if we change the kernel, the change will only affect new kernels.

And I think changing the kernel is worthwhile too. It is extremely unlikely, in my opinion, that someone relies on this illogical behavior which happens only for zero-size partitions. May be we can also disallow zero-size partitions?

Artem.

author
#2 lore raw
Quoted 8 lines · Artem Bityutskiy
Quoted 3 lines · hujianyang

Do you think it is a valuable problem to deal with? Keep the existing logic is OK. But can we add something in mtd-utils to indicate this error than "Floating point exception"?

I think a work-around in mtd-utils is needed for sure. Because even if we change the kernel, the change will only affect new kernels.

Quoted 9 lines

And I think changing the kernel is worthwhile too. It is extremely unlikely, in my opinion, that someone relies on this illogical behavior which happens only for zero-size partitions. May be we can also disallow zero-size partitions?

Artem.

I'm agree with you.

I found another strange thing, also caused by the wrong partition table.

In my board there is only one 512M nand flash. But the partition table in nand driver is used for a board with 2G(4*512M) nand flash.

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 20000000 00020000 "ubi0"
mtd1: 00000000 00000000 "ubi1"
mtd2: 20000000 00020000 "rest"

The /proc/mtd shows there are two 512M nand flash but actually they share the same device.

If I format mtdblock0 as jffs2 and then, I can mount a jffs2 file system from mtdblock2. Very interesting~!

Hu

#3 lore raw
Quoted 5 lines · hujianyang

The /proc/mtd shows there are two 512M nand flash but actually they share the same device.

If I format mtdblock0 as jffs2 and then, I can mount a jffs2 file system from mtdblock2. Very interesting~!

The partitioning code is old and hairy, and needs love.

Artem.