Are SSE instructions allowed in the AMD64 kernel? Is #ifdef __SSE__
a sufficient guard?
I have a rasops32 putchar with SSE that is 2x faster.
This increases throughput by keeping the worker threads active for
longer.
---
sys/net/if_wg.c | 1 +
1 file changed, 1 insertion(+)
diff --git sys/net/if_wg.c sys/net/if_wg.c
index e27a575cc1b..5b7550840f8 100644
--- sys/net/if_wg.c
+++ sys/net/if_wg.c
@@ -2651,6 +2651,7 @@ wg_clone_create(struc
This will help us get a bit of testing in the snapshot builds.
---
sys/conf/GENERIC | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git sys/conf/GENERIC sys/conf/GENERIC
index 34d608cff44..f0eff16d2b8 100644
--- sys/conf/GENERIC
+++ sys/conf/GENERIC
@@ -109,7 +109,7 @@ pseudo-device
This enables us to process queueing of different packet queues without
KERNEL_LOCK. Combined with the increase in txlen, this keeps our
encryption workers more active. This results in a ~30% performance
boost.
---
sys/net/if_wg.c | 22 +++---
1 file changed, 11 insertions(+), 11 de
Current btrace has `interval:hz:1` probe that makes periodically events.
`interval:hz:1` looks to make events once per second (= 1Hz),
but current implementation makes once per tick (= 100Hz on amd64).
I think the interval should be counted by reciprocal of ticks so that fit to Hz.
Following patch
In OpenBSD, the erase character is ^?
^H is accepted in a few places, like here (because of CTRL_H) but
it is absolutely not the canonical tty 'character erase' character,
which is implied in your text by placing it next to kill and the
canonical tty werase default ^U
It was vague, and I guess OK
On Mon, Jun 22, 2020 at 06:33:30PM -0600, Theo de Raadt wrote:
> > +character erase (^H) and line kill (^U) characters
>
> ^H is wrong
How so? It is currently hardcoded as such in engine.c:cmd_keyboard():
1188 switch (ch) {
1189 case KEY_ENTER:
1190 case 0x0a:
1191
> +character erase (^H) and line kill (^U) characters
^H is wrong
On Mon, Jun 22, 2020 at 07:13:30AM +0100, Jason McIntyre wrote:
> how will people be able to find this if we don;t document it? from a
> brief skim of docs which may hold answers, i still can;t find where
> these values are documented.
Fair point, I removed them because they imply that systat honou
New iteration:
- ps_timekeep should not coredump, pointed by deraadt@
- set ps_timekeep to 0 before user uvm_map for randomization
- map timekeep before fixup. confirmed by naddy@ that it fixes NULL init
- initialize va. clarified by kettenis@
How's the magical max skew value research goi
pppx_if_start() checks `IFF_RUNNING' bit to be sure `pxi' is consistent
but this bit is not cleared on `pxi' destroy. pppx_if_output() checks
`IFF_UP' bit for the same reason but this bit is always set and this
check is useless. pppac_output() checks `IFF_RUNNING' bit but
pppac_start() doesn't.
Di
Christian Weisgerber wrote:
> Christian Weisgerber:
>
> > If I move
> >
> > vaddr_t ps_timekeep;/* User pointer to timekeep */
> >
> > up into the zeroed area, I get a properly randomized _timekeep in
> > userland.
>
> Also note that exec_sigcode_map() has this
>
>
On Mon, Jun 22, 2020 at 09:46:13AM -0600, Theo de Raadt wrote:
> Christian Weisgerber wrote:
>
> > Paul Irofti:
> >
> > > 683 /* map the process's timekeep page */
> > > 684 if (exec_timekeep_map(pr))
> > > 685 goto free_pack_abort;
> > > 686 /* setup new
On Mon, Jun 22, 2020 at 05:35:48PM +0200, Christian Weisgerber wrote:
> Paul Irofti:
>
> > 683 /* map the process's timekeep page */
> > 684 if (exec_timekeep_map(pr))
> > 685 goto free_pack_abort;
> > 686 /* setup new registers and do misc. setup. */
> > 68
Christian Weisgerber wrote:
> Paul Irofti:
>
> > 683 /* map the process's timekeep page */
> > 684 if (exec_timekeep_map(pr))
> > 685 goto free_pack_abort;
> > 686 /* setup new registers and do misc. setup. */
> > 687 if (pack.ep_emul->e_fixup != N
Christian Weisgerber:
> If I move
>
> vaddr_t ps_timekeep;/* User pointer to timekeep */
>
> up into the zeroed area, I get a properly randomized _timekeep in
> userland.
Also note that exec_sigcode_map() has this
pr->ps_sigcode = 0; /* no hint */
uao_refere
Paul Irofti:
> 683 /* map the process's timekeep page */
> 684 if (exec_timekeep_map(pr))
> 685 goto free_pack_abort;
> 686 /* setup new registers and do misc. setup. */
> 687 if (pack.ep_emul->e_fixup != NULL) {
> 688 if ((*pack.ep_e
Paul Irofti wrote:
> So I don't know why the address is not randomized, but I bet if I print
> pr->ps_sigcode somehow from userland, it will be the same.
I just checked that.
60 out of 68 processes have a unique UVA for sigtramp, the other 8 processes
are fork's without execve.
Hi tech@,
Here is a diff to use C99 initializers in wsdisplay_font struct
definitions for Spleen kernel fonts.
Comments? OK?
Index: sys/dev/wsfont/spleen12x24.h
===
RCS file: /cvs/src/sys/dev/wsfont/spleen12x24.h,v
retrieving revisi
Paul Irofti wrote:
> So I don't know why the address is not randomized, but I bet if I print
> pr->ps_sigcode somehow from userland, it will be the same.
echo kern.allowkmem=1 >> /etc/sysctl.conf
reboot
Then procmap can be run on all processes, to see what VA the sigtramp
and timekeep land at.
On Mon, Jun 22, 2020 at 03:12:34PM +0200, Klemens Nanni wrote:
> On Mon, Jun 22, 2020 at 07:22:24AM +0100, Jason McIntyre wrote:
> > i guess the diff is correct, but removes what might be a handy reminder.
> It makes assumptions about the environment in which systat was started
> and it is wrong/mi
On Mon, Jun 22, 2020 at 07:22:24AM +0100, Jason McIntyre wrote:
> i guess the diff is correct, but removes what might be a handy reminder.
It makes assumptions about the environment in which systat was started
and it is wrong/misleading in some cases.
> i'm fine with this bit of doc remaining or b
On Mon, Jun 22, 2020 at 02:57:53PM +0900, YASUOKA Masahiko wrote:
> The line in etc/mtree/special should be updated as well.
>
> npppd.conf type=file mode=0640 uname=root gname=wheel
>
> other than that, ok yasuoka
Thanks for pointing.
On Sun, Jun 21, 2020 at 05:42:55PM -0600, Theo de Raadt wrote:
> Paul Irofti wrote:
>
> >
> >
> >
> > ??n 22 iunie 2020 01:26:16 EEST, Christian Weisgerber
> > a scris:
> > >Christian Weisgerber:
> > >
> > >> I tweaked the patch locally to make _timekeep a visible global
> > >> symbol in lib
On 2020/06/22 14:10, Tobias Heider wrote:
> On Mon, Jun 22, 2020 at 02:01:43PM +0200, Tobias Heider wrote:
> > Hi,
> >
> > I noticed that the ramdisk takes ages to boot on my T420.
> > It seems that without umodem in the kernel, umass tries to attach to my
> > Erricson F5521GW WAN modem and fails
On Mon, Jun 22, 2020 at 02:01:43PM +0200, Tobias Heider wrote:
> Hi,
>
> I noticed that the ramdisk takes ages to boot on my T420.
> It seems that without umodem in the kernel, umass tries to attach to my
> Erricson F5521GW WAN modem and fails after a annoyingly long timeout.
>
> The diff below s
Hi,
I noticed that the ramdisk takes ages to boot on my T420.
It seems that without umodem in the kernel, umass tries to attach to my
Erricson F5521GW WAN modem and fails after a annoyingly long timeout.
The diff below should prevent umass from matching this device.
ok?
diff --git a/sys/dev/us
On Mon, Jun 22, 2020 at 11:11:47AM +0200, Claudio Jeker wrote:
> This crashes are because of wg(4) calling the interface ioctl handler
> without holding the netlock() this is not allowed.
>
> As a quick fix this diff may work.
> --
> :wq Claudio
>
> Index: net/if.c
>
> Date: Mon, 22 Jun 2020 13:53:25 +0300
> From: Paul Irofti
>
> > Still uses uint instead of u_int in places. Still has the pointless
> > extra NULL and 0 for timecounters in files that are otherwise
>
> If you don't like uint, then let's fix what's in the tree in amd64
> (which is how uint got
> Still uses uint instead of u_int in places. Still has the pointless
> extra NULL and 0 for timecounters in files that are otherwise
If you don't like uint, then let's fix what's in the tree in amd64
(which is how uint got used in my diff too). OK?
diff --git sys/arch/amd64/amd64/tsc.c sys/arch
On Mon, Jun 22, 2020 at 01:27:22AM +0200, Mark Kettenis wrote:
> > Date: Mon, 22 Jun 2020 02:06:39 +0300
> > From: Paul Irofti
> >
> > În 22 iunie 2020 00:15:59 EEST, Christian Weisgerber a
> > scris:
> > >Paul Irofti:
> > >
> > >[Unrelated, just to mark where we're at]
> > >> Right. Just repro
On Mon, Jun 22, 2020 at 12:37:03PM +0200, Hrvoje Popovski wrote:
> for some reason i couldn't reproduce panic if i compile kernel with
> WITNESS and after that with or without your "if.c if_wg.c" commit
The bug might not trigger if your ifconfig binary and kernel out of sync.
But that's just
On 22.6.2020. 11:11, Claudio Jeker wrote:
> On Sun, Jun 21, 2020 at 08:51:53PM +0200, Hrvoje Popovski wrote:
>> Hi all,
>>
>> with today's snapshot from 21-Jun-2020 09:34
>> OpenBSD 6.7-current (GENERIC.MP) #286: Sun Jun 21 08:51:29 MDT 2020
>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/
On Sun, Jun 21, 2020 at 08:51:53PM +0200, Hrvoje Popovski wrote:
> Hi all,
>
> with today's snapshot from 21-Jun-2020 09:34
> OpenBSD 6.7-current (GENERIC.MP) #286: Sun Jun 21 08:51:29 MDT 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> if i do "ifconfig vlan"
Yes, this seems right.
ok yasuoka
On Thu, 18 Jun 2020 23:53:25 +0300
Vitaliy Makkoveev wrote:
> While pppac(4) destroy sessions by pipex_iface_fini() or by
> pipex_ioctl() with PIPEXSMODE command, some sessions can be linked to
> `state_list'. This case is not checked and sessions will never be
35 matches
Mail list logo
