Re: xonly on amd64: testing wanted

Hi, * Theo de Raadt wrote: > Some of you have probably noticed activity about "xonly" happening > to a bunch of architectures. First arm64, then riscv64, then hppa, > and ongoing efforts with octeon, sparc64 (sun4u only), and more of this > is going to come in the future. > > Like past work

Re: Fix level-triggered ACPI GPIO interrupts on amd64

Hi Peter, * Peter Hessler wrote: > This was committed on Oct 20, and was shipped in OpenBSD 7.2. Indeed, you're quite right, thanks for the info! Since my touchpad hangs haven't improved since then it is unrelated to the change and I must be mistaken while testing. Cheers Matthias

Re: Fix level-triggered ACPI GPIO interrupts on amd64

2 17:02:41 +0200 > > > From: Matthias Schmidt > > > > > > * Matthias Schmidt wrote: > > > > Hi Mark, > > > > > > > > Addendum after 24h of testing. Your patch fixes the frequent touchpad > > > > freezes I see on th

Re: use a zero-copy approach for vmd virtio devices

Hi Dave, * Dave Voutila wrote: > While working back and forth with dlg@ on his idea of adding in async > task queues to vmd devices, he started to introduce a cleaner way to > handle virtqueues. In short, we can just track the host virtual address > and read/write to that location. > > This has

Re: Fix level-triggered ACPI GPIO interrupts on amd64

* Matthias Schmidt wrote: > Hi Mark, > > Addendum after 24h of testing. Your patch fixes the frequent touchpad > freezes I see on this model and which I reported back then in > https://marc.info/?l=openbsd-bugs=165328803822857=2 Any chance that this patch gets committed o

Re: Fix level-triggered ACPI GPIO interrupts on amd64

* Mark Kettenis wrote: > > Date: Tue, 4 Oct 2022 07:56:22 +0200 > > From: Matthias Schmidt > > > > Hi Mark, > > > > * Mark Kettenis wrote: > > > The diff below adds the hooks to disable and enable GPIO interrupts > > > for amd

Re: Fix level-triggered ACPI GPIO interrupts on amd64

Hi Mark, Addendum after 24h of testing. Your patch fixes the frequent touchpad freezes I see on this model and which I reported back then in https://marc.info/?l=openbsd-bugs=165328803822857=2 \o/ and cheers Matthias * Matthias Schmidt wrote: > Hi Mark, > > * Mark Kette

Re: Fix level-triggered ACPI GPIO interrupts on amd64

Hi Mark, * Mark Kettenis wrote: > The diff below adds the hooks to disable and enable GPIO interrupts > for amdgpio(4), aplgpio(4), bytgpio(4), chvgpio(4), glkgpio(4) and > pchgpio(4). This is similar to what I did for qcgpio(4) a few weeks > ago. This should fix potential interrupt storms

Re: ps(1): add -d (descendancy) option to display parent/child process relationships

Hi Job, * Job Snijders wrote: > Dear all, > > Some ps(1) implementations have an '-d' ('descendancy') option. Through > ASCII art parent/child process relationships are grouped and displayed. > Here is an example: > > $ ps ad -O ppid,user > PID PPID USER TT STATTIME

Re: wsmouse(4): tapping

Hi Ulf, * Ulf Brosziewski wrote: > On 5/3/22 10:03, Ulf Brosziewski wrote: > > The implementation of the tapping mechanism in wsmouse(4) has a bug > > concerning the transitions into the hold/drag state, see > > https://marc.info/... > > for details. The patch proposed in that message is

Re: [patch] CPU frequency scheduler change proposal

Hi, * Solene Rapenne wrote: > I'm proposing a very simple change to the automatic policy of the CPU > frequency scheduler. > > Currently, every 100ms the scheduler is doing this: > > - when the CPU load exceeds the threshold, CPU frequency is set to the > maximum and the variable downbeats is

Re: initial iwx(4) 11ac patch for testing

Hi Stefan, * Stefan Sperling wrote: > On Thu, Mar 10, 2022 at 12:25:17PM +0100, Stefan Sperling wrote: > > Unless anyone else finds a problem, this patch can be considered ready > > for review and commit. > > Of course, I forgot to apply my sysassert fix to the second phy context > command

Re: request for testing: malloc and large allocations

Hi Otto, * Otto Moerbeek wrote: > Hi, > > currently malloc does cache a number of free'ed regions up to 128k in > size. This cache is indexed by size (in # of pages), so it is very > quick to check. > > Some programs allocate and deallocate larger allocations in a frantic > way. Accodomate

Re: Please test: UVM fault unlocking (aka vmobjlock)

Hi Martin, * Martin Pieuchot wrote: > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote: > > Diff below unlock the bottom part of the UVM fault handler. I'm > > interested in squashing the remaining bugs. Please test with your usual > > setup & report back. > > Thanks to all the testers, here's a

Re: update iwx(4) firmware to -67

Hi Stefan, * Stefan Sperling wrote: > This patch updates iwx(4) to new firmware images (API version -67). > > Intel has published a related security advisory: > https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00509.html > > Make sure to get a fresh kernel from -current

Re: Please test: UVM fault unlocking (aka vmobjlock)

Hi Martin, * Martin Pieuchot wrote: > Diff below unlock the bottom part of the UVM fault handler. I'm > interested in squashing the remaining bugs. Please test with your usual > setup & report back. I have the diff running on a Thinkpad T450s and noticed no regessions so far. Will continue

Typo in ASN1_NULL_new.3

Hi, a typo snuck in: diff d1fa7a12c84f12c5694097e95b271ca1621a047e /usr/src blob - dc9f00b0a071ea76a3097d0cb6178c567cf20284 file + lib/libcrypto/man/ASN1_NULL_new.3 --- lib/libcrypto/man/ASN1_NULL_new.3 +++ lib/libcrypto/man/ASN1_NULL_new.3 @@ -39,7 +39,7 @@ This function does not allocate

Re: Rework UNIX sockets locking to be fine grained

Hi Vitaliy, * Vitaliy Makkoveev wrote: > Updated diff. Re-lock dances were simplified in the unix(4) sockets > layer. I am running this diff and the one before on a Thinkpad T450s which is my daily driver (office, coding, web, videos, musik, etc) and noticed no regressions so far.

Typo in ASN1_STRING_length.3

Hi, in the recent commit to ASN1_STRING_length.3 a typo sneaked in: diff 96921f4986cebab89014f4b188cc00426e2e11d8 /usr/src blob - 9d8cbf83ce75abecbc8faf0bf1fce674ef2a8abf file + lib/libcrypto/man/ASN1_STRING_length.3 --- lib/libcrypto/man/ASN1_STRING_length.3 +++

Re: better audio defaults: please test

Hi Alexandre, * Alexandre Ratchov wrote: > The current sndiod latency (minimum time between when the program > plays something and when sound reaches Joe's ears) is too large and > makes OpenBSD unpleasant to use for telephony, games, and makes > controls of video players slugish. > > The defaut

Re: iwm: initial 40Mhz channel support

Hi Stefan, * Stefan Sperling wrote: > This patch adds initial support for 40Mhz channels to the iwm driver. > > There are a few changes in net80211 to support this feature in RA and > when parsing beacons. The work for net80211 is not yet complete but > more can be done incrementally later. What

Re: vmd(8): simplify vcpu logic, removing uart & net reads

Hi Dave, * Dave Voutila wrote: > Looking for some broader testing of the following diff. It cleans up > some complicated logic predominantly left over from the early days of > vmd prior to its having a dedicated device thread. > > In summary, this diff: > > - Removes vionet "rx pending" state

Re: softraid(4) crypto/raid1c refactoring

Hi Stefan, * Stefan Sperling wrote: > Refactor softraid crypto code to allow use of a discipline-specific data > structure for RAID1C volumes, as requested by jsing@ during review of my > initial RAID1C patch. > > This patch should effectively be a cosmetic change. > The whole point of this

Re: iwm(4): Tx aggregation

Hi Stefan, * Stefan Sperling wrote: > This is another patch for Tx aggregation support in iwm(4). > I have tested 7265, 8265, and 9560, and they seem to work. > > Causes of various fatal firmware errors from my earlier attempts at > getting this to work have been identified and fixed in this

Re: net80211 RA: gather more stats per probe attempt

Hi Stefan, * Stefan Sperling wrote: > This patch tweaks the heuristic RA is using to decide whether enough > statistics have been gathered for a candidate Tx rate. The goal is to > avoid Tx rate choices that might turn out to be too optimistic. > > In my testing RA now scales upwards a little

Re: re-enable A-MSDU support with iwm(4) and iwx(4) fixed

Hi, * Stefan Sperling wrote: > On Fri, Apr 23, 2021 at 12:28:42PM +0200, Matthias Schmidt wrote: > > I had a new kernel with only your following patch running all day and > > never encountered the situation as described in my last email. > > Connection was stable and tr

Re: re-enable A-MSDU support with iwm(4) and iwx(4) fixed

Hi Stefan, * Stefan Sperling wrote: > On Thu, Apr 22, 2021 at 07:47:29PM +0200, Matthias Schmidt wrote: > > I have a kernel with your patch running since several hours and > > noticed a regression. My usual "test case" is copying several large > > files from

Re: re-enable A-MSDU support with iwm(4) and iwx(4) fixed

Hi Stefan, * Stefan Sperling wrote: > This patch adds A-MSDU rx offloading support for both iwm(4) and iwx(4) > and re-enables net80211's software A-MSDU Rx support for all 11n drivers. > > Meaning iwn(4) and athn(4) will also be receiving A-MSDUs again. > This feature has been turned off since

Typos in ssh man pages

Hi, in the recent commits to ssh(d)_config.5 two typos slipped in (looks like classic "switch vi to edit mode" typo :)). Cheers Matthias diff --git a/usr.bin/ssh/ssh_config.5 b/usr.bin/ssh/ssh_config.5 index 5202196bce5..cf7391d9ce1 100644 --- a/usr.bin/ssh/ssh_config.5 +++

Re: Add /dev/video0 to fbtab

Hi, * Marcus Glocker wrote: > On Thu, Feb 25, 2021 at 09:34:45PM +0100, Mark Kettenis wrote: > > > > > The xenodm tty should really be ttyC4 on all our architectures. I > > would suggest that anywhere where you're not sure (or have something > > different) we shouldn't add /dev/video0. People

Re: iwm(4) A-MSDU support

Hi Stefan, * Stefan Sperling wrote: > This patch attempts to add support for receiving A-MSDUs to iwm(4). > If you are using iwm(4) then please run with this patch and let me > know if it causes regressions. Thanks! Works so far fine with the following HW: iwm0 at pci2 dev 0 function 0 "Intel

Re: net80211: new Tx rate adaptation module (iwn + iwm)

Hi Stefan, * Stefan Sperling wrote: > This implements a new rate adaptation module for net80211, called "RA", > which resulted from a long discussion and exchanges of various diffs > between Christian Ehrhardt and myself, targeting problems with MiRA. > > Tests with any of the various iwn(4) and

Re: sndiod: allow mixing of duplex, record-only and play-only audio devices

Hi Edd, * Edd Barrett wrote: > Hi, > > Currently sndiod does not allow you to use alternative devices (-F > devices) which support only a subset of the modes of the main (-f) > device. > > For example, if you do `sndiod -f rsnd/0 -F rsnd/1` and: > - rsnd/0 is full-duplex (rec + play). > -

Re: kern.video.record - part 2

Hi Marcus, * Marcus Glocker wrote: > Thanks for testing Laurie. > > Otherwise I got not much feedback -- No interest in this? Yes, sure. I really like the feature since it offers an additional level of privacy when /dev/video* is not owned by root and is a perfect supplement to

Re: ntpd: go into unsynced mode

Hi Otto, * Otto Moerbeek wrote: > Hi, > > At the moment ntpd never goes into unsynced mode if network > connectivity is lost. The code to do that is only triggered when a > pakcet is received, which does not happen. > > This diff fixes that by going into unsynced mode if no time data was >

Typo in ifconfig.8

Hi, there is a typo in the Wireguard section of the ifconfig man page. Cheers Matthias diff --git a/ifconfig.8 b/ifconfig.8 index 5c4a8ad0792..4a95d644972 100644 --- a/ifconfig.8 +++ b/ifconfig.8 @@ -2148,7 +2148,7 @@ Set the allowed IPs for the peer. The allowed IPs indicate

Re: filesystem code integer and many inodes

Hi Otto, * Otto Moerbeek wrote: > > Did anyone look closer at this? > > Did anyone test? I compiled kernel + world with your diff in a VM and performed the following tests. * fdisk, disklablel, newfs of an external disk * disklabel, growfs, fsck on a partition on an external disk * fsirand on

Re: iwm(4): re-add CCMP hardware offload support

Hi Stefan, * Stefan Sperling wrote: > On Sat, May 16, 2020 at 05:41:43PM +0200, Stefan Sperling wrote: > > On Fri, May 15, 2020 at 05:02:28PM +0200, Stefan Sperling wrote: > > > This has been attempted before, but had to backed out because in some > > > cases firmware was failing to decrypt a

Re: amd64: use ffs2 for filesystems created by install

Hi Otto, * Otto Moerbeek wrote: > > Diff below fixes the issue. Snap with it is uploaded. You should be > able to upgrade yor test with it. Did the same series of tests again with your updated snap. Worked as expected! Big thanks for the update and ... cheers Matthias

Re: amd64: use ffs2 for filesystems created by install

Hi Otto, * Otto Moerbeek wrote: > Hi, > > This is amd64 only, it contains some i386 pieces, but those are > incomplete. > > With the diff, install uses ffs2 for the filesystems created during > install. All boot loaders (except the floppy one) contain support for > loading a kernel from ffs2. >

Re: Opportunistic DoT for unwind(8)

Hi Otto, * Otto Moerbeek wrote: > Hi, > > I got *very* little feedback on this request for testing. > > If not enough enough testing is done, I'll either abandon the diff or > commit it as-is, introducing bugs that could have been prevented. Both > are not good. So get going! I have your diff

Re: call if_input only once per Rx interrupt from net80211

Hi Stefan, * Stefan Sperling wrote: > > I think I see why. I forgot to convert some existing ieee80211_input() > calls to ieee80211_inputm(), in ieee80211_input.c. > These calls are related to buffered aggregated frames, so aggregated > frames triggered multiple if_input() calls per interrupt

Re: call if_input only once per Rx interrupt from net80211

Hi Stefan, * Stefan Sperling wrote: > > New diff with above changes: I tested your new diff with two different systems: * Thinkpad T450s with iwm (8265, same as yesterday) * Thinkpad X220 with iwn (6205) and on both systems I see a drastic regression compared to yesterday's patch. The

Re: call if_input only once per Rx interrupt from net80211

Hi Stefan, * Stefan Sperling wrote: > On Mon, Sep 09, 2019 at 03:10:04PM +0200, Stefan Sperling wrote: > > The wifi stack currently calls if_input once per packet instead of once > > per interrupt. To make the wifi layer play nicely with the network stack > > we can split ieee80211_input() into

Re: net80211: more steady Tx rate with MiRa (please test)

Hi, * Stefan Sperling wrote: > > This diff has no effect on management frames; it only affects transmit > rate of data frames while in assocated state; association state is > kept alive by received frames, not by frames being sent. > > I don't see how the diff could be causing either of your

Re: net80211: more steady Tx rate with MiRa (please test)

Hi, * Stefan Sperling wrote: > On Fri, Jun 14, 2019 at 01:01:58PM +0200, Matthias Schmidt wrote: > > Hi Stefan, > > > > * Stefan Sperling wrote: > > > > > > Since I am knee-deep in Tx aggregation right now, I would like to delegate > > >

Re: net80211: more steady Tx rate with MiRa (please test)

Hi Stefan, * Stefan Sperling wrote: > > Since I am knee-deep in Tx aggregation right now, I would like to delegate > testing of the diff below against plain -current to the community. > If some of you could test the diff below and report back to me I would > appreciate it. > You don't need to

Re: [patch] cwm: filter duplicate hostnames in ssh menu

Hi, * Marcus MERIGHI wrote: > > FWIW, i use "M-period" a lot... are there easy alternatives? While I really like the ssh-menu feature it does not work reliable for me here. For some servers I can establish a SSH connection, for others a xterm launches that immediately closes again. To be

Re: Harmonize examples in signify man page

Hmm, somehow a leading space snuck in. Attached is the same diff without leading space and it now applies cleanly. Cheers Matthias On 24.02.2019 22:09, Matthias Schmidt wrote: Hi, while looking at signify's man page I noticed that the names of the arguments in the EXAMPLES section

Harmonize examples in signify man page

Hi, while looking at signify's man page I noticed that the names of the arguments in the EXAMPLES section change (newkey.sec vs key.sec, etc). The diff harmonizes the examples. It makes it easier to follow the examples. Cheers Matthias diff --git signify.1 signify.1 index

Re: rework iwm(4) Tx rate selection

Hi Stefan, * Stefan Sperling wrote: > > When testing this, please compare throughput before and after this diff. > I run tcpbench -s on a host behind the AP and start a tcpbench client on > my iwm laptop. With this diff, and an 11ac AP on channel 149, tcpbench > measures up to 26 Mpbs in my

Re: slow vim and malloc

hi Stuart, * Stuart Henderson wrote: > > These settings in .vimrc make it quite noticeable > > syn > set foldmethod=syntax > set foldlevelstart=1 Totally forget about this thread. I had the same issue and the following options made vim + syntax highlighting at least a bit more usable for me.

Re: Adding current bandwidth to ftp(1)

Hi Christian, On 08.04.2018 22:42, Christian Barthel wrote: Hello, i am often sitting behind a very slow internet link and thought, it might be useful to show the current bandwidth while downloading something with ftp(1). Since I sometimes work with crappy WLANs/connections I very much

Re: inteldrm(4) tests needed

Hi, * Benjamin Baier wrote: > > Thinkpad X220 here, with an external monitor(HDMI) connected throught > a docking station. > The external monitor is now working on the first boot, before I had > to do one suspend/resume cycle to get it recognized, great. Also a Thinkpad X220 and I can confirm

Re: clean on-disk filesystems through {suspend,hibernate}/resume

Hi, * Theo de Raadt wrote: > > BTW, if anyone uses softdep *you have to tell me*, and then try > to repeat problems you encounter without softdep. That is a > totally different problem set. Yes, I am using softdep. For testing, I removed softdep and performed all tests again and run the

Re: clean on-disk filesystems through {suspend,hibernate}/resume

Hi, * Theo de Raadt wrote: > > I would appreciate reports, and later I'll cut this into pieces and > commit incremental changes. I run four tests on an Intel NUC with softraid CRYPTO and a keydisk. Although the sync+suspend does not finish in one test it is definitely am improvement and your

Re: Properly sync filesystems during {suspend,hibernate}/resume

Hi, * Theo de Raadt wrote: > > I'd appreciate reports about how well it delivers and if any new > problems show up. I tested the patch on an amd64 Intel NUC running softraid crypto with a keydisk. I made a lot of disk activity, suspended the system and pulled the plug. Both with and without

Re: ksh: add support for HISTCONTROL ignorespace & ignoredups

Hi Jeremie, Am 30.08.2017 13:04 schrieb Jeremie Courreges-Anglas: This implements a feature I miss from bash. What I care about: - not clog the history with repeated commands - easily prevent some commands to go in the history The diff below implements HISTCONTROL for this, user-facing