Skip to contentSkip to conversation

ubi_check_volume() hung on a single core system

PATCH hujianyang 2 participants 3 messages Dec 24, 2014 – Dec 25, 2014

Subsystems (2)
Memory technology devices (MTD) Unsorted block images (UBI)
lore
Share & tools
lore

hujianyang

author
#0 lore raw

Hi,

When I was running mtd-utils/tests/ubi-tests/io_basic.c on a single core system, watchdog reset the OS and printed:

ERR:The task of feeding senior watchdog overtimes, system will reset!

io_basic.c tests the UBI_IOCVOLUP feature of UBI driver. UBI will perform ubi_check_volume() after updating operation is finished. The used ebs will be scanned for a static volume in this function.

If I run schedule() in the loop of eraseblock scanning, the *reset* not happen and the system works in right condition.

drivers/mtd/ubi/misc.c +3 -0
index dbda77e..f4f478c 100644
@@ -74,6 +74,9 @@ int ubi_check_volume(struct ubi_device *ubi, int vol_id)
        for (i = 0; i < vol->used_ebs; i++) {
                int size;
 
+               set_current_state(TASK_UNINTERRUPTIBLE);
+               schedule_timeout(HZ/10);
+
                if (i == vol->used_ebs - 1)
                        size = vol->last_eb_bytes;
                else

I think this error can't be re-created on a multi-core system. It can only happen on a single core system. This directly schedule I modified would hurt the performance of volume check.

Does anyone interested in this issue?

Thanks,
Hu

maintainer
#1 lore raw

Am 24.12.2014 um 13:11 schrieb hujianyang:

Quoted 20 lines

Hi,

When I was running mtd-utils/tests/ubi-tests/io_basic.c on a single core system, watchdog reset the OS and printed:

ERR:The task of feeding senior watchdog overtimes, system will reset!

io_basic.c tests the UBI_IOCVOLUP feature of UBI driver. UBI will perform ubi_check_volume() after updating operation is finished. The used ebs will be scanned for a static volume in this function.

If I run schedule() in the loop of eraseblock scanning, the *reset* not happen and the system works in right condition.

drivers/mtd/ubi/misc.c +0 -0
index dbda77e..f4f478c 100644

drivers/mtd/ubi/misc.c int ubi_check_volume(struct ubi_device *ubi, int vol_id) · line 78

Quoted 5 lines
drivers/mtd/ubi/misc.c +2 -0
@@ -74,6 +74,9 @@ int ubi_check_volume(struct ubi_device *ubi, int vol_id)
        for (i = 0; i < vol->used_ebs; i++) {
                int size;
 
+               set_current_state(TASK_UNINTERRUPTIBLE);
+               schedule_timeout(HZ/10);

cond_resched() please.

Quoted 11 lines
drivers/mtd/ubi/misc.c +0 -0
                if (i == vol->used_ebs - 1)
                        size = vol->last_eb_bytes;
                else

I think this error can't be re-created on a multi-core system. It can only happen on a single core system. This directly schedule I modified would hurt the performance of volume check.

Does anyone interested in this issue?

Of course!

Thanks,
//richard

author
#2 lore raw
Quoted 39 lines · Richard Weinberger

Am 24.12.2014 um 13:11 schrieb hujianyang:

Quoted 20 lines

Hi,

When I was running mtd-utils/tests/ubi-tests/io_basic.c on a single core system, watchdog reset the OS and printed:

ERR:The task of feeding senior watchdog overtimes, system will reset!

io_basic.c tests the UBI_IOCVOLUP feature of UBI driver. UBI will perform ubi_check_volume() after updating operation is finished. The used ebs will be scanned for a static volume in this function.

If I run schedule() in the loop of eraseblock scanning, the *reset* not happen and the system works in right condition.

drivers/mtd/ubi/misc.c +0 -0
index dbda77e..f4f478c 100644

drivers/mtd/ubi/misc.c int ubi_check_volume(struct ubi_device *ubi, int vol_id) · line 78

Quoted 5 lines
drivers/mtd/ubi/misc.c +2 -0
@@ -74,6 +74,9 @@ int ubi_check_volume(struct ubi_device *ubi, int vol_id)
        for (i = 0; i < vol->used_ebs; i++) {
                int size;
 
+               set_current_state(TASK_UNINTERRUPTIBLE);
+               schedule_timeout(HZ/10);

cond_resched() please.

Quoted 10 lines
drivers/mtd/ubi/misc.c +0 -0
                if (i == vol->used_ebs - 1)
                        size = vol->last_eb_bytes;
                else

I think this error can't be re-created on a multi-core system. It can only happen on a single core system. This directly schedule I modified would hurt the performance of volume check.

Quoted 9 lines
Quoted 1 line

Does anyone interested in this issue?

Of course!

Thanks,
//richard

.

Hi Richard,

Thanks for your suggestion. I've tested it and achieve much better performance. Certainly, fix this issue.

I'd like to send a patch about this problem. Do you think it is necessary to fix this in mainline?

Thanks,
Hu