ubi_check_volume() hung on a single core system

ubi_check_volume() hung on a single core system

[hujianyang]

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.

diff --git a/drivers/mtd/ubi/misc.c b/drivers/mtd/ubi/misc.c
index dbda77e..f4f478c 100644
--- a/drivers/mtd/ubi/misc.c
+++ b/drivers/mtd/ubi/misc.c
@@ -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

Re: ubi_check_volume() hung on a single core system

[Richard Weinberger]

Am 24.12.2014 um 13:11 schrieb hujianyang:
> 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.
> 
> diff --git a/drivers/mtd/ubi/misc.c b/drivers/mtd/ubi/misc.c
> index dbda77e..f4f478c 100644
> --- a/drivers/mtd/ubi/misc.c
> +++ b/drivers/mtd/ubi/misc.c
> @@ -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.

>                 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

Re: ubi_check_volume() hung on a single core system

[hujianyang]

On 2014/12/24 21:29, Richard Weinberger wrote:
> Am 24.12.2014 um 13:11 schrieb hujianyang:
>> 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.
>>
>> diff --git a/drivers/mtd/ubi/misc.c b/drivers/mtd/ubi/misc.c
>> index dbda77e..f4f478c 100644
>> --- a/drivers/mtd/ubi/misc.c
>> +++ b/drivers/mtd/ubi/misc.c
>> @@ -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.
> 
>>                 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
> 
> .
> 

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