On Mon, Jan 21, 2019 at 09:05:19PM -0500, Ted Unangst wrote:
> Scott Cheloha wrote:
> > > > diff --git sys/arch/sparc64/dev/fd.c sys/arch/sparc64/dev/fd.c
> > > > index 8d548062f83..654d8c95524 100644
> > > > --- sys/arch/sparc64/dev/fd.c
> > > > +++ sys/arch/sparc64/dev/fd.c
> > > > @@ -1632,7 +1632,7 @@ loop:
> > > > fdc->sc_state = RECALCOMPLETE;
> > > > if (fdc->sc_flags & FDC_NEEDHEADSETTLE) {
> > > > /* allow 1/30 second for heads to settle */
> > > > - timeout_add(&fdc->fdcpseudointr_to, hz / 30);
> > > > + timeout_add_msec(&fdc->fdcpseudointr_to, 33);
> > > > return (1); /* will return later */
> > > > }
> > > >
> > >
> > > Wonder if this should be 30 or 40 since 33 is rather odd.
> >
> > The intent was to wait a 30th of a second. In practice it has always
> > fired 30ms hence. It's a magic number, so I'd just call it 30ms.
> > miod might have an opinion on whether those extra milliseconds would
> > be useful in the event that sparc64 is ever able to timeout with
> > millisecond or better precision on OpenBSD.
>
> make it 30 and the let the next sparc64 user with a floppy drive worry about
> the fallout. :)
I don't think there will be any fallout. sparc64 has HZ = 100:
hz / 30 = 100 / 30 = 3 ticks
so it currently goes off sometime between 20 and 30 milliseconds
from the call to timeout_add(9).
Now we're doing timeout_add_msec(9) with 30 milliseconds, which
becomes
(30 * 1000) / (1000000 / HZ) = 30000 / 10000 = 3 ticks
so using 30 milliseconds should not change any behavior unless
I fucked up a number somewhere.
arithmetic is no fun
