terminal tab stop incorrect until reset
This came up long ago, but I've lost the mail, and the problem remains. When printing a line of text containing vt100 escapes and tabs, the tab stops are not set correctly. After running reset, they are. Repro: Open a new xterm and run printf "\e[32m\tgreen\e[0m\n". Observe four space indent. Run reset and run printf again. Observe eight spaces. One of the magic OXTABS bits needs to be adjusted? I thought that was the proposed resolution?
immediate acpitz shutdown
Turned on my laptop (samsung 9 ativ) and immediately shutdown because acpitz was 144C. That seems rather unlikely. This repeated through a few reboots, and also after going back to a previous kernel, so I'm not sure if anything changed. It just woke up unhappy today. Probably not actionable, but reporting for the record. OpenBSD 6.6-current (GENERIC.MP) #583: Wed Jan 1 12:21:07 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8480653312 (8087MB) avail mem = 8211169280 (7830MB) User Kernel Config UKC> disable acpitz 418 acpitz* disabled UKC> quit Continuing... mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed250 (77 entries) bios0: vendor American Megatrends Inc. version "P03AEU.079.150709.MK" date 07/09/2015 bios0: SAMSUNG ELECTRONICS CO., LTD. 930X2K/931X2K acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI LPIT MSDM SSDT SSDT SSDT SSDT SSDT DMAR CSRT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(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) M-5Y31 CPU @ 0.90GHz, 1995.73 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,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) M-5Y31 CPU @ 0.90GHz, 1995.39 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,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 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) M-5Y31 CPU @ 0.90GHz, 1995.39 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,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) M-5Y31 CPU @ 0.90GHz, 1995.38 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,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 acpihpet0 at acpi0: 14318179 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 (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 -1 (RP08) acpiec0 at acpi0 acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at
ryzen disabled L3 cache
An oddity I noticed in dmesg: cpu0: AMD Ryzen 7 3700X 8-Core Processor, 3600.44 MHz, 17-71-00 cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 32MB 64b/line disabled L3 cache Why is my L3 cache disabled? I saw some other ryzen dmesg reports, but for different CPU models, and none of them said disabled. Is this an openbsd reporting problem or a system problem? OpenBSD 6.6-current (GENERIC.MP) #484: Fri Nov 22 08:53:13 MST 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 68651323392 (65471MB) avail mem = 66558337024 (63474MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe6cf0 (62 entries) bios0: vendor American Megatrends Inc. version "B.30" date 10/29/2019 bios0: Micro-Star International Co., Ltd. MS-7A38 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT SSDT MCFG HPET UEFI IVRS PCCT SSDT CRAT CDIT BGRT SSDT SSDT WSMT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) GPPF(S4) GP10(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 Ryzen 7 3700X 8-Core Processor, 3600.44 MHz, 17-71-00 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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 32MB 64b/line disabled L3 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 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 100MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: AMD Ryzen 7 3700X 8-Core Processor, 3599.99 MHz, 17-71-00 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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 32MB 64b/line disabled L3 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: AMD Ryzen 7 3700X 8-Core Processor, 3599.99 MHz, 17-71-00 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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 32MB 64b/line disabled L3 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: AMD Ryzen 7 3700X 8-Core Processor, 3599.99 MHz, 17-71-00 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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 32MB 64b/line disabled L3 cache cpu3: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: smt 0, core 3, package 0 cpu4 a
Re: ios 13 dhcpd vs dhclient stale lease
Ted Unangst wrote: > I'm not sure where the bug is exactly (seems probable it could be an apple > problem), but for the record... I think this was fixed with an apple update? Nothing in the release notes of course, but it doesn't seem to happen anymore.
Re: ssh asks for key password incorrectly?
Damien Miller wrote: > On Sun, 20 Oct 2019, Ted Unangst wrote: > > > Ah, so when this happens, it's on a machine that doesn't have > > id_ed25519.pub. > > Here's a before and after ssh -vvv for reference. > > ah, so you have just the private key id_ed25519 and no corresponding > pubkey on this machine? not intentionally, just happenstance. anyway, since that seems to be the root cuase, and it's kinda odd, feel free to ignore if this is how it should work.
Re: ssh asks for key password incorrectly?
Damien Miller wrote: > On Sun, 20 Oct 2019, Ted Unangst wrote: > > > I have two OpenBSD machines, let's call them laptop and desktop. desktop is > > a > > bit older, and has a ecdsa-sha2-nistp256 key in .ssh/authorized_keys. laptop > > is configured with a ssh-ed25519 .ssh/id_ed25519 key file. The keyfile has a > > password and I use ssh-agent and ssh-add to unlock it. > > > > What happens: I ssh from laptop to desktop and ssh asks for the id_ed25519 > > password. This doesn't accomplish much, since it isn't authorized on desktop > > anyway. > > > > Expected: If the key doesn't work, I should be asked for the remote system > > password, not the key password. The key has already been unlocked via > > ssh-add. > > > > Theory: ssh tries the key, doesn't work, then gets confused when it goes > > back > > into the .ssh for more options and asks to unlock a key it's already seen. > > > > I think this is a regression, I've had similar setup for ages and never > > noticed this before. > > Could you send the output of "ssh -vvv desktop" from the laptop side? > Also, what are the permissions for ~/.ssh/id_ed25519*? Ah, so when this happens, it's on a machine that doesn't have id_ed25519.pub. Here's a before and after ssh -vvv for reference. Note that it works fine (without the pub key) connecting to a host that does have authorized_keys including ed25519. ativ:~> ssh -vvv 10.3.3.32 OpenSSH_8.1, LibreSSL 3.0.2 debug1: Reading configuration data /home/tedu/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug2: resolve_canonicalize: hostname 10.3.3.32 is address debug1: auto-mux: Trying existing master debug1: Control socket "/home/tedu/.ssh/ctrl-tedu@10.3.3.32:22" does not exist debug2: ssh_connect_direct debug1: Connecting to 10.3.3.32 [10.3.3.32] port 22. debug1: Connection established. debug1: identity file /home/tedu/.ssh/id_rsa type -1 debug1: identity file /home/tedu/.ssh/id_rsa-cert type -1 debug1: identity file /home/tedu/.ssh/id_dsa type -1 debug1: identity file /home/tedu/.ssh/id_dsa-cert type -1 debug1: identity file /home/tedu/.ssh/id_ecdsa type -1 debug1: identity file /home/tedu/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/tedu/.ssh/id_ed25519 type -1 debug1: identity file /home/tedu/.ssh/id_ed25519-cert type -1 debug1: identity file /home/tedu/.ssh/id_xmss type -1 debug1: identity file /home/tedu/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9 debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x0400 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to 10.3.3.32:22 as 'tedu' debug3: hostkeys_foreach: reading file "/home/tedu/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /home/tedu/.ssh/known_hosts:5 debug3: load_hostkeys: loaded 1 keys from 10.3.3.32 debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 debug3: send packet: type 20 debug1: SSH2_MSG_KEXINIT sent debug3: receive packet: type 20 debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c debug2: host key algorithms: ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-...@openssh.com,rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa debug2: ciphers ctos: chacha20-poly1...@openssh.com,aes128-ctr,aes128-...@openssh.com debug2: ciphers stoc: chacha20-poly1...@openssh.com,aes128-ctr,aes128-...@openssh.com debug2: MACs ctos: umac-64-...@openssh.com,umac...@openssh.com,hmac-sha2-256,hmac-sha1 debug2: MACs stoc: umac-64-...@openssh.com,umac...@openssh.com,hmac-sha2-256,hmac-sha1 debug2: compression ctos: none,z...@openssh.com,zlib debug2: compression stoc: none,z...@openssh.com,zlib debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug2: peer server KEXINIT proposal debug2: KEX algorithms: curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha
ssh asks for key password incorrectly?
I have two OpenBSD machines, let's call them laptop and desktop. desktop is a bit older, and has a ecdsa-sha2-nistp256 key in .ssh/authorized_keys. laptop is configured with a ssh-ed25519 .ssh/id_ed25519 key file. The keyfile has a password and I use ssh-agent and ssh-add to unlock it. What happens: I ssh from laptop to desktop and ssh asks for the id_ed25519 password. This doesn't accomplish much, since it isn't authorized on desktop anyway. Expected: If the key doesn't work, I should be asked for the remote system password, not the key password. The key has already been unlocked via ssh-add. Theory: ssh tries the key, doesn't work, then gets confused when it goes back into the .ssh for more options and asks to unlock a key it's already seen. I think this is a regression, I've had similar setup for ages and never noticed this before.
ios 13 dhcpd vs dhclient stale lease
I'm not sure where the bug is exactly (seems probable it could be an apple problem), but for the record... When my laptop roams from my home wifi to my phone hotspot, it retains the same IP it had on the home network, which doesn't work with the phone network. Running dhclient manually results in it supposedly getting the same IP: iwm0: bound to 10.3.3.63 from 172.20.10.1 The only way to get a working IP is to delete the dhclient.leases file, then run it again. At last: iwm0: bound to 172.20.10.6 from 172.20.10.1 I'm not sure what can be done. Does ios echo back our suggestion incorrectly? Does it return some result that dhclient misinterprets? No idea. We could detect this condition perhaps? Anyway, there's a workaround for affected people.
Re: Bypass doas password check with chroot
Ted Unangst wrote: > I think this is not the right note, but after some review I just realized we > don't ever say that a password is required. It's merely hinted at in various > options. I'll make a note of that. Just a simple sentence, but I think it makes explicit the behavior. Index: doas.1 === RCS file: /home/cvs/src/usr.bin/doas/doas.1,v retrieving revision 1.22 diff -u -p -r1.22 doas.1 --- doas.1 21 Jun 2019 17:02:27 - 1.22 +++ doas.1 4 Jul 2019 15:29:00 - @@ -40,6 +40,9 @@ or .Fl s is specified. .Pp +The user will be required to authenticate by entering their password, +unless configured otherwise. +.Pp By default, a new environment is created. The variables .Ev HOME ,
Re: Bypass doas password check with chroot
cho...@jtan.com wrote: > Ingo Schwarze writes: > > I see nothing wrong with it. It is easier to describe in the manual > > Indeed I was not suggesting that there was something wrong; being asked for a > password when doing something which root could implicitly do simply confused > me for a moment which prompted figuring out what the situation was. > > > The bikeshed has already been painted, and no matter whether you are > > justified in calling the colour that tedu@ chose "pink", i wouldn't > > see an obvious benefit in re-painting it now. > > I have no desire to change this behaviour or engage in bike-shedding. Please > no. Perhaps instead 5 free lines? I think this is not the right note, but after some review I just realized we don't ever say that a password is required. It's merely hinted at in various options. I'll make a note of that. > > --- doas.1.~1.19.~ Sun Sep 4 18:20:37 2016 > +++ doas.1 Thu Jul 4 01:26:21 2019 > @@ -85,6 +85,12 @@ > Execute the command as > .Ar user . > The default is root. > +.Sh NOTE > +Although the kernel imposes no restrictions on the root user's ability > +to pose as any other user, > +.Nm > +will always require a password as per its configuration in order to > +keep unnecessary complications out of a critical security utility. > .El > .Sh EXIT STATUS > .Ex -std doas > > Not necessary of course but would have been nice for my peace of mind the > other day when it happened (ie. to know that the situation has been duly > considered). btw. I've never done anything with mdoc before so I expect > there's a better macro to use to head this than .Sh but that's really not the > point. > > > Please do not cross-post between different OpenBSD lists. > > Apologies and understood. > > Matthew >
Re: "infinite" gethostbyname(3)
Martin Pieuchot wrote: > When my machine doesn't get a reply from a DNS server, generally the > wifi router of the place where I'm drinking coffee, applications sit > in gethostbyname(3) "indefinitely". At least too long for me to wait > and I end up killing the app. We used to add an entry for the machine's hostname to /etc/hosts, but this lead to other problems and was removed some years ago I believe. Personally, I think it's a likely bug for software to resolve local hostname. You already know the hostname, it's just gethostname(), and if you really need to know the IP, it's in ifconfig, etc., but there's no reason to believe there's only one IP or that other machines will know that this system has this name.
Re: panic on vmctl start
Klemens Nanni wrote: > Surprisingly simple, the last commit in that range broke it: > > revision 1.238 > date: 2019/04/18 18:51:34; author: mlarkin; > jMpas4GuYFG5; > vmm(4): whitespace fix > > Reverting the first hunk of this commit fixes `vmctl start vpn' for me. > > Feedback? OK? obviously not intended. ok. > > Index: arch/amd64/amd64/vmm.c > === > RCS file: /cvs/src/sys/arch/amd64/amd64/vmm.c,v > retrieving revision 1.238 > diff -u -p -r1.238 vmm.c > --- arch/amd64/amd64/vmm.c18 Apr 2019 18:51:34 - 1.238 > +++ arch/amd64/amd64/vmm.c20 Apr 2019 22:56:37 - > @@ -40,7 +40,7 @@ > > #include > > -#define VMM_DEBUG > +/* #define VMM_DEBUG */ > > void *l1tf_flush_region; > >
Re: Cannot set locale categories independently with POSIX 2008 locales
Karl Williamson wrote: > On 3/28/19 8:03 AM, Ingo Schwarze wrote: > >It is unspecified whether the locale object pointed to by base > >shall be modified, or freed and a new locale object created. > > I can see how you might be able to argue for your interpretation. I > believe the wording in the spec is poor in this case (and it isn't the > only such place). I, and every other implementer takes the above text > to mean, that it's up to the implementation as to how to combine 'base' > with the new locale specified by the other parameters. 'base' can be > modified and returned, or 'base' can be freed with some new locale which > is the combination of 'base' and the other parameters. I don't take > that wording to mean that 'base' can be irrelevant. That can't be the > intent, as that would mean wildly unportable code, and no way for the > program to specify an update to a category in isolation from the others. I would agree. > > In any case, in the commit message, do not call it a "bug fix", > > describe it as a change for compatibility with other systems. > > > > Ted, feel free to either commit this version or tell me to commit. Your version is good to commit. If you like, you may call it a workaround for a specification bug that permitted the current behavior. :)
Re: Cannot set locale categories independently with POSIX 2008 locales
Karl Williamson wrote:
> > This should fix things.
>
> Does it work if 'oldloc' is 0? a legal value
Nope. Good catch.
Index: newlocale.c
===
RCS file: /home/cvs/src/lib/libc/locale/newlocale.c,v
retrieving revision 1.1
diff -u -p -r1.1 newlocale.c
--- newlocale.c 5 Sep 2017 03:16:13 - 1.1
+++ newlocale.c 27 Mar 2019 22:01:12 -
@@ -22,8 +22,7 @@
#include "rune.h"
locale_t
-newlocale(int mask, const char *locname,
-locale_t oldloc __attribute__((__unused__)))
+newlocale(int mask, const char *locname, locale_t oldloc)
{
int ic, flag;
@@ -45,7 +44,7 @@ newlocale(int mask, const char *locname,
/* Only character encoding has thread-specific effects. */
if ((mask & LC_CTYPE_MASK) == 0)
- return _LOCALE_C;
+ return oldloc ? oldloc : _LOCALE_C;
/* The following may initialize UTF-8 for later use. */
if ((locname = _get_locname(LC_CTYPE, locname)) == NULL) {
Re: Cannot set locale categories independently with POSIX 2008 locales
Karl Williamson wrote:
> This has been reported from multiple sources, and we at Perl 5 have
> diagnosed the problem
>
> If LC_CTYPE is set to C.UTF-8, it is not possible to set any other
> category independently to either C or C.UTF-8 without inadvertently
> setting LC_CTYPE back to C. The attached program demonstrates the problem.
Thanks for a very thorough report. I believe your guesses about the
implementation were quite accurate. :)
This should fix things.
Index: newlocale.c
===
RCS file: /home/cvs/src/lib/libc/locale/newlocale.c,v
retrieving revision 1.1
diff -u -p -r1.1 newlocale.c
--- newlocale.c 5 Sep 2017 03:16:13 - 1.1
+++ newlocale.c 27 Mar 2019 06:25:01 -
@@ -22,8 +22,7 @@
#include "rune.h"
locale_t
-newlocale(int mask, const char *locname,
-locale_t oldloc __attribute__((__unused__)))
+newlocale(int mask, const char *locname, locale_t oldloc)
{
int ic, flag;
@@ -45,7 +44,7 @@ newlocale(int mask, const char *locname,
/* Only character encoding has thread-specific effects. */
if ((mask & LC_CTYPE_MASK) == 0)
- return _LOCALE_C;
+ return oldloc;
/* The following may initialize UTF-8 for later use. */
if ((locname = _get_locname(LC_CTYPE, locname)) == NULL) {
Re: ping issue with rdomains
Claudio Jeker wrote: > Ping is a bit of a special case since it runs with user _ping when started > as root. So by the time the SO_RTABLE is issued it does not have the privs > to do it. The ping -V option only works when used in rdomain 0. Maybe we can drop privs a little later if we started running as root? Just after getopt, which lets the setsockopt work, but before we do anything dangerous. Index: ping.c === RCS file: /home/cvs/src/sbin/ping/ping.c,v retrieving revision 1.234 diff -u -p -r1.234 ping.c --- ping.c 13 Nov 2018 14:30:36 - 1.234 +++ ping.c 19 Mar 2019 03:07:27 - @@ -283,9 +283,9 @@ main(int argc, char *argv[]) uid = getuid(); gid = getgid(); } - if (setgroups(1, &gid) || + if (ouid && (setgroups(1, &gid) || setresgid(gid, gid, gid) || - setresuid(uid, uid, uid)) + setresuid(uid, uid, uid))) err(1, "unable to revoke privs"); preload = 0; @@ -428,6 +428,11 @@ main(int argc, char *argv[]) usage(); } } + + if (ouid == 0 && (setgroups(1, &gid) || + setresgid(gid, gid, gid) || + setresuid(uid, uid, uid))) + err(1, "unable to revoke privs"); argc -= optind; argv += optind;
confusing install error with no net
Was performing an upgrade, got to the part about asking where the sets are. Specified http. https didn't work (just an internal httpd server, that's normal.) Say yes, try http. Get the error that no sets were found. Took me a few retries, guessing that maybe I typed the path wrong, but the problem was I didn't have any network interfaces configured. I'm not sure what exactly could be improved. Maybe just a better error message? "Found no openbsd sets" implies it was able to connect and look. Or maybe get fancy and if ifconfig reports no addresses print a warning?
Re: pthread_rwlock deadlock
Sebastien Marie wrote: > > does it makes sens to call __sflush() instead of fflush() in vdprintf() ? > > the FILE variable used by vdprintf() is "home made" on the stack, using > a buffer on the stack too. And as fflush() only enclose __sflush() > with FILE locking, I don't see the gain to use fflush() here. This makes sense. ok me too.
Re: pthread_rwlock deadlock
Visa Hankala wrote: > On Sat, Mar 02, 2019 at 10:29:07AM +0100, Sebastien Marie wrote: > > I am experiencing dead-lock with the new futex based rwlock > > implementation commited few days ago. > > The problem happens if a read-write lock has been read-locked and > there are multiple writers waiting. The unlock routine will clear the > waiter flag and wake up a single waiter. If no new waiters emerge > before the next unlock, no wakeup will be issued. > > A simple fix is to wake all waiters, so that no wakeup is lost. > That may cause a thundering herd effect with writers though. The > implementation could encode the number of waiters in `rwlock->value', > enabling more discreet wakeups. However, that needs more testing. > > Does the following patch help? This looks ok to me. > > Index: rthread_rwlock.c > === > RCS file: src/lib/librthread/rthread_rwlock.c,v > retrieving revision 1.12 > diff -u -p -r1.12 rthread_rwlock.c > --- rthread_rwlock.c 13 Feb 2019 13:22:14 - 1.12 > +++ rthread_rwlock.c 2 Mar 2019 13:35:31 - > @@ -273,7 +273,7 @@ pthread_rwlock_unlock(pthread_rwlock_t * > } while (atomic_cas_uint(&rwlock->value, val, new) != val); > > if (new == UNLOCKED && (val & WAITING)) > - _wake(&rwlock->value, COUNT(val)); > + _wake(&rwlock->value, INT_MAX); > > return (0); > } >
Re: pthread_rwlock deadlock
Visa Hankala wrote: > On Sat, Mar 02, 2019 at 04:37:04PM +0100, Sebastien Marie wrote: > > Thread 1 (thread 469200): > > #0 sched_yield () at -:3 > > #1 0x0a8c0609d9c5 in _libc__spinlock (lock=Variable "lock" is not > > available.) at /usr/src/lib/libc/thread/rthread.c:50 > > #2 0x0a8c060702be in _thread_flockfile (fp=0x7f7cfaa8) at > > /usr/src/lib/libc/thread/rthread_file.c:180 > > #3 0x0a8c0609e11a in _libc_fflush (fp=0x7f7cfaa8) at > > /usr/src/lib/libc/stdio/fflush.c:46 > > #4 0x0a8c0606c89a in _libc_vdprintf (fd=Variable "fd" is not > > available.) at /usr/src/lib/libc/stdio/vdprintf.c:72 > > #5 0x0a8c060a7f63 in _libc__rthread_debug (level=Variable "level" is > > not available.) at /usr/src/lib/libc/thread/rthread_debug.c:23 > > #6 0x0a8c060410c5 in _rthread_mutex_timedlock (mutexp=Variable > > "mutexp" is not available.) at /usr/src/lib/libc/thread/rthread_mutex.c:163 > > #7 0x0a8c060bc482 in malloc (size=56) at > > /usr/src/lib/libc/stdlib/malloc.c:1253 > > #8 0x0a8c060703e4 in _thread_flockfile (fp=0x7f7d02b8) at > > /usr/src/lib/libc/thread/rthread_file.c:156 > > #9 0x0a8c0609e11a in _libc_fflush (fp=0x7f7d02b8) at > > /usr/src/lib/libc/stdio/fflush.c:46 > > #10 0x0a8c0606c89a in _libc_vdprintf (fd=Variable "fd" is not > > available.) at /usr/src/lib/libc/stdio/vdprintf.c:72 > > #11 0x0a8c060a7f63 in _libc__rthread_debug (level=Variable "level" is > > not available.) at /usr/src/lib/libc/thread/rthread_debug.c:23 > > #12 0x0a8c3c2792b6 in _rthread_reaper () at > > /data/openbsd/src/lib/librthread/rthread.c:260 > > #13 0x0a8c3c279229 in pthread_join (thread=Variable "thread" is not > > available.) at /data/openbsd/src/lib/librthread/rthread.c:319 > > #14 0x0a8993d1a705 in main (argc=1, argv=0x7f7d0ab8) at test.c:86 > > This does not look good. The thread is recursing with hash_lock of > rthread_file.c. Apparently triggered by the debug output routine. > Yeah, I think thread_debug needs to use snprintf and write the message itself.
Re: OpenBSD 6.4 doesn't boot on 486 class processor anymore
Philip Guenther wrote: > The problem is that ucode_load() in sys/arch/i386/stand/libsa/exec_i386.c > uses CPUID() without checking whether the cpuid instruction is supported. > There are currently three places in sys/arch/i386/stand/libsa which make > that check: cpuprobe.c, machdep.c, and random_i386.S. ucode_load() could > copy the chunk from machdep.c...or someone could add a global and do the > check once, early... Or we make cpuid a required feature?
Re: ure not detected with ramdisk
Theo de Raadt wrote: > Ted Unangst wrote: > > > Thinkpad X1 2015. I have a ure that works fine with normal kernels but was > > not > > detected when using the ramdisk. > > 'cause it isn't in the config?? > > So the process is you add it, build a ramdisk, report the size increase, > and a few of us mull what that number means for future growth we might > need 'cause ramdisks can be quite a bit bigger than GENERIC easily since > the install filesystem is also in there. It is in the config. I don't know why it doesn't appear.
ure not detected with ramdisk
Thinkpad X1 2015. I have a ure that works fine with normal kernels but was not detected when using the ramdisk. cat /tmp/dmesg | egrep openbsd\|^uhub\|^ure dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 uhub2 at uhub1 port 1 configuration 1 interface 0 "vendor 0x8087 product 0x8001" rev 2.00/0.03 addr 2 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ure0 at uhub0 port 13 configuration 1 interface 0 "Realtek USB 10/100/1000 LAN" rev 3.00/30.00 addr 5 ure0: ver 5c10, address 9c:eb:e8:22:66:f3 uhub2 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.03 addr 2 OpenBSD 6.4-current (RAMDISK_CD) #622: Tue Jan 29 19:15:56 MST 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 8238301184 (7856MB) avail mem = 7984648192 (7614MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (66 entries) bios0: vendor LENOVO version "N14ET28W (1.06 )" date 03/12/2015 bios0: LENOVO 20BSCTO1WW acpi0 at bios0: rev 2 acpi0: tables DSDT FACP ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM BATB FPDT UEFI DMAR acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz, 2195.29 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,SMX,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 3 (EXP1) acpiprt3 at acpi0: bus 4 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus -1 (EXP6) acpicpu at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpitz at acpi0 not configured "PNP0C0D" at acpi0 not configured "PNP0C0E" at acpi0 not configured "PNP0A08" at acpi0 not configured "PNP0B00" at acpi0 not configured "PNP0C0A" at acpi0 not configured "ACPI0003" at acpi0 not configured "LEN0068" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "INT340F" at acpi0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 5G Host" rev 0x09 vga1 at pci0 dev 2 function 0 "Intel HD Graphics 5500" rev 0x09 wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) "Intel Core 5G HD Audio" rev 0x09 at pci0 dev 3 function 0 not configured 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" rev 3.00/1.00 addr 1 "Intel 9 Series MEI" rev 0x03 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 "Intel I218-LM" rev 0x03: msi, address 54:ee:75:3c:17:cb "Intel 9 Series HD Audio" rev 0x03 at pci0 dev 27 function 0 not configured ppb0 at pci0 dev 28 function 0 "Intel 9 Series PCIE" rev 0xe3: msi pci1 at ppb0 bus 3 ppb1 at pci0 dev 28 function 1 "Intel 9 Series PCIE" rev 0xe3: msi pci2 at ppb1 bus 4 iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, msi ehci0 at pci0 dev 29 function 0 "Intel 9 Series USB" rev 0x03: apic 2 int 23 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 "Intel 9 Series LPC" rev 0x03 at pci0 dev 31 function 0 not configured ahci0 at pci0 dev 31 function 2 "Intel 9 Series AHCI" rev 0x03: msi, AHCI 1.3 ahci0: port 3: 6.0Gb/s scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 3 lun 0: SCSI3 0/direct fixed naa.5002538d4024a2df sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin "Intel 9 Series SMBus" rev 0x03 at pci0 dev 31 function 3 not configured "Intel 9 Series Thermal" rev 0x03 at pci0 dev 31 function 6 not configured isa0 at mainbus0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay1 "vendor 0x138a product 0x0017" rev 1.10/0.78 addr 2 at uhub
iwm put itself down
I'm using a very bad wifi network, which causes iwm much sadness, but this particular error was new and unexpected. Suddenly ping announces the network is down. ping: sendmsg: Network is down ping: wrote ox.tedunangst.com 64 chars, ret=-1 Sure enough, ifconfig says no network. And now comes the strange part. I run ifconfig scan and get an error. ifconfig: SIOCG80211ALLNODES: Network is down Maybe if I had run ifconfig down that would be sensible, but I didn't. My expectation is that if the interface is up, it will stay up, even if it disconnects from the network. The problem was resolved by running ifconfig up manually.
Re: kern.clockrate documentation patch
Amit Kulkarni wrote: > Hi, > > I wanted to know the value of tick, went to man.openbsd.org, and got > https://man.openbsd.org/tick > > While the answer provided on this page below is accurate, IMHO it is not > useful. I had to do a grep on "tick" for the kern.clockrate sysctl. Something > like the below would be better. > > Thanks > > diff --git man9/hz.9 man9/hz.9 > index a319266e518..ac5e8f60850 100644 > --- man9/hz.9 > +++ man9/hz.9 > @@ -79,11 +79,11 @@ may be used to skew this increment, but by no more > than ten times > .Va tickadj . > .Pp > -Those systems variables are available as a struct clockinfo from > -.Xr sysctl 2 . > +These system variables are available as kern.clockrate from > +.Xr sysctl 8 . This is meant to be programmer documentation, so I think it makes sense to keep it referring to sysctl.2. However, it's a good point that you shouldn't have to grep for clockinfo. If we mention KERN_CLOCKRATE that makes searching faster and should allow users to figure out kern.clockrate. Index: hz.9 === RCS file: /cvs/src/share/man/man9/hz.9,v retrieving revision 1.8 diff -u -p -r1.8 hz.9 --- hz.912 Jan 2018 04:36:45 - 1.8 +++ hz.96 Jan 2019 19:07:27 - @@ -79,7 +79,9 @@ may be used to skew this increment, but than ten times .Va tickadj . .Pp -Those systems variables are available as a struct clockinfo from +These system variables are available by reading +.Va KERN_CLOCKRATE +from .Xr sysctl 2 . .Sh SEE ALSO .Xr adjtime 2 ,
httpd sends too many 408s
HTTP/1.1 connections stay alive by default, unless the client or server indicates it will close with the Connection: close header. After a timeout, the connection typically closes anyway. httpd in this case sends back a 408 Request Timeout response. This is unusual. I did not exhaustively study the RFCs, but 408 seems primarily for indicating that the client is sending the request too slowly. If the server has already finished the request, then 408 would not apply. Other servers don't seem to send 408 either. When they have decided that a keepalive connection is too old, they simply close it. In my case, I'm not running httpd server, but the go http client complains about receiving unexpected data.
Re: rc(8) ignores last line without newline of *.conf
George Koehler wrote: > stripcom() in /etc/rc uses `while read _line ; do ... done` > to read these files, but `read _line` exits 1 when the last line is > without a newline. This behavior in sh and ksh is consistent with > bash, dash, ksh93, and yash: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206 3.206 Line A sequence of zero or more non- characters plus a terminating character. A line without a newline is not a line.
Re: fread() on unbuffered FILE doesn't set feof flag
Todd C. Miller wrote: > > After thinking about this a bit more I believe it best to just use > the existing FILE * and swap in the buffer temporarily. There's > no need to store the value of the old buffer; since we are unbuffered > it can only point to _nbuf. This is neat.
Re: fread() on unbuffered FILE doesn't set feof flag
Ted Unangst wrote:
> Todd C. Miller wrote:
> > On Wed, 12 Dec 2018 13:08:07 -0500, "Ted Unangst" wrote:
> >
> > > i don't want to go too far down the legacy rabbit hole, just float nicely
> > > above it.
> >
> > Which is exactly how we got to this point. What else is missing
> > and how many years will it take before someone notices? Is it
> > really safe to completely ignore the stdio flags?
>
> One missed feature every five years doesn't sound all that bad. :)
>
> But sure, if we want to revert and regress before putting it back, ok.
I went with a simpler #if 0 approach because I think it will make it easier to
track the fixes.
ok?
Index: fread.c
===
RCS file: /cvs/src/lib/libc/stdio/fread.c,v
retrieving revision 1.15
diff -u -p -r1.15 fread.c
--- fread.c 21 Sep 2016 04:38:56 - 1.15
+++ fread.c 12 Dec 2018 18:50:03 -
@@ -69,6 +69,7 @@ fread(void *buf, size_t size, size_t cou
total = resid;
p = buf;
+#if 0
if ((fp->_flags & __SNBF) != 0) {
/*
* We know if we're unbuffered that our buffer is empty, so
@@ -82,6 +83,7 @@ fread(void *buf, size_t size, size_t cou
FUNLOCKFILE(fp);
return ((total - resid) / size);
}
+#endif
while (resid > (r = fp->_r)) {
(void)memcpy(p, fp->_p, r);
Re: fread() on unbuffered FILE doesn't set feof flag
Todd C. Miller wrote: > On Wed, 12 Dec 2018 13:08:07 -0500, "Ted Unangst" wrote: > > > i don't want to go too far down the legacy rabbit hole, just float nicely > > above it. > > Which is exactly how we got to this point. What else is missing > and how many years will it take before someone notices? Is it > really safe to completely ignore the stdio flags? One missed feature every five years doesn't sound all that bad. :) But sure, if we want to revert and regress before putting it back, ok.
Re: fread() on unbuffered FILE doesn't set feof flag
Todd C. Miller wrote: > On Wed, 12 Dec 2018 08:59:25 +0100, Sebastien Marie wrote: > > > The approch is to directly set __SEOF or __SERR. It is more simple than > > trying to reuse __srefill(). > > My concern is that __srefill() does more than just that. In particular, > it has the following: > > /* > * Before reading from a line buffered or unbuffered file, > * flush all line buffered output files, per the ANSI C > * standard. > */ > > However, a quick scan of the ISO C99 spec didn't reveal any such > requirement. Perhaps someone else better versed in standardese > knows what the comment is referring to. > > I also worry about the lack of stdio initialization (__sinit()) and > logic for switching from reading to writing. isn't the point to avoid all this stuff because it's not necessary? srefill() has to be one of the worst functions around. it does a dozen different things, so whenever something is supposed to happen a call to srefill is inserted, but nobody knows what's supposed to happen *right here right now*. like how do we get here without previously calling sinit? srefill seems like a very strange place to stash the init call. i don't want to go too far down the legacy rabbit hole, just float nicely above it.
Re: libGL error: ...
Roderick wrote:
>
> libGL error: Version 4 or later of flush extension not found
> libGL error: failed to load driver i915
This error also occurs on an HP mini 110. It appears cosmetic. glxgears still
runs, fast enough, and firefox runs as well, somewhat less fast.
dmesg below. it's GM45.
inteldrm0 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03
OpenBSD 6.4 (GENERIC.MP) #943: Thu Oct 11 13:51:32 MDT 2018
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem = 2138259456 (2039MB)
avail mem = 2084151296 (1987MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 09/02/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.4 @
0xfc890 (18 entries)
bios0: vendor Hewlett-Packard version "308F0 Ver. F.16" date 09/02/2009
bios0: Hewlett-Packard HP Mini 110-1100
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET ASF! SSDT
acpi0: wakeup devices P0P2(S4) P0P1(S4) LAN2(S3) USB0(S3) USB3(S3) EUSB(S3)
MC97(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(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) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz,
06-1c-02
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,NXE,LAHF,PERF,SENSOR,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz,
06-1c-02
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,NXE,LAHF,PERF,SENSOR,MELTDOWN
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P0P1)
acpiprt2 at acpi0: bus 2 (P0P5)
acpiprt3 at acpi0: bus -1 (P0P6)
acpiprt4 at acpi0: bus -1 (P0P7)
acpiprt5 at acpi0: bus -1 (P0P8)
acpiprt6 at acpi0: bus -1 (P0P9)
acpiec0 at acpi0
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1
mwait.1), PSS
acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1
mwait.1), PSS
acpitz0 at acpi0: critical temperature is 100 degC
acpicmos0 at acpi0
"SYN1E0C" at acpi0 not configured
acpibat0 at acpi0: BAT1 model "Primary" serial type LION oem "Hewlett-Packard"
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
"PNP0C14" at acpi0 not configured
acpibtn2 at acpi0: PWRB
acpivideo0 at acpi0: IGD_
acpivout0 at acpivideo0: LCD_
bios0: ROM list: 0xc/0xec00!
cpu0: Enhanced SpeedStep 1597 MHz: speeds: 1600, 1333, 1067, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GME Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: apic 2 int 16
inteldrm0: 1024x600, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: IDT 92HD81B1X
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 2 int 16
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 2 int 17
pci2 at ppb1 bus 2
alc0 at pci2 dev 0 function 0 "Attansic Technology L2C" rev 0xc0: msi, address
00:26:55:c6:a6:2b
atphy0 at alc0 phy 0: F1 10/100/1000 PHY, rev. 11
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 2 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 2 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 2 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 2 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
addr 1
ppb2 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
pci3 at ppb2 bus 3
ichpcib0 at pci0 dev 31 function 0 "Intel 82801GBM LPC" rev 0x02: PM disabled
ahci0 at pci0 dev 31 function 2 "Intel 82801GBM AHCI" rev 0x02: msi, AHCI 1.1
ahci0: port 0: 1.5Gb/s
ahci0: PHY offline on port 2
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct
fixed naa.50e043efec9f
sd0: 152627MB, 512 bytes/sector, 31258180
Re: fread() on unbuffered FILE doesn't set feof flag
Sebastien Marie wrote:
> When looking at fread(3) code in libc, I found that we doesn't set
> __SEOF when the FILE is unbuffered.
>
> src/lib/libc/stdio/fread.c
> 72 if ((fp->_flags & __SNBF) != 0) {
> 73 /*
> 74 * We know if we're unbuffered that our buffer is
> empty, so
> 75 * we can just read directly. This is much faster
> than the
> 76 * loop below which will perform a series of one byte
> reads.
> 77 */
> 78 while (resid > 0 && (r = (*fp->_read)(fp->_cookie, p,
> resid)) > 0) {
> 79 p += r;
> 80 resid -= r;
> 81 }
> 82 FUNLOCKFILE(fp);
> 83 return ((total - resid) / size);
> 84 }
> Is it a bug to not set the __SEOF flag or it is expected for unbuffered
> FILE ?
seems like a bug. the code above was added more recently, and must have missed
this case.
Re: Thinkpad X1 reproducible suspend panic
Edd Barrett wrote: > I used a USB drive so that I wouldn't trash my everyday filesystems by > constant dirty shutdowns. However, it seems essential for reproduction. > If I boot a recent snap off my SSD, this bug does not manifest (but this will never work. USB devices are ejected during suspend. there may be something else going on, but if it can only be reproduced in a known bad config, it's not worth pursuing.
idle threads say 100%
I know there have been some changes in this area, but this seems like a remaining bug. Run top. Press S to show system processes. Observe idle1 and idle3 (the hyperthreaded idles) stuck at 100%. With 0:00 time. Now if you switch hw.smt=1 the 100% slowly ticks down, but the time immediately jumps up to many hours. Just a peculiarity I noticed. Perhaps there's some way to consolidate special cases?
Re: bug in master src/lib/libc/hash/siphash.c
Mark Karpilovskij wrote: > If only a single call to SipHash_Update is performed or if the size of > processed data is a multiple of sizeof(ctx->buf), this bug does nothing. > However when we performed several updates of various lengths, the data > written to ctx->buf were too long and the call to memcpy overwrote other > data, which led to various unexpected behavior. I concur. Here's a diff for review. Index: siphash.c === RCS file: /cvs/src/lib/libc/hash/siphash.c,v retrieving revision 1.6 diff -u -p -r1.6 siphash.c --- siphash.c 12 Apr 2017 17:41:49 - 1.6 +++ siphash.c 22 Dec 2017 01:13:59 - @@ -104,7 +104,7 @@ SipHash_Update(SIPHASH_CTX *ctx, int rc, } if (len > 0) - memcpy(&ctx->buf[used], ptr, len); + memcpy(ctx->buf, ptr, len); } DEF_WEAK(SipHash_Update);
ftp proxies and redirects
I believe there's a bug with ftp and redirects when using a proxy. ftp seems to add the redirect URL to the proxy host, fetching http://proxy/new-url instead of http://orighost/new-url. I'm not certain this isn't a server or proxy bug, in part because I'm not certain who's supposed to say what or how it's interpreted, but my first guess is to blame ftp. :) In the same setup, chrome redirects to http://orighost/new-url.
Re: config(8) elf handling
Philip Guenther wrote:
> On Wed, 13 Sep 2017, Miod Vallat wrote:
> >
> > > Forcing uextraloc into .data via
> > > int uextraloc __attribute__ ((section(".data"))) = 0;
> > > avoids the crashes.
> >
> > Regardless of this bug, the in-tree gcc was modified to default to put
> > explicitly zero initialized data in .data rather than .bss, i.e. default
> > to -fno-zero-initialized-in-bss.
> >
> > It might be wise to make the default configuration of clang follow this
> > behaviour as well.
>
> Anyone recall the issues that it was originally changed to fix?
>
> If it was the kernel config stuff, maybe we should just pass the option
> explicitly in the kernel Makefiles and not push it on all of userland.
oh, hi, that was me! yes, it was for kernel config specifically, and binary
hacking in general. the old ABI, from vaxen of yore, would leave things in
data, so that's where we wanted them to remain. but time moves on i guess.
Re: Suspend-to-full-encrypted-disk is broken (by KARL?)
Natasha Kerensikova wrote: > on Thursday 20 July 2017 at 21:45, YASUOKA Masahiko wrote: > > On Tue, 18 Jul 2017 15:48:48 -0600 > > "Theo de Raadt" wrote: > > > The changes introduced into the bootloader are largely correct. They > > > make the right decisions. They just don't make them at the right > > > points in time. The IO operations should be moved further forward, to > > > after the key operations. > > > > > > Havinge done it this way, yasuoka and I were able to create a workable > > > model, but the operations need to be moved forward. > > > > > > Someone want to dive in? > > > > The diff is to support selecting bsd.booted for FED. > > I have been happily using the fixed bootloader, but I noticed a few times > that I still had unhibernating failures due to incorrect kernel. After > further investigation, I think that it correctly loads /bsd.booted when > I enter the correct passphrase on the first try, which happens quite > often thanks to muscle memory. However when I enter a wrong passphrase, > and subsequently enter the correct one on the second prompt, the > bootloader doesn't seem to detect the hibernation and loads /bsd, which > cannot unhibernate. After a failed password attempt, when you press enter, I think that picks the default again, which is "bsd". If you type bsd.booted I bet it works. The order of the tests and decisions is still a little vague.
ssh-keygen -l -v -F
The man page says using -l to print the fingerprint I can add a -v to get the pretty art, but this doesn't work with -F. It just prints the ugly base64 gibberish.
Re: asus x205ta keyboard issue
michele.cu...@gmail.com wrote: > >Synopsis:iic keyboard sometimes reapeat key press > When the problem happens, on dmesg I see messages like this: > > dwiic1: timed out reading remaining 13 > > Any idea what's happening? keyboard controllers are surprisingly complex. or perhaps quirky is a better word. it took 20 years to get the pckbd driver working. and now we get to start all over with iic controllers. that's kind of a meta point, but the idea is until such machines become common, there's probably going to be a few issues.
Re: OpenBSD guest hangs in vmd on -current host
Mike Larkin wrote:
> On Tue, Jul 18, 2017 at 09:36:12PM -0700, Max Parmer wrote:
> >
> > >Synopsis: OpenBSD guest hangs in vmd on -current host
> > >Category: system
> > >Environment:
> > System : OpenBSD 6.1
> > Details : OpenBSD 6.1-current (GENERIC.MP) #99: Mon Jul 17 16:53:49
> > MDT 2017
> >
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > When running an OpenBSD guest under vmd after a short time the guest
> > will hang, the
> > corresponding vmd process will hit and stay at 99.9% CPU usage.
> >
> > Examination with ktrace shows a pattern similar to the past reports
> > from tedu@[1] and
> > Gregor Best[2] with the process spinning on kevent and gettime, excerpt:
> > 15607 vmd RET kevent 1
> > 15607 vmd CALL clock_gettime(CLOCK_MONOTONIC,0x121dae4dbd20)
> >
> > 15607 vmd STRU struct timespec { 20180.643241450 }
> >
> > 15607 vmd RET clock_gettime 0
> > 15607 vmd CALL kevent(5,0,0,0x121da5f22000,64,0x121dae4dbcf0)
> >
> > 15607 vmd STRU struct timespec { 0.002255000 }
> >
> > I first encountered this issue on the snapshot from Jul 15th and was
> > able to reproduce
> > several times under that snapshot and the subsequent snapshots from the
> > 16th and 17th.
> >
> > Typically the VM will run normally for a short time before hanging, and
> > it seems to
> > occur both with /bsd and /bsd.rd. Typing seems to trigger it.
> >
>
> I bet I botched this with the serial port "improvement" done last month. I'll
> take a look tonight, thanks for the info.
to perhaps give you a hint, it looks, from the outside, like there's a byte to
be read, but vmd is in the "don't want bytes now" state, but has gotten out of
sync with libevent, which keeps calling the byte ready function, which keeps
doing nothing. but that's blind stabbing.
Re: OpenBSD guest hangs in vmd on -current host
Max Parmer wrote:
>
> >Synopsis:OpenBSD guest hangs in vmd on -current host
> >Category:system
> >Environment:
> System : OpenBSD 6.1
> Details : OpenBSD 6.1-current (GENERIC.MP) #99: Mon Jul 17 16:53:49
> MDT 2017
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> When running an OpenBSD guest under vmd after a short time the guest
> will hang, the
> corresponding vmd process will hit and stay at 99.9% CPU usage.
>
> Examination with ktrace shows a pattern similar to the past reports
> from tedu@[1] and
> Gregor Best[2] with the process spinning on kevent and gettime, excerpt:
>15607 vmd RET kevent 1
>15607 vmd CALL clock_gettime(CLOCK_MONOTONIC,0x121dae4dbd20)
>
>15607 vmd STRU struct timespec { 20180.643241450 }
>
>15607 vmd RET clock_gettime 0
>15607 vmd CALL kevent(5,0,0,0x121da5f22000,64,0x121dae4dbcf0)
>
>15607 vmd STRU struct timespec { 0.002255000 }
>
> I first encountered this issue on the snapshot from Jul 15th and was
> able to reproduce
> several times under that snapshot and the subsequent snapshots from the
> 16th and 17th.
i didn't dig into vmd to see where it's spinning, but if you run vmd with env
EVENT_NOKQUEUE=1 then I haven't observed the problem.
Re: missing "struct socket;" in netinet/ip_var.h prevents compiling kernel without MROUTING option
Nick Briggs wrote:
> because netinet/ip_var.h, which it includes, depends on
>#ifdef MROUTING
>extern struct socket *ip_mrouter[]; /* multicast routing daemon */
>#endif
> to get a declaration of struct socket outside of any parameter lists.
I think this is a better fix. Two parts.
1. pfkeyv2_parsemessage.c doesn't even need this header. remove it.
2. to prevent this from happening again, move the forward declaration in
ip_var.h to the end, so that it will fail regardless of compile options. i
think this is better than deliberately exporting another type here.
tested with and without MROUTING set.
Index: net/pfkeyv2_parsemessage.c
===
RCS file: /cvs/src/sys/net/pfkeyv2_parsemessage.c,v
retrieving revision 1.52
diff -u -p -r1.52 pfkeyv2_parsemessage.c
--- net/pfkeyv2_parsemessage.c 26 Jun 2017 09:17:55 - 1.52
+++ net/pfkeyv2_parsemessage.c 14 Jul 2017 02:35:13 -
@@ -76,7 +76,6 @@
#include
#include
#include
-#include
#include
#if NPF > 0
Index: netinet/ip_var.h
===
RCS file: /cvs/src/sys/netinet/ip_var.h,v
retrieving revision 1.79
diff -u -p -r1.79 ip_var.h
--- netinet/ip_var.h26 Jun 2017 19:06:12 - 1.79
+++ netinet/ip_var.h14 Jul 2017 02:34:17 -
@@ -193,9 +193,6 @@ struct ipq {
extern struct ipstat ipstat;
extern LIST_HEAD(ipqhead, ipq) ipq;/* ip reass. queue */
extern int ip_defttl; /* default IP ttl */
-#ifdef MROUTING
-extern struct socket *ip_mrouter[];/* multicast routing daemon */
-#endif
#define IPMTUDISCTIMEOUT (10 * 60) /* as per RFC 1191 */
@@ -259,6 +256,10 @@ int rip_output(struct mbuf *, struct so
int rip_usrreq(struct socket *,
int, struct mbuf *, struct mbuf *, struct mbuf *, struct proc *);
int rip_attach(struct socket *, int);
+
+#ifdef MROUTING
+extern struct socket *ip_mrouter[];/* multicast routing daemon */
+#endif
#endif /* _KERNEL */
#endif /* _NETINET_IP_VAR_H_ */
Re: canaries can cause malloc with a size of 0 to hang
Otto Moerbeek wrote: > I think I found it: requested size is not recorded for malloc(0), > bp->offset is not initialized in that case. Other code is carefull not to > use ->offset for size == 0. > OA > -Otto OA from me. :) > > Index: malloc.c > === > RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v > retrieving revision 1.226 > diff -u -p -r1.226 malloc.c > --- malloc.c 19 Jun 2017 03:06:26 - 1.226 > +++ malloc.c 7 Jul 2017 06:51:30 - > @@ -1013,7 +1013,7 @@ malloc_bytes(struct dir_info *d, size_t > /* Adjust to the real offset of that chunk */ > k += (lp - bp->bits) * MALLOC_BITS; > > - if (mopts.chunk_canaries) > + if (mopts.chunk_canaries && size > 0) > bp->bits[bp->offset + k] = size; > > k <<= bp->shift; >
Re: panic: Stopped at kqueue_scan
Aaron Bieber wrote: > For roughly a week I have been able to reliably produce panics on > amd64 (virtual machine and physical machine) using disk IO heavy > applications (gitea, syncthing). these are also network applications, no? i think that's the io that causes trouble.
Re: reorder_kernel requires writable /usr/share
Theo de Raadt wrote: > Yes, but once again I don't know what this is trying to help. > > Just you, I think. Maybe someone else? > > I am unsure if these 6-line chunks belong in /etc. The configuration > is way out of default. Configuration creep. Start with six lines to support readonly /usr because "it can't hurt". Next feature needs six more lines. Then six more lines. Now it looks like readonly /usr is supported. Look at all these lines that make it work!
Re: mandoc -Tlint and Mdocdate
Ingo Schwarze wrote: > As there is no fully satisfactory option, i propose the patch below. > It add the "-W portable" command line option, which is a variant of > "-W style" hiding messages that only apply to base system manuals. I'm not fond of the name portable. To me, this suggests it will check for things which impede portability, but that's not really what it does. It may have that effect in some cases, but more as an incidental effect. Instead, I suggest shifting the names by one. Leave -W style as the portable option, but introduce -W openbsd which performs the additional checks. Or better, name it -W system, so as to be useful on netbsd, etc. I think this matches the actual hierarchy in practice. There's errors and warnings at the top. Then there's general style warnings. Then below that there's the local system specific style guidelines. It's a matter of perspective, but the portable warnings aren't subset of style, rather the system warnings are a superset of style.
Re: httpd violates pledge with passworded private key
Joel Sing wrote: > > tls_configure_keypair() -> return EWANTSPASSWORD -> application decides how > > to proceed, possibly asking for password, calls > > tls_configure_keypair_this_time_with_password(). > > I'm not sure that I'd consider that sane. We already have tls_load_file() for > this purpose, although admittedly the API there could probably be friendlier. > Do we really want tls_configure_keypair() to become "maybe encrypted, maybe > unencrypted"? I'm not convinced that we should really be making libtls expect > to be dealing with encrypted keys at that point. oh, i think the current API is fine. tls_load_file is the function i was proposing we add. :)
Re: httpd violates pledge with passworded private key
Jonathan Gray wrote: > when using a server.key with a passphrase, ie > ) at /usr/src/lib/libc/stdio/fopen.c:54 > #3 0x022b2d92d26f in open_console (ui=Variable "ui" is not available. > ) at /usr/src/lib/libcrypto/ui/ui_openssl.c:304 > #6 0x022b2d9dc018 in PEM_def_callback > ) at /usr/src/lib/libcrypto/pem/pem_lib.c:113 > #10 0x022b6ef43b62 in tls_configure_ssl_keypair ugh, i think this is a bug in libtls. there should not be sneaky bullshit console reading functions being called behind the scenes. this is, as discovered, kind of surprising. and quite the layering violation, separation of concerns, and all that. a sane API would look something like this: tls_configure_keypair() -> return EWANTSPASSWORD -> application decides how to proceed, possibly asking for password, calls tls_configure_keypair_this_time_with_password().
weird spin in vmd
ktrace shows we appear to be spinning on kevent and gettime. fd 7 is the tty.
Not sure what went wrong. Happened just after typing "root" at login. Never
got to password. Reboot, fsck, appears to work now.
_vmd vmd750337 / 182448 crw-rw-rw-rwptypt
75033 vmd CALL clock_gettime(CLOCK_MONOTONIC,0x6cdf3156030)
75033 vmd STRU struct timespec { 366729.439807068 }
75033 vmd RET clock_gettime 0
75033 vmd CALL kevent(0,0x6ce1a957800,0,0x6cd99f5c800,64,0x6cdf3156000)
75033 vmd STRU struct timespec { 0.003247000 }
75033 vmd STRU struct kevent { ident=7, filter=EVFILT_READ,
flags=0x1, fflags=0<>, data=15, udata=0x6cb750a7638 }
75033 vmd RET kevent 1
75033 vmd CALL clock_gettime(CLOCK_MONOTONIC,0x6cdf3156030)
75033 vmd STRU struct timespec { 366729.439816566 }
75033 vmd RET clock_gettime 0
75033 vmd CALL kevent(0,0x6ce1a957800,0,0x6cd99f5c800,64,0x6cdf3156000)
75033 vmd STRU struct timespec { 0.003238000 }
75033 vmd STRU struct kevent { ident=7, filter=EVFILT_READ,
flags=0x1, fflags=0<>, data=15, udata=0x6cb750a7638 }
75033 vmd RET kevent 1
75033 vmd CALL clock_gettime(CLOCK_MONOTONIC,0x6cdf3156030)
75033 vmd STRU struct timespec { 366729.439827252 }
75033 vmd RET clock_gettime 0
75033 vmd CALL kevent(0,0x6ce1a957800,0,0x6cd99f5c800,64,0x6cdf3156000)
75033 vmd STRU struct timespec { 0.003227000 }
75033 vmd STRU struct kevent { ident=7, filter=EVFILT_READ,
flags=0x1, fflags=0<>, data=15, udata=0x6cb750a7638 }
vmctl start missing disk
start a vm with a missing disk vmctl start banana -d whatever -i 1 vmctl: start vm command failed: No such file or directory that's not much of a hint what went wrong.
Re: sparc64 -CURRENT in LDOM: ERROR: Last Trap: Fast Data Access Protection
Ax0n wrote: > FWIW, the kernels running in my -stable guests are considerably larger than > 8MB, and not much smaller than the -CURRENT kernels. So it's actually the size of the code in the kernel, not the file size. >From your boot message Booting /virtual-devices@100/channel-devices@200/disk@0:a/bsd 8381472@0x100+7136@0x17fe420+196864@0x180+3997440@0x1830100 8381472 + 7136 (padding) = 8388608
Re: sparc64 -CURRENT in LDOM: ERROR: Last Trap: Fast Data Access Protection
Ax0n wrote: > Is this limit specifically for LDOM guests? I have a Sun Blade 1500 I could > compile a custom -CURRENT kernel with, if that might help. Though I'm not > sure I want to do that with every snapshot I try. Not specifically, but the limit can vary by hardware. If you want to run a snapshot now, a custom kernel with a few devices removed will help. We'll have to make a similar long term fix anyway.
Re: sparc64 -CURRENT in LDOM: ERROR: Last Trap: Fast Data Access Protection
Ax0n wrote: > I have a SunFire T2000 that I've chopped up into LDOMs. The primary domain > and six of the LDOMs are running 6.1-STABLE just fine. I pulled down the > May 22 snapshot, and it installs (with a strange error, see bottom of > post), but the LDOM crashes upon boot. I just tried again with the May 24th > snapshot, and I'm getting the same error. This seems to dump me into > OpenBoot, not ddb. I can provide a shell on the primary domain, and serial > console (over ssh) access to a developer if needed. I am not subscribed to > bugs@, so please copy me off-list. There's a hardware/software limit that currently restricts the kernel to 8MB. Larger than that and bad things happen. Hopefully someone will soon find a way to reduce the size of the kernel.
Re: xterm fails ungracefully when saveLines resource value is too large
will.brokenbourgh2...@gmail.com wrote: > >Synopsis:xterm fails ungracefully when saveLines resource value is too > >large > >Category:system > >Environment: > System : OpenBSD 6.1 > Details : OpenBSD 6.1 (GENERIC.MP) #6: Mon May 22 20:34:30 CEST 2017 > > rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > When the xterm*saveLines resource value is too high (in this case > 99), xterm fails to run and issues the following error: > > xterm: Error 91, errno 12: Cannot allocate memory > Reason: Alloc: calloc() failed on rows > > This error message is completely unhelpful from a user standpoint. I > didn't know if this was system resource starvation or something else. A > better way to handle this situation would be to set saveLines within xterm to > the maximum and print a warning that the saveLines variable is too large. xterm is mainted outside openbsd. we're not likely to maintain a custom patch for this.
Re: softraid i/o errors: which device causes them?
Paul de Weerd wrote: > Hi all, > > I've got a system with several softraid crypto devices mounted, and > one seems to be having issues. dmesg shows several of these: > > softraid0: i/o error on block 1104 target 0 b_error 5 > > Is there a way to figure out which sd(4) device these come from? Or > what b_error 5 is? error 5 is EIO, I/O error. Target 0 doesn't reveal much, though, that's not a very helpful print out.
Re: softraid crypto performance regression
Mike Belopuhov wrote: > On Wed, May 17, 2017 at 12:42 -0400, Ted Unangst wrote: > > Stefan Sperling wrote: > > > I also have some machines which are affected by this, and I am > > > not sure what to about it. I cannot judge the advantages of > > > either AES implementation. > > > > There's very little advantage to a constant time implementation for disk > > encryption. The threat model doesn't really include such side channels. > > > > This is simply not true if you have local users on the same box. > http://www.cs.tau.ac.il/~tromer/papers/cache.pdf I think we've reached agreement regarding reverting XTS, but for the benefit of anyone following along at home or who might find this thread later... The insider threat where I have some hostile user on my computer, who runs some code to extract the disk key, then this user physically steals the computer to recover data... I would say far fetched, but let's just go with minority threat. For most people, the threat is leaving a laptop bag in a taxi, or getting burlged, or going through customs. Like 90%. 99% even? No insider threat here. Another very popular use case doesn't even involve a threat. It's very easy to repurpose a machine/disk that uses full disk encryption. Change the key, and you've instantly wiped the disk. Personally, this is the main reason I use and advocate everyone use disk encryption. It's not about machines being stolen, but about machines I plan to give away in the future.
Re: softraid crypto performance regression
Stefan Sperling wrote: > I also have some machines which are affected by this, and I am > not sure what to about it. I cannot judge the advantages of > either AES implementation. There's very little advantage to a constant time implementation for disk encryption. The threat model doesn't really include such side channels. But I don't know how much burden it will be to maintain two implementations, with the various defines like CRYPTO_AES_XTS and CRYPTO_AES_XTS_FASTER_BUT_MAYBE_A_LITTLE_UNSAFE and deciding where to use each. Although, truth be told, XTS is only useful for disk encryption. It shouldn't be used for network traffic. So we could just always make software XTS use the original rijndael code. But this is mike's fun zone.
Re: Problem in installing: cannot recognize disk
Jonathan Gray wrote: > sdmmc ends up attaching sd. > > sdhc -> sdmmc -> scsibus -> sd > > The submitter should try a release that isn't a year old and provide > details of which particular stream model this is as the branding spans > multiple generations of hardware with different variants. There are many other problems, but openbsd didn't have any difficulty detecting the sdmmc on the stream 7 and installing to it.
Re: segfault in grep
Michael Santos wrote: > >Description: > > Use of uninitialized value in grep. > > >How-To-Repeat: > > $ grep -o "" /etc/hosts > Segmentation fault (core dumped) > > >Fix: Thanks.
Re: 2017-03-24 amd64 snapshot upgrade : /etc/shells overwritten
Peter N. M. Hansteen wrote: > Upgrading my laptop to the freshest snapshot about half an hour ago, I > found that the line for my user's main shell, installed from a package > and located under /usr/local/bin was no longer in /etc/shells. > > The fix is to log in as root (or any other user with a base shell and > some way to edit /etc/shells) and append the shell's line to /etc/shells. > > Would it be possible to have upgrade's automatic sysmerge run merge > /etc/shells? Double check your procedure? shells is in the etc set. It should not be overwritten by upgrades. In fact, sysmerge should handle it.
Re: doas -n fails even when no password would be requested
Otto Moerbeek wrote: > On Tue, Feb 14, 2017 at 02:56:01PM -0500, Ted Unangst wrote: > > > Paul de Weerd wrote: > > > Well, in my case I can simply not use doas -n and ensure my script > > > works without prompting for passwords more than once (which is what I > > > care about). However, I have to say that doas works great in > > > scripting setups: it asks for a password once and then all subsequent > > > invocations of doas do not. Once the script ends, the process group > > > is gone and with it, the persist ticket. So, yeah, persist works > > > great for scripting. > > > > I must admit this usage is kind of strange, but that doesn't mean bad. > > Unexpected though. :) > > > > However, do you need to use -n in this case? You've set things up so that > > the > > first invocation asks for a password and then it relies on persist > > throughout. > > So leave off of the -n? > > H, isn't that a big race condition? What if the script takes > longer than the persists time? So that's the rationale for why it takes precendence. You can test the script and get reliable results. Depends on whether one interprets -n to mean "don't ask" or "don't wait". As an alternative, let me mention the changes that were recently done to the build system. Instead of using doas to elevate privileges during operations like install, start as root and use doas to drop privileges to the build user. This may require reworking the script somewhat, but I think it's a safer way to do things.
Re: doas -n fails even when no password would be requested
Paul de Weerd wrote: > Well, in my case I can simply not use doas -n and ensure my script > works without prompting for passwords more than once (which is what I > care about). However, I have to say that doas works great in > scripting setups: it asks for a password once and then all subsequent > invocations of doas do not. Once the script ends, the process group > is gone and with it, the persist ticket. So, yeah, persist works > great for scripting. I must admit this usage is kind of strange, but that doesn't mean bad. Unexpected though. :) However, do you need to use -n in this case? You've set things up so that the first invocation asks for a password and then it relies on persist throughout. So leave off of the -n? Maybe I will think about this some more. The current design, where -n overrides persist, was deliberate. So it's not a "bug", but perhaps a wrong decision. I just don't want anyone to rush to fix it.
Re: doas -n fails even when no password would be requested
Sebastian Benoit wrote: > The -n option helps to use doas non-interactively. > Its debateable wether 'persist' is useful with non-interactive usage, but > this fixes it: So the man page currently says "fail if doas would prompt for password." although it would be more accurate to say "fail if does may prompt for a password". The purpose of -n is to make sure a script will run with or without persist, instead of being unpredictable. Also, the way persist is tied to a process group means it's not great for scripting anyway.
Re: doas -n fails even when no password would be requested
Theo Buehler wrote: > On Tue, Feb 14, 2017 at 03:57:43PM +0100, Paul de Weerd wrote: > > Consider the following: > > > >1 [weerd@despair] $ doas true > >2 doas (we...@despair.weirdnet.nl) password: > >3 [weerd@despair] $ doas true > >4 [weerd@despair] $ doas -n true > >5 doas: Authorization required > > > > I have 'persist' to allow doas to not prompt for a password on > > subsequent invocations. However, then using 'doas -n' complains > > "Authorization required" while the manpage says for -n: "Non > > interactive mode, fail if doas would prompt for password." > > > > Doas wouldn't prompt for a password if -n wasn't specified (see line > > 3), so why does it fail in line 4? > > > > Is this a bug in doas or in the manpage? > > > > I think it's a bug in doas, even if the combination of -n and persist is > a bit iffy. Here's a simple fix: No, that's exactly why -n doesn't work with persist. Results should be consistent. -n means "no password". Adding persist allows to sometimes skip entering the password, but the password is still "required".
Re: fd_getfile with 0xdeadbeef in rax
Martin Pieuchot wrote: > Sure I can do that, I still want to add a comment since it might bite us > later. > > So a counter diff is like an ok? sure.
Re: fd_getfile with 0xdeadbeef in rax
Martin Pieuchot wrote:
> On 17/01/17(Tue) 00:24, Alexander Bluhm wrote:
> > On Mon, Jan 16, 2017 at 08:36:46PM +0100, cheek...@gmx.com wrote:
> > > kernel: protection fault trap, code=0
> > > Stopped at fd_getfile+0x20: testb $0x2,mptramp_gdt32_desc+0x1e(%r
> > > ax)
> > > ddb{3}> fd_getfile() at fd_getfile+0x20
> > > sys_fstat() at sys_fstat+0x43
> > > syscall() at syscall+0x27b
> >
> > It crashes in fd_getfile() FILE_IS_USABLE(fp) as fdp->fd_ofiles has
> > been freed.
>
> Are you sure? The faulting instruction is:
>
> /sys/kern/kern_descrip.c:190
> 80: f6 40 40 02 testb $0x2,0x40(%rax)
> 84: 75 e7 jne6d
>
> So %rax contains an incorrect value which is not NULL, are you
> suggesting that it is garbage due to free(9) poisoning the memory?
>
> If that's the case, the easiest fix in would be to do the allocations
> upfront. An alternative solution discussed here at a2k17 would be to
> use a SRP to guarantee that fd_ofiles is not freed while another CPU is
> still referencing it. That would also help for MP work.
>
> Or could it be another race that your lock is preventing?
>
> What about the diff below? Cheeky does it help?
In that case, I think it's better to move the free down. This is more
idiomatic, free the old value and immediately replace.
Index: kern_descrip.c
===
RCS file: /cvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.136
diff -u -p -r1.136 kern_descrip.c
--- kern_descrip.c 24 Sep 2016 18:39:17 - 1.136
+++ kern_descrip.c 23 Jan 2017 22:02:07 -
@@ -849,9 +849,6 @@ fdexpand(struct proc *p)
memcpy(newofileflags, fdp->fd_ofileflags, copylen);
memset(newofileflags + copylen, 0, nfiles * sizeof(char) - copylen);
- if (fdp->fd_nfiles > NDFILE)
- free(fdp->fd_ofiles, M_FILEDESC, fdp->fd_nfiles * OFILESIZE);
-
if (NDHISLOTS(nfiles) > NDHISLOTS(fdp->fd_nfiles)) {
newhimap = mallocarray(NDHISLOTS(nfiles), sizeof(u_int),
M_FILEDESC, M_WAITOK);
@@ -877,6 +874,9 @@ fdexpand(struct proc *p)
fdp->fd_himap = newhimap;
fdp->fd_lomap = newlomap;
}
+
+ if (fdp->fd_nfiles > NDFILE)
+ free(fdp->fd_ofiles, M_FILEDESC, fdp->fd_nfiles * OFILESIZE);
fdp->fd_ofiles = newofile;
fdp->fd_ofileflags = newofileflags;
fdp->fd_nfiles = nfiles;
Re: fd_getfile with 0xdeadbeef in rax
Alexander Bluhm wrote:
> On Mon, Jan 16, 2017 at 08:36:46PM +0100, cheek...@gmx.com wrote:
> > kernel: protection fault trap, code=0
> > Stopped at fd_getfile+0x20: testb $0x2,mptramp_gdt32_desc+0x1e(%r
> > ax)
> > ddb{3}> fd_getfile() at fd_getfile+0x20
> > sys_fstat() at sys_fstat+0x43
> > syscall() at syscall+0x27b
>
> It crashes in fd_getfile() FILE_IS_USABLE(fp) as fdp->fd_ofiles has
> been freed.
>
> fdexpand() assumes that is has the write lock, calls free(fdp->fd_ofiles)
> and then sleeps in mallocarray(M_WAITOK) before updating fdp->fd_ofiles.
>
> As fd_getfile() does not grab a readlock, it may get scheduled while
> fdexpand() sleeps.
>
> Simply calling rw_enter_read(&fdp->fd_lock) in fd_getfile() does
> not work, as sometimes it is called with the writelock already held.
> Not sure wether such a write lock check is nice style, but it avoids
> to fix all callers.
I worry that this leaves some other race open. When I added fdplock(), I never
even considered a race in getfile. But fixing all the callers will be invasive
and it seems likely we'll miss one, so I guess this is the best approach.
noisy pkg_info errors
When a package doesn't exist, pkg_info prints error messages from the commands it runs in the background. pkg_info burritobox Error from http://ftp.usa.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ ftp: Error retrieving file: 404 Not Found signify: gzheader truncated Messages about truncated gzheaders are more confusing than informational. Compare with the output of pkg_add for a package that doesn't exist: pkg_add burritobox quirks-2.275 signed on 2016-12-20T16:07:48Z Can't find burritobox
Re: [OpenBSD 6.0/amd64] - Panic with bsd.mp that looks like file system race condition
Igor Boehm wrote: > > > On 7 Sep 2016, at 15:20, Ted Unangst wrote: > > > > Igor Boehm wrote: > >> Here some additional information on the issue: > >> > >> Stack-trace core0 converted from > >> [http://bytelabs.org/openbsd-6.0-bug-report/0-panic.png] using OCR: > >>> OpenBSD/amd64 (openbsd.bytelabs.org) (ttyC0) > >>> login: mode = 0100644, inum = 9348113, fs = /home > >>> panic: ffs_valloc: dup alloc > > > > dup alloc panics are most often the result of disk corruption. > > Thanks for having a look at this. > > The machine I am running this on is a virtual server with SSDs where OpenBSD > 6.0 is the guest. I believe VirtIO is used for HD virtualisation. > > Would you have any hints on how I can further debug the true cause of the > problem or are there any known issues with SSDs, VirtIO, etc. > Not really. It's hard to find out when corruption happened after the fact. I'd start over with a new install to ensure the filesystems are recreated cleanly. Running fsck -f may also detect more errors. My first suspect is that virtio or the VM is not flushing data to disk properly. You install, reboot, and some data doesn't get saved. This is somewhat easy, if annoying to test. Just write a bunch of data and reboot. Don't necessarily need to reinstall everytime. Just create a file, fill it with non-zero data, and reboot immediately after. Check contents after.
Re: [OpenBSD 6.0/amd64] - Panic with bsd.mp that looks like file system race condition
Igor Boehm wrote: > Here some additional information on the issue: > > Stack-trace core0 converted from > [http://bytelabs.org/openbsd-6.0-bug-report/0-panic.png] using OCR: > > OpenBSD/amd64 (openbsd.bytelabs.org) (ttyC0) > > login: mode = 0100644, inum = 9348113, fs = /home > > panic: ffs_valloc: dup alloc dup alloc panics are most often the result of disk corruption.
Re: Allow DDB to be disabled at boot time?
Adam McDougall wrote: > > I just installed installed a snapshot build from: > https://www.mirrorservice.org/pub/OpenBSD/snapshots/amd64/ > dated 2016-09-02 on a Dell R420 and I was able to reproduce > the issue. I am willing to participate further if you or anyone > else has ideas worth trying. Thanks. you might have a look at src/sys/dev/ic/pckbd.c and some related files. you can read the comments for various behaviors the driver tries to accomodate, read the cvs log to learn about other stranger problems, etc. when all else fills, stick delay() calls everywhere. and then of course there are other operating systems which either work or not, each with their own driver and comments and history that can be studied. but the short answer to the simple question is that there is no way to disable ddb at boot time.
Re: Stopped at bufq_destroy+0x83: movq 0(%rdx),%rax
FranciscoGaitán wrote:
> After making my SATA disk to work during some time, when I reboot or
> halt I get this message (hand transcribed):
>
> syncing disks... done
> kernel: protection fault trap, code=0
> Stopped at bufq_destroy+0x83: movq 0(%rdx),%rax
> ddb{0}> trace
> bufq_destroy at bufq_destroy+0x83
> sddetach() at sddetach+0x3d
> config_detach() at config_detach+0x13c
> scsi_detach_lun() at scsi_detach_lun+0x97
> sr_discipline_shutdown() at src_discipline_shutdown+0x147
> sr_shutdown() at sr_shutdown+0x2a
> boot() at boot+0x144
I've seen this a few times, but not recently. I don't think it's fixed, but
it's not always so easy to trigger.
Re: bpfilter_create kassert panic
Alexander Bluhm wrote:
> Hi,
>
> When running some scapy regression tests, a current i386 machine
> triggered this panic.
dunno if this is best. maybe. the refcounting of units implies that they can
last longer than close(). therefore, if open() is expecting close() to remove
the unit from the list, we must make sure close does that. dangling refs then
will be freed when the refcount drops.
The bpfilter_destory function is obfuscation at this point.
Alas, no time to test right now.
Index: bpf.c
===
RCS file: /cvs/src/sys/net/bpf.c,v
retrieving revision 1.142
diff -u -p -r1.142 bpf.c
--- bpf.c 10 Jun 2016 20:33:29 - 1.142
+++ bpf.c 24 Jul 2016 13:30:29 -
@@ -117,7 +117,6 @@ int bpf_sysctl_locked(int *, u_int, void
struct bpf_d *bpfilter_lookup(int);
struct bpf_d *bpfilter_create(int);
-void bpfilter_destroy(struct bpf_d *);
/*
* Reference count access to descriptor buffers
@@ -368,6 +367,7 @@ bpfclose(dev_t dev, int flag, int mode,
if (d->bd_bif)
bpf_detachd(d);
bpf_wakeup(d);
+ LIST_REMOVE(d, bd_list);
D_PUT(d);
splx(s);
@@ -1494,7 +1494,7 @@ bpf_freed(struct bpf_d *d)
srp_update_locked(&bpf_insn_gc, &d->bd_rfilter, NULL);
srp_update_locked(&bpf_insn_gc, &d->bd_wfilter, NULL);
- bpfilter_destroy(d);
+ free(d, M_DEVBUF, sizeof(*d));
}
/*
@@ -1651,12 +1651,6 @@ bpfilter_create(int unit)
return (bd);
}
-void
-bpfilter_destroy(struct bpf_d *bd)
-{
- LIST_REMOVE(bd, bd_list);
- free(bd, M_DEVBUF, sizeof(*bd));
-}
/*
* Get a list of available data link type of the interface.
Re: The kernel did not panic
Atanas Vladimirov wrote: > Snapshot was from Sat Jun 25 12:45:00 MDT 2016. thanks, people are looking for causes.
Re: rm -rf "" # prints error
rkito...@gmail.com wrote:
> >Synopsis:rm -rf "" # prints error message but should be silent
> >Category:system
> >Environment:
> System : OpenBSD 5.9
> Details : OpenBSD 5.9 (GENERIC.MP) #1888: Fri Feb 26 01:20:19 MST
> 2016
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> The command:
>
> rm -rf ""
>
> prints to STDERR:
>
> rm: No such file or directory
>
> but it should print nothing because of the -f flag.
This fixes it.
Index: rm.c
===
RCS file: /cvs/src/bin/rm/rm.c,v
retrieving revision 1.37
diff -u -p -r1.37 rm.c
--- rm.c15 Apr 2016 23:09:57 - 1.37
+++ rm.c28 Jun 2016 14:49:42 -
@@ -150,8 +150,11 @@ rm_tree(char **argv)
flags = FTS_PHYSICAL;
if (!needstat)
flags |= FTS_NOSTAT;
- if (!(fts = fts_open(argv, flags, NULL)))
- err(1, NULL);
+ if (!(fts = fts_open(argv, flags, NULL))) {
+ if (!fflag || errno != ENOENT)
+ err(1, NULL);
+ return;
+ }
while ((p = fts_read(fts)) != NULL) {
switch (p->fts_info) {
case FTS_DNR:
Re: when to free tls config?
Joel Sing wrote: > On Saturday 25 June 2016 22:58:59 Ted Unangst wrote: > > It's unfortunately unclear from the documentation when it is safe to call > > tls_config_free(). One might naively assume after a call to tls_configure, > > but that's not correct as the config is also accessed during connect. > > Right, we currently keep a reference to the tls_config struct within the > context. We could fix this by (a) improving the documentation (only free > after > all tls contexts have been freed), (b) copying the configuration struct when > tls_configure() is called or (c) reference counting on the tls_config. Out of > these it is probably preferable to do reference counting so that you can > immediately tls_config_free() after tls_configure(). Thoughts? ref counting makes sense. It may be difficult for programs to correctly maintain lifetimes for two dependent objects.
when to free tls config?
It's unfortunately unclear from the documentation when it is safe to call tls_config_free(). One might naively assume after a call to tls_configure, but that's not correct as the config is also accessed during connect.
Re: panic: pool_do_get: pfstitem free list modified
Alexey Suslikov wrote:
> ddb{3}> show panic
> pool_do_get: pfstitem free list modified: page 0xff01e8e2c000; item addr
> 0x
> ff01e8e2cc90; offset 0x0=0x139e137bdb8816c8 != 0x139e136bdb8816c8
struct pf_state_item {
TAILQ_ENTRY(pf_state_item) entry;
struct pf_state *s;
};
A one bit corruption in a pointer looks a lot like memory failure.
Re: gzip pledge - change in behavior
Simon Mages wrote: > I just noticed a problem with gzip in OpenBSD 5.9 introduced with pledge: > if root compresses a file, the owner and group are not copied onto the created > archive file: > > user@obsd59:tmp >ls -l server.log > > -rw-r--r-- 1 user wheel 345 Jun 3 09:16 server.log > > user@obsd59:tmp >sudo gzip server.log > > user@obsd59:tmp >ls -l server.log.gz > > -rw-r--r-- 1 root wheel 234 Jun 3 09:16 server.log.gz > > This change in behavior makes especially problems in newsyslog, as newsyslog > sets owner and group of the rotated file prior to calling gzip. > As a result, every .0 file which is compressed will belong to root:wheel > instead > of the correct user and group. ack. we're looking at it. pledge failing chown is intentional, but the consequence in gzip was not.
Re: dig -p should abort instead of printing a warning
peter.van.d...@powerdns.com wrote:
> >Synopsis:dig -p prints a warning and ignores the argument
> >Category:user
> >Environment:
> System : OpenBSD 5.9
> Details : OpenBSD 5.9 (GENERIC.MP) #4: Thu May 19 08:22:39 CEST 2016
>
> jas...@stable-59-amd64.mtier.org:/binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/GENERIC.MP
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> Since revision 1.15 at
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bind/bin/dig/dig.c, dig
> ignores the -p option and instead sends to 53. I understand how support for
> pledge() makes it impossible to support -p, however, just ignoring the
> argument leads to several painful potential failure modes.
>
> >How-To-Repeat:
> $ dig -p 5300 www.example.com @localhost
> ;; Warning, -p option ignored
This should work a little better.
Index: dig.c
===
RCS file: /cvs/src/usr.sbin/bind/bin/dig/dig.c,v
retrieving revision 1.16
diff -u -p -r1.16 dig.c
--- dig.c 11 Nov 2015 02:52:46 - 1.16
+++ dig.c 4 Jun 2016 18:28:08 -
@@ -1192,8 +1192,10 @@ dash_option(char *option, char *next, di
strlcpy(keyfile, value, sizeof(keyfile));
return (value_from_next);
case 'p':
- fprintf(stderr, ";; Warning, -p option ignored\n");
- /* port = (in_port_t) parse_uint(value, "port number",
MAXPORT); */
+ if (parse_uint(value, "port number", MAXPORT) != 53) {
+ fprintf(stderr, ";; Error, only port 53 supported\n");
+ exit(1);
+ }
return (value_from_next);
case 'q':
if (!config_only) {
Re: Small lock.c patch
ilya.kali...@gmail.com wrote: > Brace belongs to switch statement, not while loop > > RCS file: /cvs/src/usr.bin/lock/lock.c,v > retrieving revision 1.32 > diff -u -p -r1.32 lock.c > --- lock.c 15 Oct 2015 02:35:04 - 1.32 > +++ lock.c 27 May 2016 21:41:15 - > @@ -134,7 +134,7 @@ main(int argc, char *argv[]) > "usage: %s [-np] [-a style] [-t timeout]\n", > __progname); > exit(1); > - } > + } > timeout.tv_sec = sectimeout * 60; > > gethostname(hostname, sizeof(hostname)); I think these problems are best fixed by adding braces in both places. That's a very large while() to leave a bare statement dangling off it.
Re: two audio beep bugs
Mark Kettenis wrote: > > I personally think the wsconsctl settings should be respected by X. > But perhaps we should have a more fundamental discussion about things > first about how X should interact with wscons. There is a more > fundamental problem here where X assumes it has full control over the > hardware. There still is the volume key issue and there are problems Implementation issues aside, as a user, my expectation is that X is a client of the hardware. Therefore any "hardware" settings I have configured elsewhere will be respected. I don't see any difference between speaker volume and network interfaces. X uses my existing network configuration, so it should be the same for other interfaces.
two audio beep bugs
1. I have wsconsctl keyboard.bell.volume=0 because I don't like things beeping at me. This recently stopped working in xterm, where I now get a loud beep. Related to loss of pcvt? I'm not sure where the failure is, but my expectation is that if I say the glass console doesn't beep, then I don't want it beeping. Somehow the beeps are getting routed into the audio device before wscons fixes them. 2. Even with mixerctl inputs.mix_beep=0 I still here beeps. They are softer, but they are not gone. My expectation is that if I set something to 0, it should disappear. 2015 Thinkpad X1 Carbon OpenBSD 5.9-current (GENERIC.MP) #1998: Wed Apr 27 15:44:04 MDT 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80 real mem = 8238301184 (7856MB) avail mem = 7984259072 (7614MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (66 entries) bios0: vendor LENOVO version "N14ET28W (1.06 )" date 03/12/2015 bios0: LENOVO 20BSCTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT 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-5300U CPU @ 2.30GHz, 2195.30 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,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 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-5300U CPU @ 2.30GHz, 2194.92 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT 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-5300U CPU @ 2.30GHz, 2194.92 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT 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-5300U CPU @ 2.30GHz, 2194.92 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,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, 40 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 3 (EXP1) acpiprt3 at acpi0: bus 4 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus -1 (EXP6) 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 acpicpu2 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 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 acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB "LEN0071" at acpi0 not configured "LEN0048" at acpi0 not configured acpibat0 at acpi0: BAT0 model "00HW003" serial 546 type LiP oem "SMP" acpiac0 at acpi0: AC unit onli
Re: a subset of kevent fails to work with setuid()
Luke Small wrote: > The other kevent calls I use seem to work alright, but when run as root, > this fails. contrary to the manual, kevent() enforces additional restrictions on watching procs. this is a local change that was made when kqueue was first imported, but i can't think of a reason why.
Re: race between kqueue vnode note for writes triggering reads on a pre-mmapped file segment
Ben Woolley wrote: > Do the updates of the mmap happen in the order that writes are made? > If so, I could at least tell when coherence was reached. > > But it isn't a huge deal. The main purpose was to be able to share > memory between workers, and I can just do a read() into the shared > memory to make the memory coherent. I'm not sure it's possible to predict when a write() will become visible via mmap(). If feasible, I would try doing the write via mmap as well. Or as you say, if you only need shared memory, read() back into it would work.
Re: race between kqueue vnode note for writes triggering reads on a pre-mmapped file segment
Ben Woolley wrote: > On both UFS and tmpfs, if you watch for updates to the file with > kqueue, and pre-mmap a segment of the file, using the kqueue data to > notify of updates to the file crusor, and append the file in a > separate process, the written contents will populate AFTER the kqueue > event is received, and is starting to be read. Part of the end of the > read (of mapped memory) will still have 0s until the write completes. openbsd does not have coherent mmap. you can't rely on read/write and mmap working together.
Re: [bug?] pthread_barrier_wait
Kári Tristan Helgason wrote: > I apologise in advance if the diff appears strange, I don't really know how > to get cvs to do what I want. cvs diff -u helps a lot. :)
Re: [bug?] pthread_barrier_wait
Paul Irofti wrote:
> > What do you think?
>
> I think this diff is even safer: it checks for threads entering and
> exiting the barrier while holding the mutex, and if both values are 0 it
> proceeds to destroy the barrier.
>
> I also renamed sofar to in so that the relationship between threads is
> more obvious.
where did this go?
>
>
> Index: rthread.h
> ===
> RCS file: /cvs/src/lib/librthread/rthread.h,v
> retrieving revision 1.55
> diff -u -p -r1.55 rthread.h
> --- rthread.h 27 Jan 2016 08:40:05 - 1.55
> +++ rthread.h 16 Mar 2016 12:36:39 -
> @@ -141,7 +141,8 @@ struct pthread_barrier {
> pthread_mutex_t mutex;
> pthread_cond_t cond;
> int threshold;
> - int sofar;
> + int in;
> + int out;
> int generation;
> };
>
> Index: rthread_barrier.c
> ===
> RCS file: /cvs/src/lib/librthread/rthread_barrier.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 rthread_barrier.c
> --- rthread_barrier.c 23 Apr 2012 08:30:33 - 1.2
> +++ rthread_barrier.c 16 Mar 2016 12:36:39 -
> @@ -74,12 +74,18 @@ pthread_barrier_destroy(pthread_barrier_
> if (barrier == NULL || *barrier == NULL)
> return (EINVAL);
>
> + if (pthread_mutex_trylock(&(*barrier)->mutex))
> + return (EBUSY);
> +
> b = *barrier;
>
> - if (b->sofar > 0)
> + if (b->out > 0 || b->in > 0) {
> + pthread_mutex_unlock(&b->mutex);
> return (EBUSY);
> + }
>
> *barrier = NULL;
> + pthread_mutex_unlock(&b->mutex);
> pthread_mutex_destroy(&b->mutex);
> pthread_cond_destroy(&b->cond);
> free(b);
> @@ -103,9 +109,10 @@ pthread_barrier_wait(pthread_barrier_t *
> if ((rc = pthread_mutex_lock(&b->mutex)))
> goto cancel;
>
> - _rthread_debug(6, "sofar: %d, threshold: %d\n", b->sofar, b->threshold);
> - if (++b->sofar == b->threshold) {
> - b->sofar = 0;
> + _rthread_debug(6, "in: %d, threshold: %d\n", b->in, b->threshold);
> + if (++b->in == b->threshold) {
> + b->out = b->in - 1; /* mark thread exit */
> + b->in = 0;
> b->generation++;
> if ((rc = pthread_cond_broadcast(&b->cond)))
> goto err;
> @@ -118,6 +125,7 @@ pthread_barrier_wait(pthread_barrier_t *
> if ((rc = pthread_cond_wait(&b->cond, &b->mutex)))
> goto err;
> } while (gen == b->generation);
> + b->out--; /* mark thread exit */
> }
>
> err:
>
openssl command can't be exited
Accidentally ask for a password: # openssl genrsa -aes256 -out /etc/ssl/private/server.key 2048 Generating RSA private key, 2048 bit long modulus .+++ ...+++ e is 65537 (0x10001) Enter pass phrase for /etc/ssl/private/server.key: 822626074580:error:28069065:lib(40):UI_set_result:result too small:/home/tedu/src/lib/libcrypto/crypto/../../libssl/src/crypto/ui/ui_lib.c:834:You must type in 4 to 1023 characters Enter pass phrase for /etc/ssl/private/server.key: Enter pass phrase for /etc/ssl/private/server.key: And now you can't quit. ^C doesn't work. ^D doesn't work. pkill openssl in another terminal doesn't work. Nothing works.
Re: equivalence classes do NOT work at all
George Delles wrote: > # echo á | grep '[[=a=]]'# echo ô | grep '[[=o=]]'# > On Linux to compare: > # echo á | grep '[[=a=]]'á# echo ô | grep '[[=o=]]'ô# > «STANDARDSThe grep utility is compliant with the IEEE Std 1003.1-2008 > (“POSIX.1”) specification». > http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/egrep.1?query=grep > > IEEE Std 1003.1: > «9.3.5 RE Bracket Expression...It consists of one or more expressions: > collating elements, collating symbols, equivalence classes...» > http://pubs.opengroup.org/onlinepubs/009696899/basedefs/xbd_chap09.html unicode support is incomplete.
"apropos Vt=short" finds nothing
My understanding is that "apropos Vt=short" should find the stdarg.3 man page. "apropos Va=va_list" does find the page, so I think I have a working index.
Re: dhclient doesn't work in trunk failover
timo.my...@wickedbsd.net wrote: > This might be caused by my current setup. I haven't used the ethernet > with my Thinkpad in ages. Previously I had the wireless and wired > clients in same subnet. This time the wireless and wired clients use > different subnets. Might explain why it previously has worked. Long story short, trunk is used to combine two interfaces that are connected to the same network. Combining two interfaces connected to different networks works less well.
Re: libc getaddrinfo() bug
Serguey Parkhomovsky wrote: > On Wed, Dec 16, 2015 at 06:08:22PM -0500, Ted Unangst wrote: > > > > well, nobody fixed it, so if it's working, it's not using getaddrinfo. > > > > Hmmm... looks like getaddrinfo was using my nameserver to resolve the > decimal IP? I get the same behavior in -current by passing the > AI_NUMERICHOST flag in hints. The following patch should fix this issue: We're not convinced we want to fix this. The RFC may be mistaken in perpetuating this silliness.
Re: screen brightness resets
Mark Kettenis wrote:
> > From: "Ted Unangst"
> > Date: Wed, 09 Dec 2015 06:49:42 -0500
> >
> > Thinkpad X1 2015 (broadwell). This is a recent regression, though I'm not
> > sure
> > when it was introduced. I have lidsuspend=0. When I close the lid and open
> > it
> > again, the screen comes back at 100% brightness. As in, far too bright.
> >
> > Previously, the screen would always open back up at the same brightness
> > level
> > I closed it at. kettenis mentioned that the keyboard brightness keys work
> > (they do) but that's a recent addition. For many months, they did not. I
> > wonder if the changes are correlated.
>
> They probably are. And probably the weird behaviour of the brightness
> keys is related as well. See my rants about ACPI being fucked because
> we claim to support both Windows 7 and Windows 8. My suggestion would
> be to comment out most of the Windows versions in the "aml_valid_osi"
> array and see how the behaviour changes if you only enable the
> "Windows 2012", "Windows 2009" or "Windows 2006" entry.
It took a while to get around to it, but I'm now running with the diff below
and things seem much more sensible. The brightness controls still work, but
things don't reset every time I add or remove power.
Index: acpi/dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.218
diff -u -p -r1.218 dsdt.c
--- acpi/dsdt.c 20 Aug 2015 20:50:10 - 1.218
+++ acpi/dsdt.c 9 Dec 2015 14:06:50 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: dsdt.c,v 1.218 2015/08/20 20:50:10 kettenis Exp $ */
+/* $OpenBSD: dsdt.c,v 1.217 2015/05/04 10:42:06 jmatthew Exp $ */
/*
* Copyright (c) 2005 Jordan Hargrave
*
@@ -1476,18 +1476,7 @@ struct aml_defval {
* We return True for Windows to fake out nasty bad AML
*/
char *aml_valid_osi[] = {
- "Windows 2000",
- "Windows 2001",
- "Windows 2001.1",
- "Windows 2001 SP0",
- "Windows 2001 SP1",
- "Windows 2001 SP2",
- "Windows 2001 SP3",
- "Windows 2001 SP4",
- "Windows 2006",
"Windows 2009",
- "Windows 2012",
- "Windows 2013",
NULL
};
Re: libc getaddrinfo() bug
Serguey Parkhomovsky wrote:
> On Wed, Dec 16, 2015 at 04:17:53PM -0500, Ted Unangst wrote:
> > >
> > > This seems to have been fixed in -current. Verified by running:
> > >
> > > openbsd:~ sparkhom$ getent hosts 1755800511
> > > 104.167.99.19 11755800511
> >
> > that doesn't call getaddrinfo().
>
> Are you sure? In hostsaddrinfo():
well, nobody fixed it, so if it's working, it's not using getaddrinfo.
>
> if (getaddrinfo(name, NULL, &hints, &res0) == 0) {
>
> Which gets called in hosts() after both inet_pton calls return 0:
>
> if (inet_pton(AF_INET6, argv[i], (void *)addr) > 0)
> he = gethostbyaddr(addr, IN6ADDRSZ, AF_INET6);
> else if (inet_pton(AF_INET, argv[i], (void *)addr) > 0)
> he = gethostbyaddr(addr, INADDRSZ, AF_INET);
> if (he != NULL)
> hostsprint(he);
> else if ((rv = hostsaddrinfo(argv[i])) == RV_NOTFOUND)
> break;
Re: libc getaddrinfo() bug
Serguey Parkhomovsky wrote: > On Tue, Dec 15, 2015 at 01:08:22AM -0800, am...@backwatcher.com wrote: > > >Synopsis: getaddrinfo() fails 32bit decimal IP addresses (i.e. no octets) > > >Category: library > > >Environment: > > System : OpenBSD 5.8 > > Details : OpenBSD 5.8 (GENERIC) #1170: Sun Aug 16 02:26:00 MDT 2015 > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > Please reference NetBSD PR #50552 for a thorough description. > > http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50552 > > >How-To-Repeat: > > OpenBSD doesn't have the getaddrinfo(1) utility (see above referenced > > NetBSD PR), so it's a little less easy to exhibit the issue on OpenBSD, > > but basically just pass a 32bit decimal IP address (e.g. 1755800511) to > > getaddrinfo(3) via any expeditions means. > > >Fix: > > The fix is well covered in the foregoing reference. > > > > This seems to have been fixed in -current. Verified by running: > > openbsd:~ sparkhom$ getent hosts 1755800511 > 104.167.99.19 11755800511 that doesn't call getaddrinfo().
Re: httpd crashes when fetching a hidden file located on a CD
Ted Unangst wrote: > Jonathan Gray wrote: > > > > > > There's one thing to add though, it looks like it happens for any file on > > > cd9660, not just dotfiles. > > > > It is worth pointing out that httpd has had trouble serving files off > > specific filesystems in the past due to kqueue issues. > > > > cd9660_vops does not currently set .vop_kqfilter, does anything change > > if you set EVENT_NOKQUEUE before running httpd? > > this maybe adds kqueue to cd9660. We've confirmed this diff fixes the problem. However, there seems to be a larger problem that httpd/libevent cannot gracefully handle the condition where kevent returns an error. We are doomed to see this problem repeat if that is not addressed.
Re: screen brightness resets
Ted Unangst wrote: > Thinkpad X1 2015 (broadwell). This is a recent regression, though I'm not sure > when it was introduced. I have lidsuspend=0. When I close the lid and open it > again, the screen comes back at 100% brightness. As in, far too bright. > > Previously, the screen would always open back up at the same brightness level > I closed it at. kettenis mentioned that the keyboard brightness keys work > (they do) but that's a recent addition. For many months, they did not. I > wonder if the changes are correlated. Little more info. Sorry, it's not related to lid closing. It's related to power status changing. (which tends to happen in correlation with lid operations). Every time I attach or remove the power plug the screen jumps to 100% brightness. This would almost even make sense if it only happened when plugging in, but in what world do I want the screen to jump from 20% to 100% when I *remove* power?
