On Fri, May 28, 2021 at 05:13:02AM +0700, Robert Elz wrote:
> But it isn't, you can't convert 60 ticks/second into some number of
> milliseconds, the two are different units.
Sure you can. period = 1/frequency.
But HZ (and now hz) in the code is also used as a period, thus the idioms:
On 2021-05-28 00:46, Joerg Sonnenberger wrote:
On Fri, May 28, 2021 at 03:14:24AM +0700, Robert Elz wrote:
Date:Thu, 27 May 2021 05:05:15 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| mlel...@serpens.de (Michael van Elst) writes:
|
On Fri, May 28, 2021 at 03:14:24AM +0700, Robert Elz wrote:
> Date:Thu, 27 May 2021 05:05:15 - (UTC)
> From:mlel...@serpens.de (Michael van Elst)
> Message-ID:
>
> | mlel...@serpens.de (Michael van Elst) writes:
> |
> | >Either direction mstohz or hztoms
Thank you for fixing the problem.
On Thu, May 27, 2021 at 9:19 PM Jared McNeill wrote:
>
> Good catch! I've committed a slightly modified version of your patch.
>
> Take care,
> Jared
>
>
> On Thu, 27 May 2021, sc.dy...@gmail.com wrote:
>
> > hi,
> >
> > sometimes memories allocated by
On 2021-05-28 00:13, Robert Elz wrote:
Date:Thu, 27 May 2021 20:19:06 +
From:"Koning, Paul"
Message-ID: <8765ae3a-b5b7-4b67-82ce-93473a5b9...@dell.com>
| In this particular case it's converting frequency to period,
| that is a sensible conversion.
But
Date:Thu, 27 May 2021 20:19:06 +
From:"Koning, Paul"
Message-ID: <8765ae3a-b5b7-4b67-82ce-93473a5b9...@dell.com>
| In this particular case it's converting frequency to period,
| that is a sensible conversion.
But it isn't, you can't convert 60 ticks/second
Good catch! I've committed a slightly modified version of your patch.
Take care,
Jared
On Thu, 27 May 2021, sc.dy...@gmail.com wrote:
hi,
sometimes memories allocated by usb_allocmem with USBMALLOC_ZERO
are not cleared.
usb_block_allocmem, called from usb_allocmem, returns with valid dmap
On 2021-05-27 22:50, Mouse wrote:
A tick is not a duration. A tick is a specific event at a specific
time. It has no duration. You have a duration between two ticks.
At least as I use it and have heard it used, `tick' can also be used to
refer to the interval between two of those events.
> A tick is not a duration. A tick is a specific event at a specific
> time. It has no duration. You have a duration between two ticks.
At least as I use it and have heard it used, `tick' can also be used to
refer to the interval between two of those events. "How long are timer
ticks on this
On 2021-05-27 22:14, Robert Elz wrote:
Date:Thu, 27 May 2021 05:05:15 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| And both should be replaced by hztous()/ustohz().
While changing ms to us is probably a good idea, when a change
> On May 27, 2021, at 4:14 PM, Robert Elz wrote:
>
> ...
> While changing ms to us is probably a good idea, when a change happens,
> the "hz" part should be changed too.
>
> hz is (a unit of) a measure of frequency, ms (or us) is (a unit of) a
> measure of time (duration) - converting one to
Date:Thu, 27 May 2021 05:05:15 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| mlel...@serpens.de (Michael van Elst) writes:
|
| >Either direction mstohz or hztoms should better always round up to
| >guarantee a minimal delay.
|
| And
> On May 27, 2021, at 6:17 AM, Jason Thorpe wrote:
>
>>
>> On May 27, 2021, at 3:35 AM, Taylor R Campbell
>> wrote:
>>
>>> Date: Wed, 26 May 2021 19:46:57 -0700
>>> From: Jason Thorpe
>>>
>>> The test program sets up a SIGFPE handler, and the handler make a
>>> copy of the siginfo, sets
> On May 27, 2021, at 6:29 AM, Jason Thorpe wrote:
>
>
>> On May 27, 2021, at 3:35 AM, Taylor R Campbell
>> wrote:
>>
>> The default exception handling defined in IEEE 754-2019 precisely
>> defines what the results of the operation should be, so there's no
>> semantic ambiguity about what
>> In some cases, you want to re-execute the instruction. A simple
>> example is "FPU disabled" on architectures that have such a notion,
>> eg for lazy FPU switching.
> Weâ??re not talking about lazy FPU switching hereâ?? weâ??re talking about p$
(Or timing. Yes.) A better example might be
> On May 27, 2021, at 3:35 AM, Taylor R Campbell
> wrote:
>
> The default exception handling defined in IEEE 754-2019 precisely
> defines what the results of the operation should be, so there's no
> semantic ambiguity about what the program should observe when it
> proceeds on return from the
> On May 26, 2021, at 8:14 PM, Mouse wrote:
>
>> But the x86_64 code appears to return to the same instruction, banging its h$
>
>> It's my belief that the alpha behavior is more desirable.
>
>> Please, discuss.
>
> I could argue that either way.
>
> In some cases, you want to re-execute
> On May 27, 2021, at 3:35 AM, Taylor R Campbell
> wrote:
>
>> Date: Wed, 26 May 2021 19:46:57 -0700
>> From: Jason Thorpe
>>
>> The test program sets up a SIGFPE handler, and the handler make a
>> copy of the siginfo, sets a global flag, and returns. The program
>> then does "1.0 / 0.0"
>> How heavily is hztoms used?
> [18 uses]
That's...almost none, seems to me. And these
> sys/dev/ic/mvsata.c: timeout = mstohz(timeout + hztoms(1) - 1);
> sys/dev/ic/mvsata.c: ata_delay(chp, hztoms(1), "mvsata_edma2",
> wflags);
> sys/dev/sdmmc/if_bwfm_sdio.c:
> Date: Wed, 26 May 2021 19:46:57 -0700
> From: Jason Thorpe
>
> The test program sets up a SIGFPE handler, and the handler make a
> copy of the siginfo, sets a global flag, and returns. The program
> then does "1.0 / 0.0" and prints the result. It checks to ensure
> that the DZE exception is
hi,
sometimes memories allocated by usb_allocmem with USBMALLOC_ZERO
are not cleared.
usb_block_allocmem, called from usb_allocmem, returns with valid dmap
if it has found a block in usb_blk_freelist. In that path memset is not done.
--- src/sys/dev/usb/usb_mem.c.orig 2021-01-05
21 matches
Mail list logo
