Messages in this thread | | | Date | Sun, 6 Sep 2009 07:58:41 +0200 | From | Pavel Machek <> | Subject | Re: PROBLEM: CONFIG_NO_HZ could cause software timeouts |
| |
On Sat 2009-09-05 20:19:46, Marcin Slusarz wrote: > Norbert van Bolhuis wrote: > > > > The problem occurs when e.g. drivers use time_after(jiffes, timeout). > > > > CONFIG_NO_HZ could make jiffies advance by more than 1. > > This is done by: > > tick_nohz_update_jiffies->tick_do_update_jiffies64->do_timer > > > > If drivers use a timeout value of jiffies+1, > > "time_after(jiffies, timeout)" will be true after 1 interrupt > > (given that it advances jiffies by at least 2). > > > > This is exactly what happens in cfi_cmdset_0002.c:do_write_buffer > > for our case (Powerpc MPC8313, linux-2.6.28, CONFIG_HZ=250, > > CONFIG_NO_HZ=y). > > > > do_write_buffer does the following: > > unsigned long uWriteTimeout = ( HZ / 1000 ) + 1; > > ... > > timeo = jiffies + uWriteTimeout; > > ... > > for (;;) { > > ... > > if (time_after(jiffies, timeo) && !chip_ready(map, adr)) > > break; > > if (chip_ready(map, adr)) { > > xip_enable(map, chip, adr); > > goto op_done; > > } > > UDELAY(map, chip, adr, 1); > > } > > /* software timeout */ > > ret = -EIO; > > opdone: > > ... > > > > I've seen a few software timeouts after the for-loop > > looped only 13 times (= 13 us delay, i.s.o. the expected 1 ms). Typically > > Are you sure? UDELAY may call schedule(), which can return to this thread > after much longer time than 13us...
Too long wait is expected, but AFAICS he's complaining about too short delay and that's a hard bug.
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |