On Thu, Nov 11, 2021 at 02:13:26PM -0600, Scott Cheloha wrote:
> On Thu, Nov 11, 2021 at 08:53:20PM +0100, Mark Kettenis wrote:
> > > Date: Thu, 11 Nov 2021 13:30:04 -0600
> > > From: Scott Cheloha
> > >
> > > My understanding of sigsuspend(2) is that it only returns if a signal
> > > is delivere
On Thu, Nov 11, 2021 at 02:42:39PM +0100, Stefan Sperling wrote:
> Testing on 4965 by jsg@ revealed an unrelated issue on those devices.
> A fix for this problem has just been committed.
> This new version of the 40MHz patch applies on top of that fix.
Working fine on my "Intel Centrino Advanced-N
Anton Lindqvist writes:
> On Thu, Nov 11, 2021 at 03:29:15PM +0100, Anton Lindqvist wrote:
>> Hi,
>> The second attempt to solve the uhidev claim multiple report ids
>> conflict didn't work out either as it broke fido(4). Signalling claim
>> multiple report ids to the match routines using the rep
The final step before rework UNIX sockets to fine grained locks. Except
`unp_ino' this leaves only per-socket data protected by `unp_lock'. The
`unp_ino' protection is not the big deal and will be done with mutex(9)
in the future diff.
The `unp_gc_lock' rwlock(9) protects `unp_defer', `unp_gcing',
On Thu, Nov 11, 2021 at 06:25:46PM +0100, Leon Fischer wrote:
> Some keywords in make(1)'s list of conditionals have extra spaces:
>
> .ifmake [!]target [operator target ...]
> Test the target being built.
>
> .ifnmake [!] target [operator target ...]
> Test th
On Thu, Nov 11, 2021 at 08:30:45PM +, Klemens Nanni wrote:
> On Thu, Nov 11, 2021 at 08:13:13PM +, Jason McIntyre wrote:
> > i don;t think this bit of text works well now because you say it runs
> > ifconfig 3 times then ... respectively. but you only list two things
> > (even though i unde
On Thu, Nov 11, 2021 at 08:13:13PM +, Jason McIntyre wrote:
> i don;t think this bit of text works well now because you say it runs
> ifconfig 3 times then ... respectively. but you only list two things
> (even though i understand dynamic config is two). since your text is
> already clear, i'd
On Thu, Nov 11, 2021 at 08:53:20PM +0100, Mark Kettenis wrote:
> > Date: Thu, 11 Nov 2021 13:30:04 -0600
> > From: Scott Cheloha
> >
> > My understanding of sigsuspend(2) is that it only returns if a signal
> > is delivered to the calling thread. However, in sys_sigsuspend() we
> > pass &p->p_p-
On Thu, Nov 11, 2021 at 08:01:37PM +, Klemens Nanni wrote:
> On Thu, Nov 11, 2021 at 05:48:24PM +, Stuart Henderson wrote:
> > On 2021/11/11 16:30, Klemens Nanni wrote:
> > > On Thu, Nov 11, 2021 at 04:11:10PM +, Raf Czlonka wrote:
> > > > Hello,
> > > >
> > > > It seems like this has
On Thu, Nov 11, 2021 at 05:48:24PM +, Stuart Henderson wrote:
> On 2021/11/11 16:30, Klemens Nanni wrote:
> > On Thu, Nov 11, 2021 at 04:11:10PM +, Raf Czlonka wrote:
> > > Hello,
> > >
> > > It seems like this has been missed in recent thread[0].
> > >
> > > Not entirely sure whether the
The growth is not terrible, considering what media this is.
Fine with me.
Klemens Nanni wrote:
> On Thu, Nov 04, 2021 at 10:49:46PM +, Klemens Nanni wrote:
> > amd64, alpha, i386 and macppc strip all symbols off the ramdisk bsd.rd
> > (before gzipping it) and thus break config(8)'s modifica
> Date: Thu, 11 Nov 2021 13:30:04 -0600
> From: Scott Cheloha
>
> My understanding of sigsuspend(2) is that it only returns if a signal
> is delivered to the calling thread. However, in sys_sigsuspend() we
> pass &p->p_p->ps_sigacts as the wakeup channel to tsleep_nsec(9).
>
> Are we actually w
On Thu, Nov 04, 2021 at 10:49:46PM +, Klemens Nanni wrote:
> amd64, alpha, i386 and macppc strip all symbols off the ramdisk bsd.rd
> (before gzipping it) and thus break config(8)'s modification feature:
>
> $ gzcat bsd.rd > bsd.rd.raw
> $ config -e bsd.rd.raw
> WARNING no ou
My understanding of sigsuspend(2) is that it only returns if a signal
is delivered to the calling thread. However, in sys_sigsuspend() we
pass &p->p_p->ps_sigacts as the wakeup channel to tsleep_nsec(9).
Are we actually waiting for a wakeup on that channel? Or can we sleep
on &nowake here? Patc
Nicola Dell'Uomo wrote:
> Hi,
>
> I tested my laptop using different -CURRENT releases (#67, #71, #76) and the
> problem persists.
> First of all I disabled apmd as Theo suggested and my laptop did not auto
> suspended anymore.
> This is the output of systat sens -1 when my system fails to rea
On 2021/11/11 16:30, Klemens Nanni wrote:
> On Thu, Nov 11, 2021 at 04:11:10PM +, Raf Czlonka wrote:
> > Hello,
> >
> > It seems like this has been missed in recent thread[0].
> >
> > Not entirely sure whether the sentence "flows" any longer but here
> > it goes anyway.
> >
> > [0] https://m
On Thu, Nov 11, 2021 at 04:30:15PM +, Klemens Nanni wrote:
> On Thu, Nov 11, 2021 at 04:11:10PM +, Raf Czlonka wrote:
> > Hello,
> >
> > It seems like this has been missed in recent thread[0].
> >
> > Not entirely sure whether the sentence "flows" any longer but here
> > it goes anyway.
>
On Thu, Nov 11, 2021 at 04:30:15PM GMT, Klemens Nanni wrote:
>
> Maybe this reads better in general?
>
> would run ifconfig three times to join a wireless network using WPA and
> to set the AUTOCONF6 and AUTOCONF4 flags, respectively.
>
> [...]
>
> Feedback? OK?
FWIW, this looks much b
Friendly ping
On Fri, Oct 29, 2021 at 10:06:44AM +0200, Martin Vahlensieck wrote:
> Hi
>
> Here are some small changes to quotaon(8). If you want I can split
> them up, but since they are small I am sending one diff. Here is
> a list of changes roughly in the order they appear in the diff:
>
>
On Thu, Nov 11, 2021 at 04:11:10PM +, Raf Czlonka wrote:
> Hello,
>
> It seems like this has been missed in recent thread[0].
>
> Not entirely sure whether the sentence "flows" any longer but here
> it goes anyway.
>
> [0] https://marc.info/?l=openbsd-tech&m=163507448118443&w=2
Thanks, I mi
This patch moves kernel locking a step deeper when attaching file event
filters, letting filt_fileattach() run without the kernel lock.
filt_fileattach() calls fp->f_ops->fo_kqfilter(). The f_ops field is
immutable, and the pointed fileops structs are constant.
There are five instances of fo_kqfi
Hello,
It seems like this has been missed in recent thread[0].
Not entirely sure whether the sentence "flows" any longer but here
it goes anyway.
[0] https://marc.info/?l=openbsd-tech&m=163507448118443&w=2
Cheers,
Raf
Index: share/man/man5/hostname.if.5
===
On Thu, Nov 11, 2021 at 03:29:15PM +0100, Anton Lindqvist wrote:
> Hi,
> The second attempt to solve the uhidev claim multiple report ids
> conflict didn't work out either as it broke fido(4). Signalling claim
> multiple report ids to the match routines using the report id does not
> work as all 25
On Thu, Nov 11, 2021 at 03:21:45PM +0100, Alexander Bluhm wrote:
> On Thu, Nov 11, 2021 at 12:09:41PM +0300, Vitaliy Makkoveev wrote:
> > Can I propose to commit this diff before? It reorders soclose() to
> > destroy PCB before `so_q0' and `so_q' cleanup.
>
> OK bluhm@
>
> > Also the tool to test
Hi,
The second attempt to solve the uhidev claim multiple report ids
conflict didn't work out either as it broke fido(4). Signalling claim
multiple report ids to the match routines using the report id does not
work as all 256 values already have semantic meaning. I instead want to
use `uha->claimed
On Thu, Nov 11, 2021 at 12:42:36AM +0300, Vitaliy Makkoveev wrote:
> What about 'SO_DYING' flag? Anyway I want to remove it with the next
> diff.
The so_options are for user flags. The so_state is for kernel
transitions. So a SS_DYING would be better, see sys/socketvar.h.
But as we commit the o
On Thu, Nov 11, 2021 at 12:09:41PM +0300, Vitaliy Makkoveev wrote:
> Can I propose to commit this diff before? It reorders soclose() to
> destroy PCB before `so_q0' and `so_q' cleanup.
OK bluhm@
> Also the tool to test the diff:
What happens when you run the tool with the current code? Does the
On Thu, Nov 11, 2021 at 07:01:42AM +0100, Bjorn Ketelaars wrote:
> On Wed 10/11/2021 21:20, Klemens Nanni wrote:
> > I think only unwind(8) should list all the inputs and unwindctl(8)
> > should just say "Show learned nameservers".
> >
> > unwind(8) is already incomplete regardless of sppp(4) and
On Tue, Nov 09, 2021 at 02:23:09PM +0100, Stefan Sperling wrote:
> On Mon, Nov 01, 2021 at 12:56:26PM +0100, Stefan Sperling wrote:
> > I have tested on a 6205 device. More tests are needed, especially on
> > the old 4965AGN generation because those chips require the driver to
> > do specific calib
Hi,
Recently I tried to crossbuild for arm64 on amd64.
I found "TARGET=arm64 make cross-tools" stops when building libfido2.
libfido2 requires libz but this is not built yet at that time.
lib/Makefile needs to tweak like this.
openbsd-current-vm# diff -uNpr Makefile~ Makefile
--- Makefile~ Sun
On Thu, Nov 11, 2021 at 12:42:36AM +0300, Vitaliy Makkoveev wrote:
> On Wed, Nov 10, 2021 at 10:03:48PM +0100, Alexander Bluhm wrote:
> > On Tue, Oct 26, 2021 at 02:12:36PM +0300, Vitaliy Makkoveev wrote:
> > > --- sys/kern/uipc_socket.c14 Oct 2021 23:05:10 - 1.265
> > > +++ sys/ke
31 matches
Mail list logo
