Fixing sluggish performance on Thinkpad X1 Carbon 6th gen with proper BIOS settings
Hello, several people reported about various problems with Lenovo Thinkpad X1 Carbon 6th gen (X1C6), when performance become sluggish and fan goes wild. [1] [2] [3] I had similar problem (system OK, become sluggish with high CPU utilization after sleep/wake), but was able to completely and reliably fix it by updating to latest Lenovo BIOS (2018-09-17, version 1.31), and setting the following settings in the BIOS: * UEFI Secure Boot: Off * Power -> Sleep State: Linux * Startup -> UEFI/Legacy Boot: UEFI Only * Startup -> CSM Support: Yes * Config -> Thunderbolt(TM) 3 -> Thunderbolt BIOS Assist Mode: Enable * Config -> Thunderbolt(TM) 3 -> Wake by Thunderbolt(TM) 3: Disable It's the Thunderbolt BIOS Assist Mode: Enable that finally solved my problem. (In the BIOS itself, it recommends to set this option to Enable for Linux systems). Everything is perfect now with my system. I'm running -current: thor$ dmesg | grep OpenBSD OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 I'm happy to assist other OpenBSD users or developers if you need help further investigating this issue. I have described my adventure, along with dmesg and other details, here [4]. My dmesg is below. [1] https://www.youtube.com/watch?v=lb7mDXHGDFk [2] https://marc.info/?l=openbsd-bugs&m=154070079630478 [3] https://marc.info/?l=openbsd-bugs&m=153770491811274&w=2 [4] https://www.reddit.com/r/openbsd/comments/9q8atz/thinkpad_x1c6_heats_up_dramatically_drops/ OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16912433152 (16128MB) avail mem = 16390590464 (15631MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x4f057000 (63 entries) bios0: vendor LENOVO version "N23ET56W (1.31 )" date 09/17/2018 bios0: LENOVO 20KHCTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT SSDT BOOT BATB SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM DMAR NHLT ASF! FPDT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1393.14 MHz, 06-8e-0a cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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 23MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1138.49 MHz, 06-8e-0a cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 950.25 MHz, 06-8e-0a cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 897.90 MHz, 06-8e-0a 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,RD
Old OpenBSD 6.1 Diagnosing alloc_subregion: can't allocate region and resource shortage: 1 pages of swap lost
Hello, I have have a box terminating openVPN connections and after an upstream router rebooted suddenly I salw a klog error followed by an alloc_subregion error followed by extent_alloc_subregion error the OpenBSD Box ram s ram (according to the hypervisor) was not completely used up... is there any other reason why the error below can occur ... are there any sysctl settings changes I need to condsider to avoid this error in future ... Thanks Tom Smyth Oct 28 08:03:20 persistent02 /bsd: klog: dropped 906578 bytes, message buffer full Oct 28 08:03:36 persistent02 /bsd: alloc_subregion: can't allocate region descriptor Oct 28 08:03:36 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: warning: resource shortage: 1 pages of swap lost Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't allocate region descriptor Oct 28 08:03:39 persistent02 /bsd: extent_alloc_subregion: can't alloc
Re: Fixing sluggish performance on Thinkpad X1 Carbon 6th gen with proper BIOS settings
WARNING: I do not know if the orginal author is serious, or if he is trolling. But there are known issues with the stated Thunderbolt setting in BIOS that can brick your Thinkpad beyond repair (or BIOS reset). See here: https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/Thinkpad-X1-Yoga-3rd-Gen-Stuck-at-Black-Screen-After-Enabling/td-p/4106952/page/3 https://forums.lenovo.com/t5/ThinkPad-P-and-W-Series-Mobile/Lenovo-P52-bricked-by-selecting-BIOS-thunderbolt-support-for/td-p/4207538 https://www.reddit.com/r/thinkpad/comments/9qmqd2/thinkpad_p1_serious_issue_with_bricked_bios/ https://www.reddit.com/r/thinkpad/comments/9nb3zo/new_thinkpad_p72_biosuefi_corrupted_just_black/ (german) https://www.notebookcheck.com/Lenovo-Einige-aktuelle-ThinkPads-koennen-scheinbar-durch-eine-UEFI-Einstellung-zerstoert-werden.346101.0.html /Robert On Sun, 28 Oct 2018 00:50:03 -0700 ivp...@eml.cc wrote: > Hello, > > several people reported about various problems with Lenovo Thinkpad X1 Carbon > 6th gen (X1C6), when performance become sluggish and fan goes wild. [1] [2] > [3] > > I had similar problem (system OK, become sluggish with high CPU utilization > after sleep/wake), but was able to completely and reliably fix it by updating > to latest Lenovo BIOS (2018-09-17, version 1.31), and setting the following > settings in the BIOS: > > * UEFI Secure Boot: Off > * Power -> Sleep State: Linux > * Startup -> UEFI/Legacy Boot: UEFI Only > * Startup -> CSM Support: Yes > * Config -> Thunderbolt(TM) 3 -> Thunderbolt BIOS Assist Mode: Enable > * Config -> Thunderbolt(TM) 3 -> Wake by Thunderbolt(TM) 3: Disable > > It's the Thunderbolt BIOS Assist Mode: Enable that finally solved my problem. > (In the BIOS itself, it recommends to set this option to Enable for Linux > systems). Everything is perfect now with my system. > > I'm running -current: > > thor$ dmesg | grep OpenBSD > OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 > > I'm happy to assist other OpenBSD users or developers if you need help > further investigating this issue. I have described my adventure, along with > dmesg and other details, here [4]. My dmesg is below. > > [1] https://www.youtube.com/watch?v=lb7mDXHGDFk > [2] https://marc.info/?l=openbsd-bugs&m=154070079630478 > [3] https://marc.info/?l=openbsd-bugs&m=153770491811274&w=2 > [4] > https://www.reddit.com/r/openbsd/comments/9q8atz/thinkpad_x1c6_heats_up_dramatically_drops/ > > OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 16912433152 (16128MB) > avail mem = 16390590464 (15631MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x4f057000 (63 entries) > bios0: vendor LENOVO version "N23ET56W (1.31 )" date 09/17/2018 > bios0: LENOVO 20KHCTO1WW > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT > SSDT SSDT BOOT BATB SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM > DMAR NHLT ASF! FPDT UEFI > acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) > RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) > PXSX(S4) RP07(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 2399 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1393.14 MHz, 06-8e-0a > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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 23MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1138.49 MHz, 06-8e-0a > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: api
Re: ikev2 and road warriors setup
Hello, I really need your help. I am still trying to configure Ikev2 VPN Gateway (A.B.C.77/23) for road warriors clients (Windows). The problem is that it works ONLY if clients are in the same subnet as VPN Gateway (A.B.C.0/23). Clients from out of the gateway's subnet (!A.B.C.0/23) can not establish the connection (809 Error). It does not matter if they are behind NAT or not, tried different ISP - the same. Current tested client is Win7 (1.2.3.119). It works from A.B.C.0/23 I do not know what I am doing wrong. Can anyone please help me with solving this problem? Thank you. This is a fresh 6.3/i386 install: # syspatch -l 001_perl 002_libtls 003_arp 004_gif 005_httpd 006_ipseclen 007_libcrypto 008_ipsecout 009_libcrypto 011_perl 012_execsize 013_ipsecexpire 014_amdlfence 015_ioport WAN: # cat /etc/hostname.vr0 inet A.B.C.77 255.255.254.0 LAN: # cat /etc/hostname.vr3 inet 172.16.0.254 255.255.255.0 NONE group lan # cat /etc/hostname.enc0 inet 10.0.1.1 255.255.255.0 10.0.1.255 up # cat /etc/iked.conf ikev2 "test" passive esp \ from 0.0.0.0/0 to 0.0.0.0/0 \ local A.B.C.77 peer any \ srcid A.B.C.77 \ config address 10.0.1.0/24 \ config name-server 8.8.8.8 \ tag "IKED" # cat /etc/pf.conf set skip on {lo, enc} match in all scrub (no-df random-id max-mss 1310) match out on egress from lan:network to any nat-to egress match out on egress from enc0:network to any nat-to egress block log all pass in on egress proto udp from any to any port {isakmp,ipsec-nat-t} pass in on egress proto {ah,esp} pass out on egress pass on lan pass in on egress proto tcp from { 1.2.3.119 A.B.C.0/23 } to port ssh icmp_types = "{ echoreq, unreach }" pass inet proto icmp all icmp-type $icmp_types # ikectl show ca vpn certificates subject= /C=PL/ST=ZP/L=KL/O=PK/OU=test/CN=A.B.C.77/emailAddress=t...@123.com SHA1 Fingerprint=37:2F:33:EA:C4:9C:45:0A:80:38:EC:0E:A6:F8:8B:EA:10:84:71:CB notBefore=Oct 25 12:23:53 2018 GMT notAfter=Oct 25 12:23:53 2019 GMT subject= /C=PL/ST=ZK/L=KL/O=PK/OU=test/CN=A.B.C.77/emailAddress=t...@123.com SHA1 Fingerprint=4C:AE:A5:C6:E3:71:81:09:C0:73:BF:03:5F:E2:02:CE:48:BF:03:78 notBefore=Oct 25 12:27:35 2018 GMT notAfter=Oct 25 12:27:35 2019 GMT subject= /C=PL/ST=ZK/L=KL/O=PK/OU=test/CN=win7/emailAddress=t...@123.com SHA1 Fingerprint=E2:C1:96:F3:26:0F:CA:CD:49:0A:33:65:58:0E:07:B7:A7:90:D4:18 notBefore=Oct 25 12:32:31 2018 GMT notAfter=Oct 25 12:32:31 2019 GMT subject= /C=PL/ST=ZK/L=KL/O=PK/OU=test/CN=w520/emailAddress=w...@123.com SHA1 Fingerprint=00:ED:49:7B:CE:AF:46:25:BE:39:B6:51:AD:3E:06:91:99:58:50:C9 notBefore=Oct 27 08:54:14 2018 GMT notAfter=Oct 27 08:54:14 2019 GMT # iked -vvd ikev2 "test" passive esp inet from 0.0.0.0/0 to 0.0.0.0/0 local A.B.C.77 peer any ikesa enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 srcid A.B.C.77 lifetime 10800 bytes 536870912 signature config address 10.0.1.0 config name-server 8.8.8.8 tag "IKED" /etc/iked.conf: loaded 1 configuration rules ca_privkey_serialize: type RSA_KEY length 1193 ca_pubkey_serialize: type RSA_KEY length 270 ca_privkey_to_method: type RSA_KEY method RSA_SIG ca_getkey: received private key type RSA_KEY length 1193 ca_getkey: received public key type RSA_KEY length 270 ca_dispatch_parent: config reset config_getpolicy: received policy config_getpfkey: received pfkey fd 3 config_getcompile: compilation done config_getsocket: received socket fd 4 config_getsocket: received socket fd 5 config_getsocket: received socket fd 6 ca_reload: loaded ca file ca.crt config_getsocket: received socket fd 7 config_getmobike: mobike ca_reload: loaded crl file ca.crl ca_reload: /C=PL/ST=ZP/L=KL/O=PK/OU=test/CN=A.B.C.77/emailAddress=t...@123.com ca_reload: loaded 1 ca certificate ca_reload: loaded cert file A.B.C.77.crt ca_validate_cert: /C=PL/ST=ZK/L=KL/O=PK/OU=test/CN=A.B.C.77/emailAddress=t...@123.com ok ca_reload: local cert type X509_CERT config_getocsp: ocsp_url none ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20 ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20 ikev2_recv: IKE_SA_INIT request from initiator 1.2.3.119:500 to A.B.C.77:500 policy 'test' id 0, 528 bytes ikev2_recv: ispi 0x683d59d10fbe4a9e rspi 0x ikev2_policy2id: srcid IPV4/A.B.C.77 length 8 ikev2_pld_parse: header ispi 0x683d59d10fbe4a9e rspi 0x nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 528 response 0 ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 256 ikev2_pld_sa: more 2 reserved 0 length 40 proposal #1 protoid IKE spisize 0 xforms 4 spi 0 ikev2_pld_xform: more 3 reserved 0 length 8 type ENCR id 3DES ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1 ikev2_pld_xform: more 0 reserved 0 length 8 type DH id MODP_1024
Re: Fixing sluggish performance on Thinkpad X1 Carbon 6th gen with proper BIOS settings
Hi Robert, I'm certainly not trolling (although I'm not sure what would be a protocol to prove it, other than posting a video that shows all mentioned BIOS settings and than a successful boot), and I'm sure you are not trolling either, as I can see a number of postings to this mailing list and your first one is from 10 years ago. [1] A never considered a threat model where a malicious user posts knowingly bad BIOS settings to brick other users machines, thank you for being vigilant. If anyone else thinks that posting a video with my BIOS settings and a successful boot would be useful, I'm happy to do that. In addition to double-checking my settings, I also looked at 4 links you've provided (I don't read German and can't check the last one). The first one is a very similar machine (the difference, from what I understand, is that all Yoga's have a multi-touch screen), but the post is from 7/13, and whatever the issue they encountered, I'm using a later BIOS (version 1.31 from 9/15). The second one is posted on 9/15, but the author and few others with similar problems have P52, which is a different machine - dual graphics with NVIDIA chip and a different CPUs - either i8750H or i8850H 6-core processors, while I have a i8550U. However, what is similar, is that enabling the BIOS Assist Mode does indeed require a 15-sec or so reboot, as the author describes, and that seemed to be a step that bricked their machine. The third author also has a different machine (P1, also with NVIDIA graphics), and they refer to BIOS version 1.12 from 10/12 release - again, a different BIOS. They also post a solution for their problem [2], however it requires extracting firmware and flushing it to EEPROM, so you better know what you are doing. The fourth author has a P72 (also a machine with NVIDIA graphics), and they did say they changed something in BIOS although they never specify what exactly. Thanks! [1] https://marc.info/?l=openbsd-misc&m=128033208924257&w=2 [2] https://www.reddit.com/r/thinkpad/comments/9rnimi/ladies_and_gentlemen_i_present_to_you_the/ On Sun, Oct 28, 2018, at 4:47 AM, Robert wrote: > WARNING: > > I do not know if the orginal author is serious, or if he is trolling. > > But there are known issues with the stated Thunderbolt setting in BIOS > that can brick your Thinkpad beyond repair (or BIOS reset). > > See here: > https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/Thinkpad-X1-Yoga-3rd-Gen-Stuck-at-Black-Screen-After-Enabling/td-p/4106952/page/3 > https://forums.lenovo.com/t5/ThinkPad-P-and-W-Series-Mobile/Lenovo-P52-bricked-by-selecting-BIOS-thunderbolt-support-for/td-p/4207538 > https://www.reddit.com/r/thinkpad/comments/9qmqd2/thinkpad_p1_serious_issue_with_bricked_bios/ > https://www.reddit.com/r/thinkpad/comments/9nb3zo/new_thinkpad_p72_biosuefi_corrupted_just_black/ > > (german) > https://www.notebookcheck.com/Lenovo-Einige-aktuelle-ThinkPads-koennen-scheinbar-durch-eine-UEFI-Einstellung-zerstoert-werden.346101.0.html > > /Robert > > > On Sun, 28 Oct 2018 00:50:03 -0700 > ivp...@eml.cc wrote: > > > Hello, > > > > several people reported about various problems with Lenovo Thinkpad X1 > > Carbon 6th gen (X1C6), when performance become sluggish and fan goes wild. > > [1] [2] [3] > > > > I had similar problem (system OK, become sluggish with high CPU utilization > > after sleep/wake), but was able to completely and reliably fix it by > > updating to latest Lenovo BIOS (2018-09-17, version 1.31), and setting the > > following settings in the BIOS: > > > > * UEFI Secure Boot: Off > > * Power -> Sleep State: Linux > > * Startup -> UEFI/Legacy Boot: UEFI Only > > * Startup -> CSM Support: Yes > > * Config -> Thunderbolt(TM) 3 -> Thunderbolt BIOS Assist Mode: Enable > > * Config -> Thunderbolt(TM) 3 -> Wake by Thunderbolt(TM) 3: Disable > > > > It's the Thunderbolt BIOS Assist Mode: Enable that finally solved my > > problem. (In the BIOS itself, it recommends to set this option to Enable > > for Linux systems). Everything is perfect now with my system. > > > > I'm running -current: > > > > thor$ dmesg | grep OpenBSD > > OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 > > > > I'm happy to assist other OpenBSD users or developers if you need help > > further investigating this issue. I have described my adventure, along with > > dmesg and other details, here [4]. My dmesg is below. > > > > [1] https://www.youtube.com/watch?v=lb7mDXHGDFk > > [2] https://marc.info/?l=openbsd-bugs&m=154070079630478 > > [3] https://marc.info/?l=openbsd-bugs&m=153770491811274&w=2 > > [4] > > https://www.reddit.com/r/openbsd/comments/9q8atz/thinkpad_x1c6_heats_up_dramatically_drops/ > > > > OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 16912433152 (16128MB) > > avail mem = 16390590464 (15631MB) > > mpath0 at root > > scsibus0 at mpath0
Re: Redistributing between bgpd and ospfd
Henry Bonath(he...@thebonaths.com) on 2018.10.27 19:21:15 -0400: > Claudio - > > One use case where I personally ran into this need in the past is in an > MPLS PE-CE where OSPF is running between the Provider and Customer. (L3VPN) > One would want to redistribute the Customers OSPF routes into BGP as VPNv4 > prefixes into the customers VRF in the provider network. > > We typically run Cisco on our CPE's and do exactly this with our customers, > with a redistribute ospf statement under "address-family vpnv4 vrf > cusomerVRF" > I'd *love* to be able to do the same with OpenBSD and not have to fork out > Cisco money at the customer premise. This should already be possible (as described my mail) with network inet priority 32 > That being said, EIGRPD would also benefit here, as I have customers that > run EIGRP and want to use that on their CE's. same there, use priority 28 /Benno > Thanks for everything that you do, and keep up the great work! > > On Mon, Oct 15, 2018 at 8:37 AM Claudio Jeker > wrote: > > > On Mon, Oct 15, 2018 at 02:48:31PM +0300, Gregory Edigarov wrote: > > > On 15.10.18 12:58, Sebastian Benoit wrote: > > > > open...@kene.nu(open...@kene.nu) on 2018.10.15 11:05:41 +0200: > > > > > Hello, > > > > > > > > > > I am trying to get bgpd and ospfd play nicely with route > > redistribution. > > > > > > > > > > So far the only way I have found that suits my need is to use > > > > > bgpd.conf network statements and rtlabels. > > > > > > > > > > So, to make ospfd learn route from bgpd I use rtlabels. So in > > bgpd.conf: > > > > > match from set rtlabel from_bgpd > > > > > > > > > > And in ospfd.conf: > > > > > redistribute rtlabel from_bgpd > > > > > > > > > > > > > > > So far so good. But the other way around, to bake bgpd learn from > > > > > ospfd it becomes a bit more tedious. The only way I have found to > > make > > > > > bgpd announce ospf originated routes (to its bgp peers) is via > > network > > > > > statements in bgpd.conf. These network statements are not conditional > > > > > on the availability of such a route in ospf though so they are not > > > > > very dynamic anymore. > > > > > > > > > > I understand that it according to standard > > > > > (https://tools.ietf.org/html/rfc1364) should be something that is > > > > > explicit for type 1 and 2 LSAs. > > > > > > > > > > What is the recommended way to achieve dynamic explicit route > > > > > redistribution in both directions? > > > > Network statements are the correct way. > > > > > > > > You can use > > > > > > > > network (inet|inet6) priority ... > > > > network (inet|inet6) rtlabel ... > > > > > > > > So with > > > > > > > >network inet priority 32 > > > > > > > > you should be able to redistribute all ospf routes into bgp. > > > > > > > > If this does not help, please explain your problem further (and > > include your > > > > config). > > > > > > > > (Note that you should run OpenBSD 6.4 (just use the latest snapshot) > > for > > > > this as there was at least a bugfix for route-labels.) > > > wouldn't it be nice to have rtlabels in ospf(6)d? I would even prefer > > > setting them per area, or per interface where a route was learned. > > > just wondering why is it not implemented yet. is that too complex > > change? or > > > just not necessary? > > > > > > > Until now there has not been a need for this. In general and probably best > > common practice is to not mix BGP and OSPF. Instead OSPF is building the > > underlaying network to run BGP on top of. This is why benno@ was asking > > for the use case. > > > > By the way, because of the nature of OSPF it does not make sense to tag > > routes by interface, doing it by area could be an option but that comes > > with some edge cases that need further inspection. > > > > -- > > :wq Claudio > > > > > --
Re: acme-client memory setup failure
On October 28, 2018 12:09:02 AM EDT, "연락 연락" wrote: >Thank you indeed for your reply, trondd. >Yes, I added certificate(s) to cert.pem, probably more than one time so >far. >But the size looks not much bigger than normal one that I see from >another host. >size of the cert.pem modified(?): 357*** >size of cert.pem I see from another host where I didn't add anything to > >the cert.pem: 349*** > >Do you think 357*** is too big? >How did you solve the issue? >What can I do if something went wrong when I added certificates or when > >upgrading openbsd and adding the certificates again? > Put the original cert.pem back and see if it solves the issue first. >If the router/gateway before the host has been changed so the cert.pem >of the gateway is not the same of the previous one, can it be also a >matter? > > The cert.pem only matters on the machine making the SSL connection. >On 28/10/2018 04:54, trondd wrote: >> On Sat, October 27, 2018 6:19 am, ì*°ë*½ ì*°ë*½ wrote: >>> Dear misc, >>> >>> I am getting an error saying "ssl verify memory setup failure" >whenever >>> I try to renew existing certificates on a host -- Openbsd 6.3, >httpd, >>> acme-client. >>> Recently there were changes in a few configurations, including >network, >>> name servers, etc. >>> >>> The below is all I get when I try command acme-clilent -vv >example.com: >>> >>> ..domain key >>> ..account key >>> ..cert ...days left >>> ..directory >>> ..DNS: (some ip) >>> (some ip):tls_connect_socket: acme-v01.api.letsencrypt.org, ssl >verify >>> memory setup failure >>> ..bad comm >>> bad exit... >>> >>> Could someone let me know what could cause the ssl verify memory >setup >>> failure, or if the memory setup failure could be some kind of common >>> error, such as something occurred by memory configuration, such as >in >>> login.conf? >>> >>> For your information, those worked before. Recently thinking about >>> hardware issues, especially for RAM. >>> Because I can't share detailed configurations, names, etc., I am >>> wondering if someone could kindly give some advice on the above >>> information. >>> >>> Any help and your time would be greatly appreciated indeed. >>> >> >> Did you modify certs.pem? I've run into this when accidentally >adding >> certs multiple times growing the file too big or writing a DOS >formatted >> cert to it. >>
Re: Old OpenBSD 6.1 Diagnosing alloc_subregion: can't allocate region and resource shortage: 1 pages of swap lost
Le 28 octobre 2018 11:55:20 GMT+01:00, Tom Smyth a écrit : >Hello, > >I have have a box terminating openVPN connections and after an >upstream router rebooted suddenly > >I salw a klog error followed by an alloc_subregion error followed by >extent_alloc_subregion error > >the OpenBSD Box ram s ram (according to the hypervisor) was not >completely used up... > >is there any other reason why the error below can occur ... > >are there any sysctl settings changes I need to condsider to avoid >this error in future ... > > >Thanks > >Tom Smyth It may be a bug in oenbsd or openvpn. You are 18 months behind regarding to updates, this may has been fixed since 6.1.
Re: Fixing sluggish performance on Thinkpad X1 Carbon 6th gen with proper BIOS settings
Hi ivpgbe@, Thanks for the details! Yes, it was not my intention to indicate anything; but since I saw those reports of bricked machines during the last days (and having Thinkpads myself) I wanted to be rather safe than sorry. regards, Robert On Sun, 28 Oct 2018 07:15:10 -0700 ivp...@eml.cc wrote: > Hi Robert, > > I'm certainly not trolling (although I'm not sure what would be a protocol to > prove it, other than posting a video that shows all mentioned BIOS settings > and than a successful boot), and I'm sure you are not trolling either, as I > can see a number of postings to this mailing list and your first one is from > 10 years ago. [1] A never considered a threat model where a malicious user > posts knowingly bad BIOS settings to brick other users machines, thank you > for being vigilant. If anyone else thinks that posting a video with my BIOS > settings and a successful boot would be useful, I'm happy to do that. > > In addition to double-checking my settings, I also looked at 4 links you've > provided (I don't read German and can't check the last one). > > The first one is a very similar machine (the difference, from what I > understand, is that all Yoga's have a multi-touch screen), but the post is > from 7/13, and whatever the issue they encountered, I'm using a later BIOS > (version 1.31 from 9/15). > > The second one is posted on 9/15, but the author and few others with similar > problems have P52, which is a different machine - dual graphics with NVIDIA > chip and a different CPUs - either i8750H or i8850H 6-core processors, while > I have a i8550U. However, what is similar, is that enabling the BIOS Assist > Mode does indeed require a 15-sec or so reboot, as the author describes, and > that seemed to be a step that bricked their machine. > > The third author also has a different machine (P1, also with NVIDIA > graphics), and they refer to BIOS version 1.12 from 10/12 release - again, a > different BIOS. They also post a solution for their problem [2], however it > requires extracting firmware and flushing it to EEPROM, so you better know > what you are doing. > > The fourth author has a P72 (also a machine with NVIDIA graphics), and they > did say they changed something in BIOS although they never specify what > exactly. > > Thanks! > > [1] https://marc.info/?l=openbsd-misc&m=128033208924257&w=2 > [2] > https://www.reddit.com/r/thinkpad/comments/9rnimi/ladies_and_gentlemen_i_present_to_you_the/ > > On Sun, Oct 28, 2018, at 4:47 AM, Robert wrote: > > WARNING: > > > > I do not know if the orginal author is serious, or if he is trolling. > > > > But there are known issues with the stated Thunderbolt setting in BIOS > > that can brick your Thinkpad beyond repair (or BIOS reset). > > > > See here: > > https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/Thinkpad-X1-Yoga-3rd-Gen-Stuck-at-Black-Screen-After-Enabling/td-p/4106952/page/3 > > https://forums.lenovo.com/t5/ThinkPad-P-and-W-Series-Mobile/Lenovo-P52-bricked-by-selecting-BIOS-thunderbolt-support-for/td-p/4207538 > > https://www.reddit.com/r/thinkpad/comments/9qmqd2/thinkpad_p1_serious_issue_with_bricked_bios/ > > https://www.reddit.com/r/thinkpad/comments/9nb3zo/new_thinkpad_p72_biosuefi_corrupted_just_black/ > > > > (german) > > https://www.notebookcheck.com/Lenovo-Einige-aktuelle-ThinkPads-koennen-scheinbar-durch-eine-UEFI-Einstellung-zerstoert-werden.346101.0.html > > > > /Robert > > > > > > On Sun, 28 Oct 2018 00:50:03 -0700 > > ivp...@eml.cc wrote: > > > > > Hello, > > > > > > several people reported about various problems with Lenovo Thinkpad X1 > > > Carbon 6th gen (X1C6), when performance become sluggish and fan goes > > > wild. [1] [2] [3] > > > > > > I had similar problem (system OK, become sluggish with high CPU > > > utilization after sleep/wake), but was able to completely and reliably > > > fix it by updating to latest Lenovo BIOS (2018-09-17, version 1.31), and > > > setting the following settings in the BIOS: > > > > > > * UEFI Secure Boot: Off > > > * Power -> Sleep State: Linux > > > * Startup -> UEFI/Legacy Boot: UEFI Only > > > * Startup -> CSM Support: Yes > > > * Config -> Thunderbolt(TM) 3 -> Thunderbolt BIOS Assist Mode: Enable > > > * Config -> Thunderbolt(TM) 3 -> Wake by Thunderbolt(TM) 3: Disable > > > > > > It's the Thunderbolt BIOS Assist Mode: Enable that finally solved my > > > problem. (In the BIOS itself, it recommends to set this option to Enable > > > for Linux systems). Everything is perfect now with my system. > > > > > > I'm running -current: > > > > > > thor$ dmesg | grep OpenBSD > > > OpenBSD 6.4-current (GENERIC.MP) #391: Thu Oct 25 15:27:35 MDT 2018 > > > > > > I'm happy to assist other OpenBSD users or developers if you need help > > > further investigating this issue. I have described my adventure, along > > > with dmesg and other details, here [4]. My dmesg is below. > > > > > > [1] https://www.youtube.com/watch?v=lb7mDXHGDF
Monit logs vfprintf %s NULL in "%s" all the time
I'm running Monit to look at few services on OpenBSD 6.3 and I'm logging to syslog. In my /var/log/messages I routinely observe the following log entries: Oct 27 22:00:01 alpha syslogd[97814]: restart Oct 27 22:00:02 alpha monit: vfprintf %s NULL in "%s" Oct 27 22:00:32 alpha last message repeated 11 times Oct 27 22:02:32 alpha last message repeated 24 times Oct 27 22:12:33 alpha last message repeated 120 times Oct 27 22:22:33 alpha last message repeated 120 times ...and so on... Monit is installed from ports. $ monit --version This is Monit version 5.25.1 Built with ssl, with ipv6, with compression, without pam and with large files Does anybody know what does it mean? This log is not very useful, but it looks like some kind of bug. Best regards, Chris
bgpctl not showing rib entries, pftables empty
Hi all, I’ve set up bgpd for use with bgp-spamd.net’s servers. As far as I can tell, the BGP connection and transfer is working fine: --8<-- elisheva:~$ cat /etc/bgpd.conf spam_rs1="64.142.121.62" spam_rs2="217.31.80.170" spam_asn="65066" AS 65500 fib-update no group "spam-bgp" { remote-as $spam_asn multihop 64 export none neighbor $spam_rs1 neighbor $spam_rs2 } match from group "spam-bgp" community $spam_asn:42 set pftable "bgp_spamd_bypass" match from group "spam-bgp" community $spam_asn:666 set pftable "bgp_spamd" elisheva:~$ bgpctl show Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd 217.31.80.170 65066410322 0 02:39:41 37096 64.142.121.62 65066460318 0 01:25:30 37096 elisheva:~$ bgpctl show rib memory RDE memory statistics 37096 IPv4 unicast network entries using 1.4M of memory 37096 rib entries using 2.3M of memory 74192 prefix entries using 6.8M of memory 10 BGP path attribute entries using 1.1K of memory 2 BGP AS-PATH attribute entries using 82B of memory, and holding 10 references 7 BGP attributes entries using 280B of memory and holding 10 references 7 BGP attributes using 48B of memory RIB using 10.5M of memory RDE hash statistics path hash: size 131072, 10 entires min 0 max 2 avg/std-dev = 0.000/0.000 aspath hash: size 131072, 2 entires min 0 max 1 avg/std-dev = 0.000/0.000 attr hash: size 16384, 7 entires min 0 max 1 avg/std-dev = 0.000/0.000 --8<-- However, despite the entry counts being shown by `bgpctl show rib memory`, no other command lists entries as one might expect, and the pf tables are empty: --8<-- elisheva:~$ bgpctl show rib flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale, E = Error origin validation state: N = not-found, V = valid, ! = invalid origin: i = IGP, e = EGP, ? = Incomplete flags ovs destination gateway lpref med aspath origin elisheva:~$ bgpctl show rib community 65066:42 flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale, E = Error origin validation state: N = not-found, V = valid, ! = invalid origin: i = IGP, e = EGP, ? = Incomplete flags ovs destination gateway lpref med aspath origin elisheva:~$ doas pfctl -Ts -t bgp_spamd elisheva:~$ doas pfctl -Ts -t bgp_spamd_bypass elisheva:~$ --8<-- Any hints as to how to further diagnose? I’ve tried most conceivable additional arguments to `bgpctl show rib` and I haven’t found a way to list entries yet. Log entries are benign ((re)configuration success messages). Thanks, Ashe
Re: Benchmarking kernel, userland and Xenocara build processes
Hi, just for the record, and to inform others who may still be at loss regarding this matter: when compiling stuff (particularly Big Stuff, such as the userland) on an OpenBSD machine with several CPU cores, it's important to pass the '-j ' argument to the make command, in order to benefit from the (much) reduced compiling time. It would probably make sense to add a tip to the Building the system from source FAQ and/or the release man page. I feel so, so newbie... =P Thanks to tfrohwein! -j. -- +358-404-177133 (24/7) jyri.hov...@turvamies.fi
Replacing old versions of Android with OpenBSD
Hi everyone! There used to be a project called GreenOS, with plans on creating a FreeBSD based OS for Android devices: https://www.freebsdnews.com/2012/07/09/greenos-freebsd-based-project-android-devices/ Has anybody here had plans (or tried out?) hacking OpenBSD into some old, rootable Android handset? I'd be interested in setting up a little project around this idea. There's no need to worry about any of the 3G/4G stuff at first -- it would be more than enough just to see OpenBSD booting on an ex-Android device. -j. -- +358-404-177133 (24/7) jyri.hov...@turvamies.fi