Stefan Sperling wrote:
> This patch adds support for 40MHz channels to iwx(4).
>
> Please sync your source tree before attempting to apply this patch.
> I have committed some changes to this driver today which this patch
> is based on.
>
> Works for me on AX200/AX201. Does anyone else want to do
Diff below is the counterpart of the select(2) one I just committed to
make poll(2) and ppoll(2) use kqueue internally.
They use the same logic as select(2): convert pollfd into kqueue events
with EV_SET(2) then wait in kqueue_scan().
To make this implementation compatible with the existing
On 12.10.2021. 16:29, Hrvoje Popovski wrote:
> On 12.10.2021. 14:47, Stefan Sperling wrote:
>> This patch adds support for 40MHz channels to iwx(4).
>>
>> Please sync your source tree before attempting to apply this patch.
>> I have committed some changes to this driver today which this patch
>>
OK bluhm@
> - out:
> - fdpunlock(fdp);
> +out:
With a space before the label, diff -p shows the function name and
not some label within the function. I consider this helpful when
reading diffs.
On Thu, 14 Oct 2021 at 09:21:18 +0200, Stefan Hagen wrote:
> This ramp up time is reproducible. It always starts slower in the first
> 1 or 2 seconds and then ramps up to full speed.
I've observed this in ethernet transfers on OpenBSD for a long time,
it's not limited to WiFi.
On Thu, Oct 14, 2021 at 01:15:56AM +0200, Mark Kettenis wrote:
> Currently the lib/libm/msun/run-lrint_test regress fails on powerpc64
> and other platforms. Our implementation came from NetBSD, but NetBSD
> switched to the implementation from FreeBSD some time ago. That is
> the same
On Thu, 14 Oct 2021 01:15:56 +0200, Mark Kettenis wrote:
> Currently the lib/libm/msun/run-lrint_test regress fails on powerpc64
> and other platforms. Our implementation came from NetBSD, but NetBSD
> switched to the implementation from FreeBSD some time ago. That is
> the same implementation
On Thu, 14 Oct 2021 23:06:01 +0200, Mark Kettenis wrote:
> This doesn't work because of the hidden symbol madness. The way
> things currently are we need one copy (s_lrint.c) with:
>
> DEF_STD(fn);
> LDBL_MAYBE_CLONE(fn);
>
> another version (s_lrintf.c) with
>
> DEF_STD(fn);
>
> and a final
joshua stein wrote:
> On Thu, 14 Oct 2021 at 09:21:18 +0200, Stefan Hagen wrote:
> > This ramp up time is reproducible. It always starts slower in the first
> > 1 or 2 seconds and then ramps up to full speed.
>
> I've observed this in ethernet transfers on OpenBSD for a long time,
> it's not
> Date: Thu, 14 Oct 2021 22:23:25 +0200
> From: Alexander Bluhm
>
> On Thu, Oct 14, 2021 at 01:15:56AM +0200, Mark Kettenis wrote:
> > Currently the lib/libm/msun/run-lrint_test regress fails on powerpc64
> > and other platforms. Our implementation came from NetBSD, but NetBSD
> > switched to
Hi,
When we compute high resolution time, both in the kernel and in libc,
we get a 32-bit (or smaller) value from the active timecounter and
scale it up into a 128-bit bintime.
The scaling math currently looks like this in the kernel:
*bt = th->th_offset;
bintimeaddfrac(bt,
> From: "Todd C. Miller"
> Date: Thu, 14 Oct 2021 14:40:13 -0600
>
> On Thu, 14 Oct 2021 01:15:56 +0200, Mark Kettenis wrote:
>
> > Currently the lib/libm/msun/run-lrint_test regress fails on powerpc64
> > and other platforms. Our implementation came from NetBSD, but NetBSD
> > switched to the
On Mon, Oct 11, 2021 at 09:13:16AM -0500, Scott Cheloha wrote:
> On Sun, Oct 10, 2021 at 08:26:04PM -0400, gwes wrote:
> > On 10/10/21 5:03 PM, Scott Cheloha wrote:
> > > [...]
> > >
> > > If we want to have the unportable legacy syntax then it should work
> > > like other option arguments.
> On Oct 14, 2021, at 18:09, Scott Cheloha wrote:
>
> On Thu, Oct 14, 2021 at 11:37:44PM +0200, Mark Kettenis wrote:
>>> Date: Thu, 14 Oct 2021 16:13:17 -0500
>>> From: Scott Cheloha
>>>
>>> [...]
>>>
>>> Thoughts?
>>
>> I never understood this code. But I don't understand that if our
>>
> Date: Thu, 14 Oct 2021 16:13:17 -0500
> From: Scott Cheloha
>
> Hi,
>
> When we compute high resolution time, both in the kernel and in libc,
> we get a 32-bit (or smaller) value from the active timecounter and
> scale it up into a 128-bit bintime.
>
> The scaling math currently looks like
On Thu, Oct 14, 2021 at 11:37:44PM +0200, Mark Kettenis wrote:
> > Date: Thu, 14 Oct 2021 16:13:17 -0500
> > From: Scott Cheloha
> >
> > [...]
> >
> > Thoughts?
>
> I never understood this code. But I don't understand that if our
> timecounters are only 32 bits, we need more than 64 bits to
Hello tech list,
OpenBSD's libm is missing logbl(3) function on archs where long double
is double. The missing logbl breaks my builds of "NEW: devel/dtools"
(ports list) on macppc and powerpc64. I guess that other software
avoids logbl and prefers ilogbl(3) or frexp(3).
This diff adds logbl
17 matches
Mail list logo
