fw_update throwing exit 1 on successful install when passed a driver by name
Greetings. I noticed the above behavior with the latest 7.4-beta when scripting
some fw_update runs. Perhaps a corner case was missed in the recent work? Steps
below, let me know if more information is required to reproduce. Thanks in
advance.
root:current-amd64.124:0:~# fw_update -d intel; echo ${?}
fw_update: delete intel
0
root:current-amd64.124:0:~# fw_update; echo ${?}
fw_update: add intel; update none; keep inteldrm,vmm
0
root:current-amd64.124:0:~# fw_update -d intel; echo ${?}
fw_update: delete intel
0
root:current-amd64.124:0:~# fw_update intel; echo ${?}
fw_update: add intel; update none
1
Brian Conway
Owner
RCE Software, LLC
OpenBSD 7.4-beta (GENERIC.MP) #1373: Thu Sep 21 09:26:32 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4160446464 (3967MB)
avail mem = 4014624768 (3828MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x9b81 (97 entries)
bios0: vendor American Megatrends Inc. version "5.17" date 03/25/2021
bios0: Default string Default string
efi0 at bios0: UEFI 2.7
efi0: American Megatrends rev 0x50011
acpi0 at bios0: ACPI 6.2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP MCFG SSDT FIDT SSDT HPET SSDT SSDT SSDT NHLT LPIT SSDT
SSDT DBGP DBG2 SSDT DMAR WSMT APIC FPDT
acpi0: wakeup devices PS2K(S0) PS2M(S0) RP01(S0) PXSX(S0) RP02(S0) PXSX(S0)
RP03(S0) PXSX(S0) RP04(S0) PXSX(S0) RP05(S0) PXSX(S0) RP06(S0) PXSX(S0)
RP07(S0) PXSX(S0) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU 5305U @ 2.30GHz, 2194.89 MHz, 06-8e-0c, patch
00f8
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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,INVPCID,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,RRSBA,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line
4-way L2 cache, 2MB 64b/line 8-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
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) Celeron(R) CPU 5305U @ 2.30GHz, 2194.90 MHz, 06-8e-0c, patch
00f8
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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,INVPCID,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,RRSBA,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line
4-way L2 cache, 2MB 64b/line 8-way L3 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
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 (RP01)
acpiprt5 at acpi0: bus -1 (RP02)
acpiprt6 at acpi0: bus -1 (RP03)
acpiprt7 at acpi0: bus -1 (RP04)
acpiprt8 at acpi0: bus -1 (RP05)
acpiprt9 at acpi0: bus -1 (RP06)
acpiprt10 at acpi0: bus 1 (RP07)
acpiprt11 at acpi0: bus 2 (RP08)
acpiprt12 at acpi0: bus -1 (RP09)
acpiprt13 at acpi0: bus -1 (RP10)
acpiprt14 at acpi0: bus -1 (RP11)
acpiprt15 at acpi0: bus -1 (RP12)
acpiprt16 at acpi0: bus 3 (RP13)
acpiprt17 at acpi0: bus 4 (RP14)
acpiprt18 at acpi0: bus 5 (RP15)
acpiprt19 at acpi0: bus 6 (RP16)
acpiprt20 at acpi0: bus -1 (RP17)
acpiprt21 at acpi0: bus -1 (RP18)
acpiprt22 at acpi0: bus -1 (RP19)
acpiprt23 at acpi0: bus -1 (RP20)
acpiprt24 at acpi0: bus -1 (RP21)
acpiprt25 at acpi0: bus -1 (RP22)
acpiprt26 at acpi0: bus -1 (RP23)
acpiprt27 at acpi0: bus -1 (RP24)
acpiec0 at acpi0: not present
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
pchgpio0 at acpi0 GPI0 addr 0xfd6e/0x1 0xfd6d/0x1
0xfd6a/0x1 irq 14, 320 pins
"PNP0C14" at acpi0 not configured
acpibtn0 at acpi0: SLPB
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"INT33A1" at acpi0 not conf
Re: vmd(8): multi-process device emulation (plz test)
On Sun, Apr 30, 2023, at 12:43 PM, Brian Conway wrote: > On Tue, Apr 25, 2023, at 9:47 AM, Dave Voutila wrote: >> tech@: >> >> The below diff splits out virtio device emulation for virtio block and >> network devices into separate fork+exec'd & pledge(2)'d subprocesses. >> >> In order of priority, this diff: >> >> 1. Isolates common exploit targets (e.g. emulated network devices) from >>the rest of the vm process, tightening pledge to "stdio" per device. >> >> 2. Increases responsiveness of guest i/o since we no longer have a >>single thread servicing virtio pci and device emulation. >> >> I'd like to land this diff this week, so if you use atypical vmd >> configurations like: >> >> 1. multiple vioblk disks per vm >> 2. multiple nics per vm >> 3. send/receive >> 4. qcow2 base images >> >> This diff has lots of info logging enabled by default to help me >> identify what's breaking, so please reply with log message output if >> something goes sideways. >> >> -dv > > Apologies for being late to the party, I'm testing this now via > snapshots. The host in question was last updated a few weeks ago, i.e. > before the deluge of recent work. It's an amd64 VMM host running (among > other things) an i386 7.3 release VM. After updating the host to the > latest snapshot, things appear to run fine, but I did notice the > following new messages consistently when powering off (halt -p) the > i386 VM: > > Apr 29 18:41:09 coofun /bsd: uvn_flush: obj=0xfd815a44fee0, > offset=0x43287000. error during pageout. > Apr 29 18:41:09 coofun /bsd: uvn_flush: WARNING: changes to page may be > lost! > > Apr 30 17:28:26 coofun /bsd: uvn_flush: obj=0xfd812ff90c08, > offset=0x4378c000. error during pageout. > Apr 30 17:28:26 coofun /bsd: uvn_flush: WARNING: changes to page may be > lost! I should have been more clear, these messages are on the amd64 VMM host. Also, the guest is using a standard raw disk image, so I don't think it actually meets any of your atypical scenarios 1-4. Brian > The guest *appears* to run fine and reboots with a clean filesystem, > but I also haven't gone through the filesystem with a comb. I have not > had a chance to spin up an amd64 guest this weekend yet. > > Thanks! > > Brian Conway > > amd64 host dmesg: > > OpenBSD 7.3-current (GENERIC.MP) #1168: Fri Apr 28 14:47:06 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4072996864 (3884MB) > avail mem = 3929907200 (3747MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x79851000 (17 entries) > bios0: vendor American Megatrends Inc. version "GB1B 0.04" date > 10/20/2021 > bios0: BESSTAR TECH LIMITED N40 > efi0 at bios0: UEFI 2.7 > efi0: American Megatrends rev 0x5000d > acpi0 at bios0: ACPI 6.2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP FPDT FIDT MSDM MCFG SSDT DBG2 DBGP HPET LPIT > APIC NPKT SSDT SSDT SSDT SSDT SSDT SSDT BGRT TPM2 DMAR WDAT NHLT WSMT > acpi0: wakeup devices HDAS(S3) XHC_(S4) XDCI(S4) RP01(S4) PXSX(S4) > RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) > RP06(S4) PXSX(S4) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimcfg0 at acpi0 > acpimcfg0: addr 0xe000, bus 0-255 > acpihpet0 at acpi0: 1920 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Celeron(R) N4020 CPU @ 1.10GHz, 1095.50 MHz, 06-7a-08 > 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB > 64b/line 16-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 19MHz > cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Celeron(R) N4020 CPU @ 1.10GHz, 1096.97 MHz, 06-7a-08 > 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,
Re: vmd(8): multi-process device emulation (plz test)
On Tue, Apr 25, 2023, at 9:47 AM, Dave Voutila wrote: > tech@: > > The below diff splits out virtio device emulation for virtio block and > network devices into separate fork+exec'd & pledge(2)'d subprocesses. > > In order of priority, this diff: > > 1. Isolates common exploit targets (e.g. emulated network devices) from >the rest of the vm process, tightening pledge to "stdio" per device. > > 2. Increases responsiveness of guest i/o since we no longer have a >single thread servicing virtio pci and device emulation. > > I'd like to land this diff this week, so if you use atypical vmd > configurations like: > > 1. multiple vioblk disks per vm > 2. multiple nics per vm > 3. send/receive > 4. qcow2 base images > > This diff has lots of info logging enabled by default to help me > identify what's breaking, so please reply with log message output if > something goes sideways. > > -dv Apologies for being late to the party, I'm testing this now via snapshots. The host in question was last updated a few weeks ago, i.e. before the deluge of recent work. It's an amd64 VMM host running (among other things) an i386 7.3 release VM. After updating the host to the latest snapshot, things appear to run fine, but I did notice the following new messages consistently when powering off (halt -p) the i386 VM: Apr 29 18:41:09 coofun /bsd: uvn_flush: obj=0xfd815a44fee0, offset=0x43287000. error during pageout. Apr 29 18:41:09 coofun /bsd: uvn_flush: WARNING: changes to page may be lost! Apr 30 17:28:26 coofun /bsd: uvn_flush: obj=0xfd812ff90c08, offset=0x4378c000. error during pageout. Apr 30 17:28:26 coofun /bsd: uvn_flush: WARNING: changes to page may be lost! The guest *appears* to run fine and reboots with a clean filesystem, but I also haven't gone through the filesystem with a comb. I have not had a chance to spin up an amd64 guest this weekend yet. Thanks! Brian Conway amd64 host dmesg: OpenBSD 7.3-current (GENERIC.MP) #1168: Fri Apr 28 14:47:06 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4072996864 (3884MB) avail mem = 3929907200 (3747MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x79851000 (17 entries) bios0: vendor American Megatrends Inc. version "GB1B 0.04" date 10/20/2021 bios0: BESSTAR TECH LIMITED N40 efi0 at bios0: UEFI 2.7 efi0: American Megatrends rev 0x5000d acpi0 at bios0: ACPI 6.2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP FPDT FIDT MSDM MCFG SSDT DBG2 DBGP HPET LPIT APIC NPKT SSDT SSDT SSDT SSDT SSDT SSDT BGRT TPM2 DMAR WDAT NHLT WSMT acpi0: wakeup devices HDAS(S3) XHC_(S4) XDCI(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) N4020 CPU @ 1.10GHz, 1095.50 MHz, 06-7a-08 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-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 19MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) N4020 CPU @ 1.10GHz, 1096.97 MHz, 06-7a-08 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (RP01) acpiprt2 at acpi0: bus 5 (RP02) acpiprt3 at acpi0: bus 1 (RP03) acpiprt4 at acpi0: bus 2 (RP04) acpiprt5 at acpi0: bus 3 (RP05) acpiprt6 at acpi0: bus -1 (RP06) acpipci0 at acpi0 PCI0: 0x0
tmpfs: eject it
tmpfs was disabled in GENERIC a bit shy of 7 years ago, is it time to kill it?
Skimming sbin/mount_tmpfs and sys/tmpfs, it looks like the vast majority of the
touches were part of wide-encompassing diffs, along with a couple tmpfs panic
fixes from the mailing lists.
My cvs diff-fu is not strong, the attached diff expects removal of the
following src files:
regress/sys/ffs/tmpfs/*
sbin/mount_tmpfs/*
sys/tmpfs/*
Diff successfully runs a full build + release. Thanks.
Brian Conway
Index: distrib/sets/lists/base/mi
===
RCS file: /cvs/src/distrib/sets/lists/base/mi,v
retrieving revision 1.1095
diff -u -p -u -p -r1.1095 mi
--- distrib/sets/lists/base/mi 10 Mar 2023 16:47:36 - 1.1095
+++ distrib/sets/lists/base/mi 19 Apr 2023 12:41:50 -
@@ -373,7 +373,6 @@
./sbin/mount_mfs
./sbin/mount_msdos
./sbin/mount_nfs
-./sbin/mount_tmpfs
./sbin/mount_udf
./sbin/mount_vnd
./sbin/mountd
Index: distrib/sets/lists/man/mi
===
RCS file: /cvs/src/distrib/sets/lists/man/mi,v
retrieving revision 1.1698
diff -u -p -u -p -r1.1698 mi
--- distrib/sets/lists/man/mi 5 Apr 2023 10:34:36 - 1.1698
+++ distrib/sets/lists/man/mi 19 Apr 2023 12:41:52 -
@@ -2535,7 +2535,6 @@
./usr/share/man/man8/mount_msdos.8
./usr/share/man/man8/mount_nfs.8
./usr/share/man/man8/mount_ntfs.8
-./usr/share/man/man8/mount_tmpfs.8
./usr/share/man/man8/mount_udf.8
./usr/share/man/man8/mount_vnd.8
./usr/share/man/man8/mountd.8
Index: sbin/Makefile
===
RCS file: /cvs/src/sbin/Makefile,v
retrieving revision 1.110
diff -u -p -u -p -r1.110 Makefile
--- sbin/Makefile 26 Feb 2021 17:17:03 - 1.110
+++ sbin/Makefile 19 Apr 2023 12:42:47 -
@@ -5,7 +5,7 @@ SUBDIR= atactl badsect bioctl clri dhcli
fsck_msdos fsdb fsirand growfs ifconfig iked init ipsecctl \
isakmpd kbd ldattach mknod mount \
mount_cd9660 mount_ext2fs mount_ffs mount_msdos \
- mount_nfs mount_ntfs mount_tmpfs mount_udf \
+ mount_nfs mount_ntfs mount_udf \
mount_vnd mountd ncheck_ffs newfs newfs_ext2fs newfs_msdos \
nfsd nologin pdisk pfctl pflogd ping quotacheck \
reboot resolvd restore route savecore scan_ffs \
Index: sbin/mount/mount.8
===
RCS file: /cvs/src/sbin/mount/mount.8,v
retrieving revision 1.90
diff -u -p -u -p -r1.90 mount.8
--- sbin/mount/mount.8 10 Mar 2019 14:42:21 - 1.90
+++ sbin/mount/mount.8 19 Apr 2023 12:42:48 -
@@ -406,7 +406,6 @@ with option
.Xr mount_msdos 8 ,
.Xr mount_nfs 8 ,
.Xr mount_ntfs 8 ,
-.Xr mount_tmpfs 8 ,
.Xr mount_udf 8 ,
.Xr mount_vnd 8 ,
.Xr sysctl 8 ,
Index: sbin/mount/mount.c
===
RCS file: /cvs/src/sbin/mount/mount.c,v
retrieving revision 1.76
diff -u -p -u -p -r1.76 mount.c
--- sbin/mount/mount.c 4 Dec 2022 23:50:46 - 1.76
+++ sbin/mount/mount.c 19 Apr 2023 12:42:48 -
@@ -597,21 +597,6 @@ prmount(struct statfs *sf)
(void)printf("%s%s", !f++ ? " (" : ", ", "gens");
if (iso_args->flags & ISOFSMNT_EXTATT)
(void)printf("%s%s", !f++ ? " (" : ", ", "extatt");
- } else if (strcmp(sf->f_fstypename, MOUNT_TMPFS) == 0) {
- struct tmpfs_args *tmpfs_args = &sf->mount_info.tmpfs_args;
-
- if (verbose || tmpfs_args->ta_root_uid ||
tmpfs_args->ta_root_gid)
- (void)printf("%s%s=%u, %s=%u", !f++ ? " (" : ", ",
- "uid", tmpfs_args->ta_root_uid, "gid",
tmpfs_args->ta_root_gid);
- if (verbose || tmpfs_args->ta_root_mode != 040755)
- (void)printf("%s%s=%04o", !f++ ? " (" : ", ",
- "mode", tmpfs_args->ta_root_mode & 0);
- if (verbose || tmpfs_args->ta_size_max)
- (void)printf("%s%s=%lu", !f++ ? " (" : ", ",
- "size", (unsigned long)tmpfs_args->ta_size_max);
- if (verbose || tmpfs_args->ta_nodes_max)
- (void)printf("%s%s=%lu", !f++ ? " (" : ", ",
- "inodes", (unsigned long)tmpfs_args->ta_nodes_max);
}
(void)printf(f ? ")\n" : "\n");
}
Index: share/man/man4/options.4
===
RCS file: /cvs/src/share/man/man4/options.4,v
retrieving revision 1.269
diff -u -p -u -p -r1.269 options.4
--- s
Re: em(4) multiqueue
On Thu, Apr 13, 2023, at 2:45 PM, Stuart Henderson wrote: > On 2023/04/13 13:30, Brian Conway wrote: >> Reviving this thread, apologies for discontinuity in mail readers: >> https://marc.info/?t=16564219358 >> >> After rebasing on 7.3, my results have mirrored Hrvoje's testing at the end >> of that thread. No issues with throughput, unusual latency, or reliability. >> `vmstat -i` shows some level of balancing between the queues. I've been >> testing on as many em(4) systems as I have access to, some manually, some in >> a packet forwarder/firewall scenarios: >> >> em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address >> 00:f1:f3:... >> em1 at pci2 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address >> 00:f1:f3:... >> em2 at pci3 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address >> 00:f1:f3:... >> em3 at pci4 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address >> 00:f1:f3:... >> em4 at pci5 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address >> 00:f1:f3:... >> em5 at pci6 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address >> 00:f1:f3:... >> >> em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, address >> 00:0d:b9:... >> em1 at pci2 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, address >> 00:0d:b9:... >> em2 at pci3 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, address >> 00:0d:b9:... >> >> em0 at pci1 dev 0 function 0 "Intel I211" rev 0x03, msix, 2 queues, address >> 00:0d:b9:... >> em1 at pci2 dev 0 function 0 "Intel I211" rev 0x03, msix, 2 queues, address >> 00:0d:b9:... >> em2 at pci3 dev 0 function 0 "Intel I211" rev 0x03, msix, 2 queues, address >> 00:0d:b9:... >> >> em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address >> 68:05:ca:... >> >> The only questions I have are around queue identification. All the specs >> I've been able to find indicate the I210 should have 4 queues, did Intel >> make a cheaper version with 2 toward the end of production? Or could it be >> an I211 masquerading as an I210 (and would that be bad for the driver)? > > Is it a 2-cpu machine? Ah, you're right. The level of detail I provided was insufficient. >> Also, >> https://www.mouser.com/pdfdocs/Intel_82574L_82574IT_GbE_Controller_brief.pdf >> indicates that the 82574L should have 2 queues? > > No msix in your dmesg excerpt for that one I'll lug that one back out and take a look. Probably safe to assume a misunderstanding on my part. Thanks. -b
Re: em(4) multiqueue
Reviving this thread, apologies for discontinuity in mail readers: https://marc.info/?t=16564219358 After rebasing on 7.3, my results have mirrored Hrvoje's testing at the end of that thread. No issues with throughput, unusual latency, or reliability. `vmstat -i` shows some level of balancing between the queues. I've been testing on as many em(4) systems as I have access to, some manually, some in a packet forwarder/firewall scenarios: em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address 00:f1:f3:... em1 at pci2 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address 00:f1:f3:... em2 at pci3 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address 00:f1:f3:... em3 at pci4 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address 00:f1:f3:... em4 at pci5 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address 00:f1:f3:... em5 at pci6 dev 0 function 0 "Intel I210" rev 0x03, msix, 2 queues, address 00:f1:f3:... em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, address 00:0d:b9:... em1 at pci2 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, address 00:0d:b9:... em2 at pci3 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, address 00:0d:b9:... em0 at pci1 dev 0 function 0 "Intel I211" rev 0x03, msix, 2 queues, address 00:0d:b9:... em1 at pci2 dev 0 function 0 "Intel I211" rev 0x03, msix, 2 queues, address 00:0d:b9:... em2 at pci3 dev 0 function 0 "Intel I211" rev 0x03, msix, 2 queues, address 00:0d:b9:... em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 68:05:ca:... The only questions I have are around queue identification. All the specs I've been able to find indicate the I210 should have 4 queues, did Intel make a cheaper version with 2 toward the end of production? Or could it be an I211 masquerading as an I210 (and would that be bad for the driver)? Also, https://www.mouser.com/pdfdocs/Intel_82574L_82574IT_GbE_Controller_brief.pdf indicates that the 82574L should have 2 queues? Anyway, great work, please let me know if there's more I can do to help this move forward. Brian Conway Lead Software Engineer, Owner RCE Software, LLC
Re: atactl: Update common SMART attribute names
On Sat, Feb 25, 2023, at 4:43 PM, Brian Conway wrote:
> The last times the attribute names were updated were 14 and 21 years
> ago. Modern drives, especially SSDs, get a lot of Unknown columns from
> the 'readattr' command.
>
> Attributes were coalesced from smartmontools, NetBSD's atactl, and
> Wikipedia's citations. Manufacturer-specific attributes and overrides
> were not attempted, as that's an imprecise art probably better left to
> smartmontools.
>
> Thanks for your time.
>
> Brian Conway
> RCE Software, LLC
ping
> diff --git sbin/atactl/atactl.c sbin/atactl/atactl.c
> index aaba61502..c4a1d20d5 100644
> --- sbin/atactl/atactl.c
> +++ sbin/atactl/atactl.c
> @@ -309,6 +309,28 @@ struct valinfo ibm_attr_names[] = {
> { 11, "Calibration Retry Count" },
> { 12, "Device Power Cycle Count" },
> { 13, "Soft Read Error Rate" },
> + { 100, "Erase/Program Cycles" },
> + { 103, "Translation Table Rebuild" },
> + { 160, "Uncorrectable Error Count" },
> + { 170, "Reserved Block Count" },
> + { 171, "Program Fail Count" },
> + { 172, "Erase Fail Count" },
> + { 173, "Wear Worst Case Erase Count" },
> + { 174, "Power-Off Retract Count" },
> + { 175, "Program Fail Count" },
> + { 176, "Erase Fail Count" },
> + { 177, "Wear Leveling Count" },
> + { 178, "Used Reserved Block Count" },
> + { 179, "Used Reserved Block Count Total" },
> + { 180, "Unused Reserved Block Count Total" },
> + { 181, "Program Fail Count Total" },
> + { 182, "Erase Fail Count" },
> + { 183, "Runtime Bad Block" },
> + { 184, "End-to-End error" },
> + { 185, "Head Stability" },
> + { 186, "Induced Op-Vibration Detection" },
> + { 187, "Reported Uncorrectable Errors" },
> + { 188, "Command Timeout" },
> { 189, "High Fly Writes" },
> { 190, "Airflow Temperature" },
> { 191, "G-Sense Error Rate" },
> @@ -341,8 +363,15 @@ struct valinfo ibm_attr_names[] = {
> { 228, "Power-Off Retract Count" },
> { 230, "GMR Head Amplitude" },
> { 231, "Temperature" },
> + { 232, "Available reserved space" },
> + { 233, "Media wearout indicator" },
> + { 235, "Power-Off Retract Count" },
> { 240, "Head Flying Hours" },
> + { 241, "Total LBAs Written" },
> + { 242, "Total LBAs Read" },
> + { 249, "NAND Writes (1GB)" },
> { 250, "Read Error Retry Rate" },
> + { 254, "Free Fall Sensor" },
> { 0, NULL },
> };
atactl: Update common SMART attribute names
The last times the attribute names were updated were 14 and 21 years ago.
Modern drives, especially SSDs, get a lot of Unknown columns from the
'readattr' command.
Attributes were coalesced from smartmontools, NetBSD's atactl, and Wikipedia's
citations. Manufacturer-specific attributes and overrides were not attempted,
as that's an imprecise art probably better left to smartmontools.
Thanks for your time.
Brian Conway
RCE Software, LLC
diff --git sbin/atactl/atactl.c sbin/atactl/atactl.c
index aaba61502..c4a1d20d5 100644
--- sbin/atactl/atactl.c
+++ sbin/atactl/atactl.c
@@ -309,6 +309,28 @@ struct valinfo ibm_attr_names[] = {
{ 11, "Calibration Retry Count" },
{ 12, "Device Power Cycle Count" },
{ 13, "Soft Read Error Rate" },
+ { 100, "Erase/Program Cycles" },
+ { 103, "Translation Table Rebuild" },
+ { 160, "Uncorrectable Error Count" },
+ { 170, "Reserved Block Count" },
+ { 171, "Program Fail Count" },
+ { 172, "Erase Fail Count" },
+ { 173, "Wear Worst Case Erase Count" },
+ { 174, "Power-Off Retract Count" },
+ { 175, "Program Fail Count" },
+ { 176, "Erase Fail Count" },
+ { 177, "Wear Leveling Count" },
+ { 178, "Used Reserved Block Count" },
+ { 179, "Used Reserved Block Count Total" },
+ { 180, "Unused Reserved Block Count Total" },
+ { 181, "Program Fail Count Total" },
+ { 182, "Erase Fail Count" },
+ { 183, "Runtime Bad Block" },
+ { 184, "End-to-End error" },
+ { 185, "Head Stability" },
+ { 186, "Induced Op-Vibration Detection" },
+ { 187, "Reported Uncorrectable Errors" },
+ { 188, "Command Timeout" },
{ 189, "High Fly Writes" },
{ 190, "Airflow Temperature" },
{ 191, "G-Sense Error Rate" },
@@ -341,8 +363,15 @@ struct valinfo ibm_attr_names[] = {
{ 228, "Power-Off Retract Count" },
{ 230, "GMR Head Amplitude" },
{ 231, "Temperature" },
+ { 232, "Available reserved space" },
+ { 233, "Media wearout indicator" },
+ { 235, "Power-Off Retract Count" },
{ 240, "Head Flying Hours" },
+ { 241, "Total LBAs Written" },
+ { 242, "Total LBAs Read" },
+ { 249, "NAND Writes (1GB)" },
{ 250, "Read Error Retry Rate" },
+ { 254, "Free Fall Sensor" },
{ 0, NULL },
};
Re: [patch] Detect and mitigate uncontrolled ACPI GPE storms
On Fri, Feb 24, 2023, at 6:52 AM, Dave Voutila wrote: > "Brian Conway" writes: > >> Greetings. I am soliciting feedback on a patch to detect and mitigate >> uncontrolled ACPI GPE interrupt storms. >> >> Rationale: There have been a number of threads in the recent past on bugs@ >> and misc@ with acpi0 spinning a CPU at 100% [1][2][3][4]. The immediate >> cause is likely a buggy BIOS and its ACPI implementation. However, this type >> of bug is not exclusive to no-name hardware from China, nor is it specific >> to a particular hardware vendor, BIOS vendor, or GPE pin. Hardware that is >> or was affected can include Intel [5], Lenovo [6], HP [7], ASUS [8], and >> Apple [9]. >> >> I have been testing with a half-dozen ACPI-equipped systems in various >> states: storming and behaving, booting and resuming, 7.2 and -current, SMALL >> and not. The attached diff uses a minimum 5-second evaluation window, driven >> by the firing of ACPI GPE interrupts (no additional accounting thread, etc). >> An uncontrolled GPE storm will be logged as such (real number): >> > > How about zzz and ZZZ cycles? I think you might be using the wrong clock > so I hypothesize this breaks. See getuptime(9). My apologies on the impreciseness of "resuming". Yes, I have tested zzz and ZZZ successfully, but certainly additional testing would be appreciated. I chose getuptime(9) for the tracking window as a monotonic source with a simple return type. Brian
[patch] Detect and mitigate uncontrolled ACPI GPE storms
Greetings. I am soliciting feedback on a patch to detect and mitigate
uncontrolled ACPI GPE interrupt storms.
Rationale: There have been a number of threads in the recent past on bugs@ and
misc@ with acpi0 spinning a CPU at 100% [1][2][3][4]. The immediate cause is
likely a buggy BIOS and its ACPI implementation. However, this type of bug is
not exclusive to no-name hardware from China, nor is it specific to a
particular hardware vendor, BIOS vendor, or GPE pin. Hardware that is or was
affected can include Intel [5], Lenovo [6], HP [7], ASUS [8], and Apple [9].
I have been testing with a half-dozen ACPI-equipped systems in various states:
storming and behaving, booting and resuming, 7.2 and -current, SMALL and not.
The attached diff uses a minimum 5-second evaluation window, driven by the
firing of ACPI GPE interrupts (no additional accounting thread, etc). An
uncontrolled GPE storm will be logged as such (real number):
Feb 17 22:57:06 acpitest3 /bsd: uncontrolled GPE storm 7242/s, disabling GPE 06
Alternatively, if this is still too close to papering over the problem, perhaps
a smaller diff that only logs the problem, allowing a user see what the storm
is and report it to their BIOS/hardware vendor?
Thank you for your time.
Brian Conway
[1] https://marc.info/?t=16642298181
[2] https://marc.info/?t=16649772664
[3] https://marc.info/?t=16735649053
[4] https://marc.info/?t=16761438961
[5]
https://community.intel.com/t5/Intel-NUCs/APCI-GPE-0x6F-Interrupt-Storm-under-OpenBSD/m-p/1426755
[6]
https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T480s-ACPI-bug/m-p/4057604
[7]
https://h30434.www3.hp.com/t5/Gaming-Notebooks/High-CPU-Usage-System-ACPI-sys-GPE-L6F-Storm-Omen-15-17/td-p/7169255
[8]
https://answers.microsoft.com/en-us/windows/forum/all/stopping-a-gpe-event-acpi-system-interrupts/cec51e6c-1ed4-4369-9e6f-108c4d6333a6
[9] https://bugzilla.kernel.org/show_bug.cgi?id=117481
diff --git sys/dev/acpi/acpi.c sys/dev/acpi/acpi.c
index 853bad1ab..26a5c1702 100644
--- sys/dev/acpi/acpi.c
+++ sys/dev/acpi/acpi.c
@@ -52,6 +52,9 @@
#define APMDEV_NORMAL 0
#define APMDEV_CTL 8
+#define GPE_RATE_MIN_CYCLE 5 /* seconds*/
+#define GPE_RATE_MAX 2000/* per second */
+
#include "wd.h"
#ifdef ACPI_DEBUG
@@ -98,6 +101,8 @@ void acpi_disable_allgpes(struct acpi_softc *);
struct gpe_block *acpi_find_gpe(struct acpi_softc *, int);
void acpi_enable_onegpe(struct acpi_softc *, int);
intacpi_gpe(struct acpi_softc *, int, void *);
+void acpi_init_gpe_rate(struct acpi_softc *, int);
+intacpi_gpe_rate(struct acpi_softc *, int);
void acpi_enable_rungpes(struct acpi_softc *);
@@ -2229,6 +2234,7 @@ acpi_enable_onegpe(struct acpi_softc *sc, int gpe)
dnprintf(50, "enabling GPE %.2x (current: %sabled) %.2x\n",
gpe, (en & mask) ? "en" : "dis", en);
acpi_write_pmreg(sc, ACPIREG_GPE_EN, gpe>>3, en | mask);
+ acpi_init_gpe_rate(sc, gpe);
}
/* Clear all GPEs */
@@ -2307,7 +2313,40 @@ acpi_gpe(struct acpi_softc *sc, int gpe, void *arg)
if (sc->gpe_table[gpe].flags & GPE_LEVEL)
acpi_write_pmreg(sc, ACPIREG_GPE_STS, gpe>>3, mask);
en = acpi_read_pmreg(sc, ACPIREG_GPE_EN, gpe>>3);
- acpi_write_pmreg(sc, ACPIREG_GPE_EN, gpe>>3, en | mask);
+ /* Re-enable if GPE rate passes, otherwise leave disabled */
+ if (!acpi_gpe_rate(sc, gpe))
+ acpi_write_pmreg(sc, ACPIREG_GPE_EN, gpe>>3, en | mask);
+ return (0);
+}
+
+void
+acpi_init_gpe_rate(struct acpi_softc *sc, int gpe)
+{
+ sc->gpe_table[gpe].rate_start = getuptime();
+ sc->gpe_table[gpe].rate_count = 0;
+}
+
+int
+acpi_gpe_rate(struct acpi_softc *sc, int gpe)
+{
+ struct gpe_block *pgpe = &sc->gpe_table[gpe];
+ time_t cycle;
+
+ pgpe->rate_count++;
+ dnprintf(10, "rate GPE %.2x start %lld elapsed %lld count %zu\n", gpe,
+ pgpe->rate_start, getuptime() - pgpe->rate_start, pgpe->rate_count);
+
+ cycle = getuptime() - pgpe->rate_start;
+ if (cycle >= GPE_RATE_MIN_CYCLE) {
+ if (pgpe->rate_count > (GPE_RATE_MAX * cycle)) {
+ printf("uncontrolled GPE storm %lld/s, disabling GPE
%.2x\n",
+ pgpe->rate_count / cycle, gpe);
+ return (1);
+ }
+
+ /* Reset and start a new cycle */
+ acpi_init_gpe_rate(sc, gpe);
+ }
return (0);
}
diff --git sys/dev/acpi/acpivar.h sys/dev/acpi/acpivar.h
index a9b4a2ae9..4e2f47053 100644
--- sys/dev/acpi/acpivar.h
+++ sys/dev/acpi/acpivar.h
@@ -185,6 +185,9 @@ struct gpe_block {
void *arg;
int active;
int flags;
+
+ time_t rate_start;
+ size_t rate_count;
};
struct acpi_devlist {
Re: sshd reorder fails when comp72.tgz not installed
Resolved in the latest snapshot, thank you. Brian On Thu, Jan 26, 2023, at 8:48 PM, Theo de Raadt wrote: > Ah of course. I will move the missing files into base. > > Brian Conway wrote: > >> Just a heads up, I was trying a few install variations of -current and >> noticed sshd reorder failing on boot on one of them. Unpacking >> /usr/share/relink/usr/sbin/sshd/sshd.tar and running `make -f >> Makefile.relink relink` by hand yielded: >> >> ld: error: cannot open crt0.o: No such file or directory >> cc: error: linker command failed with exit code 1 (use -v to see invocation) >> >> Sure enough, that particular install had base72 but not comp72. >> >> # tar ztf comp72.tgz|grep crt0.o >> ./usr/lib/crt0.o >> ./usr/lib/gcrt0.o >> ./usr/lib/rcrt0.o >> >> Not sure if this is worth being picky over, as non-compiler installs are >> rare/not recommended, but I wanted to make a mention just in case. Thanks.
sshd reorder fails when comp72.tgz not installed
Just a heads up, I was trying a few install variations of -current and noticed sshd reorder failing on boot on one of them. Unpacking /usr/share/relink/usr/sbin/sshd/sshd.tar and running `make -f Makefile.relink relink` by hand yielded: ld: error: cannot open crt0.o: No such file or directory cc: error: linker command failed with exit code 1 (use -v to see invocation) Sure enough, that particular install had base72 but not comp72. # tar ztf comp72.tgz|grep crt0.o ./usr/lib/crt0.o ./usr/lib/gcrt0.o ./usr/lib/rcrt0.o Not sure if this is worth being picky over, as non-compiler installs are rare/not recommended, but I wanted to make a mention just in case. Thanks. dmesg (amd64 VMM): OpenBSD 7.2-current (GENERIC) #949: Thu Jan 26 09:54:34 MST 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 1593823232 (1519MB) avail mem = 1526300672 (1455MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf36e0 (10 entries) bios0: vendor SeaBIOS version "1.14.0p0-OpenBSD-vmm" date 01/01/2011 bios0: OpenBSD VMM acpi at bios0 not configured cpu0 at mainbus0: (uniprocessor) cpu0: Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz, 2304.01 MHz, 06-8e-0a cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,CX8,SEP,PGE,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 6MB 64b/line 12-way L3 cache cpu0: smt 0, core 0, package 0 cpu0: using VERW MDS workaround pvbus0 at mainbus0: OpenBSD pvclock0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "OpenBSD VMM Host" rev 0x00 virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00 viornd0 at virtio0 virtio0: irq 3 virtio1 at pci0 dev 2 function 0 "Qumranet Virtio Network" rev 0x00 vio0 at virtio1: address fe:e1:bb:d1:69:3f virtio1: irq 5 virtio2 at pci0 dev 3 function 0 "Qumranet Virtio Storage" rev 0x00 vioblk0 at virtio2 scsibus1 at vioblk0: 1 targets sd0 at scsibus1 targ 0 lun 0: sd0: 24576MB, 512 bytes/sector, 50331648 sectors virtio2: irq 6 virtio3 at pci0 dev 4 function 0 "OpenBSD VMM Control" rev 0x00 vmmci0 at virtio3 virtio3: irq 7 isa0 at mainbus0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns8250, no fifo com0: console vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (4d3a796cdb2bafb8.a) swap on sd0b dump on sd0b Brian Conway
Re: vnconfig: don't print device when passed as an argument
Corrected mandoc(1) style, thanks.
Index: vnconfig.8
===
RCS file: /cvs/src/sbin/vnconfig/vnconfig.8,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 vnconfig.8
--- vnconfig.8 16 Aug 2022 13:59:51 - 1.7
+++ vnconfig.8 3 Oct 2022 16:08:54 -
@@ -83,8 +83,8 @@ with the regular file
allowing the latter to be accessed as though it were a disk.
If
.Ar vnd_dev
-is not specified, an unused one will be allocated and the name printed
-to
+is not specified, an unused one will be allocated.
+The name is printed to
.Va stdout .
.Pp
The options are as follows:
@@ -147,6 +147,7 @@ Configure a CD-ROM or DVD image file as
and mount the ISO 9660 file system contained in it:
.Bd -literal -offset indent
# vnconfig vnd0 /tmp/diskimage
+vnd0
# mount -t cd9660 /dev/vnd0c /mnt
.Ed
.Pp
@@ -160,6 +161,7 @@ a salt file with 2 rounds:
# vnconfig -K 2 vnd0 /tmp/cryptimg
Encryption key:
Salt file: /tmp/cryptsalt
+vnd0
# mount /dev/vnd0a /mnt
.Ed
.Sh SEE ALSO
Index: vnconfig.c
===
RCS file: /cvs/src/sbin/vnconfig/vnconfig.c,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 vnconfig.c
--- vnconfig.c 1 Sep 2022 01:52:08 - 1.11
+++ vnconfig.c 3 Oct 2022 16:08:54 -
@@ -284,11 +284,12 @@ config(char *file, char *dev, struct dis
struct vnd_ioctl vndio;
char *rdev;
int fd, rv = -1;
- int unit;
+ int unit, print_dev = 0;
if (dev == NULL) {
if (getinfo(NULL, &unit) == -1)
err(1, "no devices available");
+ print_dev = 1;
asprintf(&dev, "vnd%d", unit);
}
@@ -312,7 +313,8 @@ config(char *file, char *dev, struct dis
if (rv)
warn("VNDIOCSET");
else {
- printf("%s\n", dev);
+ if (print_dev)
+ printf("%s\n", dev);
if (verbose)
fprintf(stderr, "%s: %llu bytes on %s\n", dev,
vndio.vnd_size, file);
Brian
On Mon, Oct 3, 2022, at 10:56 AM, Brian Conway wrote:
> In d52ebfd8e572596739b84b5138ef7c090a3dc442
> (https://marc.info/?t=16619957111), vnconfig was changed to not
> print an auto-allocated device on errors, however it now prints it
> unconditionally, including when passed as an argument. One might
> consider this superfluous, but it is surely contrary to the manual.
>
> # dd if=/dev/zero of=/tmp/test.img bs=1m count=0 seek=1
> 0+0 records in
> 0+0 records out
> 0 bytes transferred in 0.000 secs (0 bytes/sec)
> # vnconfig /tmp/test.img
>
> vnd0
> # vnconfig -u vnd0
>
> # vnconfig vnd0 /tmp/test.img
> vnd0
>
> Two patches are below, one to change the printing to auto-allocation
> only, and the other to update the manual to reflect the current
> behavior. I suggest either or neither, but not both. Thanks.
>
> Brian Conway
> Lead Software Engineer, Owner
> RCE Software, LLC
>
> Index: vnconfig.8
> ===
> RCS file: /cvs/src/sbin/vnconfig/vnconfig.8,v
> retrieving revision 1.7
> diff -u -p -u -p -r1.7 vnconfig.8
> --- vnconfig.816 Aug 2022 13:59:51 - 1.7
> +++ vnconfig.83 Oct 2022 15:52:31 -
> @@ -83,7 +83,7 @@ with the regular file
> allowing the latter to be accessed as though it were a disk.
> If
> .Ar vnd_dev
> -is not specified, an unused one will be allocated and the name printed
> +is not specified, an unused one will be allocated. The name is printed
> to
> .Va stdout .
> .Pp
> @@ -147,6 +147,7 @@ Configure a CD-ROM or DVD image file as
> and mount the ISO 9660 file system contained in it:
> .Bd -literal -offset indent
> # vnconfig vnd0 /tmp/diskimage
> +vnd0
> # mount -t cd9660 /dev/vnd0c /mnt
> .Ed
> .Pp
> @@ -160,6 +161,7 @@ a salt file with 2 rounds:
> # vnconfig -K 2 vnd0 /tmp/cryptimg
> Encryption key:
> Salt file: /tmp/cryptsalt
> +vnd0
> # mount /dev/vnd0a /mnt
> .Ed
> .Sh SEE ALSO
> Index: vnconfig.c
> ===
> RCS file: /cvs/src/sbin/vnconfig/vnconfig.c,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 vnconfig.c
> --- vnconfig.c1 Sep 2022 01:52:08 - 1.11
> +++ vnconfig.c3 Oct 2022 15:52:31 -
> @@ -284,11 +284,12 @@ config(char *file, char *dev, struct dis
> struct vnd_ioctl vndio;
> char
vnconfig: don't print device when passed as an argument
In d52ebfd8e572596739b84b5138ef7c090a3dc442
(https://marc.info/?t=16619957111), vnconfig was changed to not print an
auto-allocated device on errors, however it now prints it unconditionally,
including when passed as an argument. One might consider this superfluous, but
it is surely contrary to the manual.
# dd if=/dev/zero of=/tmp/test.img bs=1m count=0 seek=1
0+0 records in
0+0 records out
0 bytes transferred in 0.000 secs (0 bytes/sec)
# vnconfig /tmp/test.img
vnd0
# vnconfig -u vnd0
# vnconfig vnd0 /tmp/test.img
vnd0
Two patches are below, one to change the printing to auto-allocation only, and
the other to update the manual to reflect the current behavior. I suggest
either or neither, but not both. Thanks.
Brian Conway
Lead Software Engineer, Owner
RCE Software, LLC
Index: vnconfig.8
===
RCS file: /cvs/src/sbin/vnconfig/vnconfig.8,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 vnconfig.8
--- vnconfig.8 16 Aug 2022 13:59:51 - 1.7
+++ vnconfig.8 3 Oct 2022 15:52:31 -
@@ -83,7 +83,7 @@ with the regular file
allowing the latter to be accessed as though it were a disk.
If
.Ar vnd_dev
-is not specified, an unused one will be allocated and the name printed
+is not specified, an unused one will be allocated. The name is printed
to
.Va stdout .
.Pp
@@ -147,6 +147,7 @@ Configure a CD-ROM or DVD image file as
and mount the ISO 9660 file system contained in it:
.Bd -literal -offset indent
# vnconfig vnd0 /tmp/diskimage
+vnd0
# mount -t cd9660 /dev/vnd0c /mnt
.Ed
.Pp
@@ -160,6 +161,7 @@ a salt file with 2 rounds:
# vnconfig -K 2 vnd0 /tmp/cryptimg
Encryption key:
Salt file: /tmp/cryptsalt
+vnd0
# mount /dev/vnd0a /mnt
.Ed
.Sh SEE ALSO
Index: vnconfig.c
===
RCS file: /cvs/src/sbin/vnconfig/vnconfig.c,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 vnconfig.c
--- vnconfig.c 1 Sep 2022 01:52:08 - 1.11
+++ vnconfig.c 3 Oct 2022 15:52:31 -
@@ -284,11 +284,12 @@ config(char *file, char *dev, struct dis
struct vnd_ioctl vndio;
char *rdev;
int fd, rv = -1;
- int unit;
+ int unit, print_dev = 0;
if (dev == NULL) {
if (getinfo(NULL, &unit) == -1)
err(1, "no devices available");
+ print_dev = 1;
asprintf(&dev, "vnd%d", unit);
}
@@ -312,7 +313,8 @@ config(char *file, char *dev, struct dis
if (rv)
warn("VNDIOCSET");
else {
- printf("%s\n", dev);
+ if (print_dev)
+ printf("%s\n", dev);
if (verbose)
fprintf(stderr, "%s: %llu bytes on %s\n", dev,
vndio.vnd_size, file);
Re: Silence vmd rtc_update_rega non-32KHz timebase spam
Ping with complete diff. Thanks.
Brian Conway
diff --git usr.sbin/vmd/mc146818.c usr.sbin/vmd/mc146818.c
index e3599c685..001c1a055 100644
--- usr.sbin/vmd/mc146818.c
+++ usr.sbin/vmd/mc146818.c
@@ -34,7 +34,6 @@
#include "vmd.h"
#include "vmm.h"
-#define MC_DIVIDER_MASK 0xe0
#define MC_RATE_MASK 0xf
#define NVRAM_CENTURY 0x32
@@ -236,10 +235,6 @@ rtc_reschedule_per(void)
static void
rtc_update_rega(uint32_t data)
{
-if ((data & MC_DIVIDER_MASK) != MC_BASE_32_KHz)
-log_warnx("%s: set non-32KHz timebase not supported",
-__func__);
-
rtc.regs[MC_REGA] = data;
if ((rtc.regs[MC_REGA] ^ data) & 0x0f)
vm_pipe_send(&dev_pipe, MC146818_RESCHEDULE_PER);
On Thu, Nov 18, 2021 at 8:02 AM Brian Conway wrote:
>
> Per https://marc.info/?l=openbsd-misc&m=159113575425726 , mlarkin@
> suggested someone can remove it. It's still pretty spammy at the
> current time for me.
>
> Brian Conway
> Software Engineer, Owner
> RCE Software, LLC
>
> diff --git usr.sbin/vmd/mc146818.c usr.sbin/vmd/mc146818.c
> index e3599c68504..17cf21221e5 100644
> --- usr.sbin/vmd/mc146818.c
> +++ usr.sbin/vmd/mc146818.c
> @@ -236,10 +236,6 @@ rtc_reschedule_per(void)
> static void
> rtc_update_rega(uint32_t data)
> {
> -if ((data & MC_DIVIDER_MASK) != MC_BASE_32_KHz)
> -log_warnx("%s: set non-32KHz timebase not supported",
> -__func__);
> -
> rtc.regs[MC_REGA] = data;
> if ((rtc.regs[MC_REGA] ^ data) & 0x0f)
> vm_pipe_send(&dev_pipe, MC146818_RESCHEDULE_PER);
Re: Silence vmd rtc_update_rega non-32KHz timebase spam
It appears the MC_DIVIDER_MASK define can also be removed, my bad.
Brian Conway
On Thu, Nov 18, 2021 at 8:02 AM Brian Conway wrote:
>
> Per https://marc.info/?l=openbsd-misc&m=159113575425726 , mlarkin@
> suggested someone can remove it. It's still pretty spammy at the
> current time for me.
>
> Brian Conway
> Software Engineer, Owner
> RCE Software, LLC
>
> diff --git usr.sbin/vmd/mc146818.c usr.sbin/vmd/mc146818.c
> index e3599c68504..17cf21221e5 100644
> --- usr.sbin/vmd/mc146818.c
> +++ usr.sbin/vmd/mc146818.c
> @@ -236,10 +236,6 @@ rtc_reschedule_per(void)
> static void
> rtc_update_rega(uint32_t data)
> {
> -if ((data & MC_DIVIDER_MASK) != MC_BASE_32_KHz)
> -log_warnx("%s: set non-32KHz timebase not supported",
> -__func__);
> -
> rtc.regs[MC_REGA] = data;
> if ((rtc.regs[MC_REGA] ^ data) & 0x0f)
> vm_pipe_send(&dev_pipe, MC146818_RESCHEDULE_PER);
Silence vmd rtc_update_rega non-32KHz timebase spam
Per https://marc.info/?l=openbsd-misc&m=159113575425726 , mlarkin@
suggested someone can remove it. It's still pretty spammy at the
current time for me.
Brian Conway
Software Engineer, Owner
RCE Software, LLC
diff --git usr.sbin/vmd/mc146818.c usr.sbin/vmd/mc146818.c
index e3599c68504..17cf21221e5 100644
--- usr.sbin/vmd/mc146818.c
+++ usr.sbin/vmd/mc146818.c
@@ -236,10 +236,6 @@ rtc_reschedule_per(void)
static void
rtc_update_rega(uint32_t data)
{
-if ((data & MC_DIVIDER_MASK) != MC_BASE_32_KHz)
-log_warnx("%s: set non-32KHz timebase not supported",
-__func__);
-
rtc.regs[MC_REGA] = data;
if ((rtc.regs[MC_REGA] ^ data) & 0x0f)
vm_pipe_send(&dev_pipe, MC146818_RESCHEDULE_PER);
Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?
I meant positioning the whole case bottom-up (i.e. but the hot surface at the top). Brian Conway On Mon, Nov 9, 2015 at 9:28 AM, Chris Cappuccio wrote: > Brian Conway [bcon...@rcesoftware.com] wrote: >> >> Taking into account Mr. Cappuccio's advice on using thermal paste >> between the CPU and heat spreader, and also positioning it bottom-up, >> this one stabilized at 51 C at idle. I haven't had a chance to do much >> benchmarking for higher temps yet, other than a run of `openssl speed` >> to warm it up. > > If you put the heat speader upside down, the sticky pad would be against > the cpu heatsink contact area?? There's only one way to put that device in.
Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?
Not much different to report with the 2 GB model, other than the expected changes in memory size and ethernet chips. Everything seems to work well. Taking into account Mr. Cappuccio's advice on using thermal paste between the CPU and heat spreader, and also positioning it bottom-up, this one stabilized at 51 C at idle. I haven't had a chance to do much benchmarking for higher temps yet, other than a run of `openssl speed` to warm it up. Brian Conway OpenBSD 5.8-current (GENERIC.MP) #1574: Thu Nov 5 22:51:41 MST 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1996152832 (1903MB) avail mem = 1931587584 (1842MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x77fb7020 (7 entries) bios0: vendor coreboot version "APU2A_20150924-3-g0bf9198-dirty" date 09/28/2015 bios0: PC Engines apu2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S2 S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC HEST SSDT SSDT HPET acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH3(S3) UOH5(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.25 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.13 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD GX-412TC SOC, 998.13 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD GX-412TC SOC, 998.13 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins ioapic1: misconfigured as apic 0, remapped to apid 5 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PBR4) acpiprt2 at acpi0: bus 1 (PBR5) acpiprt3 at acpi0: bus 2 (PBR6) acpiprt4 at acpi0: bus 3 (PBR7) acpiprt5 at acpi0: bus -1 (PBR8) acpicpu0 at acpi0: !C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu1 at acpi0: !C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu2 at acpi0: !C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu3 at acpi0: !C2(0@400 io@0x1771), C1(@1 halt!), PSS acpibtn0 at acpi0: PWRB cpu0: 998 MHz: speeds: 1000 800 600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 16h Root Complex" rev 0x00 pchb1 at pci0 dev 2 function 0 "AMD AMD64 16h Host" rev 0x00 ppb0 at pci0 dev 2 function 2 "AMD AMD64 16h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 em0 at pci1 dev 0 function 0 "Intel
Re: lighter sleep
I recall this discussion on UTF-8 and locales: http://undeadly.org/cgi?action=article&sid=20150722182236 I imagine there was more elsewhere that I didn't see. Brian On Sep 22, 2015 7:07 AM, "Benny Lofgren" wrote: > On 2015-09-21 16:45, Mark Kettenis wrote: > >> From: Christian Weisgerber > >> Date: Mon, 21 Sep 2015 14:29:03 + (UTC) > >> > >> On 2015-09-21, Stefan Sperling wrote: > >> > > You could argue that the thousands separator should be supported though: > > > > $ sleep 1.000.000 > > > > if your locale is something vaguely european, and > > > > # sleep 1,000,000 > > > > for the north-americans. > > > > But let's not go there... > > In my locale (Sweden), the thousands separator is space... try to > meaningfully parse sleep 1 000 000 without all of a sudden introducing > mandatory quoting. :-) So no, let's not go there... > > > Like many others I've seen plenty of trainwrecks caused by mindless > internationalization in other operating systems, and how it wreaks havoc > in scripts and interpretation of piped data. It is NOT pretty. > > The stance that the base system should only speak English and use > time-tried and known formats is IMO the correct one. > > > With that said, we do live in an international world and I was alarmed > about something Stefan wrote earlier in this thread: > > > When we still had latin1 etc. it was possible in theory that values > between > > 128 and 255 represented a digit. But now, isdigit() does the same > regardless > > of locale setting (C or UTF-8) since it cannot be given a multibyte > sequence, > > i.e. it will not deal with character values above 127. > > Maybe I'm the only one that this is news to (and I admit I obviosly > haven't followed tech@ and misc@ closely enough lately), but am I > interpreting this correctly in understanding that 8-bit locales except > for the "C" locale (which is effectively a 7-bit locale) are gone? > > > That would be extremely unfortunate, since UTF-8 (even if it was fully > implemented in OpenBSD which of course it isn't) is *not* the sole > answer to the world's localization problems. At least not in the > forseeable future. > > For example, I still have plenty of systems running that absolutely > relies on a working ISO 8859-1 environment, and not just in the sense > that it is 8-bit transparent but in understanding collation orders, > proper case folding and functioning of the is...() macros/functions etc. > > > I tried to google for more on this issue, but came up pretty thin. Has > this been discussed publicly somewhere? If this is due to shortage of > manpower or interest or something like that, maybe we can do something > about that. > > I'm sure it isn't still a matter of lack of knowledge of the problems > facing us non-native English speakers - since I know OpenBSD developers > come from all corners of the world - so please someone tell me I've > misunderstood, or that it's just a bad dream and I'll wake up soon. :-) > > > * * * > > Are there more people like me who really could use more complete i18n > support in OpenBSD (multibyte as well as legacy 8-bit) and are willing > to make efforts into implementing it? > > Is there a coordinated effort somewhere? If not, let's discuss it! > Offlist is fine of course if it isn't of general interest (but I think > it is). And by "implementing", of course I mean doing it right, the > OpenBSD way. > > If there is interest but no coordination, I can start it off and try to > make an inventory of the current state of implementation and what > efforts may already be ongoing (or dormant or abandoned, due to lack of > interest/time/manpower/resources/pizza/beer/hikes). > > What say ye? > > * * * > > > Regards, > /Benny > >
ssh_config.5 sshd_config.5 - update cipher order
This matches the current myproposal.h ordering with chacha20-poly1305's promotion (and referenced in various release notes). Please correct if I've misunderstood or misformatted. Thanks. Index: usr.bin/ssh/ssh_config.5 === RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v retrieving revision 1.214 diff -u -p -u -p -r1.214 ssh_config.5 --- usr.bin/ssh/ssh_config.5 30 Jul 2015 00:01:34 - 1.214 +++ usr.bin/ssh/ssh_config.5 11 Aug 2015 02:54:48 - @@ -415,9 +415,9 @@ chacha20-poly1...@openssh.com .Pp The default is: .Bd -literal -offset indent +chacha20-poly1...@openssh.com, aes128-ctr,aes192-ctr,aes256-ctr, aes128-...@openssh.com,aes256-...@openssh.com, -chacha20-poly1...@openssh.com, arcfour256,arcfour128, aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc, aes192-cbc,aes256-cbc,arcfour Index: usr.bin/ssh/sshd_config.5 === RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.210 diff -u -p -u -p -r1.210 sshd_config.5 --- usr.bin/ssh/sshd_config.5 6 Aug 2015 14:53:21 - 1.210 +++ usr.bin/ssh/sshd_config.5 11 Aug 2015 02:54:48 - @@ -477,9 +477,9 @@ chacha20-poly1...@openssh.com .Pp The default is: .Bd -literal -offset indent +chacha20-poly1...@openssh.com, aes128-ctr,aes192-ctr,aes256-ctr, -aes128-...@openssh.com,aes256-...@openssh.com, -chacha20-poly1...@openssh.com +aes128-...@openssh.com,aes256-...@openssh.com .Ed .Pp The list of available ciphers may also be obtained using the Brian Conway
