> Date: Sat, 23 Oct 2021 17:29:36 +0200
> From: Claudio Jeker
>
> The sys___thrsigdivert code can be simplified a bit. It is possible to
> set the error before the loop and then have the loop exit after polling
> for pending signals. IMO the results looks nicer than what we have now.
>
> OK?
Th
> Date: Sun, 24 Oct 2021 15:14:14 +0100
> From: Martin Pieuchot
>
> On 24/10/21(Sun) 14:49, Martin Pieuchot wrote:
> > Here's another small tweak I could extract from the UVM unlocking diff.
> > This doesn't introduce any functional change. uvm_km_pgremove() is used
> > in only one place.
>
> Up
> From: Jeremie Courreges-Anglas
> Date: Sun, 24 Oct 2021 17:30:46 +0100
>
> clang(1) defaults to FP ABI but ld(1) -melf64lriscv doesn't. This is
> a problem as soon as a port tries to use raw ld(1) -b binary to embed
> data in a .o file.
>
> Downgrading this hard error to a warning seems more
> Date: Mon, 25 Oct 2021 12:01:11 +0200
> From: Patrick Wildt
>
> Hi,
>
> mortimer@ has this diff in his tree for LLVM 13. I actually haven't
> tried to see if it works fine with LLVM 11, but I feel it needs to be
> sent out and not just be blindly committed.
>
> If someone wants to take care
> Date: Mon, 25 Oct 2021 12:37:41 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Mon, 25 Oct 2021 12:01:11 +0200
> > From: Patrick Wildt
> >
> > Hi,
> >
> > mortimer@ has this diff in his tree for LLVM 13. I actually haven't
> > tried t
> From: Jeremie Courreges-Anglas
> Date: Mon, 25 Oct 2021 14:55:16 +0100
>
> On Mon, Oct 25 2021, Mark Kettenis wrote:
> >> Date: Mon, 25 Oct 2021 12:37:41 +0200 (CEST)
> >> From: Mark Kettenis
> >>
> >> > Date: Mon, 25 Oct 2021 12:01:11
> Date: Mon, 25 Oct 2021 16:44:48 +0200
> From: Patrick Wildt
>
> Hi,
>
> this fixes the build of sys/arch/amd64/stand with LLVM 13.
>
> ok?
ok kettenis@
> diff --git a/sys/lib/libsa/netif.c b/sys/lib/libsa/netif.c
> index d1a5e180291..79c6496878e 100644
> --- a/sys/lib/libsa/netif.c
> +++ b/
> Date: Tue, 2 Nov 2021 15:05:46 +0100
> From: Frederic Cambus
>
> On Fri, Oct 29, 2021 at 06:20:07PM -0400, Brad Smith wrote:
>
> > > Therefore, here is a diff to enable spleen16x32 and spleen32x64 on riscv64
> > > for GENERIC kernels, like we do on amd64, arm64, armv7, and i386.
> > >
> > > C
> Date: Tue, 2 Nov 2021 19:19:03 +0100
> From: Paul de Weerd
>
> A recent commit by Theo changed the hw.perfpolicy behavior to always
> run at full speed when AC power is on. This means that my workstation
> (and servers, once I upgrade them) now consumes significantly more
> power, even though
> Date: Fri, 5 Nov 2021 07:18:03 +0100
> From: Martin Pieuchot
>
> On 30/10/21(Sat) 21:22, Vitaliy Makkoveev wrote:
> > This completely removes global rwlock(9) from the unp_internalize() and
> > unp_externalize() normal paths but only leaves it in unp_externalize()
> > error path. Also we don't
> Date: Sat, 6 Nov 2021 14:10:57 -0500
> From: Scott Cheloha
>
> On Fri, Nov 05, 2021 at 03:15:26PM +0100, Christian Ludwig wrote:
> >
> > comments inline.
> >
> > [...]
> >
> > Unlocking if (!need_lock) below looks odd. I think it would make more
> > sense to reverse the logic:
> >
> > h
> Date: Tue, 9 Nov 2021 15:43:04 +
> From: Klemens Nanni
>
> This populates `systat sensors' with the correct lid status on my
> Pinebook Pro:
>
> -gpio-key-lid at mainbus0 not configured
> -gpio-key-power at mainbus0 not configured
> +gpiokeys0 at mainbus0: "Lid"
>
> 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
> Date: Fri, 12 Nov 2021 13:22:06 +0100
> From: Stefan Sperling
>
> The iwx Tx ring array is one entry too short due to an off-by-one error.
>
> Fortunately, this bug is harmless. The last Tx agg queue is never used
> because ieee80211_classify() only returns TID values in the range 0 - 3.
> And
> Date: Fri, 12 Nov 2021 13:37:47 +0100
> From: Stefan Sperling
>
> This tid variable is used as an array index and must thus be smaller
> than MAX_TID_COUNT (which is 8).
>
> The variable will be set to 8 if the AP wants us to use TID 8 for Rx agg,
> which I've never seen happen in practice, th
> Date: Fri, 26 Nov 2021 16:32:59 +1100
> From: Jonathan Gray
>
> Stop building the kernel with -Wno-uninitialized on clang archs.
> This hides real problems like the recently fixed uninitialised memory
> use in pf and igc.
>
> After visa's recent commit the remaining warnings are
>
> [-Wsometi
> Date: Sat, 27 Nov 2021 20:28:39 +
> From: Stuart Henderson
>
> I have some amd64 machines which are doing 600+ gettimeofday/second
> at quiet times and way more when they're busy and I'd quite like to
> get them onto userland tsc, however they're dual socket and the skew
> between cores on
> From: Dave Voutila
> Date: Sun, 28 Nov 2021 22:51:59 -0500
>
> The last vmm diff I'll be sending tonight...promise! This swaps out
> usage of printf(9) outside the autoconf(4) functions.
>
> The reason for this change is printf(9) could acquire a sleepable
> lock.
Huh?
/*
* printf: print a
> From: Dave Voutila
> Date: Mon, 29 Nov 2021 07:18:23 -0500
>
> Mark Kettenis writes:
>
> >> From: Dave Voutila
> >> Date: Sun, 28 Nov 2021 22:51:59 -0500
> >>
> >> The last vmm diff I'll be sending tonight...promise! This swaps out
&
> Date: Tue, 30 Nov 2021 23:04:49 +0100
> From: Patrick Wildt
>
> On Thu, Nov 11, 2021 at 08:27:21PM +0900, SASANO Takayoshi wrote:
> > Hi,
> >
> > Recently I tried to crossbuild for arm64 on amd64.
> > I found "TARGET=arm64 make cross-tools" stops when building libfido2.
> >
> > libfido2 requi
> Date: Sun, 5 Dec 2021 18:01:04 -0600
> From: Scott Cheloha
>
> Two things in sys_kbind() need an explicit kernel lock. First,
> sigexit(). Second, uvm_map_extract(), because the following call
> chain panics without it:
>
> panic
> assert
> uvn_reference
> uvm_mapent_clone
> uum_map_extract
> Date: Mon, 6 Dec 2021 21:08:04 +0100
> From: Patrick Wildt
>
> Hi,
>
> On one machine I had the pleasure of having to try and use the
> Serial-over-LAN feature which shows up as just another com(4)
> device. Instead of having to manually add a com(4) at isa(4)
> I figured it would be nicer to
> From: "Theo de Raadt"
> Date: Mon, 06 Dec 2021 13:17:37 -0700
>
> What comN does this attach as?
>
> The isa ones are are hard-wired:
>
> com0at isa? port 0x3f8 irq 4# standard PC serial ports
> com1at isa? port 0x2f8 irq 3
> com2at isa? port 0x3e8 irq 5
> com3at isa?
> Date: Mon, 6 Dec 2021 21:26:11 +0100
> From: Patrick Wildt
>
> Am Mon, Dec 06, 2021 at 09:23:45PM +0100 schrieb Mark Kettenis:
> > > Date: Mon, 6 Dec 2021 21:08:04 +0100
> > > From: Patrick Wildt
> > >
> > > Hi,
> > >
> > &
> Date: Mon, 6 Dec 2021 21:45:03 +0100
> From: Anton Lindqvist
>
> On Mon, Dec 06, 2021 at 09:23:45PM +0100, Mark Kettenis wrote:
> > > Date: Mon, 6 Dec 2021 21:08:04 +0100
> > > From: Patrick Wildt
> > >
> > > Hi,
> > >
> > &
> Date: Tue, 7 Dec 2021 11:30:48 +0100
> From: Anton Lindqvist
>
> On Mon, Dec 06, 2021 at 10:25:34PM +0100, Mark Kettenis wrote:
> > > Date: Mon, 6 Dec 2021 21:45:03 +0100
> > > From: Anton Lindqvist
> > >
> > > On Mon, Dec 06, 2021 at 09:23
> Date: Fri, 10 Dec 2021 07:56:44 +0100
> From: Anton Lindqvist
>
> On Tue, Dec 07, 2021 at 01:08:45PM +0100, Mark Kettenis wrote:
> > > Date: Tue, 7 Dec 2021 11:30:48 +0100
> > > From: Anton Lindqvist
> > >
> > > On Mon, Dec 06, 2021 at 10:25
> Date: Fri, 17 Dec 2021 13:04:35 +
> From: Klemens Nanni
>
> An upcoming port uses ElfW(). I first patched the port, but looking
> around shows that both NetBSD and FreeBSD adopted the macro:
>
> https://mail-index.netbsd.org/source-changes-hg/2018/07/31/msg027523.html
> +#defineEl
cpi?
> +ehci*at acpi?
> +ohci*at acpi?
> pluart* at acpi?
> sdhc*at acpi?
> xhci*at acpi?
> diff --git a/sys/dev/acpi/ehci_acpi.c b/sys/dev/acpi/ehci_acpi.c
> new file mode 100644
> index 00
> Date: Wed, 29 Dec 2021 18:36:16 +0100
> From: Patrick Wildt
>
> On Wed, Dec 29, 2021 at 06:02:02PM +0100, Mark Kettenis wrote:
> >
> > We have acpi_intr_disestablish() on arm64 now...
> >
>
> Actually we also have it on amd64 now, so maybe we should
> Date: Wed, 29 Dec 2021 19:01:11 +0100
> From: Patrick Wildt
>
> On Wed, Dec 29, 2021 at 06:43:31PM +0100, Patrick Wildt wrote:
> > On Wed, Dec 29, 2021 at 06:02:02PM +0100, Mark Kettenis wrote:
> > > > Date: Wed, 29 Dec 2021 17:16:36 +0100
> > > > Fr
> Date: Mon, 3 Jan 2022 15:12:01 -0300
> From: Crystal Kolipe
Please submit these to the Linux kernel folks. We're not going to fix
these in our tree as it would make it harder to update the code.
Cheers,
Mark
> --- sys/dev/pci/drm/amd/display/dc/dce110/dce110_hw_sequencer.c.orig Tue Jul
>
> Date: Mon, 3 Jan 2022 16:31:29 +
> From: Visa Hankala
>
> This adds an initial driver for the PolarFire SoC MSS clock controller.
>
> The driver also provides a reset function for the SoC. The soft reset
> register is in the same region that covers the clock control registers.
>
> OK?
No
> Date: Sun, 09 Jan 2022 23:54:23 +0100
> From: Leo Larnack
>
> Daniel Dickman wrote:
>
> > elfexport.cpp:352:56: error: use of undeclared identifier 'R_386_32'
> > reloc.r_info = ELFXX_R_INFO(symbolNum, isFuncPtr ?
> > HOST_DIRECT_FPTR_RELOC : HOST_DIRECT_DATA_RELOC);
> >
> Date: Tue, 11 Jan 2022 08:15:13 +
> From: Klemens Nanni
>
> 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 uvm_wxcheck() looks not MP-safe.
> >
> > Right, I did not pay
> Date: Tue, 11 Jan 2022 17:01:45 +0800
> From: Kevin Lo
>
> ok?
Right. That's a leftover from when we were still cross-compiling.
ok kettenis@
> Index: sys/arch/riscv64/conf/Makefile.riscv64
> ===
> RCS file: /cvs/src/sys/arch/r
> Date: Wed, 12 Jan 2022 17:02:03 +0100
> From: Jan Klemkow
>
> Hi,
>
> This diff enables TCP and UDP checksum offloading in ix(4) for IPv6.
>
> IPv6 extension headers aren't a problem in this case.
> in6_proto_cksum_out() in netinet6/ip6_output.c disables checksum
> offloading if ip6_nxt is no
> Date: Wed, 12 Jan 2022 17:45:57 +0100
> From: Jan Klemkow
>
> On Wed, Jan 12, 2022 at 05:36:01PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 12 Jan 2022 17:02:03 +0100
> > > From: Jan Klemkow
> > >
> > > Hi,
> > >
> > > T
> Date: Thu, 13 Jan 2022 20:34:36 +0100
> From: Alexander Bluhm
>
> On Wed, Jan 12, 2022 at 05:36:01PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 12 Jan 2022 17:02:03 +0100
> > > From: Jan Klemkow
> > >
> > > Hi,
> > >
> > > T
> Date: Tue, 11 Jan 2022 23:13:20 +
> From: Klemens Nanni
>
> On Tue, Jan 11, 2022 at 09:54:44AM -0700, Theo de Raadt wrote:
> > > Now this is clearly a "slow" path. I don't think there is any reason
> > > not to put all the code in that if (uvw_wxabort) block under the
> > > kernel lock. F
> Date: Sat, 15 Jan 2022 12:21:59 +
> From: Visa Hankala
>
> If the ending address in sfcc_cache_wbinv_range(), pa + len, is not
> cache-line-aligned, the function spins because len wraps around.
> The following patch fixes this.
>
> There still is a subtle detail. If len is zero but pa is n
> Date: Sat, 15 Jan 2022 23:54:00 +1100
> From: Jonathan Gray
>
> On Sat, Jan 15, 2022 at 12:21:59PM +, Visa Hankala wrote:
> > If the ending address in sfcc_cache_wbinv_range(), pa + len, is not
> > cache-line-aligned, the function spins because len wraps around.
> > The following patch fixe
> Date: Thu, 13 Jan 2022 17:45:03 +0100
> From: Stefan Sperling
>
> At present active scans (which send probe requests, as opposed to
> just listening for beacons) are disabled on iwm 9k and iwx. This
> was done because firmware misbehaved after association.
>
> zxystd from the OpenIntelWireless
> Date: Sun, 16 Jan 2022 19:28:06 +0100
> From: Stefan Sperling
>
> On Sun, Jan 16, 2022 at 03:50:55PM +0100, Mark Kettenis wrote:
> > However, running this diff I had a problem after resuming my laptop
> > twice. After resume the interface didn't work and I fou
> Date: Mon, 17 Jan 2022 14:43:11 +
> From: Visa Hankala
>
> This fixes two bugs in plic(4). When a particular CPU is not found,
> typically when running GENERIC or RAMDISK on a multiprocessor machine,
> plic_get_cpuid() returns -1. In that case plic_attach() should just
> ignore the entry an
> From: Greg Steuck
> Date: Mon, 10 Jan 2022 20:59:17 -0800
>
> Greg Steuck writes:
>
> > This failure can be reduced to a trivial program which does change
> > its behavior for the worse if s_cos.S is taken out:
> >
> > #include
> > #include
> >
> > int main(int a, char**b) {
> > double
> Date: Fri, 21 Jan 2022 16:05:49 +0100
> From: Stefan Sperling
>
> On Sun, Jan 16, 2022 at 07:38:11PM +0100, Mark Kettenis wrote:
> > > Date: Sun, 16 Jan 2022 19:28:06 +0100
> > > From: Stefan Sperling
> > >
> > > On Sun, Jan 16, 2022 at 03:50:
Currently we attach ACPI devices that are present in a machine.
However, in some cases ACPI devices can be present, but not enabled.
Attaching a device driver to devices that are not enabled is not a
good idea since reading and writing from/to its registers will fail
and the driver will malfunction
> Date: Mon, 24 Jan 2022 20:19:46 +0100
> From: Anton Lindqvist
>
> On Mon, Jan 24, 2022 at 05:31:49PM +0100, Mark Kettenis wrote:
> > Currently we attach ACPI devices that are present in a machine.
> > However, in some cases ACPI devices can be present, but not enabled
> Date: Fri, 21 Jan 2022 16:18:28 +0100 (CET)
> From: Mark Kettenis
>
> > Date: Fri, 21 Jan 2022 16:05:49 +0100
> > From: Stefan Sperling
> >
> > On Sun, Jan 16, 2022 at 07:38:11PM +0100, Mark Kettenis wrote:
> > > > Date: Sun, 16 Jan 2022
> Date: Tue, 25 Jan 2022 10:00:45 +0100
> From: Stefan Sperling
>
> On Tue, Jan 25, 2022 at 09:32:21AM +0100, Mark Kettenis wrote:
> > Happened again while still on a Jan 16 snapshot kernel. So it is not
> > related to that diff.
> >
> > Here is the panic m
> Date: Tue, 25 Jan 2022 07:01:41 +0100
> From: Anton Lindqvist
>
> On Mon, Jan 24, 2022 at 08:40:36PM +0100, Mark Kettenis wrote:
> > > Date: Mon, 24 Jan 2022 20:19:46 +0100
> > > From: Anton Lindqvist
> > >
> > > On Mon, Jan 2
> Date: Tue, 25 Jan 2022 19:44:23 +0100 (CET)
> From: Mark Kettenis
>
> > Date: Tue, 25 Jan 2022 07:01:41 +0100
> > From: Anton Lindqvist
> >
> > On Mon, Jan 24, 2022 at 08:40:36PM +0100, Mark Kettenis wrote:
> > > > Date: Mon, 24 Jan 2022
> From: "Theo de Raadt"
> Date: Tue, 01 Feb 2022 09:28:59 -0700
>
> A few comments.
>
> I think this approach is increasingly fragile, because a change for one
> architecture will affect others.
>
> > -.elif ${MACHINE} == "armv7" || ${MACHINE} == "arm64"
> > +.elif ${MACHINE} == "armv7" || ${MA
> From: "Theo de Raadt"
> Date: Tue, 01 Feb 2022 10:48:39 -0700
>
> Mark Kettenis wrote:
>
> > > From: "Theo de Raadt"
> > > Date: Tue, 01 Feb 2022 09:28:59 -0700
> > >
> > > A few comments.
> > >
> Date: Wed, 2 Feb 2022 10:47:59 +
> From: Miod Vallat
>
> On PowerMac11,2 systems, the PCIe bus attaches as:
>
> mpcpcibr0 at mainbus0 pci: u4-pcie
> pci0 at mpcpcibr0 bus 0
>
> However none of the devices attached to pci0 will appear in pcidump.
>
> This is caused by an incorrect bus num
> Date: Wed, 2 Feb 2022 14:16:03 +
> From: Visa Hankala
>
> On Tue, Feb 01, 2022 at 10:55:03AM -0700, Theo de Raadt wrote:
> > Mark Kettenis wrote:
> >
> > > Maybe we should rename the file to efi_installboot.c and/or rearrange
> > > the code sligh
> Date: Fri, 3 Jul 2020 15:13:22 +0200
> From: Robert Nagy
>
> 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
Are the issue that naddy@ saw solved?
Did anybody do a
> Date: Fri, 3 Jul 2020 12:42:58 -0500
> From: Scott Cheloha
>
> On Fri, Jul 03, 2020 at 02:34:20PM +0300, Paul Irofti wrote:
> > On 2020-07-03 00:40, Scott Cheloha wrote:
> > > On Fri, Jun 26, 2020 at 04:53:14PM +0300, Paul Irofti wrote:
> > > > On Wed, Jun 24, 2020 at 11:53:23AM +0200, Robert N
> Date: Sun, 5 Jul 2020 20:31:19 +0300
> From: Paul Irofti
>
> On Fri, Jul 03, 2020 at 06:36:39PM +0300, Paul Irofti wrote:
> >
> >
> > În 3 iulie 2020 17:55:25 EEST, Mark Kettenis a
> > scris:
> > >> Date: Fri, 3 Jul 2020 15:13:22 +0200
>
IEEE1275 a.k.a. Open Firmware clearly states that property name
strings can have a length of up to 31 characters. That same limit is
mentioned in various documents on the flattened device tree format.
Unfortunately that limit seems to be ignored. The device tree on the
POWER9 machines has propert
> Date: Mon, 6 Jul 2020 16:40:35 -0500
> From: Scott Cheloha
>
> On Fri, Jul 03, 2020 at 10:52:15AM +0200, Otto Moerbeek wrote:
> > On Thu, Jul 02, 2020 at 08:27:58PM -0500, Scott Cheloha wrote:
> >
> > > Hi,
> > >
> > > When we recompute the scaling factor during tc_windup() there is an
> > >
> From: Vitaliy Makkoveev
> Date: Tue, 7 Jul 2020 01:34:33 +0300
>
> > On 5 Jul 2020, at 20:31, Paul Irofti wrote:
> >
> > On Fri, Jul 03, 2020 at 06:36:39PM +0300, Paul Irofti wrote:
> >>
> >>
> >> În 3 iulie 2020 17:55:25 EEST, Mark Ke
> Date: Tue, 7 Jul 2020 15:16:33 +0200
> From: Frederic Cambus
>
> Hi tech@,
>
> The recent spike of interest around framebuffer consoles has prompted
> me to revisit a proposal I sent back in early 2017 [1].
>
> Aesthetics considerations aside, kettenis@ raised the concern that colors
> from t
> From: "Theo de Raadt"
> Date: Tue, 07 Jul 2020 08:49:41 -0600
>
> Jonathan Gray wrote:
>
> > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> > > Hi tech@,
> > >
> > > The recent spike of interest around framebuffer consoles has prompted
> > > me to revisit a proposal I sen
> Date: Tue, 7 Jul 2020 17:55:32 +0200
> From: Frederic Cambus
>
> On Wed, Jul 08, 2020 at 12:06:27AM +1000, Jonathan Gray wrote:
> > On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> > > Hi tech@,
> > >
> > > The recent spike of interest around framebuffer consoles has prompted
> Date: Tue, 7 Jul 2020 22:49:31 +0200
> From: Christian Weisgerber
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> Userland gettime support for alpha.
>
> Alas, completely untested since I don't have access to that arch.
>
> Index: lib/libc/arch/alpha/gen/usertc.
> Date: Tue, 7 Jul 2020 23:13:06 +0200
> From: Christian Weisgerber
>
> Mark Kettenis:
>
> > > --- lib/libc/arch/alpha/gen/usertc.c 6 Jul 2020 13:33:05 -
> > > 1.1
> > > +++ lib/libc/arch/alpha/gen/usertc.c 7 Jul 2020 20:40:37 -
> Date: Tue, 7 Jul 2020 23:46:00 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Tue, 7 Jul 2020 23:13:06 +0200
> > From: Christian Weisgerber
> >
> > Mark Kettenis:
> >
> > > > --- lib/libc/arch/alpha/gen/usertc.c6 Jul 2020 13:33:05 -
> From: Paul Irofti
> Date: Wed, 8 Jul 2020 12:05:04 +0300
>
> On 2020-06-26 06:22, George Koehler wrote:
> > On Mon, 22 Jun 2020 19:12:22 +0300
> > Paul Irofti wrote:
> >
> >> New iteration:
> >>
> >>- ps_timekeep should not coredump, pointed by deraadt@
> >>- set ps_timekeep to 0 befo
> From: "Theo de Raadt"
> Date: Wed, 08 Jul 2020 09:42:41 -0600
>
> I think we need something like this.
>
> Documenting it will be a challenge.
>
> I really don't like the name as is too generic, when the control is only
> for a narrow set of "current time" system calls.
I'm not sure we shoul
> Date: Wed, 8 Jul 2020 18:02:06 +0200
> From: Frederic Cambus
>
> Hi tech@,
>
> Here is a diff to enable spleen16x32 and spleen32x64 on armv7 for
> GENERIC kernels, like on arm64.
>
> I'm using the 16x32 version on my Cubieboard2.
>
> I'm not sure if any armv7 devices we support is actually c
> From: "Ted Unangst"
> Date: Wed, 08 Jul 2020 05:20:23 -0400
>
> On 2020-07-08, Ted Unangst wrote:
> > I think this makes sem_init(pshared) work.
>
> Whoops, need more context to include the header file changes.
It is a bit of a pity that we have to expose the internals here, but I
don't see a
arch/aarch64/gen/usertc.c 6 Jul 2020 13:33:05 - 1.1
+++ lib/libc/arch/aarch64/gen/usertc.c 9 Jul 2020 08:12:44 -
@@ -1,6 +1,6 @@
-/* $OpenBSD: usertc.c,v 1.1 2020/07/06 13:33:05 pirofti Exp $ */
+/* $OpenBSD$ */
/*
- * Copyright (c) 2020 Paul Irofti
+ * Copyrig
> From: "Ted Unangst"
> Date: Thu, 09 Jul 2020 11:07:02 -0400
>
> On 2020-07-08, Mark Kettenis wrote:
> > > From: "Ted Unangst"
> > > Date: Wed, 08 Jul 2020 05:20:23 -0400
> > >
> > > On 2020-07-08, Ted Unangst wrote:
> >
> From: "Theo de Raadt"
> Date: Thu, 09 Jul 2020 09:13:24 -0600
>
> Ted Unangst wrote:
>
> > On 2020-07-08, Theo de Raadt wrote:
> > > I think we need something like this.
> > >
> > > Documenting it will be a challenge.
> > >
> > > I really don't like the name as is too generic, when the cont
> Date: Thu, 9 Jul 2020 19:43:52 +0200
> From: Ingo Schwarze
>
> Hi Theo,
>
> Theo de Raadt wrote on Thu, Jul 09, 2020 at 11:08:38AM -0600:
> > Ingo Schwarze wrote:
>
> >> So, what about
> >> LD_KTRACE_GETTIME
> >> or a similar environment variable name?
>
> > That naming seems logical.
> >
So it seems that hardware reference and change bit updates are busted
on POWER9 CPUs. Or at least they don't work the way I'm reading the
specs. So I've changed the pmap for OpenBSD/powerpc64 to emulate them
instead.
While implementing this code I wondered how this is supposed to work
for pages
> Date: Fri, 10 Jul 2020 19:03:58 -0400
> From: George Koehler
>
> On Wed, 8 Jul 2020 14:26:02 +0200 (CEST)
> Mark Kettenis wrote:
>
> > > From: Paul Irofti
> > > Reads OK to me. Please make the adjustments to static functions that
> > > ketteni
> From p...@irofti.net Sat Jul 11 01:23:20 2020
> Date: Sat, 11 Jul 2020 02:22:33 +0300
>
> În 11 iulie 2020 02:15:27 EEST, Mark Kettenis a
> scris:
> >> Date: Fri, 10 Jul 2020 19:03:58 -0400
> >> From: George Koehler
> >>
> >> On Wed,
> Date: Sat, 11 Jul 2020 14:45:44 +1000
> From: Jonathan Gray
>
> In drm linux spinlocks are mapped to mutex(9).
>
> Locks without calls to spin_lock_irqsave(), spin_lock_irq() and the like
> (which block interrupts) can be changed to IPL_NONE.
This shouldn't really make a difference, although
> From: Paul Irofti
> Date: Sat, 11 Jul 2020 13:32:22 +0300
>
> Hi,
>
> Getting lots of messages about people loving the new timekeep
> functionality, which I am very happy about, but also some that have the
> skew too large for it to be enabled.
>
> I plan on sending a diff next week to impr
> From: Paul Irofti
> Date: Sat, 11 Jul 2020 13:50:37 +0300
>
> On 2020-07-11 13:46, Mark Kettenis wrote:
> >> From: Paul Irofti
> >> Date: Sat, 11 Jul 2020 13:32:22 +0300
> >>
> >> Hi,
> >>
> >> Getting lots of messages about
> Date: Sat, 11 Jul 2020 19:29:17 +0200
> From: Stefan Sperling
>
> When a wifi interface acts as a client, ifconfig will currently display
> the default value 'ccmp' for the wpagroupcipher parameter, even while
> associated to a WPA2 access point which uses TKIP as the group cipher
> for WPA1 co
> Date: Thu, 9 Jul 2020 11:29:05 -0500
> From: Scott Cheloha
> Cc: tech@openbsd.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, Jul 09, 2020 at 10:35:46AM +0200, Mark Kettenis wrote:
> >
> > Here is the arm64 version.
> Date: Sun, 12 Jul 2020 00:06:21 +0200
> From: Christian Weisgerber
>
> Mark Kettenis:
>
> > Nevertheless, here is a different take on the problem. Since the
> > timecounter only uses the low 32 bits we don't need the double read.
> > This version
While working on the OpenBSD/powerpc64 pmap I noticed that the code we
use for the G5 machines has a bug and doesn't remove execute
permission from mappings when it should.
Since I don't have a G5 machine readily available, can somebody test
this diff for me?
Index: arch/powerpc/powerpc/pmap.c
=
> Date: Sun, 12 Jul 2020 18:21:48 +0200
> From: Christian Weisgerber
>
> There is the strong suspicion that the 0x7fff mask in the various
> armv7 timecounters was simply copied from powerpc, and that these really
> are full 32-bit counters.
>
> I wanted to verify this from the data sheets,
> Date: Sun, 12 Jul 2020 18:12:39 +0200
> From: Christian Weisgerber
>
> The PowerPC/Power ISA Time Base is a 64-bit register. We can use
> the full lower 32 bits.
>
> OK?
Sure, but this needs to be coordinated with the userland diff. And
we'd better change it quick because doing it later is
> Date: Sun, 12 Jul 2020 18:23:09 +0200
> From: Christian Weisgerber
>
> Christian Weisgerber:
>
> > - tb_get_timecount, NULL, 0x7fff, 0, "tb", 0, NULL, 0
> > + tb_get_timecount, NULL, 0x, 0, "tb", 0, NULL, 0
>
> PS: Do we prefer ~0u over 0x?
I prefer 0x. We ty
> Date: Sun, 12 Jul 2020 19:30:38 +0200
> From: Christian Weisgerber
>
> Mark Kettenis:
>
> > > Date: Sun, 12 Jul 2020 18:12:39 +0200
> > > From: Christian Weisgerber
> > >
> > > The PowerPC/Power ISA Time Base is a 64-bit register. We ca
> Date: Mon, 13 Jul 2020 17:07:31 -0400
> From: George Koehler
>
> On Mon, 13 Jul 2020 01:18:14 -0500
> Scott Cheloha wrote:
>
> > To review, the update protocol is:
> >
> > 1. Set tk_generation to zero; the update has begun.
> >
> > 2. Memory barrier. The side effects of step (1) are "visib
The firmware on the POWER9 machines provides an energy sensor. This
sensor measures the energy on/in/at the chip. I'm not sure what that
actually means. But it is different from the energy content of a
battery which is measured in Watthours.
Should I add this? Or should I just skip these senso
> Date: Tue, 14 Jul 2020 20:21:24 -0400
> From: George Koehler
>
> On Tue, 14 Jul 2020 11:59:14 +0200 (CEST)
> Mark Kettenis wrote:
>
> > Yeah, one possible approach would be to increment ogen by two. A
> > little bit easier to check that they can never be the sa
> Date: Tue, 14 Jul 2020 20:17:30 -0500
> From: Scott Cheloha
> Cc: Mark Kettenis , tech@openbsd.org, p...@irofti.net
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Tue, Jul 14, 2020 at 08:21:24PM -0400, George Koehler wrote:
> > O
> Date: Wed, 15 Jul 2020 17:05:57 +0200
> From: Jan Stary
>
> This is in the vein of
> https://marc.info/?l=openbsd-cvs&m=158170787221615&w=2
>
> declares "extern int optind" and friends,
> so there is no need to declare them again.
> Still builds on current/amd64.
>
> Leaving out gnu, nsd, un
> Date: Wed, 15 Jul 2020 20:36:04 -0500
> From: Scott Cheloha
>
> On Sat, Jul 11, 2020 at 01:16:43PM +0200, Mark Kettenis wrote:
> > > From: Paul Irofti
> > > Date: Sat, 11 Jul 2020 13:50:37 +0300
> > >
> > > On 2020-07-11 13:46, Mark Kettenis
> Date: Tue, 21 Jul 2020 19:33:21 +1000
> From: Jonathan Gray
>
> Change from using timevals for ktime to 64 bit count of nanoseconds
> to closer match linux. From a discussion with cheloha@
ok kettenis@
> Index: sys/dev/pci/drm/drm_vblank.c
> ==
Booted up the old v210 to test something and noticed that it prints a
couple of:
bge0: nvram lock timed out
warnings when booting up. These are the on-board network interfaces
and we already established in the past that these come without
EEPROM/NVRAM and instead rely on the firmware to provid
Recent ACPI versions have deprecated "Processor()" nodes in favout of
"Device()" nodes with a _HID() method that returns "ACPI0007". This
diff tries to support machines with firmware that implements this. If
you see something like:
"ACPI0007" at acpi0 not configured
please try the following d
601 - 700 of 3190 matches
Mail list logo
