Re: xonly on amd64: testing wanted

2023-01-18 Thread Matthias Schmidt
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 decades ago (and I suppose continually also) on W^X, and
> increasing use of .rodata, the idea here is to have code (text segments)
> not be readable.  Or in a more generic sense, if you mprotect a region
> with only PROT_EXEC, it is not readable.
> 
> This has a number of nice characteristics.  It makes BROP techniques not
> work as well (when accompanied by the effects of many other migitations),
> it makes complex gadgets containing side effects harder to use (if the
> registers involved in the side effect contain pointers to code), etc etc.
> 
> But most of us have amd64 machines.  Thrilling news:
> 
> It turns out we can do this fairly modern modern 64-bit x86 machines
> from Intel and AMD, if operating in LONG mode, aka. amd64.  The cpu
> needs to have a feature called PKU.  The way this works is not 100%
> perfect, but it a serious enough hinderance.  A PKU memory key is
> instantiated for all memory which is PROT_EXEC-only, and that key is
> told to block memory reads.  Instruction reads are still permitted.  Now
> some of you may know how PKU works, so you will say that userland can
> change the behaviour and make the memory readable.  That is true.  Until
> a system call happens.  Then we force it back to blocking read.  Or a
> memory fault, we force it back.  Or an interrupt, even a clock
> interrupt.  We force it back.  Generally if an attacker is trying to
> read code it is because they don't have a lot of (turing complete or a
> subset) of flexibility and want more information.  Imagine they are able
> to generate a the "wrpkru" sequence to disable it, and then do something
> else?  My guess is if they can do two things in a row, then they already
> have power, and won't be doing this.  So this is a protection method
> against a lower-level attack construction.  The concept is this:  If you
> can bypass this to gain a tiny foothold, you would not have bothered,
> because you have more power and would be reaching higher. 
> 
> As I mention, some other architectures have crossed already, but not
> without little bits of pain.  Especially in the ports tree, where
> unprepared code is more common.  Mostly this consists of assembly language
> files that have put read-only data into the .text region, instead of into
> the .rodata (some people still haven't read the memos from around 1997).
> 
> So I'd like to recruit some help from those of you capable of building
> your own kernels.  Can you apply the following kernel diff, and try the
> applications you are used to.  A list of applications that fail on some
> way would be handy.  Be sure to ktrace -di then, and check there is a
> SIGSEGV near the end, and include a snippet of that information.
> 
> If you don't know how to do this, please don't ask for help.  Just let
> others do it.
> 
> The kernel diff isn't perfect yet, because it is less than 24 hours
> since this started working.  But it appears good enough for testing,
> while we work out the wrinkles.

I have the kernel patch running on my amd64 machine since you posted it
and noticed no regression so far.  All my programs continue to work
(terminal stuff + FF, Chrome, Tor Browser).

Cheers

Matthias
  userland   kernel
ld.so  0xa518a30d640  readable   readable  
mmap xz0xa5196f17000  unreadable unreadable
mmap x 0xa51c7907000  unreadable unreadable
mmap nrx   0xa5237b3b000  unreadable unreadable
mmap nwx   0xa51aaaea000  unreadable unreadable
mmap xnwx  0xa52074ba000  unreadable unreadable
main   0xa4f5adab490  readable   readable  
libc   0xa51da456410  readable   readable  


OpenBSD 7.2-current (GENERIC.MP) #10: Sun Jan 15 11:17:26 CET 2023
x...@kronos.xosc.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34064420864 (32486MB)
avail mem = 33012658176 (31483MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x43ca1000 (119 entries)
bios0: vendor American Megatrends International, LLC. version "N.1.15A09" date 
03/24/2022
bios0: TUXEDO TUXEDO InfinityBook Pro 14 Gen6
efi0 at bios0: UEFI 2.7
efi0: American Megatrends rev 0x50013
acpi0 at bios0: ACPI 6.2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP MCFG SSDT FIDT SSDT SSDT SSDT HPET APIC SSDT SSDT NHLT 
UEFI LPIT SSDT SSDT DBGP DBG2 SSDT DMAR SSDT SSDT BGRT PTDT WSMT FPDT
acpi0: wakeup devices PEGP(S4) PEGP(S4) PEGP(S4) PEG0(S4) PEGP(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) 
PXSX(S4) RP06(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits

Re: Fix level-triggered ACPI GPIO interrupts on amd64

2023-01-05 Thread Matthias Schmidt
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

2023-01-05 Thread Matthias Schmidt
Hi,

did anyone else on the list had the chance to test this patch?  It
really improved the touchpad hangs here.

Cheers

Matthias

* Mark Kettenis wrote:
> > Date: Thu, 13 Oct 2022 00:17:37 +0200
> > From: Mark Kettenis 
> > 
> > > Date: Mon, 10 Oct 2022 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 this model and which I reported back then in
> > > > https://marc.info/?l=openbsd-bugs=165328803822857=2
> > > 
> > > Any chance that this patch gets committed or wider testing in snaps?
> > > It really improved the touchpad situation here.
> > 
> > Right, I should probably just commit the diff instead of waiting for
> > more tests.
> > 
> > ok?
> 
> For reference, here is the diff again.
> 
> 
> Index: dev/acpi/amdgpio.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/amdgpio.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 amdgpio.c
> --- dev/acpi/amdgpio.c27 Jun 2022 08:00:31 -  1.9
> +++ dev/acpi/amdgpio.c3 Oct 2022 19:10:03 -
> @@ -92,6 +92,8 @@ const char *amdgpio_hids[] = {
>  int  amdgpio_read_pin(void *, int);
>  void amdgpio_write_pin(void *, int, int);
>  void amdgpio_intr_establish(void *, int, int, int (*)(void *), void *);
> +void amdgpio_intr_enable(void *, int);
> +void amdgpio_intr_disable(void *, int);
>  int  amdgpio_pin_intr(struct amdgpio_softc *, int);
>  int  amdgpio_intr(void *);
>  void amdgpio_save_pin(struct amdgpio_softc *, int pin);
> @@ -163,6 +165,8 @@ amdgpio_attach(struct device *parent, st
>   sc->sc_gpio.read_pin = amdgpio_read_pin;
>   sc->sc_gpio.write_pin = amdgpio_write_pin;
>   sc->sc_gpio.intr_establish = amdgpio_intr_establish;
> + sc->sc_gpio.intr_enable = amdgpio_intr_enable;
> + sc->sc_gpio.intr_disable = amdgpio_intr_disable;
>   sc->sc_node->gpio = >sc_gpio;
>  
>   printf(", %d pins\n", sc->sc_npins);
> @@ -275,6 +279,32 @@ amdgpio_intr_establish(void *cookie, int
>   if ((flags & LR_GPIO_POLARITY) == LR_GPIO_ACTBOTH)
>   reg |= AMDGPIO_CONF_ACTBOTH;
>   reg |= (AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
> + bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
> +}
> +
> +void
> +amdgpio_intr_enable(void *cookie, int pin)
> +{
> + struct amdgpio_softc *sc = cookie;
> + uint32_t reg;
> +
> + KASSERT(pin >= 0 && pin != 63 && pin < sc->sc_npins);
> +
> + reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, pin * 4);
> + reg |= (AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
> + bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
> +}
> +
> +void
> +amdgpio_intr_disable(void *cookie, int pin)
> +{
> + struct amdgpio_softc *sc = cookie;
> + uint32_t reg;
> +
> + KASSERT(pin >= 0 && pin != 63 && pin < sc->sc_npins);
> +
> + reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, pin * 4);
> + reg &= ~(AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
>   bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
>  }
>  
> Index: dev/acpi/aplgpio.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/aplgpio.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 aplgpio.c
> --- dev/acpi/aplgpio.c6 Apr 2022 18:59:27 -   1.5
> +++ dev/acpi/aplgpio.c3 Oct 2022 19:10:03 -
> @@ -76,6 +76,8 @@ const char *aplgpio_hids[] = {
>  int  aplgpio_read_pin(void *, int);
>  void aplgpio_write_pin(void *, int, int);
>  void aplgpio_intr_establish(void *, int, int, int (*)(void *), void *);
> +void aplgpio_intr_enable(void *, int);
> +void aplgpio_intr_disable(void *, int);
>  int  aplgpio_intr(void *);
>  
>  int
> @@ -150,6 +152,8 @@ aplgpio_attach(struct device *parent, st
>   sc->sc_gpio.read_pin = aplgpio_read_pin;
>   sc->sc_gpio.write_pin = aplgpio_write_pin;
>   sc->sc_gpio.intr_establish = aplgpio_intr_establish;
> + sc->sc_gpio.intr_enable = aplgpio_intr_enable;
> + sc->sc_gpio.intr_disable = aplgpio_intr_disable;
>   sc->sc_node->gpio = >sc_gpio;
>  
>   /* Mask and clear all interrupts. */
> @@ -227,6 +231,36 @@ aplgpio_intr_establish(void *cookie, int
>   reg = bus_space_read_4(sc->sc_memt, sc->sc_memh,
>   AP

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

2022-12-23 Thread Matthias Schmidt
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 the benefit of cleaning up a good chunk of code, mostly in the
> vioscsi device. If my count is correct, it's close to 100 lines
> removed.
> 
> Testing on a variety of systems, I see anywhere from a small (5%) to a
> large (50%) gain in things like vionet performance depending on the host
> hardware and the guest OS. (Linux guests push packets faster, on
> average.)
> 
> If/when this lands, it'll be easier to introduce the async taskq diff
> and also clean up more of the virtio codebase. Lots of duplicate logic
> in basic virtio-pci config handling, like updating queue address or
> size.
> 
> Testing is appreciated, but also looking for OKs.

I have your patch running on -current with OpenBSD -current, -stable and
Linux (voidlinux) guests.  Stable so far, no regressions and Linux "seems"
faster.

Cheers

Matthias



Re: Fix level-triggered ACPI GPIO interrupts on amd64

2022-10-10 Thread Matthias Schmidt
* 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 or wider testing in snaps?
It really improved the touchpad situation here.

Cheers

Matthias



Re: Fix level-triggered ACPI GPIO interrupts on amd64

2022-10-04 Thread Matthias Schmidt
* 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 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 related to
> > > level-triggered interrupts.
> > > 
> > > I can't really test this myself.  But if you have a machine with a
> > > line like this:
> > > 
> > > ihidev0 at iic7 addr 0x2c gpio 18, vendor 0x6cb product 0x8253, SYNA2B43
> > 
> > I have a Tuxedo Infinitbook with the following:
> > 
> > ihidev0 at iic1 addr 0x2c gpio 327, vendor 0x93a product 0x255, UNIW0001
> > 
> > > that contains the string "gpio", please give this a shot and check
> > > whether your keyboard and touchpad still work with it and report back
> > > with a fullk dmesg.
> > 
> > I can confirm that both devices still work as expected.  However, the
> > spdmem device is "gone".  Here's a diff between dmesg before and after
> 
> That is strange; I don't really see how this would happen.
> 
> >  ichiic0 at pci0 dev 31 function 4 "Intel 500 Series SMBus" rev 0x20: apic 
> > 2 int 16
> >  iic2 at ichiic0
> >  ...
> > -spdmem0 at iic2 addr 0x52: 32GB DDR4 SDRAM PC4-25600 SO-DIMM
> > +"eeprom" at iic2 addr 0x52 not configured
> 
> So an EEPROM of some sort is still detected; it just isn't detected as
> an SPD EEPROM anymore.  Have you seen this happening before?  Is there
> a difference between a cold and a warm boot?

I have never seen this before, I wouldn't have noticed it if I hadn't
prepare the dmesg diff.

I did several cold and a warm boots and now spdmem is always correctly
recognized:

--- dmesg.warm  Tue Oct  4 22:01:24 2022
+++ dmesg.cold  Tue Oct  4 22:04:25 2022
@@ -32,7 +32,7 @@
 cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 12MB 64b/line 12-way L3 cache
 cpu1: smt 0, core 1, package 0
 cpu2 at mainbus0: apid 4 (application processor)
-cpu2: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.12 MHz, 06-8c-01
+cpu2: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.11 MHz, 06-8c-01
 cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
 cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 12MB 64b/line 12-way L3 cache
 cpu2: smt 0, core 2, package 0
@@ -174,7 +174,7 @@
 audio0 at azalia0
 ichiic0 at pci0 dev 31 function 4 "Intel 500 Series SMBus" rev 0x20: apic 2 
int 16
 iic2 at ichiic0
-iic2: addr 0x20 01=80 03=52 08=63 09=64 0c=7f 15=30 16=39 19=14 1b=45 1d=08 
1e=02 21=a1 24=ff 25=92 26=5b 2d=6a 2e=01 2f=73 30=df 35=26 36=22 38=f6 3a=80 
3b=80 3c=80 3d=80 3e=80 3f=80 55=c0 58=24 6d=08 6e=1d 6f=70 70=32 72=07 73=15 
74=20 75=06 78=02 79=02 7a=20 7e=e0 88=96 8b=2d 8c=25 8d=41 96=0f 97=01 b0=28 
b1=0c b2=25 b4=42 b5=21 b6=09 b7=42 b8=80 bb=15 bd=bc be=7a bf=40 c0=13 c1=04 
c2=81 c3=0a c4=19 c5=14 c6=05 c7=81 c8=38 ca=03 cc=db cd=32 ce=06 cf=c8 d0=1f 
d1=48 d2=19 d3=48 d4=13 d5=64 d6=09 d7=24 d8=08 d9=39 da=03 db=7a dc=03 dd=7a 
de=e7 df=05 e0=0a e1=a0 e2=0a e3=1a e4=10 e5=a1 e6=30 e8=0a e9=7b ea=a4 ee=1c 
ef=41 f0=14 f1=5d f2=1e f3=78 f5=1e f6=d0 f7=59 f8=64 f9=e2 fa=43 fb=b2 fc=80 
fd=03 fe=af ff=ff words 00=00d5 01=8037 02= 03=5200 04= 05= 06= 
07=
+iic2: addr 0x20 01=80 03=52 08=63 09=64 0c=7f 15=30 16=39 19=14 1b=45 1d=08 
1e=02 21=a1 24=ff 25=92 26=5b 2d=6a 2e=01 2f=73 30=df 35=26 36=22 38=f6 3a=80 
3b=80 3c=80 3d=80 3e=80 3f=80 55=c0 58=24 6d=08 6e=1b 6f=70 70=32 72=07 73=15 
74=20 75=06 78=02 79=02 7a=20 7e=e0 88=96 8b=2d 8c=24 8d=47 96=0f b0=28 b1=0c 
b2=25 b4=42 b5=21 b6=09 b7=42 b8=80 bb=15 bd=bc be=7a bf=40 c0=13 c1=04 c2=81 
c3=0a c4=19 c5=14 c6=05 c7=81 c8=38 ca=03 cc=db cd=32 ce=06 cf=c8 d0=1f d1=48 
d2=19 d3=48 d4=13 d5=64 d6=09 d7=24 d8=08 d9=39 da=03 db=7a dc=03 dd=7a de=e7 
df=05 e0=0a e1=a0 e2=0a e3=1a e4=10 e5=a1 e6=30 e8=0a e9=7b ea=a4 ee=1c ef=41 
f0=14 f1=5d f2=1e f3=78 f5=1e f6=d0 f7=59 f8=64 f9=e2 fa=43 fb=b2 fc=80 fd=03 
fe=af ff=ff words 00=00d5 01=8037 02= 03=5200 04= 05= 06= 
07=
 spdmem0 at iic2 addr 0x52: 32GB DDR4 SDRAM PC4-25600 SO-DIMM
 "Intel 500 Series SPI" rev 0x20 at pci0 dev 31 function 5 not configured
 isa0 at pcib0



Re: Fix level-triggered ACPI GPIO interrupts on amd64

2022-10-04 Thread Matthias Schmidt
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 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 related to
> > level-triggered interrupts.
> > 
> > I can't really test this myself.  But if you have a machine with a
> > line like this:
> > 
> > ihidev0 at iic7 addr 0x2c gpio 18, vendor 0x6cb product 0x8253, SYNA2B43
> 
> I have a Tuxedo Infinitbook with the following:
> 
> ihidev0 at iic1 addr 0x2c gpio 327, vendor 0x93a product 0x255, UNIW0001
> 
> > that contains the string "gpio", please give this a shot and check
> > whether your keyboard and touchpad still work with it and report back
> > with a fullk dmesg.
> 
> I can confirm that both devices still work as expected.  However, the
> spdmem device is "gone".  Here's a diff between dmesg before and after



Re: Fix level-triggered ACPI GPIO interrupts on amd64

2022-10-03 Thread Matthias Schmidt
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 related to
> level-triggered interrupts.
> 
> I can't really test this myself.  But if you have a machine with a
> line like this:
> 
> ihidev0 at iic7 addr 0x2c gpio 18, vendor 0x6cb product 0x8253, SYNA2B43

I have a Tuxedo Infinitbook with the following:

ihidev0 at iic1 addr 0x2c gpio 327, vendor 0x93a product 0x255, UNIW0001

> that contains the string "gpio", please give this a shot and check
> whether your keyboard and touchpad still work with it and report back
> with a fullk dmesg.

I can confirm that both devices still work as expected.  However, the
spdmem device is "gone".  Here's a diff between dmesg before and after

--- dmesg.now   Mon Oct  3 22:22:11 2022
+++ dmesg.beforeMon Oct  3 22:16:16 2022
@@ -1,7 +1,7 @@
-OpenBSD 7.2-current (GENERIC.MP) #9: Mon Oct  3 22:18:38 CEST 2022
-x...@kronos.xosc.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
+OpenBSD 7.2-current (GENERIC.MP) #759: Sat Oct  1 22:48:03 MDT 2022
+dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 34064420864 (32486MB)
-avail mem = 33014628352 (31485MB)
+avail mem = 33014640640 (31485MB)
 random: good seed from bootblocks
 mpath0 at root
 scsibus0 at mpath0: 256 targets
@@ -32,12 +32,12 @@
 cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 12MB 64b/line 12-way L3 cache
 cpu1: smt 0, core 1, package 0
 cpu2 at mainbus0: apid 4 (application processor)
-cpu2: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.12 MHz, 06-8c-01
+cpu2: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.14 MHz, 06-8c-01
 cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
 cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 12MB 64b/line 12-way L3 cache
 cpu2: smt 0, core 2, package 0
 cpu3 at mainbus0: apid 6 (application processor)
-cpu3: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.12 MHz, 06-8c-01
+cpu3: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.11 MHz, 06-8c-01
 cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
 cpu3: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 12MB 64b/line 12-way L3 cache
 cpu3: smt 0, core 3, package 0
@@ -80,7 +80,7 @@
 acpibtn1 at acpi0: PWRB
 "PNP0C14" at acpi0 not configured
 "PNP0C14" at acpi0 not configured
-acpiac0 at acpi0: AC unit online
+acpiac0 at acpi0: AC unit offline
 acpibat0 at acpi0: BAT0 model "standard" serial 1 type LiON oem "OEM"
 acpibtn2 at acpi0: LID1
 "PNP0C14" at acpi0 not configured
@@ -174,8 +174,8 @@
 audio0 at azalia0
 ichiic0 at pci0 dev 31 function 4 "Intel 500 Series SMBus" rev 0x20: apic 2 
int 16
 iic2 at ichiic0
-iic2: addr 0x20 01=80 03=52 08=63 09=64 0c=7f 15=30 16=39 19=14 1b=45 1d=08 
1e=02 21=a1 24=ff 25=92 26=5b 2d=6a 2e=01 2f=73 30=df 35=26 36=22 38=f6 3a=80 
3b=80 3c=80 3d=80 3e=80 3f=80 55=c0 58=24 6d=08 6e=1b 6f=70 70=33 72=07 73=15 
74=20 75=06 78=02 79=02 7a=20 7e=e0 88=96 8b=2d 8c=25 8d=45 96=0f 97=01 b0=28 
b1=0c b2=25 b4=42 b5=21 b6=09 b7=42 b8=80 bb=15 bd=bc be=7a bf=40 c0=13 c1=04 
c2=81 c3=0a c4=19 c5=14 c6=05 c7=81 c8=38 ca=03 cc=db cd=32 ce=06 cf=c8 d0=1f 
d1=48 d2=19 d3=48 d4=13 d5=64 d6=09 d7=24 d8=08 d9=39 da=03 db=7a dc=03 dd=7a 
de=e7 df=05 e0=0a e1=a0 e2=0a e3=1a e4=10 e5=a1 e6=30 e8=0a e9=7b ea=a4 ee=1c 
ef=41 f0=14 f1=5d f2=1e f3=78 f5=1e f6=d0 f7=59 f8=64 f9=e2 fa=43 fb=b2 fc=80 
fd=03 fe=af ff=ff words 00=00d5 01=8037 02= 03=5200 04= 05= 06= 
07=
-"eeprom" at iic2 addr 0x52 not configured
+iic2: addr 0x20 01=80 03=52 08=63 09=64 0c=7f 15=30 16=39 19=14 1b=45 1d=08 
1e=02 21=a1 24=ff 25=92 26=5b 2d=6a 2e=01 

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

2022-09-01 Thread Matthias Schmidt
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 COMMAND
> 18180 12529 job  pb  I+p  0:00.01 `-- -sh (sh)
> 26689 56460 job  p3  Ip   0:00.01   `-- -ksh (ksh)
>  5153 26689 job  p3  I+p  0:40.18 `-- mutt
> 62046 25272 job  p4  Sp   0:00.25   `-- -ksh (ksh)
> 61156 62046 job  p4  R+/0 0:00.00 `-- ps -ad -O ppid
> 26816  2565 job  p5  Ip   0:00.01   `-- -ksh (ksh)
> 79431 26816 root p5  Ip   0:00.16 `-- /bin/ksh
> 43915 79431 _rpki-cl p5  S+pU 0:06.97   `-- rpki-client
> 70511 43915 _rpki-cl p5  I+pU 0:01.26 |-- rpki-client: parser 
> (rpki-client)
> 96992 43915 _rpki-cl p5  I+pU 0:00.00 |-- rpki-client: rsync 
> (rpki-client)
> 49160 43915 _rpki-cl p5  S+p  0:01.52 |-- rpki-client: http 
> (rpki-client)
> 99329 43915 _rpki-cl p5  S+p  0:03.20 `-- rpki-client: rrdp 
> (rpki-client)
> 
> The functionality is similar to pstree(1) in the ports collection.
> 
> The below changeset borrows heavily from the following two
> implementations:
> 
> 
> https://github.com/freebsd/freebsd-src/commit/044fce530f89a819827d351de364d208a30e9645.patch
> 
> https://github.com/NetBSD/src/commit/b82f6d00d93d880d3976c4f1e88c33d88a8054ad.patch
> 
> Thoughts?

As someone who is running two OpenBSD based multi-user systems I would
love to see this feature integrated.  From time to time I investigate
processes/scripts from users and seeing the process tree without
additional tools like htop would really be appreciated.

Cheers

Matthias



Re: wsmouse(4): tapping

2022-05-13 Thread Matthias Schmidt
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 obsolete.  I've
> > been made aware that there is another problem, the transition only
> > works with left-button taps.
> > 
> > This patch merges tap detection and the handling of hold/drag states,
> > which is a cleaner and more generic approach.  It fixes the problems
> > mentioned above, and it permits a better synchronization of button
> > states when tap inputs and the use of hardware buttons are mixed.
> > 
> > OK?

I tested your patch on a Thinkpad T450s and all functions (1/2/3 finger
tapping) work as before.  Addtionally, I can now use xterm's menu (Ctrl
+ left/right click) without using the physical mouse buttons.  So IMO a
great improvement for touchpad users not having physical buttons.

Cheers and thanks

Matthias



Re: [patch] CPU frequency scheduler change proposal

2022-03-21 Thread Matthias Schmidt
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 set to 5.
> - when the CPU load is below the threshold, downbeats is decremented, if
>   it's == 0 then the CPU load is reduced to 0
> 
> my proposal is to change the downbeat to be adaptive to the load, instead
> of setting it to 5 all the time, I propose to increment it with a limit
> of 5. Instead of having the frequency set at max for 500ms (5 cycles)
> every time the CPU usage is above the treshold, we will keep the
> frequency high for a number of cycles depending how long it was high
> (up to 5). So, in case of short CPU usage burst like opening a new MP3
> file for decoding or a click on a GUI, we have a frequency burst of
> 100ms instead of 500ms.
> 
> I've been using it for a few days, I noticed a huge battery life
> improvement with no responsiveness change.

I have the patch running since the weekend (when it was first shared)
and noticed that my CPU on battery spins up less often than before.  I
have the feeling that my battery lasts longer, however, I need to do
some more measurements to have a proof.

Cheers

Matthias



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

2022-03-10 Thread Matthias Schmidt
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 function...  Fixed here.

I have this patch (and the previous ones as well) running on the
following HW connected to a Fritzbox 7560 which reports that the Thinkpad
is connected via 80MHz and 11ac.

iwx0 at pci2 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix
iwx0: hw rev 0x340, fw ver 67.8f59b80b.0, address bc:f1:71:cf:3d:f7

iwx0: flags=8943 mtu 1500
lladdr 50:7b:9d:73:aa:8a
index 2 priority 4 llprio 3
trunk: trunkdev trunk0
groups: wlan
media: IEEE802.11 autoselect (VHT-MCS3 mode 11ac)
status: active
ieee80211: join karlsruhe.v01d chan 44 bssid cc:ce:1e:8b:cf:d1 56% 
wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp

So far all is stable and the speed difference is measureable.
Previously, the max speed I had was around 17M/s, with the patch I get
around 25M/s.

Cheers and thanks for the work!

Matthias



Re: request for testing: malloc and large allocations

2022-01-13 Thread Matthias Schmidt
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 those programs by also keeping a cache of regions
> betwen 128k and 2M, in a cache of variable sized regions.
> 
> My test case speeds up about twice. A make build gets a small speedup.
> 
> This has been tested by myself on amd64 quite intensively. I am asking
> for more tests, especialy on more "exotic" platforms. I wil do arm64
> myself soon.  Test can be running your favorite programs, doing make
> builds or running tests in regress/lib/libc/malloc.

I have your patch running on an amd64 Thinkpad T450s with usual desktop
usage and noticed no regression so far.

Cheers

Matthias



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

2021-12-01 Thread Matthias Schmidt
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 new version that includes a bug fix.

As with the last patch, this one also works fine on my amd64 system.
dmesg in my last message in the thread.

Cheers

Matthias



Re: update iwx(4) firmware to -67

2021-11-27 Thread Matthias Schmidt
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 sources and update
> to iwx-firmware-20211101 with fw_update before trying this patch.
> The new firmware version shows as "fw ver 67.8f59b80b.0" in dmesg.
> I have tested on AX200 and AX201 and I am not seeing any issues.
> 
> iwx(4) devices which are using the iwx-Qu-c0-hr-b0-63 image did
> not receive a firmware update. I cannot tell why.

Tested on the following device and works totally flawlessly here!

iwx0: hw rev 0x340, fw ver 67.8f59b80b.0, address 48:51:c5:0e:3e:68
iwx0 at pci2 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix

Cheers

Matthias

> ok?
> 
>  
> diff 777a5184786f624f57b85b8460919a1130498508 
> 1d9e5ec96bf733cdb7c339f7179b945ff1e0a937
> blob - 1d87b3522c60081eac0b0f54cdd772984de4b340
> blob + d48e22237cb568cb0bed6a49e82d3be6d4744da4
> --- sys/dev/pci/if_iwx.c
> +++ sys/dev/pci/if_iwx.c
> @@ -9266,7 +9266,7 @@ iwx_attach(struct device *parent, struct device *self,
>  
>   switch (PCI_PRODUCT(pa->pa_id)) {
>   case PCI_PRODUCT_INTEL_WL_22500_1:
> - sc->sc_fwname = "iwx-cc-a0-63";
> + sc->sc_fwname = "iwx-cc-a0-67";
>   sc->sc_device_family = IWX_DEVICE_FAMILY_22000;
>   sc->sc_integrated = 0;
>   sc->sc_ltr_delay = IWX_SOC_FLAGS_LTR_APPLY_DELAY_NONE;
> @@ -9283,7 +9283,7 @@ iwx_attach(struct device *parent, struct device *self,
>   return;
>   }
>  
> - sc->sc_fwname = "iwx-QuZ-a0-hr-b0-63";
> + sc->sc_fwname = "iwx-QuZ-a0-hr-b0-67";
>   sc->sc_device_family = IWX_DEVICE_FAMILY_22000;
>   sc->sc_integrated = 1;
>   sc->sc_ltr_delay = IWX_SOC_FLAGS_LTR_APPLY_DELAY_200;
> 



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

2021-11-24 Thread Matthias Schmidt
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 running the diff the next days.  Upon boot there was
a lock order reversal in dmesg:

witness: lock order reversal:
 1st 0xfd8351602630 uobjlk (>vmobjlock)
 2nd 0x80e53300 objmm (>mm.lock)
lock order ">mm.lock"(rwlock) -> ">vmobjlock"(rwlock) first seen at:
#0  rw_enter+0x65
#1  uvm_obj_wire+0x46
#2  shmem_get_pages+0xaf
#3  __i915_gem_object_get_pages+0x9d
#4  i915_vma_pin_ww+0x49b
#5  i915_ggtt_pin+0x61
#6  intel_execlists_submission_setup+0x3b2
#7  intel_engines_init+0x2ff
#8  intel_gt_init+0x133
#9  i915_gem_init+0xa3
#10 i915_driver_probe+0x75a
#11 inteldrm_attachhook+0x45
#12 config_process_deferred_mountroot+0x6b
#13 main+0x743
lock order ">vmobjlock"(rwlock) -> ">mm.lock"(rwlock) first seen at:
#0  rw_enter+0x65
#1  __i915_gem_object_get_pages+0x30
#2  i915_gem_fault+0x1aa
#3  drm_fault+0x156
#4  uvm_fault+0x179
#5  upageflttrap+0x62
#6  usertrap+0x18b
#7  recall_trap+0x8

Cheers

Matthias

OpenBSD 7.0-current (GENERIC.MP) #4: Wed Nov 24 15:33:37 CET 2021
x...@sigma.xosc.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 12765257728 (12173MB)
avail mem = 12262477824 (11694MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (65 entries)
bios0: vendor LENOVO version "JBET73WW (1.37 )" date 08/14/2019
bios0: LENOVO 20BX0049GE
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI DMAR
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.41 MHz, 06-3d-04
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.16 MHz, 06-3d-04
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.17 MHz, 06-3d-04
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.16 MHz, 06-3d-04
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 

Typo in ASN1_NULL_new.3

2021-11-22 Thread Matthias Schmidt
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 memory and cannot fail
 .Pp
 .Fn ASN1_NULL_free
 has no effect whatsoever.
-In particular, i ignores the
+In particular, it ignores the
 .Fa val_in
 argument and does not free any memory.
 In normal use, application programs only pass the invalid pointer



Re: Rework UNIX sockets locking to be fine grained

2021-11-20 Thread Matthias Schmidt
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.  Suspend/resume cycles included.

Not sure if that fits the tests/testers you need so let me know if I
should look for/do something special.

Cheers

Matthias


OpenBSD 7.0-current (GENERIC.MP) #3: Sat Nov 20 15:12:39 CET 2021
x...@sigma.xosc.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 12765257728 (12173MB)
avail mem = 12362416128 (11789MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (65 entries)
bios0: vendor LENOVO version "JBET73WW (1.37 )" date 08/14/2019
bios0: LENOVO 20BX0049GE
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI DMAR
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.42 MHz, 06-3d-04
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.16 MHz, 06-3d-04
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.17 MHz, 06-3d-04
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.16 MHz, 06-3d-04
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
acpibat0 at acpi0: BAT0 model "45N" serial 16646 type LiP oem "SONY"
acpibat1 at acpi0: BAT1 model "45N1777" serial   410 type LION oem "SANYO"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0: version 1.0
tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0xfed4/0x5000, device 0x104a rev 0x4e
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"INT340F" at acpi0 not configured
acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), 

Typo in ASN1_STRING_length.3

2021-11-14 Thread Matthias Schmidt
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
+++ lib/libcrypto/man/ASN1_STRING_length.3
@@ -346,7 +346,7 @@ returns a number of bytes.
 and
 .Fn ASN1_STRING_copy
 return 1 on success or 0 on failure.
-They fail is memory allocation fails.
+They fail if memory allocation fails.
 .Fn ASN1_STRING_set
 and
 .Fn ASN1_OCTET_STRING_set



Re: better audio defaults: please test

2021-11-06 Thread Matthias Schmidt
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 latency (of 160ms) was set ~10 years ago to workaround
> various problems: KERNEL_LOCK used to block audio processing for very
> long, azalia(4) and uaudio(4) were unable to recover after an error,
> which aggravated the problem.
> 
> The kernel improved a lot the last decade and such large buffers are
> not necessary anymore. I think something between 20ms and 40ms is a
> better default for the average OpenBSD system:
> 
>  * audio-conferencing software and games requires no sndiod_flags
>tweaks anymore
> 
>  * on modern machines (like my 7 years old i5-2500K) building a kernel
>doesn't make audio stutterer
> 
>  * sndiod_flags tweaks will still be needed for:
>   - very slow or overloaded machines used for audio
>   - machines running heavy/bogus SMM code
>   - real-time synths & effects (20ms is still too small)
> 
> Please try to switch you system to 40ms buffers (i.e. 1920 samples at
> the default 48kHz rate), for instance either apply diff below or
> simply do:
> 
>   rcctl set sndiod flags -z 480 -b 1920
>   rcctl restart sndiod

I have sndiod on -current with this flag running and it quite makes a
difference.  Audio stutters when having a movie running and reloading
some JS heavy websites in parallel are gone.  So quite a good
improvement!

Cheers

Matthias



Re: iwm: initial 40Mhz channel support

2021-10-09 Thread Matthias Schmidt
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 is missing in particular
> is integration with ifconfig to display the use of a 40 MHz channel.
> 
> And there is no way to force 40 MHz off at the client side yet.
> If the AP announces support for 40MHz we will always use it. Whether or
> not we'll need an override to handle some edge case remains to be seen.
> 
> Please test this on any supported iwm(4) device. Thanks!

Running this diff on

iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
iwm0: hw rev 0x230, fw ver 36.ca7b901d.0, address 7c:2a:31:4d:1c:b9

and noticed no regression so far.  I checked with

tcpdump -n -i iwm0 -v -y IEEE802_11_RADIO -s 4096 type mgt and subtype beacon

and I am on a 20MHz channel.  According to my Fritzbox all 2.4Ghz
clients are on 20Mhz and the 11ac clients are on 80Mhz.

Cheers

Matthias



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

2021-07-03 Thread Matthias Schmidt
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 handling and removes the code path
>   for the vcpu thread to possibly take control of the virtio net device
>   and attempt a read of the underlying tap(4). (virtio.{c,h}, vm.c)
> 
> - Removes ns8250 "rcv pending" state handling and removes the code path
>   for the vcpu thread to read the pty via com_rcv(). (ns8250.{c,h})
> 
> In both of the above cases, the event handling thread will be notified
> of readable data and deal with it.
> 
> Why remove them? The logic is overly complicated and hard to reason
> about for zero gain. (This diff results in no intended functional
> change.) Plus, some of the above logic I helped add to deal with the
> race conditions and state corruption over a year ago. The logic was
> needed once upon a time, but shouldn't be needed at present.
> 
> I've had positive testing feedback from abieber@ so far with at least
> the ns8250/uart diff, but want to cast a broader net here with both
> before either part is committed. I debated splitting these up, but
> they're thematically related.

I have the diff running since one week on -current with stable/current
and an Archlinux guest and have noticed no regression so far.

Cheers

Matthias



Re: softraid(4) crypto/raid1c refactoring

2021-05-01 Thread Matthias Schmidt
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 patch is to allow the data structure changes
> made here in softraidvar.h.
> 
> It works in my testing but more testing would be very welcome, given
> that this touches the disk I/O path of machines using softraid crypto.

I tested the patch on an Thinkpad X250 with two softraid encrypted disks
(one containing all partitions except /home, the other one solely for
/home mounted with rc.local).  Cold and warm reboots work, suspend2ram
works).

Cheers

Matthias

OpenBSD 6.9-current (GENERIC.MP) #2: Sat May  1 10:47:45 CEST 2021
x...@epsilon.xosc.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17059979264 (16269MB)
avail mem = 16527515648 (15761MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xacbfd000 (64 entries)
bios0: vendor LENOVO version "N10ET61W (1.40 )" date 03/17/2020
bios0: LENOVO 20CM004VMN
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM BATB FPDT UEFI BGRT DMAR
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.44 MHz, 06-3d-04
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.16 MHz, 06-3d-04
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
acpibat0 at acpi0: BAT0 model "45N1113" serial  1370 type LION oem "LGC"
acpibat1 at acpi0: BAT1 model "45N1735" serial   745 type LION oem "LGC"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0: version 1.0
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"INT340F" at acpi0 not configured
acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1
acpipwrres1 at acpi0: NVP3, resource for PEG_
acpipwrres2 at acpi0: NVP2, resource for PEG_
acpitz0 at acpi0: critical temperature is 128 degC
acpivideo0 at acpi0: VID_
acpivout0 at acpivideo0: LCD0
acpivideo1 at acpi0: VID_
cpu0: using VERW MDS workaround (except on vmm entry)
cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2201, 2200, 2100, 2000, 1800, 1700, 
1600, 1500, 1300, 1200, 1100, 1000, 900, 700, 600, 500 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 5G Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 5500" rev 0x09
drm0 at inteldrm0
inteldrm0: msi, BROADWELL, gen 8
azalia0 at pci0 dev 3 function 0 "Intel Core 5G HD Audio" rev 0x09: msi
azalia0: No codecs found
xhci0 at pci0 dev 20 function 0 "Intel 9 Series xHCI" rev 0x03: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" 

Re: iwm(4): Tx aggregation

2021-04-30 Thread Matthias Schmidt
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 version.
> In particular, the AP starting and stopping Tx BA sessions repeatedly
> was causing firmware crashes. And a frame header padding issue which
> caused firmware crashes on 9k devices has been fixed.
> 
> In my testing, tcpbench reports up to 100 Mbit/s both ways against
> a pepwave 11ac AP, and games/chaiki is running smoothly at 720p.
> 
> Tests on all types of iwm devices are welcome.

I did the usual test on a 8265 and noticed no regression.  Even better,
transfer speed has never been higher!  Previously I was happy when I got
around 4M/s, with the patch I get > 8M/s.

Awesome piece of work!

Cheers and thanks

Matthias



Re: net80211 RA: gather more stats per probe attempt

2021-04-29 Thread Matthias Schmidt
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 bit more slowly while the
> distance towards the AP is decreasing. The difference is not huge and
> taking the extra time to gather more reliable stats should be worth it.
> 
> In practice this only affects the case where we probe upwards. If the
> current Tx rate starts seeing loss we will still scale down very quickly.
> 
> Tests on iwn, iwm, and athn would be appreciated.

I have the patch running on the following hardware since you sent it and
noticed no regression:

iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
iwm0: hw rev 0x230, fw ver 34.0.1, address

Cheers

Matthias



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

2021-04-24 Thread Matthias Schmidt
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 transfer rates remained around 3MB/s.  This is
> > less then the rates mentioned in your recent email but I rarely get
> > higher speeds.  So I assume it is to my environment and has nothing to
> > do with the patch.
> 
> Ok. Thanks for spending the time to check this thoroughly. I have already
> made myself spend many hours debugging ghosts after test observations like
> this, many many times :-) So I've become careful about quickly drawing
> conclusions from observations like this. Wifi is complicated and as far
> as I know nobody is ever testing OpenBSD wifi patches in an RF-isolated lab.
> 
> Many problem reports I receive (and many of those arrive in private
> email, unfortunately) boil down to "it doesn't work when the cafe downstairs
> fills up with laptops and phones at lunch time" or "it only becomes slow
> when two or more laptops are doing video calls at the same time".
> The problem is that sometimes there are bugs to fix or missing features to
> implement in situations like this, so I cannot just dismiss such reports
> outright. But dealing with them can take a huge amount of time.
> To be honest, I wouldn't consider your problem a blocking issue. I would
> first wait to see if the exact same issue pops up elsewhere after the
> patch lands in the tree.

Seems I hit a byzantine situation like that.  I had the patch running on
the T450s with the 8265 and additionally on a X250 with the following
hardware all evening and morning (including suspend/resume cycles) and
it worked as expected.

iwm0 at pci2 dev 0 function 0 "Intel AC 7265" rev 0x59, msi
iwm0: hw rev 0x210, fw ver 17.3216344376.0, address

Cheers and thanks for the good work and your efforts

Matthias



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

2021-04-23 Thread Matthias Schmidt
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 my file server via NFSv3 to my laptop.  In the beginning the
> > transfer rate was about 2-3M/s and after some time it dropped to around
> > 50-300K/s and never recovered (transfer is now running for 2.5h).
> > 
> > I have the following device in a Thinkpad T450s connect to a Fritzbox
> > AP.
> > 
> > iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, 
> > msi
> > iwm0: hw rev 0x230, fw ver 34.0.1, address
> 
> The patch doesn't actually change anything in the driver's receive path for
> the 8265 chip. You might have seen a side-effect of something else that is
> unrelated to the patch, such as the wifi channel suddently becoming very
> busy with unrelated traffic. We should rule that out with a fair amount
> of certainty before trying to debug the issue. So my question would be if
> this problem is 100% repeatable with the patch and not at all repeatable
> without the patch?
> 
> One possibility is that you've managed to trigger a problem in the receive
> path of net80211 with A-MSDUs enabled. Such a bug would already have existed
> but it would have been dormant since July 2019 when A-MSDUs were disabled.
> 
> For 8265 devices the entire patch boils down to this change so you could
> simply revert all the other changes and try this much smaller patch instead
> to test for this regression:

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 transfer rates remained around 3MB/s.  This is
less then the rates mentioned in your recent email but I rarely get
higher speeds.  So I assume it is to my environment and has nothing to
do with the patch.

I'll now reboot to your other patch, again, and start testing again.

Cheers

Matthias

> diff 804ff40445876fb6652323b00b9804f826133e70 /tmp/net80211
> blob - a2de00f7bcdef99ced5d09da5e9b4bc8615156bd
> file + ieee80211_input.c
> --- ieee80211_input.c
> +++ ieee80211_input.c
> @@ -2758,7 +2758,7 @@ ieee80211_recv_addba_req(struct ieee80211com *ic, stru
>   ba->ba_params = (params & IEEE80211_ADDBA_BA_POLICY);
>   ba->ba_params |= ((ba->ba_winsize << IEEE80211_ADDBA_BUFSZ_SHIFT) |
>   (tid << IEEE80211_ADDBA_TID_SHIFT));
> -#if 0
> +#if 1
>   /* iwm(4) 9k and iwx(4) need more work before AMSDU can be enabled. */
>   ba->ba_params |= IEEE80211_ADDBA_AMSDU;
>  #endif
> blob - 5bd45d993b558bac50a513c1c4422508d96f44ba
> file + ieee80211_proto.c
> --- ieee80211_proto.c
> +++ ieee80211_proto.c
> @@ -695,7 +695,7 @@ ieee80211_addba_request(struct ieee80211com *ic, struc
>   ba->ba_params =
>   (ba->ba_winsize << IEEE80211_ADDBA_BUFSZ_SHIFT) |
>   (tid << IEEE80211_ADDBA_TID_SHIFT);
> -#if 0
> +#if 1
>   /* iwm(4) 9k and iwx(4) need more work before AMSDU can be enabled. */
>   ba->ba_params |= IEEE80211_ADDBA_AMSDU;
>  #endif



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

2021-04-22 Thread Matthias Schmidt
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 July 2019:
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net80211/ieee80211_input.c#rev1.207
> The root cause of the problem I saw at that time was related to dlg's Rx
> queue back-pressure mechanism. Once we figured this out, all wireless drivers
> were fixed to call if_input() only once per interrupt so this is no longer
> an issue.
> 
> For a very brief period we tried to enable A-MSDUs again in -current but
> we found out that iwm/iwx needed additional work for the new devices which
> received support while A-MSDU was disabled in-tree:
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net80211/ieee80211_input.c#rev1.226
> The patch below completes the missing bits to make A-MSDUs work on these
> new devices.

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 my file server via NFSv3 to my laptop.  In the beginning the
transfer rate was about 2-3M/s and after some time it dropped to around
50-300K/s and never recovered (transfer is now running for 2.5h).

I have the following device in a Thinkpad T450s connect to a Fritzbox
AP.

iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
iwm0: hw rev 0x230, fw ver 34.0.1, address

Cheers

Matthias



Typos in ssh man pages

2021-04-04 Thread Matthias Schmidt
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
+++ b/usr.bin/ssh/ssh_config.5
@@ -373,7 +373,7 @@ by certificate authorities (CAs).
 The default is:
 .Bd -literal -offset indent
 ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
-sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,i
+sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,
 rsa-sha2-512,rsa-sha2-256
 .Ed
 .Pp
diff --git a/usr.bin/ssh/sshd_config.5 b/usr.bin/ssh/sshd_config.5
index e2509bb865f..35e9e3fdabc 100644
--- a/usr.bin/ssh/sshd_config.5
+++ b/usr.bin/ssh/sshd_config.5
@@ -379,7 +379,7 @@ by certificate authorities (CAs).
 The default is:
 .Bd -literal -offset indent
 ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
-sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,i
+sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,
 rsa-sha2-512,rsa-sha2-256
 .Ed
 .Pp



Re: Add /dev/video0 to fbtab

2021-04-03 Thread Matthias Schmidt
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 won't be using a
> > webcam on those platforms anyway.  And if they do they can file a bug
> > report and we fix things.
> 
> Agree.
> 
> I've tested on amd64, i386 is obvious, tb@ tested on macppc.

I am using this on amd64 for quite some while now and it is quite handy
when joining video calls.  Any chance to get this committed?

Cheers

Matthias



Re: iwm(4) A-MSDU support

2021-03-30 Thread Matthias Schmidt
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 Dual Band Wireless-AC 8265" rev 0x78, msi
iwm0: hw rev 0x230, fw ver 34.0.1, address 7c:2a:31:4d:1c:b9

Cheers

Matthias



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

2021-03-10 Thread Matthias Schmidt
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 iwm(4) devices are very welcome.

I am testing the diff for the last tow days and didn't notice any
regression.  Connection speed even "feels" more stable than before.

Cheers

Matthias

OpenBSD 6.9-beta (GENERIC.MP) #1: Tue Mar  9 19:10:43 CET 2021
x...@sigma.xosc.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 12765265920 (12173MB)
avail mem = 12363005952 (11790MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (65 entries)
bios0: vendor LENOVO version "JBET73WW (1.37 )" date 08/14/2019
bios0: LENOVO 20BX0049GE
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI DMAR
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.50 MHz, 06-3d-04
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.16 MHz, 06-3d-04
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.16 MHz, 06-3d-04
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.16 MHz, 06-3d-04
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
acpibat0 at acpi0: BAT0 model "45N" serial 16646 type LiP oem "SONY"
acpibat1 at acpi0: BAT1 model "45N1777" serial   410 type LION oem "SANYO"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0: version 1.0
tpm0 at acpi0 TPM_ addr 0xfed4/0x5000, device 0x104a rev 0x4e
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"INT340F" at acpi0 not configured
acpicpu0 at acpi0: 

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

2021-02-28 Thread Matthias Schmidt
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).
>  - rsnd/1 is play-only.
> 
> Then you will be unable to use rsnd/1 as sndiod deems is incompatible
> and refuses to use it (similarly if rsnd/1 is record-only).

I am having exactly such a setup here. rsnd/0 is the internal speaker of
my Thinkpad T450s and rsnd/1 is a speaker connected via a Bluetooth
dongle.

> This is annoying. It means if you want to use a record-only or play-only
> device, you will either have to kill sndiod and restart it specifying
> only that device (`sndiod -f rsnd/1` for the above example), or failing
> that, downgrade the functionality of the main device (`-m play`).
> 
> This diff (a joint effort between ratchov@ and myself) makes mixing
> devices with different modes possible. It does this by making both
> recording and playing available for all devices, even if the underlying
> hardware doesn't support both modes.
> 
> For example, if I try to record from a play-only device, then recording
> will succeed, but the captured PCM data will be pure silence. Similarly,
> if I try to play to a record-only device, then the audio stream will
> disappear into the ether.
> 
> This is mostly a no-op for sndiod in the default configuration (except
> that play-only devices now accept recording clients). If you use
> alternative devices (-F), then it's possible for a record-only device to
> be found first, which may be confusing if you just want to hear sound.
> We can only assume that if you deviate from defaults, then you know what
> you are doing.
> 
> Please test and let us know if it works for you.

Works fine here and way better than before.  Switching from internal to
the external speakers was kind of a hassle and often ended up in me
restarting sndiod.  With the patch, switching worked as one would expect
it.

Cheers

Matthias



Re: kern.video.record - part 2

2020-12-26 Thread Matthias Schmidt
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 kern.audio.recording.

> What I like about the approach are mainly two things:
> 
> 1. We're aligning to audio(4), which has the kern.audio.record toggle
>already in place.  If we have a toggle for audio recording, why not
>having one for video recording?
> 
> 2. If we would decide to get kern.video.record in, as a next step I
>would like to propose changing the /dev/video* permissions so we
>don't require root access to execute video programs, by adding a
>new group 'video' and apply it together with 660 permissions to
>/dev/video*.  By that we require initial root access to enable
>video recording, but can then permit non-root accounts for video
>access.

I tested your patch with the following setup and it worked as expected.
When set to 0 I only saw a complete green video feed, when set to 1 I got
the camera picture as usual.

* video(1) worked
* Chrome and Firefox showed the camera feed and toggling worked
* I participated in a Google Meet session via Chrome and could toogle
  the sysctl and my camera feed switched from green to live.

I tested with a Thinkpad X250 and the integrated webcam:

uvideo0 at uhub0 port 8 configuration 1 interface 0 "Chicony Electronics
Co.,Ltd. Integrated Camera" rev 2.00/0.24 addr 4
video0 at uvideo0

Cheers and thanks for your work

Matthias



Re: ntpd: go into unsynced mode

2020-08-25 Thread Matthias Schmidt
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
> processed for a while. 
> 
> An earlier version of this diff was tested by naddy@. Compared to that
> version, the needed period of inactivity is now three times as large
> and I set scale to 1, so recovery goes faster.
> 
> Please test and review,

I have your diff running on my Laptop which sometimes not connected to a
network so it should be a good test case.

I haven't noticed any difference to before, so I count that as a good
sign :)  I spotted only one thing:  While "ntpctl -s a" says that the
clock is unsynced I see no message from ntpd in the logs.  Not sure if
that's on purpose or not, I just noticed it.

Cheers

Matthias



Typo in ifconfig.8

2020-06-24 Thread Matthias Schmidt


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 the IP addresses a peer is allowed to send
  from.
  That is, in order for an incoming packet from a peer to reach the host,
 -the decryped IP source address must be in the peer's
 +the decrypted IP source address must be in the peer's
  .Ar allowed-ip
  ranges.
  .Pp



Re: filesystem code integer and many inodes

2020-06-05 Thread Matthias Schmidt
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 a partition (not sure how to test this but fsirand -p
  showed different numbers afterwards...)
* Extract src.tgz, powered off the VM, reboot and fsck upon boot
* Same while extracting src.tgz on a second mounted disk

To the best of my knowledge the tools did the jobs they were supposed
to.  Let me know if there is something else I should test.

Cheers

Matthias



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

2020-05-17 Thread Matthias Schmidt
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 subset of received frames, which
> > > resulted in packet loss.
> > > 
> > > That was before we updated all iwm(4) devices to newer firmware in the
> > > previous release cycle. I hope we won't see such problems again now.
> > > 
> > > Please help out with getting this tested on the many iwm(4) variants:
> > > 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, and 9560.
> > 
> > Turns out that my initial testing was insufficient. Sorry about that.
> > 
> > My previous patch, which was based on code code written against older
> > firmware, did not work on some devices. I missed that some newer firmware
> > versions we use nowadays have different hardware encryption APIs.
> > 
> > This new version has been tested by me on 7265, 8260, and 9260.
> > It seems to work fine on those devices.
> > 
> > Could someone test on any of the other devices?
> > 
> > ok?
> 
> Sorry, that diff was generated against the wrong base and contained unrelated
> stuff.

I have your diff running since yesterday and noticed no regression.

iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
iwm0: hw rev 0x230, fw ver 34.0.1

Cheers

Matthias



Re: amd64: use ffs2 for filesystems created by install

2020-02-21 Thread Matthias Schmidt
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

2020-02-20 Thread Matthias Schmidt
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.
> 
> To test, create a snapshot (see release(8)) with this diff and use it
> to install a new system. You could also use the snap at
> www.drijf.net/openbsd/66. Note that it is unsigned.
> 
> Note that when you manually create an fs, it still will be ffs1 by
> default. That is to not disturb other platforms. Use -O2 for ffs2.
> 
> Please test and provide feedback. One think you should see is that the
> newfs is much faster and fsck as well, since ffs2 creates inodes
> lazily and thus has much less inodes to check in the typical case.

I used your provided snap to do a few installations with VMs.  The
following things worked as expected:

* Default install on one disk
* Install on softraid crypto disk
* Install on softraid 1 with two disks below

I verified each time with dumpfs that FFS2 was used indeed.

I also checked out a large git repo on the first VM into /home and
pulled the plug to see how fsck behaves.  After reboot, fsck marked / as
clean and then I saw the message that init changed the secure level from
0 to 1, but nothing more happened.  I could type so the system was not
hanging, however, it was also not checking /home (which I expected).  I
waited for 5 minutes, pulled the plug again and the fsck worked as
normal and the system booted to the login prompt.

I did that multiple times and each time it stopped on the first run.
After power cycling, everything worked as expected and ... wow, fsck on
FFS2 is indeed fast.

Cheers

Matthias



Re: Opportunistic DoT for unwind(8)

2019-10-30 Thread Matthias Schmidt
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 running for a couple of days and I can at least confirm
that it doesn't break an existing setup.  I have several upstream DoT
servers configured but no opportunistic DoT setup.

HTH and cheers

Matthias



Re: call if_input only once per Rx interrupt from net80211

2019-09-10 Thread Matthias Schmidt
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 again.
> 
> In the first diff ieee80211_input() was putting aggregated frames
> onto the global mbuf list. With this new diff they get added to the
> mbuf list which the driver's rx interrupt handler passed in.
> 
> Does this fix the issue?

Yes, indeed.  Download test files from a leaseweb mirror is now so fast
that my CPU fan starts spinning :)  This time, only tested on iwm.

Kudos for the quick fix!

Matthias



Re: call if_input only once per Rx interrupt from net80211

2019-09-10 Thread Matthias Schmidt
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 download speeds is around 400-700K/s on both systems.  As
soon as I switch back to the kernel with yesterday's patch, I end up
having 4M/s in average, again.

Cheers

Matthias



Re: call if_input only once per Rx interrupt from net80211

2019-09-09 Thread Matthias Schmidt
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 two parts:
> 
> Updated diff which avoids purging the input queue at every state
> change, e.g. even during SCAN->SCAN. With this we only purge the
> queue if we're leaving RUN state or going back to INIT state.

Tested your diff with

iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265"

So far, the diff provides amazing results.  Without your diff the
maximum speed of file downloads from my favorite mirror is around
1.2M/s in average.  With your diff it is around 4.5M/s in average.

Cheers
Matthias



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

2019-06-15 Thread Matthias Schmidt
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 issues.
> They must have been present already.
> 
> Check 'ifconfig iwn0 debug' and see which messages correlate to disconnects.
> You're probably running into known issues with background scan (sends deauth
> to old AP but never switches to new AP; stays dead until down/up) and/or
> dead AP detection (sends probe request to AP, never gets a response, drops
> to SCAN state, takes some time to find the AP again, reconnects).

Seems you were quite right.  The first disconnect I had today was
related to a firmware error.

Cheers

Matthias

2019-06-15T10:57:42.422Z sigma /bsd: iwm0: fatal firmware error
2019-06-15T10:57:42.422Z sigma /bsd: iwm0: RUN -> INIT
2019-06-15T10:57:42.592Z sigma /bsd: iwm0: begin active scan
2019-06-15T10:57:42.593Z sigma /bsd: iwm0: INIT -> SCAN
2019-06-15T10:57:45.797Z sigma /bsd: iwm0: end active scan
2019-06-15T10:57:45.797Z sigma /bsd: iwm0: - 00:1e:2a:e1:18:906   +17 54M   
ess  privacy   rsn  "ChaosUnlimited"!
2019-06-15T10:57:45.798Z sigma /bsd: iwm0: - 12:62:e5:d1:fd:a96   +21 54M   
ess  privacy   rsn  "DIRECT-A9-HP OfficeJet 5200"!
2019-06-15T10:57:45.798Z sigma /bsd: iwm0: - 1c:3a:de:64:90:5b   13   +18 54M   
ess  privacy   rsn  "CelenoInitialAP64905B"!
2019-06-15T10:57:45.798Z sigma /bsd: iwm0: - 38:10:d5:79:a3:4a6   +21 54M   
ess  privacy   rsn  "FRITZ!BS"!
2019-06-15T10:57:45.799Z sigma /bsd: iwm0: - 44:4e:6d:98:c6:176   +21 54M   
ess  privacy   rsn  "FRITZ!Box 6490 Cable"!
2019-06-15T10:57:45.799Z sigma /bsd: iwm0: - 44:4e:6d:ec:3c:d31   +21 54M   
ess  privacy   rsn  "FRITZ!Box 6490 Cable"!
2019-06-15T10:57:45.799Z sigma /bsd: iwm0: - 44:fe:3b:10:c5:dc1   +17 54M   
ess   no!  rsn! "Telekom_FON"!
2019-06-15T10:57:45.800Z sigma /bsd: iwm0: - 46:4e:6d:ec:3c:d31   +21 54M   
ess  privacy   rsn  "FRITZ!"!
2019-06-15T10:57:45.800Z sigma /bsd: iwm0: - 54:67:51:3d:90:46   11   +49 54M   
ess  privacy   rsn  "melbourne2016"!
2019-06-15T10:57:45.800Z sigma /bsd: iwm0: - 54:67:51:3d:90:c8   36   +35 54M   
ess  privacy   rsn  "melbourne2016"!
2019-06-15T10:57:45.800Z sigma /bsd: iwm0: - 56:67:11:3d:90:46   11   +48 54M   
ess  privacy   rsn! "Unitymedia WifiSpot"!
2019-06-15T10:57:45.800Z sigma /bsd: iwm0: - 90:5c:44:24:40:fa  100   +21 54M   
ess  privacy   rsn  "UPC6ED3663"!
2019-06-15T10:57:45.801Z sigma /bsd: iwm0: - 90:5c:44:24:41:03   11   +17 54M   
ess  privacy   rsn  "UPC6ED3663"!
2019-06-15T10:57:45.801Z sigma /bsd: iwm0: - 90:5c:44:27:c6:1b6   +17 54M   
ess  privacy   rsn  "UPC89142D1"!
2019-06-15T10:57:45.801Z sigma /bsd: iwm0: - 90:5c:44:cf:2c:e66   +17 54M   
ess  privacy   rsn  "UPCE5AEF49"!
2019-06-15T10:57:45.802Z sigma /bsd: iwm0: - 90:5c:44:db:c8:e56   +19 54M   
ess  privacy   rsn  "UPC877738E"!
2019-06-15T10:57:45.802Z sigma /bsd: iwm0: - 90:5c:44:dd:72:486   +17 54M   
ess  privacy   rsn  "UPCA7A2229"!
2019-06-15T10:57:45.802Z sigma /bsd: iwm0: - 92:5c:14:24:41:03   11   +17 54M   
ess  privacy   rsn! "Unitymedia WifiSpot"!
2019-06-15T10:57:45.802Z sigma /bsd: iwm0: - ae:22:15:d0:db:bf   11   +17 54M   
ess  privacy   rsn! "Unitymedia WifiSpot"!
2019-06-15T10:57:45.803Z sigma /bsd: iwm0: - cc:ce:1e:8b:cf:d1   60   +31 54M   
ess  privacy   rsn  "hs.ka.v01d"!
2019-06-15T10:57:45.803Z sigma /bsd: iwm0: + cc:ce:1e:8b:cf:d23   +46 54M   
ess  privacy   rsn  "karlsruhe.v01d"
2019-06-15T10:57:45.803Z sigma /bsd: iwm0: - d4:21:22:53:3a:9b1   +17 54M   
ess  privacy   rsn  "WLAN-604342"!
2019-06-15T10:57:45.804Z sigma /bsd: iwm0: - e0:28:6d:16:2b:18   11   +21 54M   
ess  privacy   rsn  "FRITZ!Box 7490"!
2019-06-15T10:57:45.804Z sigma /bsd: iwm0: SCAN -> AUTH
2019-06-15T10:57:45.804Z sigma /bsd: iwm0: sending auth to cc:ce:1e:8b:cf:d2 on 
channel 3 mode 11g
2019-06-15T10:57:45.813Z sigma /bsd: iwm0: AUTH -> ASSOC
2019-06-15T10:57:45.813Z sigma /bsd: iwm0: sending assoc_req to 
cc:ce:1e:8b:cf:d2 on channel 3 mode 11g
2019-06-15T10:57:45.825Z sigma /bsd: iwm0: ASSOC -> AUTH
2019-06-15T10:57:50.549Z sigma /bsd: iwm0: AUTH -> SCAN
2019-06-15T10:57:53.682Z sigma /bsd: iwm0: end active scan
2019-06-15T10:57:53.682Z sigma /bsd: iwm0: - 00:1e:2a:e1:18:906   +18 54M   
ess  privacy   rsn  "ChaosUnlimited"!
2019-06-15T10:57:53.682Z sigma /bsd: iwm0: - 44:4e:6d:ee:7e:ae1   +21 54M   
ess  privacy   rsn  "FRITZ!Box 6490 Cable"!
2019-06-15T10:57:53.683Z sigma /bsd: iwm0: - 44:fe:3b:42:1d:22   11   +17 54M   
ess  privacy   rsn  "WLAN-331218"!
2019-06-15T10:57:53.683Z sigma /bsd: iwm0: - 44:fe:3b:42:1d:24   11   +17 54M   
ess   no!  rsn! "Telekom_FON"!
2019-06-15T10:57:53.683Z sigma /bsd: iwm0: - 54:67:51:3d:90:46   11   +56 54M   
ess  privacy   rsn  "melbourne2016"!
2019-06-15T10:57:53.683Z sigma /bsd: 

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

2019-06-14 Thread Matthias Schmidt
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
> > > 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 get numbers from wireshark for this if you don't want 
> > > to.
> > > Letting me know if Tx is faster or not and whether there are any perceived
> > > regressions is sufficient.
> > 
> > I tested your diff for the last two days and noticed a regression
> > After some time one of the two things happens:
> 
> Are you sure these problem are introduced by this diff?
> I am quite certain that these symptoms must be unrelated.

The first problem also shows up without your diff, however, the
reconnect happens a lot faster.  I will spend some more time testing.

Cheers

Matthias



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

2019-06-14 Thread Matthias Schmidt
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 get numbers from wireshark for this if you don't want to.
> Letting me know if Tx is faster or not and whether there are any perceived
> regressions is sufficient.

I tested your diff for the last two days and noticed a regression
After some time one of the two things happens:

* Transfer rates drop to 0.  Directly visible if I run tcpbench,
  indirectly if I cannot work with the Network any longer.  I waited
  for quite some time (> 10m) for something to happened, however, nothing
  changes.  Then I restarted the interface.
* My Thinkpad completely looses connection to my AP (Fritzbox) such that
  I have to take iwm0 down and run sh /etc/netstart iwm0.

It happens when I work as usual (SSH, email, surfing, etc) and if I do
nothing else then running tcpbench between the Thinkpad and a APU2
running 6.5.

I run the diff with the following hardware on latest -current:

iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
iwm0: hw rev 0x230, fw ver 22.361476.0, address 7c:2a:31:4d:1c:b9

Cheers

Matthias



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

2019-05-05 Thread Matthias Schmidt
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 honest, I never
spend time debugging it.

Thus, I added all my important hosts as menu entries:

command foo "xterm -e ssh foo.example.com"

There might be other solutions/launchers, however, that works for me :)

Cheers

Matthias



Re: Harmonize examples in signify man page

2019-02-24 Thread Matthias Schmidt

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 change (newkey.sec vs key.sec, etc).
The diff harmonizes the examples.  It makes it easier to follow the 
examples.


Cheers

diff --git signify.1 signify.1
index de3b433e3b0..9f7335352a2 100644
--- signify.1
+++ signify.1
@@ -153,13 +153,13 @@ The message file is too large.
 .El
 .Sh EXAMPLES
 Create a new key pair:
-.Dl $ signify -G -p newkey.pub -s newkey.sec
+.Dl $ signify -G -p key.pub -s key.sec
 .Pp
 Sign a file, specifying a signature name:
-.Dl $ signify -S -s key.sec -m message.txt -x msg.sig
+.Dl $ signify -S -s key.sec -m message -x message.sig
 .Pp
 Verify a signature, using the default signature name:
-.Dl $ signify -V -p key.pub -m generalsorders.txt
+.Dl $ signify -V -p key.pub -m message
 .Pp
 Verify a release directory containing
 .Pa SHA256.sig
@@ -175,7 +175,7 @@ $ signify -C -p /etc/signify/openbsd-65-base.pub -x SHA256.sig bsd.rd
 .Pp
 Sign a gzip archive:
 .Bd -literal -offset indent -compact
-$ signify -Sz -s key-arc.sec -m in.tgz -x out.tgz
+$ signify -Sz -s key.sec -m in.tgz -x out.tgz
 .Ed
 .Pp
 Verify a gzip pipeline:


Harmonize examples in signify man page

2019-02-24 Thread Matthias Schmidt
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 de3b433e3b0..9f7335352a2 100644
 --- signify.1
 +++ signify.1
 @@ -153,13 +153,13 @@ The message file is too large.
  .El
  .Sh EXAMPLES
  Create a new key pair:
 -.Dl $ signify -G -p newkey.pub -s newkey.sec
 +.Dl $ signify -G -p key.pub -s key.sec
  .Pp
  Sign a file, specifying a signature name:
 -.Dl $ signify -S -s key.sec -m message.txt -x msg.sig
 +.Dl $ signify -S -s key.sec -m message -x message.sig
  .Pp
  Verify a signature, using the default signature name:
 -.Dl $ signify -V -p key.pub -m generalsorders.txt
 +.Dl $ signify -V -p key.pub -m message
  .Pp
  Verify a release directory containing
  .Pa SHA256.sig
 @@ -175,7 +175,7 @@ $ signify -C -p /etc/signify/openbsd-65-base.pub -x 
SHA256.sig bsd.rd
  .Pp
  Sign a gzip archive:
  .Bd -literal -offset indent -compact
 -$ signify -Sz -s key-arc.sec -m in.tgz -x out.tgz
 +$ signify -Sz -s key.sec -m in.tgz -x out.tgz
  .Ed
  .Pp
  Verify a gzip pipeline:



Re: rework iwm(4) Tx rate selection

2019-02-20 Thread Matthias Schmidt
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 environment, with an average rate above 20 Mbps.
> 
> Also pay attention to changes in latency. To test this, on my iwm laptop
> I run ping and rain(6) through an SSH connection to a machine behind the AP.

I tested your diff with the following setup:

iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
iwm0: hw rev 0x230, fw ver 22.361476.0

iwm0: flags=8943 mtu 1500
index 2 priority 4 llprio 3
trunk: trunkdev trunk0
groups: wlan
media: IEEE802.11 autoselect (OFDM54 mode 11g)
status: active
ieee80211: join karlsruhe chan 3 bssid cc:ce:1e:8b:cf:d2 68% wpakey 
wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp

Laptop with iwm connect to AP, both targets connected to the AP via LAN.

Without the patch:

Ping a local host: Average RTT 12.8ms
Copy large files from a local host via NFS over TCP: 2.59MB/s
Ping a local host: Average RTT 13.6ms
Copy large files from a local host via NFS over TCP: 2.56MB/s

With the patch:

Ping a local host: Average RTT 12.2ms
Copy large files from a local host via NFS over TCP: 2.49MB/s
2nd run:
Ping a local host: Average RTT 13.0ms
Copy large files from a local host via NFS over TCP: 2.61MB/s

Cheers and HTH

Matthias



Re: slow vim and malloc

2018-09-25 Thread Matthias Schmidt
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.

let sh_minlines=100
let sh_maxlines=600
set synmaxcol=300

Cheers and HTH

Matthias



Re: Adding current bandwidth to ftp(1)

2018-04-09 Thread Matthias Schmidt

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 
appreciate your patch!


Have you tried your patch in bsd.rd or in a classic 80x25 screen where 
screen space is limited?


Cheers

Matthias



Re: inteldrm(4) tests needed

2018-01-15 Thread Matthias Schmidt
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 that my external LCD is now
available during boot and it stays connected after zzz cycles.  This
works if I connect the LCD via Displayport and via VGA.

If I boot the machine w/o an external display and connect it via VGA it
works as expected.  If I connect it via Displayport nothing happens.
I tried suspend/resume but nothing changed.

Cheers

Matthias

Internal + external via Displayport (dunno why it shows HDMI-1)

Screen 0: minimum 320 x 200, current 3286 x 1080, maximum 8192 x 8192
LVDS-1 connected primary 1366x768+0+0 (normal left inverted right x axis y 
axis) 277mm x 156mm
   1366x768  60.02*+
   1024x768  60.0460.00  
   960x720   60.00  
   928x696   60.05  
   896x672   60.01  
   800x600   60.0060.3256.25  
   700x525   59.98  
   640x512   60.02  
   640x480   60.0059.94  
   512x384   60.00  
   400x300   60.3256.34  
   320x240   60.05  
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 connected 1920x1080+1366+0 (normal left inverted right x axis y axis) 
160mm x 90mm
   1920x1080 60.00*+  50.0059.94  
   1920x1080i60.0050.0059.94  
   1600x1200 60.00  
   1680x1050 59.88  
   1280x1024 60.02  
   1440x900  59.90  
   1280x960  60.00  
   1280x800  59.91  
   1280x720  60.0050.0059.94  
   1024x768  60.00  
   800x600   60.3256.25  
   720x576   50.00  
   720x480   60.0059.94  
   640x480   60.0059.94  
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
HDMI-3 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)

Internal + external via VGA

Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
LVDS-1 connected primary 1366x768+0+0 (normal left inverted right x axis y 
axis) 277mm x 156mm
   1366x768  60.02*+
   1024x768  60.0460.00  
   960x720   60.00  
   928x696   60.05  
   896x672   60.01  
   800x600   60.0060.3256.25  
   700x525   59.98  
   640x512   60.02  
   640x480   60.0059.94  
   512x384   60.00  
   400x300   60.3256.34  
   320x240   60.05  
VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 
0mm
   1024x768  60.00* 
   800x600   60.3256.25  
   848x480   60.00  
   640x480   59.94  
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
HDMI-3 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)

OpenBSD 6.2-current (GENERIC.MP) #0: Mon Jan 15 18:46:41 CET 2018
x...@x220.fritz.box:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17041059840 (16251MB)
avail mem = 16517677056 (15752MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (64 entries)
bios0: vendor LENOVO version "8DET73WW (1.43 )" date 10/12/2016
bios0: LENOVO 4290W1B
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT 
SSDT DMAR UEFI UEFI UEFI
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) 
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.29 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
acpihpet0: recalibrated TSC frequency 2491911252 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz
cpu1: 

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

2018-01-07 Thread Matthias Schmidt
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 "extract src.tar while suspending" multiple times both on /tmp
and /home.  Now, the suspend process was quite fast and the file systems
were marked clean every time.

Cheers

Matthias



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

2018-01-06 Thread Matthias Schmidt
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 work is highly appreciated!

Cheers

Matthias

1. zzz after manual fsync and pulled the plug after suspend.

Works as expected and no softraid errors.

Jan  6 20:59:21 tau /bsd: /var force clean (0 0): fmod 1 clean 1
Jan  6 20:59:21 tau /bsd: /usr/src force clean (0 0): fmod 1 clean 1
Jan  6 20:59:21 tau /bsd: /usr/ports force clean (0 0): fmod 1 clean 1
Jan  6 20:59:21 tau /bsd: /usr/obj force clean (0 0): fmod 1 clean 1
Jan  6 20:59:21 tau /bsd: /usr/local force clean (0 0): fmod 1 clean 1
Jan  6 20:59:21 tau /bsd: /usr/X11R6 force clean (0 0): fmod 1 clean 1
Jan  6 20:59:21 tau /bsd: /usr force clean (0 0): fmod 1 clean 1
Jan  6 20:59:22 tau /bsd: /tmp force clean (0 0): fmod 1 clean 1
Jan  6 20:59:22 tau /bsd: /home force clean (0 0): fmod 1 clean 1
Jan  6 20:59:22 tau /bsd: / force clean (0 0): fmod 1 clean 1

2. zzz while extracting src.tar.gz on /tmp and pulled the plug after
suspend.

Same result, works as expected.

3, ZZZ after manual fsync.

Same result, works as expected.

4.  Now the interesting case.  Basically the same as (2) but now I
extracted src.tar.gz not in /tmp but in /home which is my largest
partition.  This time, the suspend process does not finished and I
pulled the plug after some time.  My /home partition was extremely dirty
but the others were marked as clean.  So definitely an improvement over
the current situation.

/dev/sd2l: SIZE=762 MTIME=Sep 14 16:04 2016  (RECONNECTED)
/dev/sd2l (1cae2f5f79b7f28f.l): UNREF FILE  I=11553631  OWNER=xhr MODE=100644
[ Hundreds of unferenced files ]
/dev/sd2l (1cae2f5f79b7f28f.l): FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED)
/dev/sd2l (1cae2f5f79b7f28f.l): SUMMARY INFORMATION BAD (SALVAGED)
/dev/sd2l (1cae2f5f79b7f28f.l): BLK(S) MISSING IN BIT MAPS (SALVAGED)
/dev/sd2l (1cae2f5f79b7f28f.l): 176550 files, 13148621 used, 91136441 free 
(88761 frags, 11380960 blocks, 0.1% fragmentation)
/dev/sd2l (1cae2f5f79b7f28f.l): MARKING FILE SYSTEM CLEAN
/dev/sd2d (1cae2f5f79b7f28f.d): file system is clean; not checking
/dev/sd2f (1cae2f5f79b7f28f.f): file system is clean; not checking
/dev/sd2g (1cae2f5f79b7f28f.g): file system is clean; not checking
/dev/sd2h (1cae2f5f79b7f28f.h): file system is clean; not checking
/dev/sd2k (1cae2f5f79b7f28f.k): file system is clean; not checking
/dev/sd2j (1cae2f5f79b7f28f.j): file system is clean; not checking
/dev/sd2i (1cae2f5f79b7f28f.i): file system is clean; not checking
/dev/sd2e (1cae2f5f79b7f28f.e): file system is clean; not checking

Jan  6 21:09:25 tau /bsd: /var force clean (0 0): fmod 1 clean 1
Jan  6 21:09:25 tau /bsd: /usr/src force clean (0 0): fmod 1 clean 1
Jan  6 21:09:25 tau /bsd: /usr/ports force clean (0 0): fmod 1 clean 1
Jan  6 21:09:25 tau /bsd: /usr/obj force clean (0 0): fmod 1 clean 1
Jan  6 21:09:25 tau /bsd: /usr/local force clean (0 0): fmod 1 clean 1
Jan  6 21:09:25 tau /bsd: /usr/X11R6 force clean (0 0): fmod 1 clean 1
Jan  6 21:09:25 tau /bsd: /usr force clean (0 0): fmod 1 clean 1
Jan  6 21:09:25 tau /bsd: /tmp force clean (0 0): fmod 1 clean 1

Both / and /home are missing here and they were both marked as dirty.

Here my disklabel as reference:

# /dev/rsd2c:
type: SCSI
disk: SCSI disk
label: SR CRYPTO
duid: 1cae2f5f79b7f28f
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 58368
total sectors: 937697393
boundstart: 64
boundend: 937681920
drivedata: 0

16 partitions:
#size   offset  fstype [fsize bsize   cpg]
  a:  2097152   64  4.2BSD   2048 16384 12958 # /
  b: 33820888  2097216swap# none
  c:9376973930  unused
  d:  4194304 35918112  4.2BSD   2048 16384 12958 # /tmp
  e:  4194304 40112416  4.2BSD   2048 16384 12958 # /var
  f:  4194304 44306720  4.2BSD   2048 16384 12958 # /usr
  g:  2097152 48501024  4.2BSD   2048 16384 12958 # /usr/X11R6
  h: 20971520 50598176  4.2BSD   2048 16384 12958 # /usr/local
  i:  8388608 71569696  4.2BSD   2048 16384 12958 # /usr/src
  j:  8399168 79958304  4.2BSD   2048 16384 12958 # /usr/ports
  k:  8385952 88357472  4.2BSD   2048 16384 12958 # /usr/obj
  l:840938496 96743424  4.2BSD   4096 32768 26062 # /home

OpenBSD 6.2-current (GENERIC.MP) #0: Sat Jan  6 20:02:16 CET 2018
x...@tau.xosc.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17047859200 (16258MB)
avail mem = 16524271616 (15758MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7b1d5000 (58 entries)
bios0: vendor Intel Corp. 

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

2017-12-19 Thread Matthias Schmidt
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 softdep the file system was marked
clean on the next reboot.

However, I encountered a panic on a reboot.  Acquiring a crash dump does
not worked since ddb got stuck on syncing disks.  I made a couple of
photos and uploaded them to https://kappa.xosc.org/misc/.
Unfortunately, I could not reproduce the crash with several reboots.

Let me know if you need me anything else to test.

Cheers

Matthias


/dev/sd2a on / type ffs (local)
/dev/sd2l on /home type ffs (local, nodev, nosuid, softdep)
/dev/sd2d on /tmp type ffs (local, nodev, nosuid)
/dev/sd2f on /usr type ffs (local, nodev, softdep)
/dev/sd2g on /usr/X11R6 type ffs (local, nodev, softdep)
/dev/sd2h on /usr/local type ffs (local, nodev, wxallowed, softdep)
/dev/sd2k on /usr/obj type ffs (local, noatime, nodev, nosuid, softdep)
/dev/sd2j on /usr/ports type ffs (local, noatime, nodev, nosuid, softdep)
/dev/sd2i on /usr/src type ffs (local, noatime, nodev, nosuid, softdep)
/dev/sd2e on /var type ffs (local, nodev, nosuid, softdep)


OpenBSD 6.2-current (GENERIC.MP) #0: Tue Dec 19 09:42:47 CET 2017
x...@tau.xosc.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17047859200 (16258MB)
avail mem = 16524275712 (15758MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7b1d5000 (58 entries)
bios0: vendor Intel Corp. version "SYSKLi35.86A.0062.2017.0831.1905" date 
08/31/2017
bios0: Intel corporation NUC6i5SYB
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET LPIT SSDT SSDT SSDT SSDT DBGP 
DBG2 SSDT SSDT UEFI SSDT DMAR
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
SIO1(S3) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) 
RP12(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.55 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.04 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.04 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.04 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 2399 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus -1 

Re: ksh: add support for HISTCONTROL ignorespace & ignoredups

2017-08-30 Thread Matthias Schmidt

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 behavior
based on bash.  The default ksh behavior doesn't change.

I did not implement:
- "ignoreboth", which is a shorthand for "ignoredups:ignorespace";
   trivial, but not really useful
- "erasedups", I have no use for this and it's not as trivial

I have yet to put this in an mkr (dunno yet if the space savings of the
setlocale removal positively affects the ramdisks).

Thoughts?  ok?


I'd would love to see that feature in ksh since duplicates keep annoying 
me. I tested your patch on current and it works fine for me.


Cheers and thanks

Matthias