From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from a.ns.miles-group.at ([95.130.255.143] helo=radon.swed.at) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Y3m0I-0003o4-Gy for linux-mtd@lists.infradead.org; Wed, 24 Dec 2014 13:29:31 +0000 Message-ID: <549ABF9D.6030901@nod.at> Date: Wed, 24 Dec 2014 14:29:01 +0100 From: Richard Weinberger MIME-Version: 1.0 To: hujianyang , Artem Bityutskiy Subject: Re: ubi_check_volume() hung on a single core system References: <549AAD57.8020307@huawei.com> In-Reply-To: <549AAD57.8020307@huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: linux-mtd List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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