On Wed, Oct 14, 2020 at 08:06:52PM -0500, Scott Cheloha wrote:
> _exit(2) and execve(2) need to obey the locking protocol described in
> proc.h when manipulating the per-process interval timer state.
>
> While we're here we can also remove the now pointless splclock/splx
> danc
_exit(2) and execve(2) need to obey the locking protocol described in
proc.h when manipulating the per-process interval timer state.
While we're here we can also remove the now pointless splclock/splx
dance from execve(2).
The easiest way to obey the locking protocol is to reuse the interface
Hey,
> On Oct 7, 2020, at 8:49 PM, 内藤 祐一郎 wrote:
>
> Hi.
>
> I'm looking forward to this patch is committed.
> Because this patch solves my problem about CARP timeout.
>
> IIJ, a company that I am working for, is using carp(4) on VMware ESXi hosts
> for VPN and web gateway services.
>
> One
> On Oct 7, 2020, at 15:51, Klemens Nanni wrote:
>
> On Wed, Oct 07, 2020 at 03:34:36PM -0500, Scott Cheloha wrote:
>> kn@ wanted to clean it up a while ago but I wan't far enough along
>> with hi-res timeouts to change the code yet.
> That was not me.
I am thinking of
Hi,
The code in realitexpire(), the ITIMER_REAL timeout callback, is
needlessly complicated.
kn@ wanted to clean it up a while ago but I wan't far enough along
with hi-res timeouts to change the code yet.
Hi-res timeouts are now imminent, and setitimer(2) will probably be
the first guinnea pig
On Sat, Oct 03, 2020 at 09:09:00AM +0200, Martin Pieuchot wrote:
> On 02/10/20(Fri) 19:09, Scott Cheloha wrote:
> > On Fri, Oct 02, 2020 at 12:19:35PM +0200, Martin Pieuchot wrote:
> > > @@ -635,12 +642,39 @@ sys_kevent(struct proc *p, void *v, regi
> &g
On Fri, Oct 02, 2020 at 12:19:35PM +0200, Martin Pieuchot wrote:
>
> [...]
>
> I'd like to get this in early in this release cycle, so please test and
> report back :o)
You removed the resleep logic that accounts for if/when tsleep_nsec(9)
returns early. So now select and pselect can return
On Tue, Sep 01, 2020 at 10:24:11AM -0500, Scott Cheloha wrote:
> On Mon, Aug 17, 2020 at 05:55:34PM -0500, Scott Cheloha wrote:
> >
> > [...]
>
> Two week bump.
>
> In summary:
>
> - Merge the critical sections so that "timer swap" with setitimer(2)
&
`found' serves as a boolean here. I'd prefer to simple and set it to
1 instead of incrementing it when we find what we're looking for.
ok?
Index: kern_resource.c
===
RCS file: /cvs/src/sys/kern/kern_resource.c,v
retrieving revision
> On Sep 24, 2020, at 07:43, Theo de Raadt wrote:
>
> Mark Kettenis wrote:
>
>>> Date: Thu, 24 Sep 2020 11:53:59 +0200
>>> From: Martin Pieuchot
>>>
>>> Convert various "if (x) panic()" idioms into "KASSERT(!x)". The panic
>>> message isn't helping for such sanity checks and this help
Hi,
After fussing with top(1)'s uptime display a bit I now think:
- An HH:MM:SS format uptime is useful in top(1). It's also more
visually consistent with the local timestamp printed on the line
above it, so it is easier to read at a glance.
- The variable printing of "days" is annoying.
Hi,
Using nanosleep(2) to print the stats periodically causes the period
to drift. If you use setitimer(2) it won't drift.
ok?
Index: kstat.c
===
RCS file: /cvs/src/usr.bin/kstat/kstat.c,v
retrieving revision 1.6
diff -u -p -r1.6
On Wed, Sep 16, 2020 at 01:20:16AM -0600, Theo de Raadt wrote:
> Two days ago during my work on ongoing work for non-acpi suspend,
> kettenis and I observed the same thing.
>
> your diff works very well for me.
Okay, so I'm not the only one.
Let's do the full patch:
- All rates in the vmstat
Hi,
systat(1)'s vmstat view displays rates for things like interrupts.
Strangely, it uses CPU time to compute these rates, not real time.
This is potentially misleading, particularly on an MP system. If I
have 4 cores running on a HZ=100 kernel I expect ~400 clock interrupts
per second. But
On Sat, Sep 05, 2020 at 01:11:59PM +0200, Mark Kettenis wrote:
> > Date: Fri, 4 Sep 2020 17:55:39 -0500
> > From: Scott Cheloha
> >
> > On Sat, Jul 25, 2020 at 08:46:08PM -0500, Scott Cheloha wrote:
> > >
> > > [...]
> > >
> > > I
On Tue, Aug 25, 2020 at 12:22:19PM -0700, Mike Larkin wrote:
> On Tue, Aug 25, 2020 at 12:12:36PM -0700, Mike Larkin wrote:
> > On Mon, Aug 24, 2020 at 01:55:45AM +0200, Mark Kettenis wrote:
> > > > Date: Sun, 23 Aug 2020 18:11:12 -0500
> > > > From:
On Fri, Sep 04, 2020 at 05:55:40PM -0500, Scott Cheloha wrote:
> On Sat, Jul 25, 2020 at 08:46:08PM -0500, Scott Cheloha wrote:
> >
> > [...]
> >
> > I want to add clock-based timeouts to the kernel because tick-based
> > timeouts suffer from a few problems:
On Sat, Jul 25, 2020 at 08:46:08PM -0500, Scott Cheloha wrote:
>
> [...]
>
> I want to add clock-based timeouts to the kernel because tick-based
> timeouts suffer from a few problems:
>
> [...]
>
> Basically, ticks are a poor approximation for the system clock. We
On Tue, Sep 01, 2020 at 06:14:05PM +0200, Mark Kettenis wrote:
> > Date: Tue, 1 Sep 2020 11:05:26 -0500
> > From: Scott Cheloha
> >
> > Hi,
> >
> > At boot, if we don't know the lapic frequency offhand we compute it by
> > waiting for a known clock (
Hi,
At boot, if we don't know the lapic frequency offhand we compute it by
waiting for a known clock (the i8254) with a known frequency to cycle
a few times.
Currently we cycle hz times. This doesn't make sense. There is
little to no benefit to waiting additional cycles if your kernel is
On Mon, Aug 17, 2020 at 05:55:34PM -0500, Scott Cheloha wrote:
>
> [...]
Two week bump.
In summary:
- Merge the critical sections so that "timer swap" with setitimer(2)
is atomic.
- To do this, move error-free operations into a common kernel
subroutine, setitimer().
On Sun, Aug 23, 2020 at 11:45:22PM -0500, Scott Cheloha wrote:
>
> [...]
>
> > > This patch (or something equivalent) is a prerequisite to running the
> > > lapic timer in oneshot or TSC deadline mode. Using the lapic timer to
> > > implement delay(9) wh
On Mon, Aug 24, 2020 at 01:55:45AM +0200, Mark Kettenis wrote:
> > Date: Sun, 23 Aug 2020 18:11:12 -0500
> > From: Scott Cheloha
> >
> > Hi,
> >
> > Other BSDs use the TSC to implement delay(9) if the TSC is constant
> > and invariant. Here's a pa
Hi,
Other BSDs use the TSC to implement delay(9) if the TSC is constant
and invariant. Here's a patch to add something similar to our kernel.
This patch (or something equivalent) is a prerequisite to running the
lapic timer in oneshot or TSC deadline mode. Using the lapic timer to
implement
On Tue, Jul 28, 2020 at 10:02:07AM +0300, Paul Irofti wrote:
>
> [...]
>
> Is the issue with LFENCE slowing down the network stack settled? That was
> the argument against it last time.
... a month passes. Nobody says anything.
This "it might slow down the network stack" thing keeps coming
Hi,
I was auditing the tree for odd-looking time structure usage and I
came across the UUID code in ldapd(8), uuid.c.
time_cmp() is backwards. Or the caller is misusing it. One or the
other. It returns -1 if tv1 exceeds tv2 but the comments in the
caller indicate the opposite impression. I
On Mon, Aug 17, 2020 at 12:57:33PM -0600, Theo de Raadt wrote:
> Scott Cheloha wrote:
>
> > There is one behavior change: in the setitimer(2) swap case it is now
> > possible to EFAULT on copyout(9) *after* you have written the new
> > timer value and (possibly) started
On Fri, Aug 14, 2020 at 06:11:25PM -0600, Theo de Raadt wrote:
> > It has occurred to me that we could do a trial copyout(9) in
> > sys_setitimer() before entering the critical section. This is a *bit*
> > wasteful, but is relatively inexpensive and narrows the behavior
> > change I mentioned
On Wed, Aug 12, 2020 at 01:58:08PM -0500, Scott Cheloha wrote:
>
> [...]
>
> There is one behavior change: in the setitimer(2) swap case it is now
> possible to EFAULT on copyout(9) *after* you have written the new
> timer value and (possibly) started the ITIMER_REAL timeout
Hi,
Things in getitimer(2) and setitimer(2) have been rearranged
adequately. Their critical sections are ready to be combined.
Merging these critical sections is necessary to make getitimer(2) and
setitimer(2) MP-safe. They are not ready to run without the kernel
lock just yet, but this diff
Hi,
Before merging the critical sections for setitimer(2) and getitimer(2)
we need to make their critical sections as similar as possible.
In getitimer(2) we read the timer value in one place in the code:
/* getitimer(2) pseudocode */
if (which != ITIMER_REAL)
Hi,
For what are probably historical reasons we don't validate the
setitimer(2) input until after we have (optionally called getitimer(2)
to copyout(9) the current timer value.
Consolidating the copyin(9), input validation, and input conversion
into a single block makes the setitimer(2) code
On Sun, Aug 09, 2020 at 04:43:24PM +0200, Mark Kettenis wrote:
> > Date: Sat, 8 Aug 2020 19:46:14 -0500
> > From: Scott Cheloha
> >
> > Hi,
> >
> > I want to annotate the locking for the per-process interval timers.
> >
> > In the process struct,
Hi,
We update the ITIMER_VIRTUAL and ITIMER_PROF per-process interval
timers from hardclock(9). If a timer is enabled we call itimerdecr()
to update and reload it as needed. If a timer has expired we then set
a flag on the current thread to signal itself when returning to
userspace.
However,
Hi,
I want to annotate the locking for the per-process interval timers.
In the process struct, the ITIMER_REAL itimerspec and the ps_itimer_to
timeout are protected by the kernel lock. These should be annotated
with "K", right?
Also in the process struct, the ITIMER_VIRTUAL and ITIMER_PROF
On Mon, Aug 03, 2020 at 07:16:46PM +1000, Jonathan Gray wrote:
> Scott mentioned that ktime should be using a runtime clock which stops
> during suspend. The exception to this is ktime_get_bootime() which does
> not stop when suspended.
>
> This is described in
>
timeout_add_ts(9) and timeout_add_bt(9) are not used anywhere.
ok to remove them?
Index: sys/kern/kern_timeout.c
===
RCS file: /cvs/src/sys/kern/kern_timeout.c,v
retrieving revision 1.76
diff -u -p -r1.76 kern_timeout.c
---
On Fri, Jul 24, 2020 at 04:05:18PM +1000, Jonathan Gray wrote:
> On Tue, Jul 21, 2020 at 05:10:02PM -0500, Scott Cheloha wrote:
> > On Tue, Jul 21, 2020 at 07:33:21PM +1000, Jonathan Gray wrote:
> > > Change from using timevals for ktime to 64 bit count of nanoseconds
> >
Hi,
I want to add clock-based timeouts to the kernel because tick-based
timeouts suffer from a few problems:
1. They are not sensitive to NTP adjustment, so they can easily
expire too early or too late. This is incorrect, particularly
for POSIX interfaces that forbid early return.
2.
On Fri, Jul 17, 2020 at 10:47:50AM -0900, Philip Guenther wrote:
> On Thu, Jul 16, 2020 at 4:55 PM Scott Cheloha
> wrote:
>
> > > On Jul 16, 2020, at 19:36, Theo de Raadt wrote:
> > >
> > >> Note the third sentence.
> > >>
> > >
tcp_close() schedules the reaper timeout to run immediately.
Does it need to run *immediately*? Can it wait for one tick?
I'm trying to eliminate these zero-tick timeouts because they
rely on undocumented behavior and impede an optimization I want
to make in the timeout layer.
This is the one
On Tue, Jul 21, 2020 at 07:33:21PM +1000, Jonathan Gray wrote:
> Change from using timevals for ktime to 64 bit count of nanoseconds
> to closer match linux. From a discussion with cheloha@
>
>
>
> @@ -67,70 +65,66 @@ ktime_get_raw_ns(void)
> }
>
> static inline struct timespec64
>
> On Jul 16, 2020, at 19:36, Theo de Raadt wrote:
>
>> Note the third sentence.
>>
>> Given that, I reason that a serializing instruction before *and* after
>> the RDTSC should freeze it in place.
>
> I haven't seen anyone read it that way.
They say that instructions after RDTSC can run
On Thu, Jul 16, 2020 at 02:14:45PM +0200, Christian Weisgerber wrote:
> Scott Cheloha:
>
> > Can we add the missing LFENCE instructions to userspace and the
> > kernel? And can we excise the upper 32 bits?
>
> > + uint32_t lo;
> > +
> > + asm volatile
On Sat, Jul 11, 2020 at 01:16:43PM +0200, Mark Kettenis wrote:
> > From: Paul Irofti
> > Date: Sat, 11 Jul 2020 13:50:37 +0300
> >
> > On 2020-07-11 13:46, Mark Kettenis wrote:
> > >> From: Paul Irofti
> > >> Date: Sat, 11 Jul 2020 13:32:22 +0300
> > >>
> > >> Hi,
> > >>
> > >> Getting lots of
Hi,
adjtime(2) skews the clock at up to 5000ppm per second. The way this
actually happens is pretty straightforward: at the start of every UTC
second we call ntp_update_second() from tc_windup() and reset
th_adjustment. th_adjustment is then mixed into the scale for one UTC
second. This cycle
On Tue, Jul 14, 2020 at 08:21:24PM -0400, George Koehler wrote:
> On Tue, 14 Jul 2020 11:59:14 +0200 (CEST)
> Mark Kettenis wrote:
>
> > Yeah, one possible approach would be to increment ogen by two. A
> > little bit easier to check that they can never be the same since one
> > is always odd
On Tue, Jul 14, 2020 at 11:59:14AM +0200, Mark Kettenis wrote:
> > Date: Mon, 13 Jul 2020 17:07:31 -0400
> > From: George Koehler
> >
> > On Mon, 13 Jul 2020 01:18:14 -0500
> > Scott Cheloha wrote:
> >
> > > To review, the update protocol
On Sun, Jul 12, 2020 at 11:44:57PM -0400, George Koehler wrote:
> Hello tech list,
>
> My CLOCK_MONOTONIC can jump backwards.
I can reproduce it here. Very unsettling.
> It looks like a problem with tk_generation in the user timekeep page.
> If tk_offset_count and tk_offset change but
On Thu, Jul 09, 2020 at 10:35:46AM +0200, Mark Kettenis wrote:
>
> Here is the arm64 version. Again I've taken the approach of copying
> the kernel timecounter code verbatim. Technically we don't need the
> Cortex-A73 errata workaround here since the timecounter only uses the
> low 32 bits.
On Wed, Jul 08, 2020 at 09:36:03AM -0600, Theo de Raadt wrote:
> Christian Weisgerber wrote:
>
> > On 2020-06-26, George Koehler wrote:
> >
> > > Here's macppc again. My macppc isn't using your newest diff but does
> > > now need to define TC_TB in .
> >
> > Crucial question: How confident
On Wed, Jul 08, 2020 at 09:09:53AM -0600, Theo de Raadt wrote:
> Scott Cheloha wrote:
>
> > > - __asm volatile("rd %%sys_tick, %0" : "=r" (tick) :);
> > > + __asm volatile("rd %%sys_tick, %0" : "=r" (tick));
> > >
&g
On Wed, Jul 08, 2020 at 01:35:30AM +0200, Mark Kettenis wrote:
> > Date: Tue, 7 Jul 2020 23:46:00 +0200 (CEST)
> > From: Mark Kettenis
> >
> > > Date: Tue, 7 Jul 2020 23:13:06 +0200
> > > From: Christian Weisgerber
> > >
> > > Mark Kettenis:
> > >
> > > > > ---
On Mon, Jul 06, 2020 at 11:57:32PM +0200, Mark Kettenis wrote:
> > Date: Mon, 6 Jul 2020 16:40:35 -0500
> > From: Scott Cheloha
> >
> > On Fri, Jul 03, 2020 at 10:52:15AM +0200, Otto Moerbeek wrote:
> > > On Thu, Jul 02, 2020 at 08:27:58PM -0500, Scott
On Fri, Jul 03, 2020 at 10:52:15AM +0200, Otto Moerbeek wrote:
> On Thu, Jul 02, 2020 at 08:27:58PM -0500, Scott Cheloha wrote:
>
> > Hi,
> >
> > When we recompute the scaling factor during tc_windup() there is an
> > opportunity for arithmetic overflow
On Sun, Jul 05, 2020 at 08:31:19PM +0300, Paul Irofti wrote:
> On Fri, Jul 03, 2020 at 06:36:39PM +0300, Paul Irofti wrote:
> >
> > ?n 3 iulie 2020 17:55:25 EEST, Mark Kettenis a
> > scris:
> > >> Date: Fri, 3 Jul 2020 15:13:22 +0200
> > >> From: Robert Nagy
> > >>
> > >> On 02/07/20 00:31
Hi,
I want to run the lapic timer in one-shot mode on amd64 as we do with
other interrupt clocks on other platforms. I aim to make the clock
interrupt code MD where possible.
However, nobody is going to test my MD clock interrupt work unless
amd64 is ready to use it. amd64 doesn't run in
On Fri, Jul 03, 2020 at 02:34:20PM +0300, Paul Irofti wrote:
> On 2020-07-03 00:40, Scott Cheloha wrote:
> > On Fri, Jun 26, 2020 at 04:53:14PM +0300, Paul Irofti wrote:
> > > On Wed, Jun 24, 2020 at 11:53:23AM +0200, Robert Nagy wrote:
> > > > On 22/06/20
On Fri, Jul 03, 2020 at 06:36:39PM +0300, Paul Irofti wrote:
>
>
> ??n 3 iulie 2020 17:55:25 EEST, Mark Kettenis a
> scris:
> >> Date: Fri, 3 Jul 2020 15:13:22 +0200
> >> From: Robert Nagy
> >>
> >> On 02/07/20 00:31 +0100, Stuart Henderson wrote:
> >> > running on 38 of these, btw.
> >>
>
Hi,
When we recompute the scaling factor during tc_windup() there is an
opportunity for arithmetic overflow/underflow when we add the NTP
adjustment into the scale:
649 scale = (u_int64_t)1 << 63;
650 scale += \
651 ((th->th_adjustment +
On Fri, Jun 26, 2020 at 04:53:14PM +0300, Paul Irofti wrote:
> On Wed, Jun 24, 2020 at 11:53:23AM +0200, Robert Nagy wrote:
> > On 22/06/20 19:12 +0300, Paul Irofti wrote:
> > > New iteration:
> > >
> > > - ps_timekeep should not coredump, pointed by deraadt@
> > > - set ps_timekeep to 0
> On Jun 19, 2020, at 12:40, Paul Irofti wrote:
>
> [...]
>
> +
> +static inline void
> +bintimeaddfrac(const struct bintime *bt, uint64_t x, struct bintime *ct)
> +{
> +ct->sec = bt->sec;
> +if (bt->frac > bt->frac + x)
> +ct->sec++;
> +ct->frac = bt->frac + x;
> +}
> +
>
On Wed, May 13, 2020 at 06:09:52PM +0200, Mark Kettenis wrote:
> > Date: Wed, 13 May 2020 16:55:24 +0100
> > From: Stuart Henderson
> >
> > Thanks for looking at this Paul!
> >
> > On 2020/05/13 17:15, Robert Nagy wrote:
> > > On 13/05/20 17:05 +0200, Mark Kettenis wrote:
> > > > > The update
On Tue, Mar 24, 2020 at 09:02:38PM +0100, Mark Kettenis wrote:
> > Date: Tue, 24 Mar 2020 12:52:55 -0500
> > From: Scott Cheloha
> >
> > On Tue, Mar 24, 2020 at 09:17:34AM +0100, Mark Kettenis wrote:
> > > > Date: Mon, 23 Mar 2020 21:57:
Ticks to seconds. Trivial.
ok?
Index: if_wi.c
===
RCS file: /cvs/src/sys/dev/ic/if_wi.c,v
retrieving revision 1.171
diff -u -p -r1.171 if_wi.c
--- if_wi.c 31 Dec 2019 10:05:32 - 1.171
+++ if_wi.c 6 Apr 2020
Hi,
I want to remove the use of ticks from bpf(4) and replace it
with the system uptime clock.
Before we can do that, though, we need to separate the bpf(4)
descriptor's nonblocking status and its read timeout. The
two states share the same struct member, bpf_d.bd_rtout.
Currently, if
On Tue, Mar 24, 2020 at 09:17:34AM +0100, Mark Kettenis wrote:
> > Date: Mon, 23 Mar 2020 21:57:46 -0500
> > From: Scott Cheloha
> >
> > On Sun, Mar 15, 2020 at 09:55:53PM -0500, Scott Cheloha wrote:
> > >
> > > [...]
> > >
> > >
On Sun, Mar 15, 2020 at 09:55:53PM -0500, Scott Cheloha wrote:
>
> [...]
>
> This is a straightforward ticks-to-milliseconds conversion, but IIRC
> pirofti@ wanted me to get some tests before committing it.
>
> The only users of acpi_sleep() are (a) acpitz(4) and (b) any
Hi,
This is a straightforward ticks-to-milliseconds conversion, but IIRC
pirofti@ wanted me to get some tests before committing it.
The only users of acpi_sleep() are (a) acpitz(4) and (b) any AML code
that uses AMLOP_SLEEP. AMLOP_SLEEP seems to trigger just before a
suspend. I don't know when
On Tue, Jan 21, 2020 at 08:06:14PM -0600, Scott Cheloha wrote:
> On Mon, Dec 23, 2019 at 01:23:28PM -0600, Scott Cheloha wrote:
> > 1/16 seconds is exactly 62500 microseconds.
> >
> > ok?
>
> 1mo bump.
3 month bump.
After pondering this for many months I've
For the sleep, ticks to milliseconds.
The timeout is hz / 10, so 100 milliseconds.
While here, also add relevant includes.
ok?
Index: pci/pccbb.c
===
RCS file: /cvs/src/sys/dev/pci/pccbb.c,v
retrieving revision 1.99
diff -u -p
On Fri, Jan 10, 2020 at 05:41:23PM -0600, Scott Cheloha wrote:
> cz(4) is apparently not compiled, but it keeps showing up in my symbol
> searches, so I'll just convert it to reduce noise.
>
> Here the code is converting CZ_POLL_MS to ticks. We can just use that
> co
On Fri, Jan 10, 2020 at 06:54:26PM -0600, Scott Cheloha wrote:
> Ticks to milliseconds.
>
> ok?
Bump and rebase.
1/2 seconds, so, 500 milliseconds.
ok?
Index: dwiic.c
===
RCS file: /cvs/src/sys/dev/ic/dwiic.c,v
r
On Fri, Jan 10, 2020 at 07:31:28PM -0600, Scott Cheloha wrote:
> Ticks to milliseconds.
>
> ok?
Bump.
1/4 seconds, so, 250 milliseconds.
Index: ic/i82365.c
===
RCS file: /cvs/src/sys/dev/ic/i82365.c,v
retrieving revision
1/10 seconds, so, 100 milliseconds.
ok?
Index: ic/pgt.c
===
RCS file: /cvs/src/sys/dev/ic/pgt.c,v
retrieving revision 1.97
diff -u -p -r1.97 pgt.c
--- ic/pgt.c9 Jan 2020 14:35:19 - 1.97
+++ ic/pgt.c20 Feb 2020
On Wed, Feb 19, 2020 at 05:26:40PM +0100, Otto Moerbeek wrote:
> On Wed, Feb 19, 2020 at 05:10:11PM +0100, Otto Moerbeek wrote:
>
> > On Wed, Feb 19, 2020 at 10:02:10AM -0600, Scott Cheloha wrote:
> >
> > > On Wed, Feb 19, 2020 at 04:00:34PM
On Wed, Feb 19, 2020 at 04:00:34PM +0100, Otto Moerbeek wrote:
>
> [...]
>
> FFS1, the default filesystem, uses 32-bit signed timestamps on disk.
> That means that in 2038, there's going to be a problem, timestamps
> will the be interperet as coming from the start of the 1900's.
>
> FFS2 does
On Mon, Feb 17, 2020 at 07:40:40PM -0500, Kenneth R Westerback wrote:
> On Mon, Feb 17, 2020 at 06:23:01PM -0600, Scott Cheloha wrote:
> > On Sat, Jan 11, 2020 at 02:57:14AM -0600, Scott Cheloha wrote:
> > > The sleep duration is in milliseconds. We can rip out the timeval
Convert WI_WAVELAN_RES_TIMEOUT from ticks to milliseconds and use
timeout_add_msec(9) directly.
We can also easily use tsleep_nsec(9) here instead of tsleep(9).
ok?
Index: if_wi.c
===
RCS file: /cvs/src/sys/dev/ic/if_wi.c,v
Infinite sleep, trivial.
ok?
Index: net/if_pppx.c
===
RCS file: /cvs/src/sys/net/if_pppx.c,v
retrieving revision 1.74
diff -u -p -r1.74 if_pppx.c
--- net/if_pppx.c 28 Jan 2020 16:26:09 - 1.74
+++ net/if_pppx.c
On Sat, Jan 11, 2020 at 02:57:14AM -0600, Scott Cheloha wrote:
> The sleep duration is in milliseconds. We can rip out the timeval and
> tvtohz(9) and use MSEC_TO_NSEC() directly instead. I've added a local
> "msecs" variable because "timo" (a) feels a bi
On Thu, Feb 13, 2020 at 02:08:32PM +0100, Jeremie Courreges-Anglas wrote:
> On Wed, Feb 12 2020, Scott Cheloha wrote:
> > On Wed, Feb 12, 2020 at 01:35:22PM +0100, Jeremie Courreges-Anglas wrote:
> >> On Wed, Feb 12 2020, Jeremie Courreges-Anglas wrote:
> >> >
On Wed, Feb 12, 2020 at 01:35:22PM +0100, Jeremie Courreges-Anglas wrote:
> On Wed, Feb 12 2020, Jeremie Courreges-Anglas wrote:
> > On Sat, Jan 25 2020, Jeremie Courreges-Anglas wrote:
> >> The diff below improves the way apmd -z/-Z may trigger.
> >>
> >> I think the current behavior is bogus,
Another sbus(4) device driver.
This code converts between milliseconds and ticks. If we strip out
the conversions we can just use milliseconds directly with
timeout_add_msec(9) and delete the conversion code, too.
This is only built for sparc64. It ought to compile but I'm not sure.
Assuming
Ticks to microseconds.
The parameter name "ms" is misleading. All the calling code uses
microseconds. I think the author's thought process in choosing that
name was roughly: "microseconds" -> "Micro Seconds" -> "ms".
In any case, I've renamed the parameter to the less misleading
"usecs".
This
On Mon, Feb 10, 2020 at 11:48:34AM +0100, Mark Kettenis wrote:
> On 2020-02-08 20:15, Scott Cheloha wrote:
> > On Sun, Dec 22, 2019 at 01:17:56PM -0600, Scott Cheloha wrote:
> > > lcd_softc.sc_delay's unit appears to be microseconds.
> > >
> > > ok?
> &
On Sun, Dec 22, 2019 at 01:17:56PM -0600, Scott Cheloha wrote:
> lcd_softc.sc_delay's unit appears to be microseconds.
>
> ok?
1 month bump.
Index: dev/lcd.c
===
RCS file: /cvs/src/sys/arch/hppa/dev/lcd.c,v
retrieving rev
Ticks to seconds.
ok?
Index: ic/rtsx.c
===
RCS file: /cvs/src/sys/dev/ic/rtsx.c,v
retrieving revision 1.21
diff -u -p -r1.21 rtsx.c
--- ic/rtsx.c 9 Oct 2017 20:06:36 - 1.21
+++ ic/rtsx.c 7 Feb 2020 14:13:40 -
@@
Ticks to seconds. Easy.
There's a polling sleep earlier in the code that I'm going to
leave as-is for now.
ok?
Index: ipmi.c
===
RCS file: /cvs/src/sys/dev/ipmi.c,v
retrieving revision 1.108
diff -u -p -r1.108 ipmi.c
--- ipmi.c
On Fri, Jan 10, 2020 at 05:55:14PM -0600, Scott Cheloha wrote:
> Here the timeout constants are all in terms of seconds. We can change
> the input unit of the wait functions from hz to seconds and then
> convert as needed.
>
> sdhc_wait_intr_cold() uses delay(9), so convert
This one is a bit odd.
We tsleep(9) if !cold *and* usecs is a duration longer than a tick.
Otherwise we delay(9).
I am reluctant to leave the "usecs > tick" comparison here, but I am
even more reluctant to remove it and introduce latency where there
wasn't any before.
I'm going to leave the
> On Jan 29, 2020, at 10:26 AM, Jason McIntyre wrote:
>
> On Wed, Jan 29, 2020 at 11:12:56AM -0500, David Goerger wrote:
>> Monday, 20200127 18:29-0500, Daniel Jakots wrote:
>>> Can't you achieve what you want with `du -sh * | sort -h`? du(1)'s
>>> -h options will automatically select the best
On Sun, Dec 22, 2019 at 01:34:54PM -0600, Scott Cheloha wrote:
> As per dev/wscons/wsconsio.h, wskbd_bell_data.period is a count of
> milliseconds.
>
> ok?
1 month bump.
> Index: sunkbd.c
> ===
> RCS file:
Sleep for the same duration as the delay(9) in the cold path.
ok?
Index: pv/hyperv.c
===
RCS file: /cvs/src/sys/dev/pv/hyperv.c,v
retrieving revision 1.44
diff -u -p -r1.44 hyperv.c
--- pv/hyperv.c 7 Oct 2019 15:36:01 -
Ticks to milliseconds.
ok?
Index: i2c/ihidev.c
===
RCS file: /cvs/src/sys/dev/i2c/ihidev.c,v
retrieving revision 1.21
diff -u -p -r1.21 ihidev.c
--- i2c/ihidev.c31 Jul 2019 16:09:12 - 1.21
+++ i2c/ihidev.c23
Now that we've separated the sleeping path and the busy-waiting path
we can remove the ticks.
"i" is a count of milliseconds here. Convert it to a timespec to
get a starting interval "ts" and add that to the current time "now"
to get an absolute timeout "end".
Then we chip away at it as we loop
On Tue, Jan 21, 2020 at 07:23:43PM -0700, Theo de Raadt wrote:
> I suspect this breaks an usage case which is not documented.
>
> People may be doing leave +1 to mean "1 minutes".
>
> % leave +1
> Alarm set for Tue Jan 21 19:23. (pid 55602)
> % date
> Tue Jan 21 19:22:32 MST 2020
> % Just one
If you look at the for-loop in ciss_cmd() you can see that there are
really two loops. One for SCSI_NOSLEEP with delay(9), the other with
tsleep(9). The two paths basically don't interact, they merely happen
to share the loop.
If we pull the if-else out of the loop and give each clause its own
On Mon, Dec 23, 2019 at 01:26:34PM -0600, Scott Cheloha wrote:
> hz/4 -> 250ms.
>
> ok?
1mo bump.
> Index: w83l518d_sdmmc.c
> ===
> RCS file: /cvs/src/sys/dev/ic/w83l518d_sdmmc.c,v
> retrieving revisio
On Mon, Dec 23, 2019 at 01:23:28PM -0600, Scott Cheloha wrote:
> 1/16 seconds is exactly 62500 microseconds.
>
> ok?
1mo bump.
> Index: arch/hppa/hppa/autoconf.c
> ===
> RCS file: /cvs/src/sys/arch/hppa
501 - 600 of 927 matches
Mail list logo
