Manuel Bouyer writes: > On Wed, May 26, 2021 at 05:35:53PM +1000, matthew green wrote: > > Manuel Bouyer writes: > > > On Tue, May 25, 2021 at 10:46:04PM -0000, Michael van Elst wrote: > > > > bou...@antioche.eu.org (Manuel Bouyer) writes: > > > > > > > > >Another issue could be mstohz() called with a delay too short; > > > > >mstohz() will round it up to 1 tick. > > > > > > > > > > > > # define mstohz(ms) ((unsigned int)((ms + 0ul) * hz / 1000ul))
actually, this one is problematic as well. mstohz(1) here gives 0 for hz < 1000. "(1 + 0) * hz / 1000" for any 'hz' less than 1000 will give 0. > > it's hztoms() that is the problem here. > > > > # define hztoms(t) ((unsigned int)(((t) + 0ul) * 1000ul / hz)) > > > > ah... this is the new one. the old one was: > > > > #define hztoms(t) \ > > (__predict_false((t) >= 0x20000) ? \ > > ((t +0u) / hz) * 1000u : \ > > ((t +0u) * 1000u) / hz) > > > > looks like christos fixed it in 2019. > > I'm not sure how christos's change could be a fix. I introduced hztoms() > and mstohz() to avoid interger overflow for large values, and it looks like > christos reintroduced it for 32bits platforms :( there's an inline for 32 bit now, not the above code. i realise the problem i recall here: it happens with both of the above with hz is > 1000. "1 * 1000 / 1024" is 0. .mrg.