On 30/05/20(Sat) 09:25, Theo de Raadt wrote:
> [...]
> What does this have to do with threads? That is an implimentation detail.
This implementation detail is specific to NFS, no other FS do anything
like that. So I'm questioning whether calling kthread_create(9) inside a
kqueue(2) handler,
On 2020-05-31 07:28, Theo de Raadt wrote:
PowerPC Mac OS X had a userland gettimeofday(2) using the cpu's
timebase and a "common page" from the kernel. Their common page also
had executable code for gettimeofday, memcpy, pthread_self, and a few
other functions.
We are desperately avoiding the
On 30/05/20(Sat) 15:49, Visa Hankala wrote:
> [...]
> Local filesystems can observe changes at the source, which makes polling
> unnecessary. NFS clients do not have that benefit. The NFSv3 protocol
> lacks a mechanism to notify clients of changes.
>
> The NFS polling mechanism is in use for
On Fri, 29 May 2020 11:25:44 +0200
Bruno Flueckiger wrote:
> Hi,
>
> My brand new laptop HP EliteBook 850 G6 comes with an Intel 300 Series
> HD Audio device rev 0x11. The device shows up as not configured in the
> dmesg. The PCI config space of the device identifies its subclass as
>
NFS poll(2)/select(2) and kqueue(2) behaviors are incoherent. Diff
below uses the kernel-only NOTE_IMM hint to make the kqueue handlers
behave like the current poll handler: the poller is bypassed.
The new EVFILT_WRITE handler doesn't check for NOTE_IMM because it is
unlikely to introduce
On Fri, May 29, 2020 at 02:41:07PM +1000, David Gwynne wrote:
> This is another bit of the puzzle for supporting multiple rx rings
> and receive side scaling (RSS) on nics. It borrows heavily from
> DragonflyBSD, but I've made some tweaks on the way.
>
> For background on the dfly side, I
On Sun, May 31, 2020 at 09:40:47AM +0200, Martin Pieuchot wrote:
> On 30/05/20(Sat) 15:49, Visa Hankala wrote:
> > [...]
> > Local filesystems can observe changes at the source, which makes polling
> > unnecessary. NFS clients do not have that benefit. The NFSv3 protocol
> > lacks a mechanism to
On 30/05/2020 00:19, Jason A. Donenfeld wrote:
> Note that you need to run this with `-nographic`, because the kernel
> crashes when trying to use vgafb on sparc64/qemu. I've witnessed two
> varieties crashes:
>
> - https://data.zx2c4.com/openbsd-6.7-sparc64-vga-panic-miniroot67.png
> This
On 30/05/2020 10:54, Otto Moerbeek wrote:
> https://cdn.openbsd.org/pub/OpenBSD/snapshots/sparc64/
> contains the unpatched miniroot.
>
> https://www.drijf.net/openbsd/disk.qcow2
>
> is the disk image based on the miniroot containing the patch in the
> firts post in this thread.
>
> Thanks for
On Sun, May 31, 2020 at 12:25:00AM -0400, George Koehler wrote:
> On Sat, 30 May 2020 19:21:30 +0300
> Paul Irofti wrote:
>
> > Here is an updated diff with no libc bump. Please use this one for
> > further testing.
>
> Your diff does amd64.
> Here is a diff to add macppc. Apply after your
FS poll handlers always return true kqueue handlers are different. So
the diff below introduces a new NOTE_IMM hint to be able to match the
existing poll(2)/select(2) behavior.
This hint is obviously kernel-only. This is related to the NFS poller
discussion so I'm bringing the diff now in order
On Sun, May 31, 2020 at 09:49:34AM +0100, Mark Cave-Ayland wrote:
> On 30/05/2020 10:54, Otto Moerbeek wrote:
>
> > https://cdn.openbsd.org/pub/OpenBSD/snapshots/sparc64/
> > contains the unpatched miniroot.
> >
> > https://www.drijf.net/openbsd/disk.qcow2
> >
> > is the disk image based on
> Date: Sun, 31 May 2020 00:25:00 -0400
> From: George Koehler
>
> On Sat, 30 May 2020 19:21:30 +0300
> Paul Irofti wrote:
>
> > Here is an updated diff with no libc bump. Please use this one for
> > further testing.
>
> Your diff does amd64.
> Here is a diff to add macppc. Apply after your
> Date: Sun, 31 May 2020 00:25:00 -0400
> From: George Koehler
>
> On Sat, 30 May 2020 19:21:30 +0300
> Paul Irofti wrote:
>
> > Here is an updated diff with no libc bump. Please use this one for
> > further testing.
>
> Your diff does amd64.
> Here is a diff to add macppc. Apply after your
On 31.05., Benjamin Baier wrote:
> On Fri, 29 May 2020 11:25:44 +0200
> Bruno Flueckiger wrote:
>
> > Hi,
> >
> > My brand new laptop HP EliteBook 850 G6 comes with an Intel 300 Series
> > HD Audio device rev 0x11. The device shows up as not configured in the
> > dmesg. The PCI config space of
Hi,
updated diff after millert@ and beck@ remarks:
- use union to collapse in_addr + in6_addr
- doesn't allocate buffer and directly use s->relay->domain->name
Thanks.
--
Sebastien Marie
diff 73b535ef4537e8454483912fc3420bc304759e96 /home/semarie/repos/openbsd/src
blob -
On 2020-05-31 20:46, Mark Kettenis wrote:
From: Paul Irofti
Date: Sun, 31 May 2020 19:12:54 +0300
On 2020-05-31 18:25, Theo de Raadt wrote:
Mark Kettenis wrote:
I changed __amd64 to __amd64__ because I didn't find __powerpc. I'm
not sure, but one might move the list of arches to
On 2020-05-31 20:51, Theo de Raadt wrote:
(There has been some pressure to get this in before it covers all the
architectures and this kind of discussion is why I think such a
premature "and then we'll fix it in the tree" procedure is wrong).
Again, I hope not from me. I am in no rush with
Paul Irofti wrote:
> > Forget about all that for a moment. Here is an alternative suggestion:
> >
> > On sparc64 we need to support both tick_timecounter and
> > sys_tick_timecounter. So we need some sort of clockid value to
> > distnguish between those two. I already suggested to use the
> From: Paul Irofti
> Date: Sun, 31 May 2020 19:12:54 +0300
>
> On 2020-05-31 18:25, Theo de Raadt wrote:
> > Mark Kettenis wrote:
> >
> >>> I changed __amd64 to __amd64__ because I didn't find __powerpc. I'm
> >>> not sure, but one might move the list of arches to dlfcn/Makefile.inc
> >>>
Mark Kettenis wrote:
> On sparc64 we need to support both tick_timecounter and
> sys_tick_timecounter. So we need some sort of clockid value to
> distnguish between those two. I already suggested to use the tc_user
> field of the timecounter for that. 0 means that a timecounter is not
>
Hello tech@,
While using my macppc to try a port I noticed there is a discrepancy
between login classes limits: default datasize-cur is defined to 2048M
while staff datasize-cur is 512M. This happened in
/src/etc/etc.macppc/login.conf 1.12 as "grow limits a bit because clang
is a pig." A similar
On Tue, May 26, 2020 at 12:08:08PM -0400, matthew j weaver wrote:
> During childsa last use checks, iked debug logs results, per SA, after a
> successful pfkey_sa_last_used call.
>
> This patch makes logging behavior more closely match that, on error.
>
> I chose log_warn instead of log_debug
Lucas wrote:
> Hello tech@,
>
> While using my macppc to try a port I noticed there is a discrepancy
> between login classes limits: default datasize-cur is defined to 2048M
> while staff datasize-cur is 512M. This happened in
> /src/etc/etc.macppc/login.conf 1.12 as "grow limits a bit because
Mark Cave-Ayland wrote:
> On 30/05/2020 00:19, Jason A. Donenfeld wrote:
>
> > Note that you need to run this with `-nographic`, because the kernel
> > crashes when trying to use vgafb on sparc64/qemu. I've witnessed two
> > varieties crashes:
> >
> > -
looks good to me
ok beck@
On Sun, May 31, 2020 at 03:38:00PM +0200, Sebastien Marie wrote:
> Hi,
>
> updated diff after millert@ and beck@ remarks:
> - use union to collapse in_addr + in6_addr
> - doesn't allocate buffer and directly use s->relay->domain->name
>
> Thanks.
> --
> Sebastien
Paul Irofti wrote:
> On 2020-05-31 19:17, Theo de Raadt wrote:
> > Paul Irofti wrote:
> >
> >> Yeah, I just followed the dlfcn/dlfcn_stubs.c example from libc. Which
> >> I see now it is commented out...
> >>
> > --- lib/libc/dlfcn/init.c.beforeSat May 30 23:26:35 2020
> > +++
On Sun, May 31, 2020 at 03:22:45PM +0200, Otto Moerbeek wrote:
> On Sun, May 31, 2020 at 09:49:34AM +0100, Mark Cave-Ayland wrote:
> > Thanks for the test case which enables me to reproduce the issue. With
> > ?fcode-verbose
> > enabled you see this at the end of the FCode execution:
FWIW, on
Hi Martijn,
Martijn van Duren wrote on Tue, May 19, 2020 at 10:25:37PM +0200:
> So according to RFC2579 an octetstring can contain UTF-8 characters if
> so described in the DISPLAY-HINT. One of the main consumers of this is
> SnmpAdminString, which is used quite a lot.
>
> Now that we trimmed
Mark Kettenis wrote:
> > I changed __amd64 to __amd64__ because I didn't find __powerpc. I'm
> > not sure, but one might move the list of arches to dlfcn/Makefile.inc
> > and do -DTIMEKEEP, like how thread/Makefile.inc does -DFUTEX. One
> > might drop the tc_get_timecount function pointer and
On 2020-05-31 18:25, Theo de Raadt wrote:
Mark Kettenis wrote:
I changed __amd64 to __amd64__ because I didn't find __powerpc. I'm
not sure, but one might move the list of arches to dlfcn/Makefile.inc
and do -DTIMEKEEP, like how thread/Makefile.inc does -DFUTEX. One
might drop the
On 31/05/2020 15:58, Theo de Raadt wrote:
>> AFAICT the problem here is the Forth being used at
>> https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511:
>> since the
>> addr word isn't part of the IEEE-1275 specification, it is currently
>> unimplemented in
>> OpenBIOS.
>>
Paul Irofti wrote:
> Yeah, I just followed the dlfcn/dlfcn_stubs.c example from libc. Which
> I see now it is commented out...
>
> >>> --- lib/libc/dlfcn/init.c.before Sat May 30 23:26:35 2020
> >>> +++ lib/libc/dlfcn/init.c Sat May 30 18:00:45 2020
> >>> @@ -70,7 +70,7 @@
> >>> /* provide
On 2020-05-31 19:17, Theo de Raadt wrote:
Paul Irofti wrote:
Yeah, I just followed the dlfcn/dlfcn_stubs.c example from libc. Which
I see now it is commented out...
--- lib/libc/dlfcn/init.c.beforeSat May 30 23:26:35 2020
+++ lib/libc/dlfcn/init.c Sat May 30 18:00:45 2020
@@
> At the end of this loop, key[b] contains two copies of the cyclically
> permuted skey next to each other. When building the cache, you scan
> through the bits of val, xor the corresponding keys in if they're set
> and then throw away half of the 32 bits when assigning
> scache->bytes[val] = res;
35 matches
Mail list logo
