Re: Expected behavior when returning from a SIGFPE handler
> 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 set via fpgetsticky(). It then does "1.0 > / 0.0" again, and then verifies that the SIGFPE handler was not > called a second time (because I never cleared DZE with > fpsetsticky()). This strikes me as wrong. The status flags (fpgetsticky, fetestexcept) don't determine whether a floating-point operation `signals an exception' (in the language of IEEE 754-2019); they only record whether it happened in the past. It seems to me that if an operation [ieee754-]signals an exception that the user has asked (with fpsetmask/feenableexcept) to be trapped, then it should deliver a [unix-]signal, irrespective of whether some past operation already [ieee754-]signalled an exception. > The alpha code has, for a very long time, always advanced the PC > past the faulting instruction on an arithmetic trap[1]. This, in > essence, makes it behave exactly as if the exception were disabled, > while still giving the handler a chance to "do something"). > > But the x86_64 code appears to return to the same instruction, > banging its head against the proverbial wall. > > It's my belief that the alpha behavior is more desirable. I agree. It would be perfectly reasonable to use a SIGFPE handler to, say, record a history of the instructions (and perhaps stack traces) that signalled floating-point exceptions, to give more precise diagnostic information about where they're happening than the status flags do -- without otherwise interrupting the flow of the program. 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 signal handler.
Re: 9.1: boot-time delay? [WORKAROUND FOUND]
>> 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: sdmmc_pause(hztoms(1)*1000, NULL);
look to me like bugs waiting to happen - and the first one looks as
though it might even be related to the bug that got us talking about
this; it changes the units of the number in timeout (from ms to hz) in
just the sort of way that could have led to what I saw.
The last, it seems to me, really should be hztoms(1000).
And these
> sys/dev/i2c/tsllux.c: if (ms < hztoms(1)) {
> sys/dev/pci/ixgbe/ixgbe_netbsd.c: else if ((us / 1000) >= hztoms(1)) {
might be as well; I'd have to read more context.
> sys/dev/usb/if_axe.c: usbd_delay_ms(sc->axe_un.un_udev, hztoms(y));
> \
> sys/external/bsd/drm2/include/linux/jiffies.h:return hztoms(j);
> sys/external/bsd/drm2/include/linux/sched.h: unsigned ms
> = hztoms(MIN((unsigned long)timeout,
> sys/kern/sched_4bsd.c:int rttsms = hztoms(sched_rrticks);
> sys/kern/sched_m2.c: int rttsms = hztoms(sched_rrticks);
> sys/kern/sched_m2.c: newsize = hztoms(min_ts);
> sys/kern/sched_m2.c: newsize = hztoms(max_ts);
These might be as well, but they look at least slightly more
reasonable.
> sys/dev/usb/if_axe.c: usbd_delay_ms(un->un_udev, hztoms(hz / 32));
> sys/dev/usb/if_axe.c: usbd_delay_ms(un->un_udev, hztoms(hz / 32));
> sys/dev/usb/if_axe.c: usbd_delay_ms(un->un_udev, hztoms(hz / 32));
> sys/dev/usb/if_axe.c: usbd_delay_ms(un->un_udev, hztoms(hz / 32));
And these are not only bugs waiting to happen (consider HZ=25), they're
extremely peculiar. Why hztoms(hz/32) rather than just 30, or 31, or
whatever? Weird.
Would it be useful for me to send-pr this, or is it more likely to be
something nobody would do anything with?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Expected behavior when returning from a SIGFPE handler
> 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" and prints the result. It checks to ensure >> that the DZE exception is set via fpgetsticky(). It then does "1.0 >> / 0.0" again, and then verifies that the SIGFPE handler was not >> called a second time (because I never cleared DZE with >> fpsetsticky()). > > This strikes me as wrong. > > The status flags (fpgetsticky, fetestexcept) don't determine whether a > floating-point operation `signals an exception' (in the language of > IEEE 754-2019); they only record whether it happened in the past. > > It seems to me that if an operation [ieee754-]signals an exception > that the user has asked (with fpsetmask/feenableexcept) to be trapped, > then it should deliver a [unix-]signal, irrespective of whether some > past operation already [ieee754-]signalled an exception. I agree. I was describing behavior the alpha port already had. I will write a unit test for this behavior (specifically round DZE), or make sure that there is one that covers it already (there may be … I’m still peeling the onion on the alpha port…) >> The alpha code has, for a very long time, always advanced the PC >> past the faulting instruction on an arithmetic trap[1]. This, in >> essence, makes it behave exactly as if the exception were disabled, >> while still giving the handler a chance to "do something"). >> >> But the x86_64 code appears to return to the same instruction, >> banging its head against the proverbial wall. >> >> It's my belief that the alpha behavior is more desirable. > > I agree. It would be perfectly reasonable to use a SIGFPE handler to, > say, record a history of the instructions (and perhaps stack traces) > that signalled floating-point exceptions, to give more precise > diagnostic information about where they're happening than the status > flags do -- without otherwise interrupting the flow of the program. > > 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 signal handler. Ok, I will write a unit test that verifies this behavior. Thanks! -- thorpej
Re: Expected behavior when returning from a SIGFPE handler
> 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 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 performing an FP operation that causes an exception per the IEEE 754 rules. The traps generated in these two situations are easily distinguishable, and user-space code has no visibility into lazy FPU switching traps (modulo the sorts of speculative execution information leaks that modern CPUs are vulnerable to). This is all about what to do AFTER the user-specified signal handler has been called, and it returns to normal program flow via the sigreturn path. > In some cases, you don't want to. An example might be soft-float, or > partial soft-float (such as, emulation of cases the hardware doesn't > handle). As I mentioned, on the Alpha, the PALcode pushes a trap frame with the PC pointing at least one instruction *after* the one that triggered the arithmetic exception (on EV6, it’s the instruction immediately following, on pre-EV6, you have to go looking backwards in the instruction stream for it). > On architectures like SPARC or, I think - you'd know better than I - > Alpha, where there are very few possible instruction sizes, sometimes > as few as just one, advancing past the instruction in the trap handler > is easy even if you have to do it in software. On others, like the > VAX, it's a right pain to do in software. On the latter sort, ideally, > the hardware would give you both the PC to use to re-execute the > instruction and the PC to use to skip the instruction, letting the trap > handler choose, but I'm not aware of any architecture that does that. > (The closest I'm aware of is, ironically, the SPARC, on which advancing > past an instruction in software is about as simple as it gets - but it > has both PC and next-PC in hardware, though admittedly for other > reasons.) > > I see no clear single right answer here. I’m not particularly concerned about VAX in this case; it doesn’t have IEEE 754 floating point, so all bets are off :-) -- thorpej
Re: Expected behavior when returning from a SIGFPE handler
> 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 signal handler. Hm, I guess this means that I really need to do software-completion for DZE faults, as well, even if SWC was not explicitly requested for it (we already do that for INV faults to handle QNaNs). Otherwise, I’m going to be stuck with UNPREDICTABLE as the result, and that’s not great. -- thorpej
Re: Expected behavior when returning from a SIGFPE handler
>> 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 turning on denormalized-result exceptions (does 754 specify them? I'm fairly sure I've seen at least one FPU that's documented to support them) with a handler that handles them by setting a global flag, disabling the exception, and re-executing the instruction, so as to note that a denormal occurred but otherwise proceeding with the computation. >> On others, like the VAX, [advancing over an instruction is] a right >> pain to do in software. > Iâ??m not particularly concerned about VAX in this case; it doesnâ??t > have IEEE 754 floating point, so all bets are off :-) 68k, then, or x86 - anything with 754 FP and CISCy enough to have variable-sized instructions. The VAX just happens to be the CISC architecture I know best. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Expected behavior when returning from a SIGFPE handler
> 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 the program should observe when it >> proceeds on return from the signal handler. > > Hm, I guess this means that I really need to do software-completion for DZE > faults, as well, even if SWC was not explicitly requested for it (we already > do that for INV faults to handle QNaNs). Otherwise, I’m going to be stuck > with UNPREDICTABLE as the result, and that’s not great. …and while we’re at it… The fenv(3) man suggests that if you have a SIGFPE handler set up in your program with exceptions enabled, and you do a: feholdexcept(&env); /* do stuff that might raise an exception. */ feupdateenv(&env); …that the feupdateenv() call would result in the SIGFPE being delivered to the handler. Not sure if we have unit tests for that stuff at the moment, but I’m pretty sure the alpha will not do that correctly as it stands (the fenv implementation for alpha appears to have been lifted from a FreeBSD implementation, and it interacts with the FPCR directly, rather than the architecturally mandated FP_C virtual register). -- thorpej
Re: Expected behavior when returning from a SIGFPE handler
> 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 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 set via fpgetsticky(). It then does "1.0
>>> / 0.0" again, and then verifies that the SIGFPE handler was not
>>> called a second time (because I never cleared DZE with
>>> fpsetsticky()).
>>
>> This strikes me as wrong.
>>
>> The status flags (fpgetsticky, fetestexcept) don't determine whether a
>> floating-point operation `signals an exception' (in the language of
>> IEEE 754-2019); they only record whether it happened in the past.
>>
>> It seems to me that if an operation [ieee754-]signals an exception
>> that the user has asked (with fpsetmask/feenableexcept) to be trapped,
>> then it should deliver a [unix-]signal, irrespective of whether some
>> past operation already [ieee754-]signalled an exception.
>
> I agree. I was describing behavior the alpha port already had. I will write
> a unit test for this behavior (specifically round DZE), or make sure that
> there is one that covers it already (there may be … I’m still peeling the
> onion on the alpha port…)
Ok, circling back on this point, the behavior I described for the alpha port is
also how amd64 behaves, which is to say “if the an exception is enabled and the
exception’s flag is already set, then the signal handler will not be called on
a second triggering of the exceptional condition”.
Consider this test program:
#include
#include
#include
#include
volatile float f_zero = 0.0;
siginfo_t siginfo_copy;
jmp_buf sigfpe_env;
volatile float f_result;
static void
sigfpe_action(int sig, siginfo_t *info, void *ctx)
{
siginfo_copy = *info;
longjmp(sigfpe_env, 1);
}
static void __noinline
divide_by_zero(void)
{
f_result = 1.0 / f_zero;
}
int
main(int argc, char *argv[])
{
struct sigaction sigact = {
.sa_sigaction = sigfpe_action,
.sa_flags = SA_SIGINFO,
};
(void) sigaction(SIGFPE, &sigact, NULL);
fp_except_t mask = fpgetmask();
printf("default MASK:\n");
if (mask & FP_X_INV)
printf("\tFP_X_INV\n");
if (mask & FP_X_DZ)
printf("\tFP_X_DZ\n");
if (mask & FP_X_OFL)
printf("\tFP_X_OFL\n");
if (mask & FP_X_UFL)
printf("\tFP_X_UFL\n");
if (mask & FP_X_IMP)
printf("\tFP_X_IMP\n");
#ifdef FP_X_IOV
if (mask & FP_X_IOV)
printf("\tFP_X_IOV\n");
#endif
fpsetmask(FP_X_DZ);
if (setjmp(sigfpe_env)) {
printf("SIGFPE 1 received: signo=%d code=%d\n",
siginfo_copy.si_signo,
siginfo_copy.si_code);
} else {
divide_by_zero();
printf("1: 1.0 / f_zero -> %f\n", f_result);
}
fp_except_t sticky = fpgetsticky();
if (sticky & FP_X_DZ) {
printf(“1: GOT FP_X_DZ!\n");
}
if (setjmp(sigfpe_env)) {
printf("SIGFPE 2 received: signo=%d code=%d\n",
siginfo_copy.si_signo,
siginfo_copy.si_code);
} else {
divide_by_zero();
printf("2: 1.0 / f_zero -> %f\n", f_result);
}
sticky = fpgetsticky();
if (sticky & FP_X_DZ) {
printf("2: GOT FP_X_DZ!\n");
}
return 0;
}
Running this program on amd64 results in:
the-ripe-vessel:thorpej 50$ ./fptest
default MASK:
SIGFPE 1 received: signo=8 code=3
2: 1.0 / f_zero -> inf
2: GOT FP_X_DZ!
the-ripe-vessel:thorpej 51$
…which seems very counter-intuitive to me.
I enable FP_X_DZ, I get the SIGFPE signal the first time, and fpgetsticky()
does NOT indicate FP_X_DZ … yet I do not get the second SIGFPE, and I get
FP_X_DZ from the second call to fpgetsticky()?
WTF is going on here?
-- thorpej
Re: 9.1: boot-time delay? [WORKAROUND FOUND]
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 both should be replaced by hztous()/ustohz(). 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 the other makes no sense. What these functions/macros do is convert between ms (or us) and ticks (another measure of a duration), not hz, so the misleading "hz" part of the name should be removed (changed) if a new macro/function is to be invented. (The benefit isn't worth it to justify changing the current existing names, but we shouldn't persist with nonsense if we're doing something new.) kre ps: note that the variable "hz" (and the macro HZ) are used correctly -- their values are frequencies (ticks/second).
Re: 9.1: boot-time delay? [WORKAROUND FOUND]
> 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 the other makes no sense. In this particular case it's converting frequency to period, that is a sensible conversion. You could say "hztoperiodinus" but that's rather verbose. paul
Re: 9.1: boot-time delay? [WORKAROUND FOUND]
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 happens, the "hz" part should be changed too. Not sure I agree with that. hz is (a unit of) a measure of frequency, ms (or us) is (a unit of) a measure of time (duration) - converting one to the other makes no sense. It sure does. Frequency essentially means a counting of the number of time something happens over a specific time period. With hertz, the time period is one second. So then converting the number of times an event happens in a second into how long it is between two events makes total sense. What these functions/macros do is convert between ms (or us) and ticks (another measure of a duration), not hz, so the misleading "hz" part of the name should be removed (changed) if a new macro/function is to be invented. (The benefit isn't worth it to justify changing the current existing names, but we shouldn't persist with nonsense if we're doing something new.) 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. And commonly at every tick you get an interrupt, and you do something, and then resume your normal work. The tick has passed. Waiting for the next one to happen. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: 9.1: boot-time delay? [WORKAROUND FOUND]
> 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 hardware?" or "For the next few ticks, we crunch on this...". /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: 9.1: boot-time delay? [WORKAROUND FOUND]
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. "How long are timer ticks on this hardware?" or "For the next few ticks, we crunch on this...". I think that is mostly a bit sloppy terminology where they actually want to know the time between two ticks. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: usb: does USBMALLOC_ZERO work correctly?
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
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 22:12:39.913414469 +
+++ src/sys/dev/usb/usb_mem.c 2021-05-27 01:36:53.189148366 +
@@ -135,6 +135,11 @@ usb_block_allocmem(bus_dma_tag_t tag, si
usb_blk_nfree--;
*dmap = b;
DPRINTFN(6, "free list size=%ju", b->size, 0, 0, 0);
+ if ((flags & USBMALLOC_ZERO) != 0) {
+ memset(b->kaddr, 0, b->size);
+ bus_dmamap_sync(b->tag, b->map, 0, b->size,
+ BUS_DMASYNC_PREWRITE);
+ }
return 0;
}
}
Re: 9.1: boot-time delay? [WORKAROUND FOUND]
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 into some number of milliseconds, the two are different units. That's just the same as you can't convert metres/second (velocity) into seconds. Given a particular velocity, and some number of metres, you can calculate the time it takes to move that far, but that isn't converting velocity into seconds. What it is happening is that (in one direction of the other, depending upon which function) it is converting between the number of ticks that occur and the duration of an interval (which of course depends upon the frequency, but it is not converting the frequency). The hztoms() function is no different than a ustoms() function, except that in the former we have a semi-variable (the frequency) which is simply a constant (1000) in the second - but that's only a variable because we allow HZ to vary (by architecture, and sometimes, configuration). Calling ustoms() thousandtoms() would be absurd. So is calling this one hztoms(). | You could say "hztoperiodinus" but that's rather verbose. That doesn't help, we're still not converting a frequency to a period. And in another reply: Johnny Billquist said: | Frequency essentially means a counting of the number of time something | happens over a specific time period. With hertz, the time period is one | second. Sure. | So then converting the number of times an event | happens in a second into how long it is between two events makes total | sense. It would, but that's not what the functions do. What they do is tell how many ticks occur in a specific number of milliseconds (or vice versa). Your calculation is just (in milliseconds) 1000/hz, and assuming hz isn't varying, is a constant. | 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. Sure, reasonable point, but as Mouse said, when we're dealing with this stuff the number of ticks is counted as a representation of the number of those durations, and we just say how many ticks happened. The ticks represent the duration between them - that might be slightly sloppy, but it isn't outright wrong. kre
Re: 9.1: boot-time delay? [WORKAROUND FOUND]
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 it isn't, you can't convert 60 ticks/second into some number of milliseconds, the two are different units. Not that much. To quote wikipedia: "The dimension of the unit hertz is 1/time (1/T). Expressed in base SI units it is 1/second (1/s)." So basically, it's just the inverse of time. Based on that, it's pretty clear that conversion to/from time is very valid. And in another reply: Johnny Billquist said: | Frequency essentially means a counting of the number of time something | happens over a specific time period. With hertz, the time period is one | second. Sure. | So then converting the number of times an event | happens in a second into how long it is between two events makes total | sense. It would, but that's not what the functions do. What they do is tell how many ticks occur in a specific number of milliseconds (or vice versa). Your calculation is just (in milliseconds) 1000/hz, and assuming hz isn't varying, is a constant. Good point. It's a conversion from ms (or whatever time) to/from the number of cycles (or ticks of you want) based on the frequency given. I didn't think this through enough. While I certainly believe it's perfectly valid to convert between a frequency and a time for a single cycle, it do become weird to talk about frequency if we are in fact talking about some specific number of cycles, although those cycles can only be converted to a time if we have a frequency. I guess you convinced me. We should really call it something like tickstoms and mstoticks. But that do rely on people then understanding that it is the ticks defined by HZ, and not any random ticks. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: usb: does USBMALLOC_ZERO work correctly?
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 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.orig2021-01-05 22:12:39.913414469 +
> > +++ src/sys/dev/usb/usb_mem.c 2021-05-27 01:36:53.189148366 +
> > @@ -135,6 +135,11 @@ usb_block_allocmem(bus_dma_tag_t tag, si
> > usb_blk_nfree--;
> > *dmap = b;
> > DPRINTFN(6, "free list size=%ju", b->size, 0, 0, 0);
> > + if ((flags & USBMALLOC_ZERO) != 0) {
> > + memset(b->kaddr, 0, b->size);
> > + bus_dmamap_sync(b->tag, b->map, 0, b->size,
> > + BUS_DMASYNC_PREWRITE);
> > + }
> > return 0;
> > }
> > }
> >
> >
Re: 9.1: boot-time delay? [WORKAROUND FOUND]
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 should better always round up to > | >guarantee a minimal delay. > | > | And both should be replaced by hztous()/ustohz(). > > 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 the other makes no sense. "hz" in this context comes from HZ - it is used here as dimension of 1s/HZ. Just like "ms" here is used as "1s/1000". It's a pretty sensible naming compared to much longer naming variants. Joerg
Re: 9.1: boot-time delay? [WORKAROUND FOUND]
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: | | >Either direction mstohz or hztoms should better always round up to | >guarantee a minimal delay. | | And both should be replaced by hztous()/ustohz(). 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 the other makes no sense. "hz" in this context comes from HZ - it is used here as dimension of 1s/HZ. Just like "ms" here is used as "1s/1000". It's a pretty sensible naming compared to much longer naming variants. Well, Robert have a point. If you say hztoms(4), we are not asking for a conversion from 4Hz to ms, but in fact four ticks at the current HZ, converted to ms. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: 9.1: boot-time delay? [WORKAROUND FOUND]
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: delay(5*HZ)wait 5 seconds timeout(ttrstrt, tp, HZ/4) trigger ttrstrt in 1/4 second That's the simplicity when your time units are 1/HZ, then the same number (called HZ) can stand for a frequency and a one second period. If the programming language would use measures (number + specific unit) instead of (integer) numbers, it became more explicit. But I guess a modern language would still allow to use the same value as a frequency or a period with some automatic type conversion. Can we go back now to the original problem ? Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
