Re: monotonic time going back by wrong skews

2021-04-07 Thread Mark Kettenis
> 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

Re: uvideo(4) new quirk flag UVIDEO_FLAG_NOATTACH

2021-04-05 Thread Mark Kettenis
> 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

Re: uvideo(4) new quirk flag UVIDEO_FLAG_NOATTACH

2021-04-05 Thread 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 usability question inline. > > Thanks. See below. > > > Marcus Glocker writes: > > > > > martijn@ has recently reported that in his machine

Re: monotonic time going back by wrong skews

2021-04-05 Thread Mark Kettenis
> 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. > > > > > >

Re: monotonic time going back by wrong skews

2021-04-05 Thread Mark Kettenis
: > >>> 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

Re: simpleaudio: set sysclk before using it

2021-04-04 Thread Mark Kettenis
> 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 > > > > >

Re: simpleaudio: set sysclk before using it

2021-04-04 Thread Mark Kettenis
> 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 -

Re: fyi: get HP EliteBook 830 G7/G8 booting

2021-03-26 Thread Mark Kettenis
> 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 > >

Re: monotonic time going back by wrong skews

2021-03-25 Thread Mark Kettenis
> 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

Re: sdmmc(4) off-by-one on boundary check

2021-03-24 Thread Mark Kettenis
> 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: > > > > > &

Re: sdmmc(4) off-by-one on boundary check

2021-03-23 Thread Mark Kettenis
> 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

Re: cwfg: update device-tree bindings

2021-03-22 Thread Mark Kettenis
> 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); > > > > > &

Re: cwfg: update device-tree bindings

2021-03-22 Thread Mark Kettenis
> 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

Re: fork(2), PT_ATTACH & SIGTRAP

2021-03-22 Thread Mark Kettenis
> 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 regression mac

Re: uvm_page_physload: use km_alloc(9)

2021-03-22 Thread Mark Kettenis
> 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:

Re: malloc: use km_alloc(9) for kmemusage

2021-03-22 Thread Mark Kettenis
> 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 >

Re: arm64: make cwfg(4) report battery information to apm(4)

2021-03-21 Thread Mark Kettenis
> 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

Re: arm64: make cwfg(4) report battery information to apm(4)

2021-03-21 Thread Mark Kettenis
> 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

Re: fork(2), PT_ATTACH & SIGTRAP

2021-03-21 Thread Mark Kettenis
> 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. > >

Re: uvm: sync some comments with NetBSD

2021-03-19 Thread Mark Kettenis
> 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

Re: uvm: sync some comments with NetBSD

2021-03-18 Thread Mark Kettenis
> 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.

Re: diff: efiboot: alignment for media which has IoAlign > 1

2021-03-15 Thread Mark Kettenis
> 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

Re: ixl(4): add ID for X710 10G SFP+

2021-03-15 Thread Mark Kettenis
> 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. > >

Re: xenodm : don't add authorizations for tcp connections by default

2021-03-13 Thread Mark Kettenis
> 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. > >

Re: More arm64 memory

2021-03-13 Thread Mark Kettenis
> 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

Re: add missing PCI ID for Intel NVMe

2021-03-12 Thread Mark Kettenis
> 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.

More arm64 memory

2021-03-11 Thread Mark Kettenis
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

Re: diff: efiboot: alignment for media which has IoAlign > 1

2021-03-10 Thread Mark Kettenis
> 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) > > + %

Re: A curious case of disappearing iwx

2021-03-09 Thread Mark Kettenis
> 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:

Re: 2 diffs for dev/acpi/dsdt.c

2021-03-07 Thread Mark Kettenis
> 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

Re: 2 diffs for dev/acpi/dsdt.c

2021-03-07 Thread Mark Kettenis
> 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: > >

Re: acpi(4): pass DMA tag to ACPI tables

2021-03-06 Thread Mark Kettenis
> 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

Re: pcidump(8): add missing PCI classes

2021-03-05 Thread Mark Kettenis
> 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:

Re: Read `ps_single' once

2021-03-04 Thread Mark Kettenis
> 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

Re: Read `ps_single' once

2021-03-04 Thread Mark Kettenis
> 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

Re: Read `ps_single' once

2021-03-04 Thread Mark Kettenis
> 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,

Re: uvm: modify `uvmexp.swpgonly' atomically

2021-03-03 Thread Mark Kettenis
> 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

Re: Add /dev/video0 to fbtab

2021-02-25 Thread Mark Kettenis
> 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

Re: uvm_fault_lower refactoring

2021-02-23 Thread Mark Kettenis
> 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

Re: uvm_fault_lower refactoring

2021-02-22 Thread Mark Kettenis
> 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

Re: hppa: terminate backtrace of secondary processors

2021-02-22 Thread Mark Kettenis
> 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

Re: occasional SSIGSEGV on C++ exception handling

2021-02-20 Thread Mark Kettenis
> 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

Re: occasional SSIGSEGV on C++ exception handling

2021-02-20 Thread Mark Kettenis
> 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

Re: occasional SSIGSEGV on C++ exception handling

2021-02-19 Thread Mark Kettenis
> 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:

Re: occasional SSIGSEGV on C++ exception handling

2021-02-19 Thread Mark Kettenis
> 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 >

Re: use /dev/dri/ in xenocara

2021-02-18 Thread Mark Kettenis
> 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

Re: use /dev/dri/ in xenocara

2021-02-18 Thread Mark Kettenis
> 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:

Re: add simplepmbus(4)

2021-02-17 Thread Mark Kettenis
> 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

Re: add simplepmbus(4)

2021-02-17 Thread Mark Kettenis
> 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

Re: Posted vs. non-posted device access

2021-02-16 Thread Mark Kettenis
> 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 +

Re: Posted vs. non-posted device access

2021-02-15 Thread Mark Kettenis
> 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

Posted vs. non-posted device access

2021-02-14 Thread Mark Kettenis
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

Re: execve -1 errno 12 Cannot allocate memory

2021-01-29 Thread Mark Kettenis
> 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

Re: search usbd_interfaces in case of non-compliant device

2021-01-28 Thread Mark Kettenis
> 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

Re: vacation.1: correct .forward file example

2021-01-21 Thread Mark Kettenis
> 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

rpi4 bcmpcie(4) fix

2021-01-17 Thread Mark Kettenis
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

Re: tpm(4): don't use tvtohz(9)

2021-01-14 Thread Mark Kettenis
> 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

Re: uvm_fault: amap & anon locking

2021-01-11 Thread Mark Kettenis
> 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 &a

Re: all platforms: isolate hardclock(9) from statclock()

2021-01-09 Thread Mark Kettenis
> 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 > > > >

Re: hid_is_collection() sync with NetBSD

2021-01-09 Thread Mark Kettenis
> 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

Re: tpm(4): don't use tvtohz(9)

2021-01-08 Thread Mark Kettenis
> 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

Re: all platforms: isolate hardclock(9) from statclock()

2021-01-07 Thread Mark Kettenis
> 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

Re: rasops1

2021-01-07 Thread Mark Kettenis
> 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

Re: tpm(4): don't use tvtohz(9)

2021-01-06 Thread Mark Kettenis
> 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 >

Re: Thread local data setup and destruct

2021-01-04 Thread Mark Kettenis
> 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

Re: convert vga POST uvm_km_vallocs

2021-01-02 Thread Mark Kettenis
> 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

Re: drm(4) memory allocation diff

2021-01-01 Thread Mark Kettenis
> 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

Re: drm(4) memory allocation diff

2021-01-01 Thread Mark Kettenis
> 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 allocati

Re: uvm_fault: amap & anon locking

2020-12-31 Thread Mark Kettenis
> 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

drm(4) memory allocation diff

2020-12-31 Thread Mark Kettenis
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

Re: /dev/video* permissions

2020-12-29 Thread Mark Kettenis
> 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

Re: Thread local data setup and destruct

2020-12-29 Thread Mark Kettenis
> 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:

Re: Thread local data setup and destruct

2020-12-29