On 24/10/22 14:49 +0200, Theo Buehler wrote:
> On Mon, Oct 24, 2022 at 09:24:14AM +0200, Otto Moerbeek wrote:
> > Hello,
> >
> > after updating my M1 macmini after my vacatiuon to the latest snap it
> > seems to have lost a few sysctl nodes, making apm(8) fail:
> >
> > [otto@macmini:4]$ ktrace
On 16/09/22 13:20 +, Miod Vallat wrote:
> > I've also removed the hidkbd_apple_mba_iso_munge() function as it is
> > the same as hidkbd_apple_iso_munge() so this also cleans up the switch
> > in ukbd.c
>
> Oh no, it isn't.
>
> See, you are in a maze of twisty little functions, all alike.
>
On 16/09/22 13:03 +, Miod Vallat wrote:
> > rev3:
>
> Almost there! Minor nits below, then ok.
>
> > Index: dev/hid/hidkbd.c
>
> > +static const struct hidkbd_translation apple_iso_trans[] = {
> > + { 53, 100 },/* less -> grave */
> > + { 100, 53 }
> > +};
> > +
> > +static const
On 16/09/22 12:43 +, Miod Vallat wrote:
> > On 16/09/22 12:20 +, Miod Vallat wrote:
> > > > Index: dev/hid/hidkbdtrans.h
> > >
> > > > +static const struct hidkbd_translation apple_fn_trans[] = {
> > >
> > > No effing way. Every file including this header will embed its own copy
> > > of
On 16/09/22 12:45 +, Klemens Nanni wrote:
> > Index: dev/hid/hidkbd.c
>
> > +static const struct hidkbd_translation apple_mba_trans[] = {
>
> These *_apple_* structs could be under #ifdef __arm64__ as only arm64
> has a driver using them, no?
no. ukbd(4)
On 16/09/22 06:40 -0600, Theo de Raadt wrote:
> > thing inside !SMALL_KERNEL
>
> Is that neccessary?
>
> Because arm64 has no limitation on bsd.rd size
but hidkbd is not arm64 only
On 16/09/22 12:20 +, Miod Vallat wrote:
> > Index: dev/hid/hidkbdtrans.h
>
> > +static const struct hidkbd_translation apple_fn_trans[] = {
>
> No effing way. Every file including this header will embed its own copy
> of these tables.
>
> Better keep the tables in their original locations.
On 16/09/22 14:01 +0200, Robert Nagy wrote:
> On 14/09/22 17:21 +0200, Tobias Heider wrote:
> > On Wed, Sep 14, 2022 at 11:56:48AM +, Miod Vallat wrote:
> > > > Hey,
> > > >
> > > > the diff below adds FN key combos for Page Up, Page Down an
RCS file: dev/hid/hidkbdtrans.h
diff -N dev/hid/hidkbdtrans.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/hid/hidkbdtrans.h 16 Sep 2022 11:58:42 -
@@ -0,0 +1,123 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2022 Robert Nagy
+ *
+ * Permission to use, copy,
On 11/01/22 09:57 +0100, Claudio Jeker wrote:
> On Tue, Jan 11, 2022 at 08:15:13AM +, Klemens Nanni wrote:
> > On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote:
> > > On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> > > > The uvm_wxabort path within
On 07/09/21 19:31 +0200, Paul de Weerd wrote:
> Hi all,
>
> On Tue, Sep 07, 2021 at 02:30:43PM +0200, Robert Nagy wrote:
> | /etc/reorder_kernel.conf
>
> Thank you for your suggest Robert! In the mean time, I've had a few
> more off-list comments about this proposal
On 29/08/21 08:10 -0600, Theo de Raadt wrote:
> Ingo Schwarze wrote:
>
> > One - admittedly completely unUNIXy - way would be to invent a long,
> > descriptive name like /etc/kernel.config.commands or even /bsd.config.cmd
> > in the root rather than the /etc directory, which is more discoverable
ils on how to configure the kernel.
> +.Sh FILES
> +.Bl -tag -width /etc/kernel.conf -compact
> +.It Pa /etc/kernel.conf
> +Kernel configuration file.
> +.Sh SEE ALSO
> +.Xr config 8
>
> --
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
> http://www.weirdnet.nl/
>
--
Regards,
Robert Nagy
On 15/01/21 14:53 +0100, Claudio Jeker wrote:
> I forgot to add ip_mreqn support to IP_MULTICAST_IF and so the
> IP_ADD_MEMBERSHIP change is not fixing all the issues I have.
>
> Linux supports calling IP_MULTICAST_IF with a struct in_addr, a struct
> ip_mreq, or a struct ip_mreqn. FreeBSD only
On 14/01/21 14:50 +0100, Theo Buehler wrote:
> On Thu, Jan 14, 2021 at 02:37:20PM +0100, Robert Nagy wrote:
> > On 14/01/21 14:27 +0100, Robert Nagy wrote:
> > > On 14/01/21 14:20 +0100, Theo Buehler wrote:
> > > > On Thu, Jan 14, 2021 at 01:32:41PM +0100, Matt
On 14/01/21 14:27 +0100, Robert Nagy wrote:
> On 14/01/21 14:20 +0100, Theo Buehler wrote:
> > On Thu, Jan 14, 2021 at 01:32:41PM +0100, Matthieu Herrb wrote:
> > > Hi,
> > >
> > > I'm trying to debug strange beahaviour changes with certificates on a
>
On 14/01/21 14:20 +0100, Theo Buehler wrote:
> On Thu, Jan 14, 2021 at 01:32:41PM +0100, Matthieu Herrb wrote:
> > Hi,
> >
> > I'm trying to debug strange beahaviour changes with certificates on a
> > systemc after upgrading it from 6.7 to 6.8...
> >
> > On 6.7, If I run :
> >
> > openssl
On 23/10/20 10:24 +1100, Jonathan Gray wrote:
> On Thu, Oct 22, 2020 at 04:34:11PM +0200, Robert Nagy wrote:
> > The diff below makes azalia(4) work on my new shiny chromium build box:
>
> You have a 17-31-00 epyc or threadripper?
>
> This id also shows up on
> B550
The diff below makes azalia(4) work on my new shiny chromium build box:
Index: dev/pci/azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.178
diff -u -p -u -r1.178 azalia_codec.c
---
On 02/07/20 00:31 +0100, Stuart Henderson wrote:
> running on 38 of these, btw.
been running with this on all my workstations and laptops and on 3 build
servers as well
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 before user uvm_map for randomization
> - map timekeep before fixup. confirmed by naddy@ that it fixes NULL init
> - initialize va. clarified by
it definitely got better:
cpu0: TSC skew=0 observed drift=0
cpu0: TSC skew=0 observed drift=0
cpu1: TSC skew=51 observed drift=0
cpu2: TSC skew=68 observed drift=0
cpu3: TSC skew=68 observed drift=0
cpu4: TSC skew=0 observed drift=0
cpu5: TSC skew=0 observed drift=0
cpu6: TSC skew=85 observed
On 11/06/20 20:10 +0200, Mark Kettenis wrote:
> > Date: Thu, 11 Jun 2020 19:38:48 +0200
> > From: Christian Weisgerber
> >
> > Theo de Raadt:
> >
> > > The diff is growing complexity to support a future which wouldn't
> > > exist if attempts at *supporting all* architectures received priority.
On 30/05/20 10:40 +0200, Mark Kettenis wrote:
> > Date: Sat, 30 May 2020 10:32:15 +0200
> > From: Robert Nagy
> >
> > On 29/05/20 17:51 +0300, Paul Irofti wrote:
> > > On Fri, May 29, 2020 at 03:00:50PM +0200, Mark Kettenis wrote:
> > > > > Date
On 29/05/20 17:51 +0300, Paul Irofti wrote:
> On Fri, May 29, 2020 at 03:00:50PM +0200, Mark Kettenis wrote:
> > > Date: Fri, 29 May 2020 13:45:37 +0100
> > > From: Stuart Henderson
> > >
> > > On 2020/05/29 13:50, Paul Irofti wrote:
> > > > +struct __timekeep {
> > > > + uint32_t major;
On 16/05/20 20:14 +0300, Paul Irofti wrote:
> Make sure you clean your /usr/share/relink directory before compiling
> and installing this! Robert's machine was picking up old objects and
> creating a broken library on every reboot becuase his directory was not
> clean.
It was actually an old .so
On 13/05/20 17:05 +0200, Mark Kettenis wrote:
> > The update currently does the work of clock_gettime(), but it can
> > probably be changed to only update the timehands and move the logic
> > elsewhere. Note that if we expose only the timehands to userland, most
> > of the bintime functionality
On 13/05/20 17:03 +0300, Paul Irofti wrote:
> Hi,
>
> By far one of the most popular and frequently used system calls is
> clock_gettime(2). As a result the cost of kernel-userland transitions
> out weight the actual work, thus I am proposing we make the data
> available directly from userland
On 28/04/19 12:01 +0200, Matthieu Herrb wrote:
> On Sun, Apr 28, 2019 at 08:55:16AM +0100, Stuart Henderson wrote:
> > > >> > On Sat, Apr 27, 2019 at 09:55:33PM +0800, Nathanael Rensen wrote:
> > > >> > > The diff below speeds up ld.so library intialisation where the
> > > >>dependency
> > > >> >
On 31/10/18 09:54 +0100, Patrick Wildt wrote:
> Hi,
>
> during the libunwind update to 6.0 we lost a particular patchset that
> fixes register numbering for OpenBSD/i386, thus breaking exception
> handling on that platform. Looks like no one noticed until now.
>
> ok?
>
> Patrick
>
> diff
Hi
I think you should call unveil before pledge, so that you don't
need to pledge unveil.
This will prevent futher calls to unveil.
On 18/07/18 12:59 +0100, Ricardo Mestre wrote:
> Hi,
>
> Are there any brave souls out there with unveil(2) enabled already?
>
> If yes please test this diff for
Hi
Obviously I am ok with this since it makes my controller work ;)
mpii0 at pci6 dev 0 function 0 "Symbios Logic MegaRAID SAS3408" rev 0x01: msi
scsibus3 at mpii0: 640 targets
st0 at scsibus3 targ 5 lun 0: SCSI4 1/sequential
removable naa.5000e111c457f001
ch0 at scsibus3 targ 5 lun 1: SCSI3
On 17/01/18 11:40 +0100, Martin Pieuchot wrote:
> Hello Sebastien,
>
> On 17/01/18(Wed) 10:19, Sebastien Marie wrote:
> > [...]
> > kernel modification is desirable in some cases, at least for disabling
> > ulpt(4) when using cups with USB printer.
>
> Sorry to hijack your thread, but if
Hi
This is an updated diff for preliminary kabylake support for 6.2,
this needs extensive testing on all inteldrm variants.
This diff is also in snapshots now so please, test, test test!
Thank you
Index: sys/dev/pci/drm/i915_pciids.h
Hi!
It turns out that the changes to get kabylake to work are quiet minimal so I
took a
stab at it and backported all the relevant kabylake commits from linux-4.8.y to
our drm tree. I did not touch anything outside of dev/pci/drm/i915 on purprose,
so that the update work of kettenis@ is only
It seems that SIGTERM is not enough for mountd, according to the code
SIGTERM only sends a RPCMNT_UMNTALL broadcast to the clients.
So I think what we should do in this case is to first send a SIGTERM to mountd,
and then SIGKILL it in rc_stop().
On (2011-07-28 09:46), David Coppa wrote:
It
On (2011-07-28 11:17), Mark Kettenis wrote:
Date: Thu, 28 Jul 2011 10:16:00 +0200
From: David Coppa dco...@gmail.com
On Thu, 28 Jul 2011, Robert Nagy wrote:
It seems that SIGTERM is not enough for mountd, according to the code
SIGTERM only sends a RPCMNT_UMNTALL broadcast
Hello
p2k9 (the ports hackathon in Budapest) is on since Friday. People
are working on different things like GNOME, GCC4, BluRay support or
even ACPI.
I would like to thank everyone who donated money to the project because
the individual donors made it possible to organize this event.
So ... BIG
38 matches
Mail list logo
