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))
If mstohz() would round up to full ticks, it could actually avoid
some pitfalls.
On Tue, May 25, 2021 at 04:04:56PM -0400, Mouse wrote:
> > I suppose it's not possible to configure ahcisata in the BIOS on the
> > long-delay machines?
>
> Thank you very much! Yes. That is possible - and it fixes the delay.
> I would not have thought to look for that; I would not have
On Tue, May 25, 2021 at 10:21:40PM +0200, Christoph Badura wrote:
> On Wed, May 26, 2021 at 05:02:52AM +1000, matthew green wrote:
> > > > +optionsHZ=8000
> > this can become a problem due to integer division.
> >
> > any number of ticks less than hz (8000) will be rounded
> > down to 0
>>> I suppose it's not possible to configure ahcisata in the BIOS on
>>> the long-delay machines?
>> I would not have thought to look for that; I would not have expected
>> piixide and ahcisata to be similar enough that a BIOS setting could
>> personality-swap between them.
> IIRC, they are not
On Wed, May 26, 2021 at 05:02:52AM +1000, matthew green wrote:
> > > +options HZ=8000
> this can become a problem due to integer division.
>
> any number of ticks less than hz (8000) will be rounded
> down to 0 in a number of places now, where as before it
> was only less than 100. i've seen
On Tue, May 25, 2021 at 04:04:56PM -0400, Mouse wrote:
> > I suppose it's not possible to configure ahcisata in the BIOS on the
> > long-delay machines?
>
> Thank you very much! Yes. That is possible - and it fixes the delay.
> I would not have thought to look for that; I would not have
> I suppose it's not possible to configure ahcisata in the BIOS on the
> long-delay machines?
Thank you very much! Yes. That is possible - and it fixes the delay.
I would not have thought to look for that; I would not have expected
piixide and ahcisata to be similar enough that a BIOS setting
Hello. I suppose it's not possible to configure ahcisata in the BIOS
on the long-delay
machines? I'm guessing this is some quirk of the pciide(4) and piixide(4)
drivers. Not to be too
flip, but do you expect these machines to reboot frequently in production? If
not, then I'd
>>> +optionsHZ=8000
> this can become a problem due to integer division.
> any number of ticks less than hz (8000) will be rounded down to 0 in
> a number of places now, where as before it was only less than 100.
Dividing by hz would be used to...all I can think of is, to convert a
tick
>> Will HZ=1000 be sufficient and does that reduce the boot time?
> The latter is a good question which is likely to hint at possible
> causes. I'll experiment with various HZ values and see what happens.
At HZ=8000, the delay (based on the bracketed numbers) is almost
exactly 22 seconds.
At
> > +optionsHZ=8000
this can become a problem due to integer division.
any number of ticks less than hz (8000) will be rounded
down to 0 in a number of places now, where as before it
was only less than 100. i've seen this trip up in the
kernel before, and sometimes that '0' means 'poll',
> Is there a reason you need a frequency that high?
Yes. I'm not just cranking HZ up to be difficult. (I might do it just
to smoke out bugs...on my _own_ machines. Except, of course, that I
don't use 9.x except at work, where the tradeoffs are different.)
> Will HZ=1000 be sufficient and does
Hello. Is there a reason you need a frequency that high? Will HZ=1000
be sufficient and
does that reduce the boot time?
Also,while I don't entirely understand all the timing mechanisms inside NetBSD,
it seems if you
do need a higher frequency clock, I'd suggest HZ=1, since it's a
Last week, I wrote, here, of a delay when booting 9.1
>>> [ 3.288539] uhub2: 4 ports with 4 removable, self powered
>>> [ 3.288539] uhub3: 6 ports with 6 removable, self powered
>>> [25.272567] wd0 at atabus0 drive 0
>>> [25.273568] wd0:
and, in a later mail,
> [A]s soon as I
14 matches
Mail list logo