Re: 9.1: boot-time delay? [WORKAROUND FOUND]

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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:
> > > bouyer%antioche.eu.org@localhost (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))
> > > 
> > > If mstohz() would round up to full ticks, it could actually avoid
> > > some pitfalls. But it doesn't.
> >
> > indeed. But in this case the problem will show up with smaller hz, not
> > larger. So I think we can rule out this case.
> 
> 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 :(

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--