Re: Adding more syspatch platform.
On 2020-08-13 02:39, Sebastian Benoit wrote: Jordan Geoghegan(jor...@geoghegan.ca) on 2020.08.12 10:32:21 -0700: On 2020-08-12 02:08, Stuart Henderson wrote: The only proxy we have for "what is really used" is dmesg submissions. Since 6.7 release: amd64 62 i3865 arm64 3 macppc 2 octeon 1 Based on this there isn't a great case for adding any more. I didn't realize you guys used dmesg@ as a popularity gauge, I thought s/popularity/usage/ it was just for sending dmesgs for interesting/new hardware. I figured with something like Edgerouters with their standardized hardware that repeat dmesgs would just serve to irritate the devs. I personally administer more OpenBSD 6.x machines than are on that list you sent. I can start hammering dmesg@, but then I'm gonna skew your stats and In a way, you also skew the stats if you dont send dmesgs. And "you" means everyone. Do it once every 6 months (for every release) i'd say. you're gonna think that your userbase consists of a bunch of autists that unironically run macppc, sparc64 and octeon in production everywhere. In the small Canadian town I live in, I've got a big chunk of it running on OpenBSD. I've got a bunch of old 90's / 2000's i386 stuff too, so I can send dmesgs in for that too, the reason I didn't is I figured the hardware was already 'been there, done that'. If the dmesgs dont show that certain hardware is still used, the drivers for it will get deleted eventually. Another reason to show what you use. As I mentioned earlier in the thread, I can afford to donate 2 octeon machines to any devs that are interested (including shipping world wide; any devs reading: please contact me if you're interested), and am also happy to help out with octeon stuff in any way I can. Obviously you guys aren't going to trust me to do anything syspatch related as I'm not a dev, but I'd at least like it to be known that there are people who care about the octeon port and who are willing make an effort for it. Regards, Jordan Okay, thanks for the info Sebastian, I'll start doing twice annual dumps to dmesg@ for all my machines. Regards, Jordan
gcc linked -static segfaults with bogus syscall on recent snapshot
For the August 11 snapshot
ry$ sysctl kern.version
kern.version=OpenBSD 6.7-current (GENERIC.MP) #22: Tue Aug 11 21:29:51
MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
ry$ egcc --version
egcc (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
ry$ cat mytls.c
__thread int a; int b; int main() { return a = b; }
ry$ egcc -o mytls -static mytls.c
ry$ ./mytls
Segmentation fault (core dumped)
ry$ grep mytls /var/log/messages
...[snip]...
Aug 13 15:44:40 ry /bsd: [mytls]36048/435394 pc=5951167a inside
27732e000-27733c000: bogus syscall
For the Jun 15 snapshot, all is well:
snap1$ sysctl kern.version
kern.version=OpenBSD 6.7-current (GENERIC.MP) #272: Mon Jun 15 01:54:58
MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
snap1$ egcc --version
egcc (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
snap1$ cat mytls.c
__thread int a; int b; int main() { return a = b; }
snap1$ egcc -o mytls mytls.c -O2 -static
snap1$ mytls
snap1$
And the static image is different:
snap1$ ldd mytls
mytls:
StartEnd Type Open Ref GrpRef Name
0fda3f626000 0fda3f648000 dlib 10 0
/home/j/tls/mytls
on the older snapshot, and
ry$ ldd mytls
mytls:
StartEnd Type Open Ref GrpRef Name
04822c606000 04822c62a000 exe 10 0 mytls
048524b42000 048524b42000 ld.so 01 0
/usr/libexec/ld.so
on the newer snapshot.
These are two different machines, snap1 is Dell workstation,
E7400 Core 2 Duo, and ry is Ryzen 3700 8-core.
The example code is scooped from the gcc configure scripts. A gcc build
provokes this behaviour (using this code fragment) when building gcc for
these libraries:
libstdc++-v3
libobjc
libitm
libgomp (which is me adding OMP to gcc)
It seems to be only for TLS (thread-local-storage) tests, iiuc.
clang does not show this behaviour.
John
smtpd returns 'TempFail' and 'No route to destination' when using localhost as source behind NAT
OpenSMTPd 6.7.0 OpenBSD 6.7-current on local machine. All machine's traffic
redirected trough iked IPsec VPN to remote gateway machine and uses PF NAT rule
first:
match out log on enc0 from 0.0.0.0/0 to 0.0.0.0/0 nat-to 10.100.0.2
where 10.100.0.2 is virtual IP to NAT all local machine's traffic right into
IPsec VPN tunnel.
Other local machine's services successfully connect to their destinations using
NAT from local machine's localhost by IPsec VPN.
Logically, smtpd should bind on 127.0.0.1 local machine and expose its external
remote gateway machine's IP in heloname as configured:
# cat /etc/mail/smtpd.conf
...
table sources {127.0.0.1}
table helonames {1.2.3.4 = smtp.domain.tld}
...
But any attempt to send mail returns errors as shown below and no messages are
sent to their destinations in result.
smtpd [95677]: smtp-out: Error on 127.0.0.1 <-> 199.185.178.25
(mail.openbsd.org): Failed to retrieve helo string
smtpd [95677]: smtp-out: Disabling route 127.0.0.1 <-> 199.185.178.25
(mail.openbsd.org) for 15s
smtpd [95677]: mta delivery evpid=9f2a1cf3a8e83deb
from= to= rcpt=<-> source"-"
relay="openbsd.org" delay=6m42s result="TempFail" stat="No valid route to
destionatin"
smtpd [95677]: smtp-out: Enabling route 127.0.0.1 <-> 199.185.178.25
(mail.openbsd.org)
Telnet connects from local machine to 199.185.178.25 successfully.
# telnet 199.185.178.25 25
Trying 199.185.178.25...
Connected to 199.185.178.25
Escape character is '^]'.
220 mail.openbsd.org ESMTP mail.openbsd.org; Thu Aug 13 04:26:10 2020
Please advice what I did wrong in configuring smtpd?
Can smtpd send messages in any way stays behind IPsec VPN NAT?
Martin
Re: smtpd returns 'TempFail' and 'No route to destination' when using localhost as source behind NAT
On Thu, Aug 13, 2020 at 10:35:32AM +, Martin wrote:
> OpenSMTPd 6.7.0 OpenBSD 6.7-current on local machine. All machine's traffic
> redirected trough iked IPsec VPN to remote gateway machine and uses PF NAT
> rule first:
>
> match out log on enc0 from 0.0.0.0/0 to 0.0.0.0/0 nat-to 10.100.0.2
>
> where 10.100.0.2 is virtual IP to NAT all local machine's traffic right into
> IPsec VPN tunnel.
>
> Other local machine's services successfully connect to their destinations
> using NAT from local machine's localhost by IPsec VPN.
>
> Logically, smtpd should bind on 127.0.0.1 local machine and expose its
> external remote gateway machine's IP in heloname as configured:
>
> # cat /etc/mail/smtpd.conf
> ...
> table sources {127.0.0.1}
> table helonames {1.2.3.4 = smtp.domain.tld}
> ...
>
You don't show how you use these tables in action definitions in your config.
You need to have something like
action dxxx relay src helo-src
Re: aggr(4) not working with Intel XXV710 SFP28 on a Supermicro X11DPi-N(T)
On Wed, Aug 12, 2020 at 02:54:36PM +0100, Tom Smyth wrote: > What is the Switch telling you about the LACP ? This is a Cisco switch running Nexus not IOS so I am not quite as familiar with it as the IOS ones so I may have a few things wrong here. Also, you are asking for a lot of into so this is a long email. This is what I think you are asking for. > can you do a > > show port-channel # sh port-channel ^ % Incomplete command at '^' marker This is not right for NXOS. Do you mean this: # show port-channel database ... port-channel32 Last membership update is successful 2 ports in total, 2 ports up First operational port is Ethernet5/38 Age of the port-channel is 5d:01h:54m:27s Time since last bundle is 5d:01h:50m:54s Last bundled member is Ethernet6/38 Ports: Ethernet5/38[on] [up] * Ethernet6/38[on] [up] port-channel33 Last membership update is successful 2 ports in total, 2 ports up First operational port is Ethernet7/38 Age of the port-channel is 5d:01h:53m:58s Time since last bundle is 5d:01h:48m:28s Last bundled member is Ethernet8/38 Ports: Ethernet7/38[on] [up] * Ethernet8/38[on] [up] > show port-channel detailed # sh port-channel detailed ^ % Invalid command at '^' marker. Do you mean this: show port-channel internal event-history all | include port-channel32 next 20 port-channel32 channel: 32 bundle : 65535 ifindex: 0x161f admin mode : on oper mode : on nports : 2 active : 2 pre cfg: 0 ltl: 0x15 (21) lif: 0x12bc iod: 0x2bf (703) global id : 20 flag : 0 lock count : 0 num. of SIs: 0 ac mbrs: 0 0 lacp graceful conv disable : 0 lacp suspend indiv disable : 0 pc min-links : 1 pc max-bundle: 32 -- PC SDB: Is a member of port-channel32 FSM: has 191 logged transitions< 1) Event:ESQ_RSP length:38, at 75399 usecs after Wed Aug 12 17:18:28 2020 Instance:0x1A204A00, Seq Id:0x1, Ret:SUCCESS [E_MTS_RX] Src:MTS_SAP_PIXM_LOCAL(153), Opc:MTS_OPC_PIXM_MOD_MEMB_LTL(69637) RRtoken:0x4C0F7380 2) Event:ESQ_REQ length:38, at 75466 usecs after Wed Aug 12 17:18:28 2020 Instance:0x1A204A00, Seq Id:0x1, Ret:SUCCESS [E_MTS_TX] Dst:MTS_SAP_UFDM_SYS(193), Opc:MTS_OPC_PCM_PROTOCOL_DN(63497) RRtoken:0x4C0F73D9 3) Event:ESQ_RSP length:38, at 75593 usecs after Wed Aug 12 17:18:28 2020 Instance:0x1A204A00, Seq Id:0x1, Ret:SUCCESS [E_MTS_RX] Src:MTS_SAP_UFDM_SYS(193), Opc:MTS_OPC_PCM_PROTOCOL_DN(63497) RRtoken:0x4C0F73D9 4) Event:ESQ_REQ length:38, at 75646 usecs after Wed Aug 12 17:18:28 2020 -- PC SDB: Is a member of port-channel32 FSM: has 191 logged transitions< 1) Event:ESQ_RSP length:38, at 263607 usecs after Wed Aug 12 17:18:28 2020 Instance:0x1A284A00, Seq Id:0x1, Ret:SUCCESS [E_MTS_RX] Src:MTS_SAP_PIXM_LOCAL(153), Opc:MTS_OPC_PIXM_MOD_MEMB_LTL(69637) RRtoken:0x4C0F7603 2) Event:ESQ_REQ length:38, at 263663 usecs after Wed Aug 12 17:18:28 2020 Instance:0x1A284A00, Seq Id:0x1, Ret:SUCCESS [E_MTS_TX] Dst:MTS_SAP_UFDM_SYS(193), Opc:MTS_OPC_PCM_PROTOCOL_DN(63497) RRtoken:0x4C0F7613 3) Event:ESQ_RSP length:38, at 263825 usecs after Wed Aug 12 17:18:28 2020 Instance:0x1A284A00, Seq Id:0x1, Ret:SUCCESS [E_MTS_RX] Src:MTS_SAP_UFDM_SYS(193), Opc:MTS_OPC_PCM_PROTOCOL_DN(63497) RRtoken:0x4C0F7613 4) Event:ESQ_REQ length:38, at 263887 usecs after Wed Aug 12 17:18:28 2020 Or maybe this: # show port-channel internal info interface po32 port-channel32 channel: 32 bundle : 65535 ifindex: 0x161f admin mode : on oper mode : on nports : 2 active : 2 pre cfg: 0 ltl: 0x15 (21) lif: 0x12bc iod: 0x2bf (703) global id : 20 flag : 0 lock count : 0 num. of SIs: 0 ac mbrs: 0 0 lacp graceful conv disable : 0 lacp suspend indiv disable : 0 pc min-links : 1 pc max-bundle: 32 pc max active members: 32 pc is-suspend-minlinks : 0 port load defer enable : 0 port-channel bfd config enabled : 0 port-channel bfd config complete: 0 port-channel bfd destination: null port-channel bfd start timeout: 0 lacp fast-select-hot-standby disable : 0 port-channel port hash-distribution: none ethpm bundle lock count : 0 lacp delayed-enable fop Ethernet5/38 0x1a204a00 lacp delayed-enable : 0 lacp delayed-enable cfg-port none lacp delayed-enable
Re: laptop cpu high temperature while idle
"Due to the way in which thermal information is reported on Intel processors, the temperature may be off by exactly +/-15 degrees C." man 4 cpu http://man.openbsd.org/cpu#BUGS This must be my case. Thanks for participating to Stefan Hagen and John aka j. Topic closed. Sadly, temperature output is not accompanied by warning of known bugs. That would add clarity and save time for users, e.g. it was not obvious to me that man 4 cpu http://man.openbsd.org/cpu#BUGS needs to be read. Although that would add complexity to the code and take time from developers, sadly.
Re: Adding more syspatch platform.
Jordan Geoghegan(jor...@geoghegan.ca) on 2020.08.12 10:32:21 -0700: > > > On 2020-08-12 02:08, Stuart Henderson wrote: > >The only proxy we have for "what is really used" is dmesg submissions. > >Since 6.7 release: > > > >amd6462 > >i386 5 > >arm643 > >macppc 2 > >octeon 1 > > > >Based on this there isn't a great case for adding any more. > > > > I didn't realize you guys used dmesg@ as a popularity gauge, I thought s/popularity/usage/ > it was just for sending dmesgs for interesting/new hardware. I figured > with something like Edgerouters with their standardized hardware that > repeat dmesgs would just serve to irritate the devs. I personally > administer more OpenBSD 6.x machines than are on that list you sent. I > can start hammering dmesg@, but then I'm gonna skew your stats and In a way, you also skew the stats if you dont send dmesgs. And "you" means everyone. Do it once every 6 months (for every release) i'd say. > you're gonna think that your userbase consists of a bunch of autists > that unironically run macppc, sparc64 and octeon in production > everywhere. In the small Canadian town I live in, I've got a big chunk > of it running on OpenBSD. I've got a bunch of old 90's / 2000's i386 > stuff too, so I can send dmesgs in for that too, the reason I didn't is > I figured the hardware was already 'been there, done that'. If the dmesgs dont show that certain hardware is still used, the drivers for it will get deleted eventually. Another reason to show what you use. > As I mentioned earlier in the thread, I can afford to donate 2 octeon > machines to any devs that are interested (including shipping world wide; > any devs reading: please contact me if you're interested), and am also > happy to help out with octeon stuff in any way I can. Obviously you guys > aren't going to trust me to do anything syspatch related as I'm not a > dev, but I'd at least like it to be known that there are people who care > about the octeon port and who are willing make an effort for it. > > Regards, > > Jordan > --
Re: Adding more syspatch platform.
Den ons 12 aug. 2020 kl 00:50 skrev Predrag Punosevac : > Theo de Raadt wrote: > > No, it is a question of which additional platform, you avoided that > > didn't you > > octeon is the only one I can think of. > I would volunteer doing the work and dedicating two octeons of mine for building syspatches for the supported releases, I have enough of them for it. -- May the most significant bit of your life be positive.
