Re: How I got iked in -current to work with iOS
Ted, Thank you for sending this - I’m sure it will be useful to someone, and now it’s “archived” for those who go looking for help in the future. -David > On Apr 2, 2021, at 3:41 PM, Theodore Wynnychenko wrote: > > Hi > I had some time today, and decided to send this now. > > This is how I got OpenBSD's iked daemon (version in current about 3/28/2021) > to work with Apple's iOS (iphone/ipad's) version (about) 14.4.2. > > Some prelude: > > So, I have no real reason to do this, other than that I want to. > I think of it as a learning exercise, so my knowledge is limited in many > ways. I got this to work for my specific use case. > > Specially, I only have a few devices that I want/need to have access to my > home's VPN. I do this to have a secure gateway for access to my > email/calendar/files/etc when not at home (yes, I host my own services - I > know that Apple and Google and other respect my privacy, etc., but ...). > > I have NOT tried to set this up as a VPN to route all traffic from > associated devices (I don't have the a connection with the bandwidth > necessary to do so). > > Because I am only "managing" a handful of devices, I did all of this > manually. > > > Limitations/Requirements: > > Apple's iOS: > > Recently, Apple has put several restrictions on the certificates iOS devices > will accept for ikev2 connections. These are "disclosed" at > https://support.apple.com/en-us/HT211025 and > https://support.apple.com/en-us/HT210176. > > Specifically, certificates must: > - CA and TLS certs using RSA must use key => 2048 > - CA and TLS certs must use SHA-2 > - TLS certs must have a SubjectAlternativeName with the DNS name of the > server; a CommonName only is not enough > > For certificates issued after 7/1/2019: > - ExtendedKeyUsage for TLS server and TLS client must be included > - TLS certs can only be valid for 825 days or less > > For certificates issued by the Root CA's preinstalled in iOS, after > 9/1/2020: > - TLS certs can only be valid for 398 days or less > > > > OpenBSD's iked: > > OpenBSD ikev2 also has some specific requirements for certificate > authentication. > > iked requires specific key/authentication combinations: > - rfc7427 only supports SHA2-256 (not sure if iOS supports rfc7427) > - ecdsa256 only supports P-256 with SHA2-256 > - ecdsa382 only supports P-384 with SHA2-384 > - ecdsa521 only supports P-521 with SHA2-512 > - rsa suppors RSA but only with SHA1 > > > Other/General: > > In terms of ECDSA certificates, it seems that P-256 and P-384 are the ones > that are more generally accepted, and will likely continue to be generally > accepted. This appears to be based on NIST's inclusion of them in their > "Suite B Cryptography" information. P-521 was not included in "Suite B," > and it seems some things have not included support for it. > > So, I concluded, to be safe (and since it seems the computational/security > cost/benefit of P-384 vs P-521 is narrow), and based on the requirements > above, to use P-384 with SHA2-384. > > > My setup: > > Certificates: > > In order to do this, I used openssl commands directly. I did not use ikectl > to create certs or the CA. > > Before I go into details, I wanted to have certs that would last longer than > the Apple limit. Therefore, I needed to have a CA certificate, and TLS > certs, that had a "Not Before" date before 7/1/2019. > > In order to do this, when I created my CA certificate, I changed the > time/date on the system using "date 20190101" before creating the CA, > and then reset the date when I was done. > > Creating back-dated TLS certs is a bit more direct, all that is necessary is > to add "-startdate 2019010200Z" to the openssl ca command when signing > the TLS certificate. > > Obviously, you need to have complete control of the CA (and not care that > you are doing this) to accomplish this and get certificates with a longer > time horizon for iOS. > > So, first I created a CA using ECDSA384: > > I created/edited the openssl.cnf file to have the appropriate > additions/defaults I need for these certificates. I will not cover > everything, but I think these are the basic requirements (I have edited out > many things in the actual file I used, but I THINK what is left is all that > may be really needed, but my openssl knowledge is not absolute, and I may > have errors that I don't realize): > > (NOTE: When I was trying to get this to work, I began to believe that the > current iOS has a problem with "-" [hyphens] in the CN/SAN, so I did not use > them. I now am not sure if "-"'s will work or not.] > > General defaults for generating the signing request (csr), openssl.cnf: > > default_bits= 4096 > default_keyfile= key.pem > default_md= sha384 > string_mask= utf8only > distinguished_name= req_distinguished_name > attributes= req_attributes > > The distinguished name/attributes are basically from the default cnf file. > > F
Re: gl.inet Brume (GL-MV1000): sdcard works with 6.8 but not -current
Am Fri, Apr 02, 2021 at 12:56:24PM +1100 schrieb Darren Tucker: > On Fri, Apr 02, 2021 at 01:01:30AM +0200, Mark Kettenis wrote: > > Hi Darren, > > > > This got broken when Patrick fixed something related to slow mode for > > the Marvel ARMADA 8040 SoC. The diff below fixes it for me on my > > Turris MOX which uses the same SoC. Not entirely sure what is going > > wrong here since looking at the Linux code suggests that Patrick's fix > > should work on the ARMADA 3720 as well. > > Confirmed that this fixes it. dmesg at end of mail. Damn. I'm sorry, it wasn't my intention to break anything with that. As far as I remember, that particular change was an attempt to reduce diff. This one wasn't even needed to fix my ClearFog GT8K. By the way, U-Boot always sets slow mode for legacy and high speed, which is similar to what we had before. I would actually propose reverting my change completely. My GT 8K still works, but even better: it seems to make the SD card show up on my early revision MacchiatoBin. -sdmmc1: can't enable card scsibus2 at sdmmc0: 2 targets, initiator 0 sd1 at scsibus2 targ 1 lun 0: removable sd1: 7456MB, 512 bytes/sector, 15269888 sectors +scsibus3 at sdmmc1: 2 targets, initiator 0 +sd2 at scsibus3 targ 1 lun 0: removable +sd2: 7632MB, 512 bytes/sector, 15630336 sectors Maybe you both can try my revert and make sure it doesn't introduce any other regressions? > > That BRUME thingy looks cute, but has a bit of an issue. It doesn't > > really have three Ethernet ports. Instead those ports are part of a > > switch that also connects to an Ethernet interface on the SoC. > > Yeah I noticed that. Single ethernet plus programmable switch seems to > be pretty common in this class of device. And if someone wants to program it, feel free to, mvsw(4) exists for a reason, might just need some code. :) diff --git a/sys/dev/fdt/sdhc_fdt.c b/sys/dev/fdt/sdhc_fdt.c index 56bf15c46fa..cc0239df682 100644 --- a/sys/dev/fdt/sdhc_fdt.c +++ b/sys/dev/fdt/sdhc_fdt.c @@ -430,8 +430,8 @@ phy_init: XENON_EMMC_PHY_TIMING_ADJUST); reg |= XENON_EMMC_PHY_TIMING_ADJUST_SAMPL_INV_QSP_PHASE_SELECT; reg &= ~XENON_EMMC_PHY_TIMING_ADJUST_SLOW_MODE; - if ((timing == SDMMC_TIMING_LEGACY || - timing == SDMMC_TIMING_HIGHSPEED) && sc->sc_slow_mode) + if (timing == SDMMC_TIMING_LEGACY || + timing == SDMMC_TIMING_HIGHSPEED || sc->sc_slow_mode) reg |= XENON_EMMC_PHY_TIMING_ADJUST_SLOW_MODE; bus_space_write_4(sc->sc_iot, sc->sc_ioh, XENON_EMMC_PHY_TIMING_ADJUST, reg);
Slow network performance - iperf3/tcpbench on local machine
Hi, I'm trying to debug some general network slowness with my 6.8 server (i7-3930k) that seems to affect all protocols (e.g. Samba capping at 70MB/s, FTP at 45MB/s for upload). I've run some iperf3/tcpbench tests and the results seems low even when running both client and server on the same machine to eliminate the actual network. Setting the client to localhost, I get an average of about 10Gbit/s in iperf3. [ 5] 0.00-10.00 sec 11.3 GBytes 9.74 Gbits/sec sender [ 5] 0.00-10.00 sec 11.3 GBytes 9.74 Gbits/sec receiver tcpbench is a bit quicker: Conn: 1 Mbps:11585.269 Peak Mbps:11602.117 Avg Mbps:11585.269 Conn: 1 Mbps:11580.000 Peak Mbps:11602.117 Avg Mbps:11580.000 Conn: 1 Mbps:11583.638 Peak Mbps:11602.117 Avg Mbps:11583.638 Conn: 1 Mbps:10029.172 Peak Mbps:11602.117 Avg Mbps:10029.172 Running with the IP address of the machine: [ 5] 0.00-10.00 sec 1.51 GBytes 1.30 Gbits/sec sender [ 5] 0.00-10.00 sec 1.51 GBytes 1.30 Gbits/sec receiver Conn: 1 Mbps: 1026.018 Peak Mbps: 1543.406 Avg Mbps: 1026.018 Conn: 1 Mbps: 977.226 Peak Mbps: 1543.406 Avg Mbps: 977.226 Conn: 1 Mbps: 1281.376 Peak Mbps: 1543.406 Avg Mbps: 1281.376 Conn: 1 Mbps: 1128.490 Peak Mbps: 1543.406 Avg Mbps: 1128.490 smbclient to IP address is around 100-120MB/s depending on Samba settings. To localhost it goes up to 200MB/s. This is copying between SSDs which manage 500MB/s directly. Those tests were with PF disabled. PF enabled is basically the same: [ 5] 0.00-10.00 sec 1.49 GBytes 1.28 Gbits/sec sender [ 5] 0.00-10.00 sec 1.49 GBytes 1.28 Gbits/sec receiver With UDP, iperf3 seems broken (1Mbit/s), with tcpbench: localhost: Elapsed: 2 Mbps: 912.534 Peak Mbps: 926.653 Tx PPS: 77491 Elapsed: 21000 Mbps: 861.850 Peak Mbps: 926.653 Tx PPS: 73187 local IP: Elapsed: 16000 Mbps: 908.789 Peak Mbps: 917.009 Tx PPS: 77173 Elapsed: 17000 Mbps: 788.132 Peak Mbps: 917.009 Tx PPS: 66927 systate with tcpbench running with TCP & IP address: 3 users Load 1.31 0.64 0.32 caleb.home.duncanma 14:29:14 memory totals (in KB)PAGING SWAPPING Interrupts real virtual free in out in out 204 total Active 211624211624 11526980 ops200 clock All 4660156 4660156 19920940 pages3 ipi 1 em0 Proc:r d s wCsw Trp Sys Int Sof Flt forks ehci0 1 105 299265634 1171 fkppw azalia1 fksvm ahci0 0.0%Int 0.7%Spn 17.5%Sys 0.8%Usr 81.0%Idle pwait ehci1 ||||||||||| relck ahci1 = rlkok pckbc0 noram Namei Sys-cacheProc-cacheNo-cache ndcpy Calls hits%hits %miss % fltcp zfod cow Disks sd0 sd1 sd2 sd3 134892 fmin seeks 179856 ftarg xfers itarg speed3K 3K 2 wired sec 0.0 0.0 pdfre pdscn pzidl 211289 IPKTS 13 kmape 211288 OPKTS and top: load averages: 1.39, 1.01, 0.54 66 processes: 63 idle, 3 on processor CPU00 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU01 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU02 states: 1.0% user, 0.0% nice, 53.3% sys, 2.0% spin, 0.0% intr, 43.7% idle CPU03 states: 0.4% user, 0.0% nice, 48.9% sys, 2.0% spin, 0.0% intr, 48.7% idle CPU04 states: 1.2% user, 0.0% nice, 7.8% sys, 0.0% spin, 0.0% intr, 91.0% idle CPU05 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle Memory: Real: 206M/4550M act/tot Free: 11G Cache: 3781M Swap: 0K/8197M PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 55082 duncan400 680K 2060K onproc/2 - 1:17 13.96% tcpbench 41980 duncan330 660K 2040K onproc/4 - 0:05 6.30% tcpbench I also tried a different machine (i9-10850K) wi
Re: acme-client, error 21 at 0 depth lookup:unable to verify the first certificate
Self solved.
Am 02.04.2021 14:02, schrieb open...@crw.name:
Hello, I need some help to configure my acme-client the right way.
Obtain certificates itself works using OpenBSD -current #434 from April
1st.
I have a CAA record
$ dig -t CAA our.bio-planet.earth +short
0 issue "letsencrypt.org"
The configuration for httpd.conf and relayd.conf are taken fron honk
https://cvsweb.openbsd.org/ports/www/honk/pkg/README?rev=1.4&content-type=text/x-cvsweb-markup
The acme-client.conf is taken from /etc/examples/ and the settings for
the domain are
$ tail -f /etc/acme-client.conf
domain our.bio-planet.earth {
domain key "/etc/ssl/private/our.bio-planet.earth.key"
domain certificate "/etc/ssl/our.bio-planet.earth.crt"
domain full chain certificate
"/etc/ssl/our.bio-planet.earth.fullchain.pem"
sign with letsencrypt
}
The FQHN equals the domain and I don´t want to use other / sub
domains. The .crt file is required for the tls keypair part in
relayd.conf.
If I try to verify the certificate using
$ openssl verify our.bio.planet.earth.fullchain.pem
CN = our.bio-planet.earth
error 21 at 0 depth lookup:unable to verify the first certificate
CN = our.bio-planet.earth
error 21 at 0 depth lookup:unable to verify the first certificate
/etc/ssl/our.bio-planet.earth.fullchain.pem: verification failed: 21
(unable to verify the first certificate)
On the other hand
$ openssl verify /etc/ssl/cert.pem
cert.pem: OK
How can I fix this as it did not work if I try to use the certs for
example for prosody.
Thanks and regards,
Christoph
Re: acme-client, error 21 at 0 depth lookup:unable to verify the first certificate
https://xkcd.com/979/
On Sat, Apr 03, 2021 at 05:43:36PM +0200, open...@crw.name wrote:
> Self solved.
>
> Am 02.04.2021 14:02, schrieb open...@crw.name:
> > Hello, I need some help to configure my acme-client the right way.
> >
> > Obtain certificates itself works using OpenBSD -current #434 from April
> > 1st.
> >
> > I have a CAA record
> >
> > $ dig -t CAA our.bio-planet.earth +short
> > 0 issue "letsencrypt.org"
> >
> > The configuration for httpd.conf and relayd.conf are taken fron honk
> > https://cvsweb.openbsd.org/ports/www/honk/pkg/README?rev=1.4&content-type=text/x-cvsweb-markup
> >
> > The acme-client.conf is taken from /etc/examples/ and the settings for
> > the domain are
> >
> > $ tail -f /etc/acme-client.conf
> > domain our.bio-planet.earth {
> > domain key "/etc/ssl/private/our.bio-planet.earth.key"
> > domain certificate "/etc/ssl/our.bio-planet.earth.crt"
> > domain full chain certificate
> > "/etc/ssl/our.bio-planet.earth.fullchain.pem"
> > sign with letsencrypt
> > }
> >
> > The FQHN equals the domain and I don´t want to use other / sub
> > domains. The .crt file is required for the tls keypair part in
> > relayd.conf.
> >
> > If I try to verify the certificate using
> >
> > $ openssl verify our.bio.planet.earth.fullchain.pem
> > CN = our.bio-planet.earth
> > error 21 at 0 depth lookup:unable to verify the first certificate
> > CN = our.bio-planet.earth
> > error 21 at 0 depth lookup:unable to verify the first certificate
> > /etc/ssl/our.bio-planet.earth.fullchain.pem: verification failed: 21
> > (unable to verify the first certificate)
> >
> > On the other hand
> >
> > $ openssl verify /etc/ssl/cert.pem
> > cert.pem: OK
> >
> > How can I fix this as it did not work if I try to use the certs for
> > example for prosody.
> >
> > Thanks and regards,
> >
> >
> > Christoph
>
--
I'm not entirely sure you are real.
Re: acme-client, error 21 at 0 depth lookup:unable to verify the first certificate
Yeah, like that but Google was no help. Am 03.04.2021 19:10, schrieb Florian Obser: https://xkcd.com/979/
Re: acme-client, error 21 at 0 depth lookup:unable to verify the first certificate
On 2021-04-03, open...@crw.name wrote: > Yeah, like that but Google was no help. > > Am 03.04.2021 19:10, schrieb Florian Obser: >> https://xkcd.com/979/ >> > > But if you follow-up with information about what the problem was and how you fixed it, then it might be helpful for someone who comes along in the future.
Re: Suspend/resume does not work on Lenovo X1 Carbon 3rd gen laptop
Hi Ricky, I tested your suspend suggestion and interestingly suspend works like a charm. Hibernate however still does not work. I still suspect the tpm(4) driver may lack support for this particular Lenovo X1 Carbon 3rd gen machine, but have no proof to conclusively claim this. Cheersm Mark P.S. If any OpenBSD developer is reading this email, I am more than happy to try out tpm(4) patches and report back. On 3/23/2021 3:48 AM, Ricky Cintron wrote: Hey Mark, I don't have an X1C so I can't offer any hardware-specific advice, but I see you're using the ZZZ command to hibernate the system, yet it appears you want to suspend the system (based on wording). Have you tested zzz (lowercase) instead? Maybe your hardware/setup doesn't support hibernation. If you are indeed trying to hibernate, then I have nothing. Sorry. ‐‐‐ Original Message ‐‐‐ On Monday, March 22nd, 2021 at 8:20 AM, Mark Hesselink wrote: Hi, I'm sending the below bug report to misc@openbsd.org as I have deliberately not configured my OpenBSD workstations to be able to send mail -- they are mostly used by my children -- and a bug report sent directly to b...@openbsd.org never seems to have arrived. Hopefully this email does arrive. Cheers, Mark --- Synopsis: Suspend/resume does not work on Lenovo X2 Carbon 3rd gen laptop Category: system Environment: System : OpenBSD 6.9 Details : OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12 15:01:24 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: Suspend/resume unfortunately does not work on my Lenovo X1 Carbon 3rd gen laptop. Suspending the laptop using the ZZZ command does seem to suspend the laptop, but restarting the laptop afterwards does not result in the expected boot loader prompt of: >> OpenBSD/amd64 BOOT 3.53 unhibernate detected: switching to /bsd.booted boot> Instead a standard boot prompt is presented as if the laptop never completed the suspend request, but instead was abruptly shut down. During boot the system detects that 1 or more filesystems were not cleanly unmounted as well. I have tried playing around with the various TPM settings in the BIOS, i.e. disabled, hidden and enabled TPM. Neither of these settings seem to have an effects on the laptop's ability to cleanly suspend/resume. How-To-Repeat: ZZZ followed by booting of the laptop. Fix: No known work around. dmesg: OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12 15:01:24 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8261603328 (7878MB) avail mem = 7995826176 (7625MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries) bios0: vendor LENOVO version "N14ET54W (1.32 )" date 03/19/2020 bios0: LENOVO 20BTS0MX00 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI 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) i7-5600U CPU @ 2.60GHz, 2494.63 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,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.24 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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16
Re: acme-client, error 21 at 0 depth lookup:unable to verify the first certificate
Hello Stuart ! Yes, you are right. I was long time not here (used another E - Mail before) so I was not sure if it is really interesting. tedu uses for honk relayd as TLS endpoint. If someone uses the default /etc/examples/acme-client.conf with httpd only everything works fine. If the certs are obtained using domain.fullchain.pem and the domain.key and the paths are in the tls section of httpd.conf all is fine. Relayd expects - if the tls keypair option - is used in relayd.conf a .crt file (relayd -n or the try to start ends in errors refering to the relay section of missing certs). So I added just the line in the acme-client.conf to obtain a certificate file too. Basically things work fine with this configuration but at some points I get a x509 error about a self signed certificate. tedus doku is fine I just overlooked it. BTW tls keypair did not require to link the IPs to which relayd listens to the cert files (is as fallback defined in the man page). As this .crt file contains only a part (0) of the cert chain I got the error 21 as (1) from the cert chain is missing. The solution is as tedu does, to name the fullchein certificate domain.crt or, if used the default above acme-client.conf just copy domain.fullchain.pem to domain.crt. This is only important for relayd and tls keypair. The try to local verify the cert chain still fails with the tried command but I think it is just a thing of the used options. But openssl s_client -showcerts -connect our.bio-planet.earth:443 now reports Verify return code: 0 (ok) instead of 21 and all is fine as the whole cert chain is transmitted. Another day I will look at prosody ;-) and the cert thing. Regards, Christoph Am 03.04.2021 22:38, schrieb Stuart Henderson: On 2021-04-03, open...@crw.name wrote: Yeah, like that but Google was no help. Am 03.04.2021 19:10, schrieb Florian Obser: https://xkcd.com/979/ But if you follow-up with information about what the problem was and how you fixed it, then it might be helpful for someone who comes along in the future.
Re: gl.inet Brume (GL-MV1000): sdcard works with 6.8 but not -current
On Sun, 4 Apr 2021 at 01:32, Patrick Wildt wrote: > [...] > Maybe you both can try my revert and make sure it doesn't introduce any > other regressions? > That also seems to work on the Brume in question: >> OpenBSD/arm64 BOOTAA64 1.2 boot> boot /bsd.test booting sd0a:/bsd.test: 8808452+1793560+567784+830080 [634134+109+1073400+630260]=0xf904a0 type 0x2 pa 0x0 va 0x0 pages 0x4000 attr 0x8 [lots snipped] type 0x2 pa 0x3ffa6000 va 0x3e715000 pages 0x5a attr 0x8 [ using 2338872 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2021 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.9-beta (GENERIC.MP) #1: Thu Apr 1 19:48:05 AEDT 2021 dtuc...@brume.dtucker.net:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 1032523776 (984MB) avail mem = 968355840 (923MB) random: good seed from bootblocks mainbus0 at root: GL.inet GL-MV1000 (Marvell) psci0 at mainbus0: PSCI 1.0 cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu0: 256KB 64b/line 16-way L2 cache cpu0: CRC32,SHA2,SHA1,AES+PMULL,ASID16 cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4 cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu1: 256KB 64b/line 16-way L2 cache cpu1: CRC32,SHA2,SHA1,AES+PMULL,ASID16 efi0 at mainbus0: UEFI 2.0.5 efi0: Das U-boot rev 0x0 apm0 at mainbus0 agtimer0 at mainbus0: 12500 kHz "pmu" at mainbus0 not configured simplebus0 at mainbus0: "soc" simplebus1 at simplebus0: "internal-regs" mvclock0 at simplebus1 mvclock1 at simplebus1 mvclock2 at simplebus1 mvpinctrl0 at simplebus1 syscon0 at simplebus1: "syscon" mvpinctrl1 at simplebus1 agintc0 at simplebus1 shift 4:3 nirq 224 nredist 2 ipi: 0, 1: "interrupt-controller" mvspi0 at simplebus1 mvuart0 at simplebus1 mvneta0 at simplebus1 mvneta0: Ethernet address 94:83:c4:03:b0:d9 mvmdio0 at simplebus1: "mdio" mvsw0 at mvmdio0 phy 1: 88E6141 rev 0 xhci0 at simplebus1, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 "usb" at simplebus1 not configured "u3d" at simplebus1 not configured "udc" at simplebus1 not configured "xor" at simplebus1 not configured sdhc0 at simplebus1 sdhc0: SDHC 3.0, 400 MHz base clock sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, dma sdhc1 at simplebus1 sdhc1: SDHC 3.0, 400 MHz base clock sdmmc1 at sdhc1: 8-bit, sd high-speed, mmc high-speed, ddr52, dma "sata" at simplebus1 not configured mvkpcie0 at simplebus0 mvkpcie0: timeout "regulator" at mainbus0 not configured scsibus0 at sdmmc1: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: removable sd0: 7456MB, 512 bytes/sector, 15269888 sectors scsibus1 at sdmmc0: 2 targets, initiator 0 sd1 at scsibus1 targ 1 lun 0: removable sd1: 30436MB, 512 bytes/sector, 62333952 sectors vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd1a (9e51f250b602291d.a) swap on sd1b dump on sd1b WARNING: CHECK AND RESET THE DATE! Automatic boot in progress: starting file system checks. /dev/sd1a (9e51f250b602291d.a): file system is clean; not checking 9e51f250b602291d.i: 6 files, 16034 free (8017 clusters) pf enabled starting network starting early daemons: syslogd pflogd ntpd. starting RPC daemons:. savecore: can't find device 255/16777088 checking quotas: done. clearing /tmp kern.securelevel: 0 -> 1 creating runtime link editor directory cache. preserving editor files. starting network daemons: sshd smtpd sndiod. starting local daemons: cron. Thu Apr 1 19:50:48 AEDT 2021 OpenBSD/arm64 (brume.dtucker.net) (console) > > That BRUME thingy looks cute, but has a bit of an issue. It doesn't > > > really have three Ethernet ports. Instead those ports are part of a > > > switch that also connects to an Ethernet interface on the SoC. > > > > Yeah I noticed that. Single ethernet plus programmable switch seems to > > be pretty common in this class of device. > > And if someone wants to program it, feel free to, mvsw(4) exists for a > reason, might just need some code. :) > and maybe docs :-) # man 4 mvsw man: No entry for mvsw in section 4 of the manual. -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Re: The simplest full cray data core with 3 cpu's and a physics hack that makes it work
On Sat, Apr 03, 2021 at 04:06:42AM +0100, Joe Davis wrote: > > > On 2 Apr 2021, at 14:17, Benjamin Baier wrote: > > > > GPT-3 gone wild, or what? Definitely to late for Aprilfools-day. > > > > If it’s GPT-3, it’s slipping. Yes and no, but if you draw the architecture up: 6 segments in a circle with flat sides and close. One control line for double data rate to opposite segment and its neigbhours. Such that the only data path goes straight forward. Let's imagine that each segment is the equivalent of 16*32 bit vector operations per core per cycle, and that the chip maths the speed of light across this octagon or whatever, such that you can pull and push on this link so hard you cause bremsstrahlung for trying to go to fast in parts of the segment or chip, killing parts of its over time and inoperable during the operation. Before saying that it's insane to run this at 10 Ghz, and that Von Neumann architecture is better or have a better tuned pipeline. I'll pump my neighbouring nodes at full speed. Each clock cycles give each segment the state of 0xfeedbeef, 0xdeadbeef, 0xbeef, 0xfeedface. So the two neigbhouring segments does deadbeef and use the beefy link to pump data to the other half of the cpu, I'll start doing remote ddr sram operations to drive as a von neumann chip. Which patent would you suggest for this if the important vectorization is done in software, in a UNIX model that should run on it, where some things are physical necessities, like a unix consol to a segment and a daemon that filter instructions, data and handles address space. -- Balder Oddson
Re: The simplest full cray data core with 3 cpu's and a physics hack that makes it work
On Sat, Apr 03, 2021 at 04:06:42AM +0100, Joe Davis wrote: > > > On 2 Apr 2021, at 14:17, Benjamin Baier wrote: > > > > GPT-3 gone wild, or what? Definitely to late for Aprilfools-day. > > > > If it’s GPT-3, it’s slipping. Yes and no, but if you draw the architecture up: 6 segments in a circle with flat sides and close. One control line for double data rate to opposite segment and its neigbhours. Such that the only data path goes straight forward. Let's imagine that each segment is the equivalent of 16*32 bit vector operations per core per cycle, and that the chip maths the speed of light across this octagon or whatever, such that you can pull and push on this link so hard you cause bremsstrahlung for trying to go to fast in parts of the segment or chip, killing parts of its over time and inoperable during the operation. Before saying that it's insane to run this at 10 Ghz, and that Von Neumann architecture is better or have a better tuned pipeline. I'll pump my neighbouring nodes at full speed. Each clock cycles give each segment the state of 0xfeedbeef, 0xdeadbeef, 0xbeef, 0xfeedface. So the two neigbhouring segments does deadbeef and use the beefy link to pump data to the other half of the cpu, I'll start doing remote ddr sram operations to drive as a von neumann chip. Which patent would you suggest for this if the important vectorization is done in software, in a UNIX model that should run on it, where some things are physical necessities, like a unix consol to a segment and a daemon that filter instructions, data and handles address space. You have your big lock that mainly creates the machine state every clock cycle. There are six fully functional segments that must initialise and run a local terminal. Very few have a relationship to Cray, I don't, not original nor modern Cray's. If you open up a Cray to try and work out how it works, you find empty space with a bunch of wires, get angry for the evil inside and go with a bunch of DEC's, as it doesn't involve physics shenanigans and actually has the important part inside. But it easier to tweak your digital spec based on length of wires. There were possible even a reason for picking Intel, as they focused on the part everyone liked about IBM compared to Cray's.
Re: cannot get re(4) to use 100baseT
I know this is a reply to an old thread, but I hope this note will be useful. On an Apu2 connected to a cable modem with a gigabit port, I was also getting only 100baseT. After reading the replies to this 2018 post, I checked the cables and found that while the cables were cat8, they were also being run through an old APC Back-UPS for surge protection. Once I connected the PcEngines Apu2 directly to the cable modem, I could resume bathing in the glorious light of 1000baseT. A hearty thank you to all who replied regarding checking the cables!
Re: Suspend/resume does not work on Lenovo X1 Carbon 3rd gen laptop
That's great. If hibernating is what you're really after, I hope that gets worked out at some point. I don't currently use OpenBSD on laptops, so I don't know what else can be done. At least suspending works though. ‐‐‐ Original Message ‐‐‐ On Saturday, April 3rd, 2021 at 1:09 PM, Mark Hesselink wrote: > Hi Ricky, > > I tested your suspend suggestion and interestingly suspend works like a > > charm. Hibernate however still does not work. I still suspect the tpm(4) > > driver may lack support for this particular Lenovo X1 Carbon 3rd gen > > machine, but have no proof to conclusively claim this. > > Cheersm > > Mark > > P.S. If any OpenBSD developer is reading this email, I am more than > > happy to try out tpm(4) patches and report back. > > On 3/23/2021 3:48 AM, Ricky Cintron wrote: > > > Hey Mark, I don't have an X1C so I can't offer any hardware-specific advice, > > > > but I see you're using the ZZZ command to hibernate the system, yet it > > appears > > > > you want to suspend the system (based on wording). Have you tested zzz > > > > (lowercase) instead? Maybe your hardware/setup doesn't support hibernation. > > > > If you are indeed trying to hibernate, then I have nothing. Sorry. > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Monday, March 22nd, 2021 at 8:20 AM, Mark Hesselink > > mhess...@alumni.caltech.edu wrote: > > > > > Hi, > > > > > > I'm sending the below bug report to misc@openbsd.org as I have > > > > > > deliberately not configured my OpenBSD workstations to be able to send > > > > > > mail -- they are mostly used by my children -- and a bug report sent > > > > > > directly to b...@openbsd.org never seems to have arrived. Hopefully this > > > > > > email does arrive. > > > > > > Cheers, > > > > > > Mark > > > > > > > Synopsis: Suspend/resume does not work on Lenovo X2 Carbon 3rd gen > > > > > > > > laptop > > > > > > > Category: system > > > > > > > > Environment: > > > > > > > > System : OpenBSD 6.9 > > > > > > Details : OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12 > > > > > > 15:01:24 MST 2021 > > > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > Architecture: OpenBSD.amd64 > > > > > > Machine : amd64 > > > > > > > Description: > > > > > > > > Suspend/resume unfortunately does not work on my Lenovo X1 Carbon > > > > > > 3rd gen laptop. Suspending the laptop using the ZZZ command does > > > > > > seem to suspend the laptop, but restarting the laptop afterwards > > > > > > does not result in the expected boot loader prompt of: > > > > > > >> OpenBSD/amd64 BOOT 3.53 > > > > > > unhibernate detected: switching to /bsd.booted > > > > > > boot> > > > > > > Instead a standard boot prompt is presented as if the laptop never > > > > > > completed the suspend request, but instead was abruptly shut down. > > > > > > During boot the system detects that 1 or more filesystems were not > > > > > > cleanly unmounted as well. > > > > > > I have tried playing around with the various TPM settings in the > > > > > > BIOS, i.e. disabled, hidden and enabled TPM. Neither of these > > > > > > settings seem to have an effects on the laptop's ability to cleanly > > > > > > suspend/resume. > > > > > > > How-To-Repeat: > > > > > > > > ZZZ followed by booting of the laptop. > > > > > > > Fix: > > > > > > > > No known work around. > > > > > > dmesg: > > > > > > OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12 15:01:24 MST 2021 > > > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > real mem = 8261603328 (7878MB) > > > > > > avail mem = 7995826176 (7625MB) > > > > > > random: good seed from bootblocks > > > > > > mpath0 at root > > > > > > scsibus0 at mpath0: 256 targets > > > > > > mainbus0 at root > > > > > > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries) > > > > > > bios0: vendor LENOVO version "N14ET54W (1.32 )" date 03/19/2020 > > > > > > bios0: LENOVO 20BTS0MX00 > > > > > > acpi0 at bios0: ACPI 5.0 > > > > > > acpi0: sleep states S0 S3 S4 S5 > > > > > > acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT > > > > > > SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI > > > > > > 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) i7-5600U CPU @ 2.60GHz, 2494.63 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,TSC_ADJUST,B
