> From: "Theo de Raadt"
> Date: Thu, 10 Dec 2020 10:13:52 -0700
>
> Marcus Glocker wrote:
>
> > Hi All,
> >
> > I recently started to play around with uvideo(4) and uaudio(4) on my
> > amd64 iMacs. There I quickly noticed regular freezes when streaming
> > USB video or audio. On some of thos
> Date: Thu, 10 Dec 2020 16:13:22 -0600
> From: Scott Cheloha
>
> Hi,
>
> We looked at removing the ticks from subr_pool.c a while back but it
> got shelved. That may or may not have been my fault. I don't
> remember.
>
> Anyway, I would normally suggest switching to getuptime(9) here, but
>
> Date: Fri, 11 Dec 2020 11:51:54 -0600
> From: Scott Cheloha
>
> On Fri, Dec 11, 2020 at 09:49:07AM -0300, Martin Pieuchot wrote:
> > On 11/12/20(Fri) 12:52, Mark Kettenis wrote:
> > > > Date: Thu, 10 Dec 2020 16:13:22 -0600
> > > > From: Scott Cheloha
Diff below has been in snaps for about a week now without ill effects.
It fixes some issues with referencing named ACPI nodes from Packages.
These references need to be resolved at runtime rather than when
they're parsed such that they pick up the right values for those nodes
which can be changed w
> Date: Tue, 15 Dec 2020 13:32:22 +0100
> From: Claudio Jeker
>
> On Fri, Dec 11, 2020 at 07:07:56PM -0600, Scott Cheloha wrote:
> > Hi,
> >
> > I'd like to remove lbolt from the kernel. I think having it in the
> > kernel complicates otherwise simple code.
> >
> > We can start with sdmmc(4).
> Date: Tue, 15 Dec 2020 12:15:30 -0300
> From: Martin Pieuchot
>
> When the first thread of multimedia/mpv exits after having played a video
> with the "gpu" (default) output, the programs receives a SIGSEV when it
> tries to execute one of its destructor:
>
> void
> _rthread_tls_destructors(pt
> From: jungle Boogie
> Date: Tue, 15 Dec 2020 08:07:04 -0800
>
> Hi All,
>
> On my i386 Toshiba netbook machine, I am getting a kernel panic with
> the latest i386 snapshot.
>
> I hope this information helps someone with the issue.
>
> > show panic
> kernel diagnostic assertion "_kernel_lock_
> Date: Tue, 15 Dec 2020 21:21:37 +0100
> From: Alexander Bluhm
>
> On Tue, Dec 15, 2020 at 06:57:03PM +0100, Mark Kettenis wrote:
> > Does the diff below fix this?
>
> I can reproduce the panic and your diff fixes it.
>
> Usually my regress machines do not
> Date: Wed, 16 Dec 2020 12:50:46 -0600
> From: Scott Cheloha
>
> On Tue, Dec 15, 2020 at 01:47:24PM +0100, Mark Kettenis wrote:
> > > Date: Tue, 15 Dec 2020 13:32:22 +0100
> > > From: Claudio Jeker
> > >
> > > On Fri, Dec 11, 2020 at 0
> Date: Thu, 17 Dec 2020 18:56:52 -0300
> From: Martin Pieuchot
>
> On 16/12/20(Wed) 22:49, Greg Steuck wrote:
> > I just hit this while booting an i386-current in vmd. The source tree is
> > synced to "Remove the assertion in uvm_km_pgremove()."
> >
> > I enabled WITNESS on top of GENERIC. Natu
> Date: Fri, 18 Dec 2020 13:04:42 +0100
> From: Alexander Bluhm
>
> On Fri, Dec 18, 2020 at 10:36:28AM +1000, Jonathan Matthew wrote:
> > Here are a couple of relatively easy ones, applying changes from r1.86 of
> > amd64's acpi_machdep.c to i386 and arm64. I've tested i386 but it turns
> > out
> Date: Thu, 17 Dec 2020 19:25:44 -0300
> From: Martin Pieuchot
>
> On 17/12/20(Thu) 23:16, Mark Kettenis wrote:
> > > Date: Thu, 17 Dec 2020 18:56:52 -0300
> > > From: Martin Pieuchot
> > >
> > > On 16/12/20(Wed) 22:49, Greg Steuck wrote:
>
Graphics stuff is weird. It doesn't just care about endianness on the
byte level, but also about endianness on the bit level. This matters
for monochrome framebuffers, where a true big-endian framebuffer will
have the leftmost pixel in the MSB wheras a little-endian framebuffer
will have it in th
> Date: Sat, 19 Dec 2020 20:05:08 +1000
> From: Jonathan Matthew
>
> A few more km_alloc()s following the same pattern as acpi. I don't have any
> machines that actually need mpbios(4) but I've booted amd64 and i386 smp qemu
> vms with acpi disabled, which causes mpbios to attach instead.
>
> o
> Date: Sat, 19 Dec 2020 18:07:41 -0300
> From: Martin Pieuchot
>
> On 18/12/20(Fri) 08:04, Todd C. Miller wrote:
> > On Fri, 18 Dec 2020 13:34:39 +0100, Mark Kettenis wrote:
> >
> > > Anyway, your analysis is right. When a kernel thread wants to use
> &g
> Date: Sun, 20 Dec 2020 14:53:16 -0600
> From: Scott Cheloha
>
> I want to see if a process is waiting in sigsuspend(2) from top(1).
> The current sleep string is "pause", which leaves me wondering what
> the process is actually doing. The string "sigsuspend" would make it
> unambiguous.
>
> o
> Date: Sun, 20 Dec 2020 16:23:25 -0600
> From: Scott Cheloha
>
> Short version:
>
> Please test if this patch breaks suspend or hibernate on your
> machine. Reply with the results of your test and your dmesg.
>
> Both are still working on my Lenovo Thinkpad X1 Carbon Gen 6.
>
> Long version:
> Date: Fri, 18 Dec 2020 13:49:32 -0600
> From: Scott Cheloha
>
> Hi,
>
> This patch adds support for passing NULL as the ident when calling
> tsleep(9) etc. When this happens, sleep_setup() will use the address
> of the sleep_state struct as the value for p_wchan. This address is
> basically
> Date: Mon, 21 Dec 2020 11:25:28 -0600
> From: Scott Cheloha
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> The manpage for delay(9) suggests that the prototype is:
>
> void delay(int);
>
> But on armv7, arm64, hppa, macppc, and powerpc64 the input is unsigned
>
> Date: Mon, 21 Dec 2020 16:46:32 -0300
> From: Martin Pieuchot
>
> During a page fault multiples counters are updated. They fall into two
> categories "fault counters" and "global statistics" both of which are
> currently represented by int-sized fields inside a global: `uvmexp'.
>
> Diff belo
> Date: Wed, 23 Dec 2020 10:58:16 -0300
> From: Martin Pieuchot
>
> On 22/12/20(Tue) 23:43, Mark Kettenis wrote:
> > > Date: Mon, 21 Dec 2020 16:46:32 -0300
> > > From: Martin Pieuchot
> > >
> > > During a page fault multiples counters are upda
Diff below switches the i386 pmap to use the modern km_alloc(9)
functions and uses IPL_VM for the pmap pool, following the example of
amd64.
Don't have easy access to an i386 machine right now, so this has only
been compile tested.
ok (if it works)?
Index: arch/i386/i386/pmap.c
> Date: Wed, 23 Dec 2020 14:59:02 -0600
> From: Scott Cheloha
>
> Okay, let's try one more time.
>
> This patch adds a global sleep channel, "nowake", for sleeping threads
> that don't want to receive wakeup(9) broadcasts.
>
> You use it like this:
>
> #include
>
> tsleep(nowake,
Some ACPI platforms targetting linux that have quirky SDHC controllers
use ACPI _DSD properties to override the capability register of the
controller. An example is the SDHC controller on the Raspberry Pi4.
Diff below implements this.
ok?
Index: dev/acpi/sdhc_acpi.c
===
> Date: Fri, 25 Dec 2020 11:52:03 -0600
> From: Scott Cheloha
>
> On Wed, Dec 16, 2020 at 10:04:48PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 16 Dec 2020 12:50:46 -0600
> > > From: Scott Cheloha
> > >
> > > On Tue, Dec 15, 2020 at 01:47:24PM
> Date: Sat, 26 Dec 2020 16:40:15 +0100
> From: Christian Weisgerber
>
> Denis Fondras:
>
> > This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify with
> > FreeBSD and Linux.
> >
> > I added aliases at the end of queue.h to avoid breaking base too much. they
> > will
> > be re
> Date: Sat, 26 Dec 2020 18:39:36 +0100
> From: Denis Fondras
>
> Le Sat, Dec 26, 2020 at 06:23:41PM +0100, Mark Kettenis a écrit :
> > > > This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify
> > > > with FreeBSD and Linux.
> > > >
> Date: Tue, 29 Dec 2020 12:21:25 +0100
> From: Otto Moerbeek
>
> Hi,
>
> this is a continuation from the threads on bugs@
>
> This version makes it explicit to *only* setup "TLS" (which actually
> is just a pointer to static data) with the data provided if we're
> running single threaded (ie..
> Date: Tue, 29 Dec 2020 16:07:19 +0100
> From: Otto Moerbeek
>
> On Tue, Dec 29, 2020 at 01:42:57PM +0100, Otto Moerbeek wrote:
>
> > On Tue, Dec 29, 2020 at 12:46:54PM +0100, Mark Kettenis wrote:
> >
> > > > Date: Tue, 29 Dec 2020 12:
> Date: Tue, 29 Dec 2020 15:24:58 +0100
> From: Marcus Glocker
>
> Now that we have a switch in place with kern.video.record which requires
> initial root access to enable video recording, I want propose the idea
> of making the /dev/video* devices accessible to users who are a member
> of the 'v
The diff below changes the emulated Linux memory allocation functions
a bit such that they only use malloc(9) for allocations smaller than a
page. This reduces pressure on the "interrupt safe" map and hopefully
will avoid the
uvm_mapent_alloc: out of static map entries
messages that some peo
> Date: Wed, 30 Dec 2020 11:19:41 -0300
> From: Martin Pieuchot
>
> Diff below adds some locking to UVM's amap & anon data structures that
> should be enough to get the upper part of the fault handler out of the
> KERNEL_LOCK().
>
> This diff doesn't unlock the fault handler, I'd suggest to do t
> Date: Fri, 1 Jan 2021 09:51:27 +0100
> From: Otto Moerbeek
>
> On Thu, Dec 31, 2020 at 10:09:36PM +0100, Mark Kettenis wrote:
>
> > The diff below changes the emulated Linux memory allocation functions
> > a bit such that they only use malloc(9) for allocations sma
> Date: Fri, 1 Jan 2021 20:10:45 +1100
> From: Jonathan Gray
New diff at the end of this mail. Please test this one instead of the
previous one.
> On Thu, Dec 31, 2020 at 10:09:36PM +0100, Mark Kettenis wrote:
> > The diff below changes the emulated Linux memory allocation func
> Date: Sat, 2 Jan 2021 18:39:03 +1000
> From: Jonathan Matthew
>
> This code is now only here for some unfortunate Intel graphics chips
> based on PowerVR, and I don't have a machine with one of those.
> vga_post_init() gets called from vga_attach() in any case, and
> vga_post_free() doesn't see
> Date: Sun, 3 Jan 2021 13:47:45 +0100
> From: Otto Moerbeek
>
> On Thu, Dec 31, 2020 at 05:54:06PM +0100, Alexander Bluhm wrote:
>
> > On Tue, Dec 29, 2020 at 04:07:19PM +0100, Otto Moerbeek wrote:
> > > This workds better, checking the flags does not work if the thread is
> > > already on the
> Date: Wed, 6 Jan 2021 16:16:27 -0600
> From: Scott Cheloha
>
> On Wed, Jan 06, 2021 at 12:16:13PM -0600, Scott Cheloha wrote:
> > As mentioned in a prior mail, tpm(4) is the last user of tvtohz(9) in
> > the tree.
> >
> > However, we don't need to use tvtohz(9) in tpm(4) at all. Converting
>
> Date: Thu, 7 Jan 2021 14:24:58 +0100
> From: Frederic Cambus
>
> On Thu, Dec 24, 2020 at 12:25:40AM +0100, Patrick Wildt wrote:
>
> > > On Fri, Dec 18, 2020 at 10:33:52PM +0100, Mark Kettenis wrote:
> > >
> > > > The diff below disa
> Date: Thu, 7 Jan 2021 11:15:41 -0600
> From: Scott Cheloha
>
> Hi,
>
> I want to isolate statclock() from hardclock(9). This will simplify
> the logic in my WIP dynamic clock interrupt framework.
>
> Currently, if stathz is zero, we call statclock() from within
> hardclock(9). It looks like
> Date: Fri, 8 Jan 2021 10:27:38 -0600
> From: Scott Cheloha
>
> On Wed, Jan 06, 2021 at 11:26:27PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 6 Jan 2021 16:16:27 -0600
> > > From: Scott Cheloha
> > >
> > > On Wed, Jan 06, 2021 at 12:16:13PM
> Date: Sat, 9 Jan 2021 10:38:20 +0100
> From: Marcus Glocker
>
> I have not much clue about HID, but when we did some testing for the
> new ujoy(4) driver it turned out that the PS4 controller doesn't get
> handled correctly by hid.c:hid_is_collection(). This made me peek in
> to the NetBSD cod
> Date: Fri, 8 Jan 2021 10:18:27 -0600
> From: Scott Cheloha
>
> On Thu, Jan 07, 2021 at 08:12:10PM -0600, Scott Cheloha wrote:
> > On Thu, Jan 07, 2021 at 09:37:58PM +0100, Mark Kettenis wrote:
> > > > Date: Thu, 7 Jan 2021 11:15:41 -0600
> > > >
> Date: Mon, 11 Jan 2021 11:35:17 -0300
> From: Martin Pieuchot
>
> On 31/12/20(Thu) 22:35, Mark Kettenis wrote:
> > > Date: Wed, 30 Dec 2020 11:19:41 -0300
> > > From: Martin Pieuchot
> > >
> > > Diff below adds some locking to UVM's amap
> Date: Wed, 13 Jan 2021 21:39:37 -0600
> From: Scott Cheloha
>
> On Fri, Jan 08, 2021 at 08:21:14PM +0100, Florian Obser wrote:
> >
> > My x1 gen 2 seems to have a TPM 1.2 chip. Or can emulate one?
> > The bios is confusing. I had it disabled until now.
> > It seems to be able to suspend/resume
The diff below fixes an issue with using the rpi4 with newer
RaspberryPi firmware in combination with the EDK2-based UEFI firmware.
The problem is that the EDK2-based firmware programs the outbound mmio
window in a way that is incompatible with the device tree. There are
multiple ways to fix this,
> Date: Thu, 21 Jan 2021 12:49:57 +
> From: Jason McIntyre
>
> On Thu, Jan 21, 2021 at 12:47:15PM +, Stuart Henderson wrote:
> > On 2021/01/21 12:43, Jason McIntyre wrote:
> > > On Thu, Jan 21, 2021 at 11:15:48AM +0100, Martin Vahlensieck wrote:
> > > > Hi
> > > >
> > > > I think the bac
> Date: Thu, 28 Jan 2021 16:45:12 +0100
> From: Marcus Glocker
> Cc: Alexandre Ratchov , tech@openbsd.org, ratc...@openbsd.org,
> st...@openbsd.org, kette...@openbsd.org, m...@openbsd.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, Jan 28, 2021 a
> Date: Fri, 29 Jan 2021 09:48:42 -0500
> From: Philippe Meunier
>
> Philippe Meunier wrote:
> >Is there some kind of limitation on the size of an ELF executable that can
> >be executed on i386? I mean, in addition to the limits in /etc/login.conf?
>
> When using readelf(1) on the chrome execut
One of the aspects of device access is whether CPU writes to a device
are posted or non-posted. For non-posted writes, the CPU will wait
for the device to acknowledge that the write has performed. If the
device sits on a bus far away, this can take a while and slow things
down. The alternative a
> Date: Mon, 15 Feb 2021 01:19:29 +0100
> From: Patrick Wildt
>
> Am Mon, Feb 15, 2021 at 09:55:56AM +1000 schrieb David Gwynne:
> >
> >
> > > On 15 Feb 2021, at 07:54, Mark Kettenis wrote:
> > >
> > > One of the aspects of device access is
> From: David Gwynne
> Date: Tue, 16 Feb 2021 12:58:35 +1000
>
> > On 16 Feb 2021, at 06:01, Mark Kettenis wrote:
> >
> >> Date: Mon, 15 Feb 2021 01:19:29 +0100
> >> From: Patrick Wildt
> >>
> >> Am Mon, Feb 15, 2021 at 09:55:56AM +
> Date: Wed, 17 Feb 2021 20:59:06 +1100
> From: Jonathan Gray
>
> On Wed, Feb 17, 2021 at 10:33:18AM +0100, Patrick Wildt wrote:
> > Am Wed, Feb 17, 2021 at 11:56:16AM +1100 schrieb Jonathan Gray:
> > > Add a driver for "simple-pm-bus" a way to enable a clock and/or
> > > power domain for a group
> Date: Wed, 17 Feb 2021 22:12:40 +1100
> From: Jonathan Gray
>
> On Wed, Feb 17, 2021 at 11:49:27AM +0100, Mark Kettenis wrote:
> > > Date: Wed, 17 Feb 2021 20:59:06 +1100
> > > From: Jonathan Gray
> > >
> > > On Wed, Feb 17, 2021 at 10:33:18AM
> Date: Thu, 18 Feb 2021 21:18:51 +1100
> From: Jonathan Gray
I suspect that there are some ports that need to get their unveils
updated if we do this.
> Index: lib/libdrm/xf86drm.h
> ===
> RCS file: /cvs/xenocara/lib/libdrm/xf86drm
> Date: Thu, 18 Feb 2021 22:24:10 +1100
> From: Jonathan Gray
>
> On Thu, Feb 18, 2021 at 12:01:28PM +0100, Mark Kettenis wrote:
> > > Date: Thu, 18 Feb 2021 21:18:51 +1100
> > > From: Jonathan Gray
> >
> > I suspect that there are some ports that need
> Date: Fri, 19 Feb 2021 10:57:30 +0100
> From: Otto Moerbeek
>
> Hi,
>
> working on PowerDNS Recursor, once in a while I'm seeing:
>
> #0 0x09fd67ef09dc in
> libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT_COLOR
> (this=,
> head=0x9fd67efc8e8 , elm=0x9fca04be900)
> at
>
> Date: Fri, 19 Feb 2021 16:43:10 +0100
> From: Otto Moerbeek
>
> On Fri, Feb 19, 2021 at 01:06:43PM +0100, Otto Moerbeek wrote:
>
> > On Fri, Feb 19, 2021 at 12:45:58PM +0100, Mark Kettenis wrote:
> >
> > > > Date: Fri, 19 Feb 2021 10:
> Date: Sat, 20 Feb 2021 18:23:26 +0100
> From: Otto Moerbeek
> Cc: tech@openbsd.org, piro...@openbsd.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Fri, Feb 19, 2021 at 05:29:31PM +0100, Mark Kettenis wrote:
>
> > > Date
> Date: Sat, 20 Feb 2021 18:31:55 +0100
> From: Otto Moerbeek
> Cc: tech@openbsd.org, piro...@openbsd.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Sat, Feb 20, 2021 at 06:30:23PM +0100, Mark Kettenis wrote:
>
> > > Date
> Date: Sun, 7 Feb 2021 15:42:27 +
> From: Miod Vallat
>
> When asking for the backtrace of a secondary processor in ddb, if that
> backtrace reaches the secondary cpu startup code before the
> switch_trampoline call, it will trust uninitialized stack data and is
> likely to panic with an una
> Date: Mon, 22 Feb 2021 10:10:21 +0100
> From: Martin Pieuchot
>
> On 16/02/21(Tue) 11:20, Martin Pieuchot wrote:
> > Start by moving `pgo_fault' handler outside of uvm_fault_lower().
> >
> > If a page has a backing object that prefer to handler to fault itself
> > the locking will be different
> Date: Tue, 23 Feb 2021 10:07:43 +0100
> From: Martin Pieuchot
>
> On 23/02/21(Tue) 00:24, Mark Kettenis wrote:
> > > Date: Mon, 22 Feb 2021 10:10:21 +0100
> > > From: Martin Pieuchot
> > >
> > > On 16/02/21(Tue) 11:20, Martin Pieuchot wr
> Date: Thu, 25 Feb 2021 20:10:00 +0100
> From: Marcus Glocker
>
> We had this discussion recently when fbtab(5) for xenodm(1) was fixed
> 6 weeks ago, but we didn't come to an agreement yet. tb@ asked me the
> same question yesterday whether we can add video(1) to fbtab to avoid
> manual chown
> Date: Wed, 3 Mar 2021 10:27:34 +0100
> From: Martin Pieuchot
>
> On 24/02/21(Wed) 11:33, Martin Pieuchot wrote:
> > As soon as the upper part of the page fault handler is executed w/o
> > KERNEL_LOCK(), uvm_anfree_list() will also be executed without it.
> >
> > To not corrupt the value of `uv
> Date: Thu, 4 Mar 2021 10:34:24 +0100
> From: Martin Pieuchot
>
> Running t/rw/msleep(9) w/o KERNEL_LOCK() implies that a thread can
> change the value of `ps_single' while one of its siblings might be
> dereferencing it.
>
> To prevent inconsistencies in the code executed by sibling thread,
> Date: Thu, 4 Mar 2021 10:54:48 +0100
> From: Patrick Wildt
>
> Am Thu, Mar 04, 2021 at 10:42:24AM +0100 schrieb Mark Kettenis:
> > > Date: Thu, 4 Mar 2021 10:34:24 +0100
> > > From: Martin Pieuchot
> > >
> > > Running t/rw/msleep(9) w/o KERN
> Date: Thu, 4 Mar 2021 11:19:23 +0100
> From: Martin Pieuchot
>
> On 04/03/21(Thu) 11:01, Mark Kettenis wrote:
> > > Date: Thu, 4 Mar 2021 10:54:48 +0100
> > > From: Patrick Wildt
> > >
> > > Am Thu, Mar 04, 2021 at 10:42:24AM +0100 schrieb Mark
> Date: Fri, 5 Mar 2021 12:05:38 +0100
> From: Jan Klemkow
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> Hi,
>
> this diff adds the missing PCI classes Accelerator and Instrumentation.
> Thus, we can replace a few unknown in its output:
>
> - 0x0008: Class
> Date: Sat, 6 Mar 2021 20:19:07 +0100
> From: Patrick Wildt
>
> Hi,
>
> to be able to have acpiiort(4) pass a DMA tag to smmu(4), acpiiort(4)
> needs to be passed a DMA tag. So far acpi(4) only seems to pass it on
> acpi_foundhid(), but the ACPI table drivers don't get it. So, let's
> just pa
> Date: Fri, 26 Feb 2021 13:42:32 +0900 (JST)
> From: YASUOKA Masahiko
>
> Hi,
>
> My vaio repeatedly crashed by "Data modified on freelist"(*1) or other
> memory corruptions. After my long time debug, I found the route cause
> is a handling of references of LocalX, like the following:
>
>
> Date: Sat, 27 Feb 2021 19:43:31 +0900 (JST)
> From: YASUOKA Masahiko
> Content-Type: Text/Plain; charset=us-ascii
>
> Hi,
>
> Let me update "diff #2".
>
> On Fri, 26 Feb 2021 13:42:32 +0900 (JST)
> YASUOKA Masahiko wrote:
> > My vaio repeatedly crashed by "Data modified on freelist"(*1) or o
> Date: Mon, 8 Mar 2021 10:15:35 +0100
> From: Stefan Sperling
>
> On Sun, Mar 07, 2021 at 05:14:08PM -0800, Greg Steuck wrote:
> > I had an iwx working fine (modulo known issues) for a bit on amd64 current:
> >
> > iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX201" rev 0x00, msix
> > iwx0: hw
> Date: Wed, 10 Mar 2021 20:42:42 +0900 (JST)
> From: YASUOKA Masahiko
>
> Sorry for making noise, let me update the diff.
>
> > + if (ed->blkio->Media->IoAlign > 1 &&
> > + ((UINTN)buf + i_lblks * DEV_BSIZE)
> > + % ed->blkio->Media-
The UEFI standard indicates that the EfiBootServicesCode and
EfiBootServicesData memory types are available for general use after
ExitBootServices() has been called. So unless the firmware is really
really buggy, this should be safe and give us a bit more memory.
Tested this on three different UE
> Date: Fri, 12 Mar 2021 11:30:04 +0100
> From: Jan Klemkow
>
> Hi,
>
> This diff add a missing PCI ID of an Intel NVMe disk. The disk works
> after my last fix [1].
>
> OK?
That seems to be a poorly chosen name.
I believe this is what ark.intel.com calls a "Intel SSD DC P4510
Series" part.
> Date: Fri, 12 Mar 2021 00:42:27 +0100
> From: Klemens Nanni
>
> On Thu, Mar 11, 2021 at 11:36:26PM +0100, Mark Kettenis wrote:
> > The UEFI standard indicates that the EfiBootServicesCode and
> > EfiBootServicesData memory types are available for general use after
&g
> Date: Mon, 8 Mar 2021 21:09:49 +0100
> From: Matthieu Herrb
>
> Hi,
>
> If you look at the output of "xauth list" on you favourite OpenBSD
> machine you might get a bit scared, especially if you have an IPv6
> enabled network or if you used to travel and connect to various
> networks.
>
> Mos
> Date: Mon, 15 Mar 2021 19:25:56 +0100
> From: Patrick Wildt
>
> Am Mon, Mar 15, 2021 at 08:59:05AM +0100 schrieb Jan Klemkow:
> > On Mon, Mar 15, 2021 at 01:35:28AM -0600, Theo de Raadt wrote:
> > > My comments are about the "text name", which goes into every kernel
> > > anyone compiles.
> > >
> Date: Thu, 11 Mar 2021 15:05:11 +0900 (JST)
> From: YASUOKA Masahiko
>
> On Wed, 10 Mar 2021 13:15:58 +0100 (CET)
> Mark Kettenis wrote:
> >> On Wed, 10 Mar 2021 20:35:41 +0900 (JST)
> >> YASUOKA Masahiko wrote:
> >> > efiboot cannot load t
> Date: Thu, 18 Mar 2021 09:26:14 +0100
> From: Martin Pieuchot
>
> Diff below only touches comments in sys/uvm. It reverts the commit from
> 2014 that turned three line comments into one line comments and sync
> some more block with NetBSD -current. This helps reducing the diff with
> NetBSD.
> Date: Fri, 19 Mar 2021 09:19:21 +0100
> From: Martin Pieuchot
>
> On 18/03/21(Thu) 16:49, Mark Kettenis wrote:
> > > Date: Thu, 18 Mar 2021 09:26:14 +0100
> > > From: Martin Pieuchot
> > >
> > > Diff below only touches comments in sys/uvm. I
> Date: Sat, 20 Mar 2021 13:10:17 +0100
> From: Martin Pieuchot
>
> On SP systems, like bluhm@'s armv7 regression machine, the kern/ptrace2
> test is failing due to a subtle behavior. Diff below makes it pass.
>
> http://bluhm.genua.de/regress/results/2021-03-19T15%3A17%3A02Z/logs/sys/kern/ptra
> Date: Sun, 21 Mar 2021 01:02:53 +0100
> From: Klemens Nanni
>
> apm(4/arm64) merely provides an all zero/unknown stub for those values,
> e.g. apm(8) output is useless.
>
> Hardware sensors however provide the information:
>
> $ sysctl hw.sensors
> hw.sensors.rktemp0.temp0=32.22 d
> Date: Sun, 21 Mar 2021 17:22:05 +0100
> From: Klemens Nanni
>
> On Sun, Mar 21, 2021 at 02:02:00PM +0100, Mark Kettenis wrote:
> > > Date: Sun, 21 Mar 2021 01:02:53 +0100
> > > From: Klemens Nanni
> > >
> > > apm(4/arm64) merely provides an a
> Date: Mon, 22 Mar 2021 11:27:40 +0100
> From: Martin Pieuchot
>
> Diff below convert a use of uvm_km_zalloc(9) to km_alloc(9), this memory
> is never released, ok?
This will need some careful testing on multiple architectures.
> Index: kern/kern_malloc.c
>
> Date: Mon, 22 Mar 2021 11:29:52 +0100
> From: Martin Pieuchot
>
> Convert the last MI uvm_km_zalloc(9) to km_alloc(9), ok?
Also needs some careful testing on multiple architectures.
> Index: uvm/uvm_page.c
> ===
> RCS file: /cvs/
> Date: Sun, 21 Mar 2021 16:56:47 +0100
> From: Martin Pieuchot
>
> On 21/03/21(Sun) 13:42, Mark Kettenis wrote:
> > > Date: Sat, 20 Mar 2021 13:10:17 +0100
> > > From: Martin Pieuchot
> > >
> > > On SP systems, like bluhm@'s armv7 regressio
> Date: Mon, 22 Mar 2021 17:48:56 +0100
> From: Klemens Nanni
>
> Using our dtb package's blobs cwfg(4) won't attach on the Pinebook Pro
> since linux changed it:
>
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
>
> Thanks to k
> Date: Mon, 22 Mar 2021 19:07:23 +0100
> From: Klemens Nanni
>
> On Mon, Mar 22, 2021 at 06:19:14PM +0100, Mark Kettenis wrote:
> > > @@ -167,7 +167,7 @@ cwfg_attach(struct device *parent, struc
> > > free(batinfo, M_TEMP, len);
> > >
> > &
> From: "Theo de Raadt"
> Date: Tue, 23 Mar 2021 08:29:06 -0600
>
> Marcus Glocker wrote:
>
> > Index: sys/dev/sdmmc/sdmmc_scsi.c
> > ===
> > RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_scsi.c,v
> > retrieving revision 1.59
> > diff -u
> Date: Wed, 24 Mar 2021 20:58:48 +0100
> From: Marcus Glocker
>
> On Tue, Mar 23, 2021 at 09:52:42AM -0600, Theo de Raadt wrote:
>
> > Mark Kettenis wrote:
> >
> > > &
> From: Scott Cheloha
> Date: Thu, 25 Mar 2021 13:18:04 -0500
>
> > On Mar 24, 2021, at 8:29 AM, Josh Rickmar wrote:
> >
> > On Wed, Mar 24, 2021 at 05:40:21PM +0900, YASUOKA Masahiko wrote:
> >> Hi,
> >>
> >> I hit a problem which is caused by going back of monotonic time. It
> >> happens on
> Date: Fri, 26 Mar 2021 19:43:23 +0900 (JST)
> From: YASUOKA Masahiko
>
> Hi,
>
> On Fri, 26 Mar 2021 09:30:43 +0100
> Jan Klemkow wrote:
> > If you want to boot OpenBSD on an HP EliteBook 830 G7/G8, the bootloader
> > will hang while loading the kernel. Because, the UEFI loads the
> > bootlo
> Date: Sun, 4 Apr 2021 21:08:09 +0200
> From: Klemens Nanni
>
> Feedback? Objections? OK?
Explanation?
Not sure what happened here, but the reply-to was completely garbled...
> diff c154c5b3e913ab7299483002bea9fb9782684007
> 274222c1624a27cde904e8964e7b663a3d0750d8
> blob - 59cda075c0a8ec80
> Date: Sun, 4 Apr 2021 22:24:57 +0200
> From: Klemens Nanni
> Cc: Mark Kettenis
>
> On Sun, Apr 04, 2021 at 10:01:50PM +0200, Mark Kettenis wrote:
> > > Date: Sun, 4 Apr 2021 21:08:09 +0200
> > > From: Klemens Nanni
> > >
> > > Feedback?
:
> >>> On Thu, 25 Mar 2021 19:41:35 +0100 (CET)
> >>> Mark Kettenis wrote:
> >>>>> From: Scott Cheloha
> >>>>> Date: Thu, 25 Mar 2021 13:18:04 -0500
> >>>>>> On Wed, Mar 24, 2021 at 05:40:21PM +0900, YASUOKA Masahik
> Date: Sat, 3 Apr 2021 22:21:02 -0500
> From: Scott Cheloha
>
> On Fri, Apr 02, 2021 at 10:37:36AM -0700, Mike Larkin wrote:
> > On Thu, Apr 01, 2021 at 06:43:30PM -0500, Scott Cheloha wrote:
> > >
> > > [...]
> > >
> > > Hmmm. Being able to work around this would be nice.
> > >
> > > FreeBSD
> Date: Mon, 5 Apr 2021 23:15:23 +0200
> From: Marcus Glocker
>
> On Mon, Apr 05, 2021 at 07:30:43AM -0700, Greg Steuck wrote:
>
> > OK gnezdo with a usability question inline.
>
> Thanks. See below.
>
> > Marcus Glocker writes:
> >
> > > martijn@ has recently reported that in his machine
> Date: Mon, 5 Apr 2021 23:19:02 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Mon, 5 Apr 2021 23:15:23 +0200
> > From: Marcus Glocker
> >
> > On Mon, Apr 05, 2021 at 07:30:43AM -0700, Greg Steuck wrote:
> >
> > > OK gnezdo with a usabil
> From: Scott Cheloha
> Date: Wed, 7 Apr 2021 10:25:04 -0500
>
> > On Apr 6, 2021, at 07:49, Paul Irofti wrote:
> >
> The diff is obviously fine. But it is still a heuristic with no real
> motivation except for this particular ESXi VM case. So my question
> about why we choose th
1 - 100 of 3190 matches
Mail list logo
