Re: pkg_add -u Base64.c: loadable library and perl binaries are mismatched
I'll be honest your best bet is
rm -rf /usr/local/*
And I wish I was joking.
It seems somehow perl has become accustomed to prefering whatever it finds
in /usr/local, rather than it's own components installed as part of base.
Another way of looking at this, is that the /usr/ports tree parts of
"perl extensions" are unaware that in OpenBSD perl is a first-class citizen,
and the people involved have become unaware that that the ABI changes they
land there will break 'base' perl use.
Jon Fineman wrote:
> For cpan/cpanm I had gotten the same base64 error.
>
> After moving those two directories and rebooting I was able to run pkg_add
> and now cpanm. However cpan now gets the below error:
> desktop(~)$: cpan
> Encode.c: loadable library and perl binaries are mismatched (got handshake
> key 0xb60, needed 0xec0)
> desktop(~)$:
>
> And one of my programs gets the below error:
> Discount.c: loadable library and perl binaries are mismatched (got handshake
> key 0xb60, needed 0xec0)
>
>
> Outside of X11 the only libraries on the sysclean list are:
>
> /usr/lib/libc++.so.4.0
>
> /usr/lib/libc++abi.so.2.1
>
> /usr/lib/libcbor.so.0.6
>
> /usr/lib/libcrypto.so.46.1
>
> /usr/lib/libfido2.so.2.0
>
> /usr/lib/libpcap.so.8.4
>
> /usr/lib/libssl.so.48.1
>
> /usr/lib/libtls.so.20.1
>
> /usr/lib/libperl.a
>
> /usr/lib/libagentx.so.0.0
>
> /usr/lib/libc++.so.5.0
>
> /usr/lib/libc++abi.so.3.0
>
> /usr/bin/podselect
>
>
>
>
> - Original message -
> From: Andrew Hewus Fresh
> To: Jon Fineman
> Cc: bugs@openbsd.org
> Subject: Re: pkg_add -u Base64.c: loadable library and perl binaries are
> mismatched
> Date: Monday, May 03, 2021 8:57 PM
>
> On Mon, May 03, 2021 at 08:47:15PM -0400, Jon Fineman wrote:
> > Any detailed instructions on how to remove the newer module? Both cpan and
> > cpanm also get the binary mismatch error, so I can't uninstall base64 via
> > cpan.
> >
> > Is there a list of files/directories I can remove? I tried moving Base64.so
> > in local but still got the error. So there seems to be a few more steps
> > needed.
>
> Based on this:
> https://metacpan.org/source/CAPOEIRAB/MIME-Base64-3.16/MANIFEST
>
> I would expect removing these two directories to clean that up.
>
> /usr/local/libdata/perl5/site_perl/amd64-openbsd/MIME
> /usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/MIME
>
> Once pkg_add works again, sysutils/sysclean should help find anything
> other cruft in there.
>
>
> Or, specifically the files covering these three:
>
> $ find /usr/libdata/perl5/*/{,auto/}MIME -type f
> /usr/libdata/perl5/amd64-openbsd/MIME/Base64.pm
> /usr/libdata/perl5/amd64-openbsd/MIME/QuotedPrint.pm
> /usr/libdata/perl5/amd64-openbsd/auto/MIME/Base64/Base64.so
>
>
> Is it still the same Base64.c error, or did some other module get
> installed as well?
>
>
> l8rZ,
> --
> andrew - http://afresh1.com
>
> Computer analyst to programmer:
>"You start coding. I'll go find out what they want."
>
Re: pkg_add -u Base64.c: loadable library and perl binaries are mismatched
Andrew Hewus Fresh wrote: > This would do it, you will need to update this file that you've someone > installed manually, this covers over the one that ships with base and > will definitely cause that issue. Removing the files installed by the > old version of perl's cpan client should get things working again though. It is completely ridiculous that base perl is affected by something which lands in /usr/local It is absolutely unacceptable. > I will try to think about how we could put the pkg installed modules in > the current dir and the cpan installed files into a versioned dir. Not > sure quite how to do that without bumping every perl module, but I'll > think about it more. That seems entirely backwards. You want to crank base perl over and over and over when the outside universe changes? That will make all the perl upgrade tools even *LESS* reliable
Re: bus error on octeon
> I produced a patch for you, but it's not complete but works around the SIGBUS:
>
> Index: print-wg.c
> ===
> RCS file: /cvs/src/usr.sbin/tcpdump/print-wg.c,v
> retrieving revision 1.6
> diff -u -p -u -r1.6 print-wg.c
> --- print-wg.c14 Apr 2021 19:34:56 - 1.6
> +++ print-wg.c3 May 2021 16:29:29 -
> @@ -21,6 +21,7 @@
>
> #include
> #include
> +#include
>
> #include "interface.h"
> #include "extract.h"
> @@ -104,6 +105,9 @@ wg_print(const u_char *bp, u_int length)
> struct wg_data *data = (void *)bp;
> u_intcaplen;
>
> + uint32_treceiver;
> + uint64_tnonce;
> +
> caplen = snapend - bp;
> if (caplen < sizeof(type))
> goto trunc;
> @@ -142,8 +146,12 @@ wg_print(const u_char *bp, u_int length)
> printf("[wg] keepalive ");
> if (caplen < offsetof(struct wg_data, mac))
> goto trunc;
> +
> + memcpy((void *), (void *)>receiver,
> sizeof(receiver));
> + memcpy((void *), (void *)>nonce, sizeof(nonce));
> +
> printf("to 0x%08x nonce %llu",
> - letoh32(data->receiver), letoh64(data->nonce));
> + letoh32(receiver), letoh64(nonce));
> break;
> }
> return;
>
>
> There may be other variables that need the same treatment... if that looks ok
> for you I'll work on that and submit the patch formally.
I dumped with this patch for about an hour, and even restarted the wg tunnel
on the device behind vlan6 so that other types get used (initialization) and
I found that there was no more SIGBUS's for tcpdump on octeon, so I am unsure
if other variables actually do need same treatment still.
Best Regards,
-peter
Re: pkg_add -u Base64.c: loadable library and perl binaries are mismatched
On Mon, May 03, 2021 at 09:51:59PM -0400, Jon Fineman wrote: > For cpan/cpanm I had gotten the same base64 error. > > After moving those two directories and rebooting I was able to run pkg_add > and now cpanm. However cpan now gets the below error: > desktop(~)$: cpan > Encode.c: loadable library and perl binaries are mismatched (got handshake > key 0xb60, needed 0xec0) > desktop(~)$: > > And one of my programs gets the below error: > Discount.c: loadable library and perl binaries are mismatched (got handshake > key 0xb60, needed 0xec0) > > > Outside of X11 the only libraries on the sysclean list are: Hmm, maybe I'm wrong about sysclean and /usr/local/libdata, although since it looks at packages and I don't see anything about ignoring that directory I'm not sure why it would. Are there .so files in /usr/local/libdata that don't show up in /var/db/pkg/*/+CONTENTS? l8rZ, -- andrew - http://afresh1.com I wish life had an UNDO function.
Re: pkg_add -u Base64.c: loadable library and perl binaries are mismatched
For cpan/cpanm I had gotten the same base64 error.
After moving those two directories and rebooting I was able to run pkg_add and
now cpanm. However cpan now gets the below error:
desktop(~)$: cpan
Encode.c: loadable library and perl binaries are mismatched (got handshake key
0xb60, needed 0xec0)
desktop(~)$:
And one of my programs gets the below error:
Discount.c: loadable library and perl binaries are mismatched (got handshake
key 0xb60, needed 0xec0)
Outside of X11 the only libraries on the sysclean list are:
/usr/lib/libc++.so.4.0
/usr/lib/libc++abi.so.2.1
/usr/lib/libcbor.so.0.6
/usr/lib/libcrypto.so.46.1
/usr/lib/libfido2.so.2.0
/usr/lib/libpcap.so.8.4
/usr/lib/libssl.so.48.1
/usr/lib/libtls.so.20.1
/usr/lib/libperl.a
/usr/lib/libagentx.so.0.0
/usr/lib/libc++.so.5.0
/usr/lib/libc++abi.so.3.0
/usr/bin/podselect
- Original message -
From: Andrew Hewus Fresh
To: Jon Fineman
Cc: bugs@openbsd.org
Subject: Re: pkg_add -u Base64.c: loadable library and perl binaries are
mismatched
Date: Monday, May 03, 2021 8:57 PM
On Mon, May 03, 2021 at 08:47:15PM -0400, Jon Fineman wrote:
> Any detailed instructions on how to remove the newer module? Both cpan and
> cpanm also get the binary mismatch error, so I can't uninstall base64 via
> cpan.
>
> Is there a list of files/directories I can remove? I tried moving Base64.so
> in local but still got the error. So there seems to be a few more steps
> needed.
Based on this:
https://metacpan.org/source/CAPOEIRAB/MIME-Base64-3.16/MANIFEST
I would expect removing these two directories to clean that up.
/usr/local/libdata/perl5/site_perl/amd64-openbsd/MIME
/usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/MIME
Once pkg_add works again, sysutils/sysclean should help find anything
other cruft in there.
Or, specifically the files covering these three:
$ find /usr/libdata/perl5/*/{,auto/}MIME -type f
/usr/libdata/perl5/amd64-openbsd/MIME/Base64.pm
/usr/libdata/perl5/amd64-openbsd/MIME/QuotedPrint.pm
/usr/libdata/perl5/amd64-openbsd/auto/MIME/Base64/Base64.so
Is it still the same Base64.c error, or did some other module get
installed as well?
l8rZ,
--
andrew - http://afresh1.com
Computer analyst to programmer:
"You start coding. I'll go find out what they want."
Re: pkg_add -u Base64.c: loadable library and perl binaries are mismatched
On Mon, May 03, 2021 at 08:47:15PM -0400, Jon Fineman wrote:
> Any detailed instructions on how to remove the newer module? Both cpan and
> cpanm also get the binary mismatch error, so I can't uninstall base64 via
> cpan.
>
> Is there a list of files/directories I can remove? I tried moving Base64.so
> in local but still got the error. So there seems to be a few more steps
> needed.
Based on this:
https://metacpan.org/source/CAPOEIRAB/MIME-Base64-3.16/MANIFEST
I would expect removing these two directories to clean that up.
/usr/local/libdata/perl5/site_perl/amd64-openbsd/MIME
/usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/MIME
Once pkg_add works again, sysutils/sysclean should help find anything
other cruft in there.
Or, specifically the files covering these three:
$ find /usr/libdata/perl5/*/{,auto/}MIME -type f
/usr/libdata/perl5/amd64-openbsd/MIME/Base64.pm
/usr/libdata/perl5/amd64-openbsd/MIME/QuotedPrint.pm
/usr/libdata/perl5/amd64-openbsd/auto/MIME/Base64/Base64.so
Is it still the same Base64.c error, or did some other module get
installed as well?
l8rZ,
--
andrew - http://afresh1.com
Computer analyst to programmer:
"You start coding. I'll go find out what they want."
Re: pkg_add -u Base64.c: loadable library and perl binaries are mismatched
Any detailed instructions on how to remove the newer module? Both cpan and cpanm also get the binary mismatch error, so I can't uninstall base64 via cpan. Is there a list of files/directories I can remove? I tried moving Base64.so in local but still got the error. So there seems to be a few more steps needed. Thanks. Jon - Original message - From: Andrew Hewus Fresh To: Jon Fineman Cc: bugs@openbsd.org Subject: Re: pkg_add -u Base64.c: loadable library and perl binaries are mismatched Date: Monday, May 03, 2021 8:41 PM On Mon, May 03, 2021 at 08:27:11PM -0400, Jon Fineman wrote: > > > - Original message - > From: Andrew Hewus Fresh > To: Jon Fineman > Cc: bugs@openbsd.org > Subject: Re: pkg_add -u Base64.c: loadable library and perl binaries are > mismatched > Date: Monday, May 03, 2021 8:20 PM > > Did you possibly use a cpan client to install a newer version of > Base64.so? Can you see if `find /usr/local/libdata -name Base64.so` > turns anything up? > desktop(~)$: find /usr/local/libdata -name Base64.so > /usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/MIME/Base64/Base64.so > desktop(~)$: This would do it, you will need to update this file that you've someone installed manually, this covers over the one that ships with base and will definitely cause that issue. Removing the files installed by the old version of perl's cpan client should get things working again though. I will try to think about how we could put the pkg installed modules in the current dir and the cpan installed files into a versioned dir. Not sure quite how to do that without bumping every perl module, but I'll think about it more. l8rZ, -- andrew - http://afresh1.com I think I understand, but my stubborn brain refuses to admit it until I beat it into submission by proof upon proof. -- Michael Shiloh
Re: pkg_add -u Base64.c: loadable library and perl binaries are mismatched
- Original message - From: Andrew Hewus Fresh To: Jon Fineman Cc: bugs@openbsd.org Subject: Re: pkg_add -u Base64.c: loadable library and perl binaries are mismatched Date: Monday, May 03, 2021 8:20 PM On Mon, May 03, 2021 at 08:11:04PM -0400, Jon Fineman wrote: > >Synopsis:pkg_add fails > >Category: > >Environment: > System : OpenBSD 6.9 > Details : OpenBSD 6.9 (GENERIC.MP) #473: Mon Apr 19 10:40:28 MDT > 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > After running sysupgrade from 6.8 to 6.9 release the rc.firsttime output > showed the bellow error message: > > Path to firmware: http://firmware.openbsd.org/firmware/6.9/ > Updating: vmm-firmware-1.11.0p3 intel-firmware-20200616v0 > iwm-firmware-20191022p1 uvideo-firmware-1.2p3 inteldrm-firmware-20200421 > Base64.c: loadable library and perl binaries are mismatched (got handshake > key 0xb60, needed 0xec0) > > > Then when I tried to run pkg_add -u to upgrade my packages I got the same > error below. > > desktop(~)$: doas pkg_add -u > doas (j...@desktop.jonjfineman.com) password: > Base64.c: loadable library and perl binaries are mismatched (got handshake > key 0xb60, needed 0xec0) > desktop(~)$: This says libperl and (I assume) MIME/Base64.so are mismatched, which both come from the base set, so I'm not quite sure how you accomplished this. My (sadly very outdated) snapshot says: $ ls -l /usr/lib/libperl.so* /usr/libdata/perl5/amd64-openbsd/auto/MIME/Base64/Base64.so -r--r--r-- 1 root bin 3715880 Apr 12 20:10 /usr/lib/libperl.so.22.0 -r-xr-xr-x 1 root bin17528 Apr 12 20:10 /usr/libdata/perl5/amd64-openbsd/auto/MIME/Base64/Base64.so* How about yours? desktop(~)$: ls -l /usr/lib/libperl.so* /usr/libdata/perl5/amd64-openbsd/auto/MIME/Base64/Base64.so -r--r--r-- 1 root bin 3546048 Oct 4 2020 /usr/lib/libperl.so.20.0 -r--r--r-- 1 root bin 3715880 Apr 19 12:17 /usr/lib/libperl.so.22.0 -r-xr-xr-x 1 root bin17528 Apr 19 12:17 /usr/libdata/perl5/amd64-openbsd/auto/MIME/Base64/Base64.so desktop(~)$: Did you possibly use a cpan client to install a newer version of Base64.so? Can you see if `find /usr/local/libdata -name Base64.so` turns anything up? desktop(~)$: find /usr/local/libdata -name Base64.so /usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/MIME/Base64/Base64.so desktop(~)$: l8rZ, -- andrew - http://afresh1.com Instructions are just another man's opinion of how to do something. -- Weldboy #DPWisdom
Re: pkg_add -u Base64.c: loadable library and perl binaries are mismatched
On Mon, May 03, 2021 at 08:11:04PM -0400, Jon Fineman wrote: > >Synopsis:pkg_add fails > >Category: > >Environment: > System : OpenBSD 6.9 > Details : OpenBSD 6.9 (GENERIC.MP) #473: Mon Apr 19 10:40:28 MDT > 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > After running sysupgrade from 6.8 to 6.9 release the rc.firsttime output > showed the bellow error message: > > Path to firmware: http://firmware.openbsd.org/firmware/6.9/ > Updating: vmm-firmware-1.11.0p3 intel-firmware-20200616v0 > iwm-firmware-20191022p1 uvideo-firmware-1.2p3 inteldrm-firmware-20200421 > Base64.c: loadable library and perl binaries are mismatched (got handshake > key 0xb60, needed 0xec0) > > > Then when I tried to run pkg_add -u to upgrade my packages I got the same > error below. > > desktop(~)$: doas pkg_add -u > doas (j...@desktop.jonjfineman.com) password: > Base64.c: loadable library and perl binaries are mismatched (got handshake > key 0xb60, needed 0xec0) > desktop(~)$: This says libperl and (I assume) MIME/Base64.so are mismatched, which both come from the base set, so I'm not quite sure how you accomplished this. My (sadly very outdated) snapshot says: $ ls -l /usr/lib/libperl.so* /usr/libdata/perl5/amd64-openbsd/auto/MIME/Base64/Base64.so -r--r--r-- 1 root bin 3715880 Apr 12 20:10 /usr/lib/libperl.so.22.0 -r-xr-xr-x 1 root bin17528 Apr 12 20:10 /usr/libdata/perl5/amd64-openbsd/auto/MIME/Base64/Base64.so* How about yours? Did you possibly use a cpan client to install a newer version of Base64.so? Can you see if `find /usr/local/libdata -name Base64.so` turns anything up? l8rZ, -- andrew - http://afresh1.com Instructions are just another man's opinion of how to do something. -- Weldboy #DPWisdom
Re: pkg_add -u Base64.c: loadable library and perl binaries are mismatched
Also my /etc/installurl is: desktop(/etc)$: cat /etc/installurl https://cdn.openbsd.org/pub/OpenBSD desktop(/etc)$: - Original message - From: Jon Fineman To: bugs@openbsd.org Cc: j...@fineman.me Subject: pkg_add -u Base64.c: loadable library and perl binaries are mismatched Date: Monday, May 03, 2021 8:11 PM >Synopsis: pkg_add fails >Category: >Environment: System : OpenBSD 6.9 Details : OpenBSD 6.9 (GENERIC.MP) #473: Mon Apr 19 10:40:28 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: After running sysupgrade from 6.8 to 6.9 release the rc.firsttime output showed the bellow error message: Path to firmware: http://firmware.openbsd.org/firmware/6.9/ Updating: vmm-firmware-1.11.0p3 intel-firmware-20200616v0 iwm-firmware-20191022p1 uvideo-firmware-1.2p3 inteldrm-firmware-20200421 Base64.c: loadable library and perl binaries are mismatched (got handshake key 0xb60, needed 0xec0) Then when I tried to run pkg_add -u to upgrade my packages I got the same error below. desktop(~)$: doas pkg_add -u doas (j...@desktop.jonjfineman.com) password: Base64.c: loadable library and perl binaries are mismatched (got handshake key 0xb60, needed 0xec0) desktop(~)$:
pkg_add -u Base64.c: loadable library and perl binaries are mismatched
>Synopsis: pkg_add fails >Category: >Environment: System : OpenBSD 6.9 Details : OpenBSD 6.9 (GENERIC.MP) #473: Mon Apr 19 10:40:28 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: After running sysupgrade from 6.8 to 6.9 release the rc.firsttime output showed the bellow error message: Path to firmware: http://firmware.openbsd.org/firmware/6.9/ Updating: vmm-firmware-1.11.0p3 intel-firmware-20200616v0 iwm-firmware-20191022p1 uvideo-firmware-1.2p3 inteldrm-firmware-20200421 Base64.c: loadable library and perl binaries are mismatched (got handshake key 0xb60, needed 0xec0) Then when I tried to run pkg_add -u to upgrade my packages I got the same error below. desktop(~)$: doas pkg_add -u doas (j...@desktop.jonjfineman.com) password: Base64.c: loadable library and perl binaries are mismatched (got handshake key 0xb60, needed 0xec0) desktop(~)$: >How-To-Repeat: run pkg_add -u >Fix: dmesg: OpenBSD 6.9 (GENERIC.MP) #473: Mon Apr 19 10:40:28 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17047867392 (16258MB) avail mem = 16515821568 (15750MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x8b1d7000 (57 entries) bios0: vendor Intel Corp. version "SYSKLi35.86A.0042.2016.0409.1246" date 04/09/2016 bios0: Intel corporation NUC6i5SYB acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT UEFI SSDT BGRT DMAR acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) SIO1(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(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) i5-6260U CPU @ 1.80GHz, 1796.46 MHz, 06-4e-03 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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,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 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1712.90 MHz, 06-4e-03 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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,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 1 (application processor) cpu2: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.05 MHz, 06-4e-03 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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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) i5-6260U CPU @ 1.80GHz, 1696.05 MHz, 06-4e-03 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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa
Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install
Further info (screen shots) - today during a lengthy rsync it seemed the screen saver kicked in but X crashed right after and then this sequence happened: https://www.bsdly.net/~peter/20210503_164555.jpg https://www.bsdly.net/~peter/20210503_164607.jpg https://www.bsdly.net/~peter/20210503_164616.jpg https://www.bsdly.net/~peter/20210503_164624.jpg https://www.bsdly.net/~peter/20210503_165327.jpg https://www.bsdly.net/~peter/20210503_165335.jpg still running with a disable acpicpu* kernel, FWIW All the best, Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install
Hi Peter, Here is a small diff. Two questions: 1. Does the machine powerdown if you do halt -p with this diff? 2. Does the diff fix the crashes? Thanks, Mark Index: dev/acpi/acpi.c === RCS file: /cvs/src/sys/dev/acpi/acpi.c,v retrieving revision 1.397 diff -u -p -r1.397 acpi.c --- dev/acpi/acpi.c 15 Mar 2021 22:44:57 - 1.397 +++ dev/acpi/acpi.c 3 May 2021 17:00:09 - @@ -262,6 +262,9 @@ acpi_gasio(struct acpi_softc *sc, int io dnprintf(50, "gasio: %.2x 0x%.8llx %s\n", iospace, address, (iodir == ACPI_IOWRITE) ? "write" : "read"); + if (len == 0) + return 0; + KASSERT((len % access_size) == 0); pb = (uint8_t *)buffer;
Re: bus error on octeon
On Mon, May 03, 2021 at 09:42:10AM -0600, Theo de Raadt wrote:
> You didn't use a -g binary as I suggested, then gdb will show more.
Apologies, I did compile with -g but since I cherry picked the source over
to the router (which is extremely low on space) it installed the binary in
the wrong spot and stripped it. Murphy's law I guess :-(.
So I finally compiled it with -ggdb and copied it right out of the obj to the
/usr/sbin. I now have a nice traceback for you all:
--->
Loaded symbols for /usr/libexec/ld.so
#0 wg_print (bp=0x2c2d3d8044 "\004", length=Variable "length" is not available.
)
at /usr/src/usr.sbin/tcpdump/print-wg.c:146
146 letoh32(data->receiver), letoh64(data->nonce));
(gdb) bt
#0 wg_print (bp=0x2c2d3d8044 "\004", length=Variable "length" is not available.
)
at /usr/src/usr.sbin/tcpdump/print-wg.c:146
#1 0x0027cd281880 in udp_print (bp=Variable "bp" is not available.
)
at /usr/src/usr.sbin/tcpdump/print-udp.c:586
#2 0x0027cd27d5f8 in ip_print (bp=Variable "bp" is not available.
)
at /usr/src/usr.sbin/tcpdump/print-ip.c:394
#3 0x0027cd27c4f8 in ether_encap_print (ethertype=Variable "ethertype" is n
ot available.
)
at /usr/src/usr.sbin/tcpdump/print-ether.c:228
#4 0x0027cd27bf10 in ether_tryprint (p=Variable "p" is not available.
)
at /usr/src/usr.sbin/tcpdump/print-ether.c:148
#5 0x0027cd27bcc4 in ether_if_print (user=Variable "user" is not available.
)
at /usr/src/usr.sbin/tcpdump/print-ether.c:100
#6 0x002cc2283f98 in pcap_read (p=0x2c2055ec00, cnt=-1,
callback=0x27cd27bc40 , user=0x0)
at /usr/src/lib/libpcap/pcap-bpf.c:188
- cut -
(gdb) down
#0 wg_print (bp=0x2c2d3d8044 "\004", length=Variable "length" is not available.
)
at /usr/src/usr.sbin/tcpdump/print-wg.c:146
146 letoh32(data->receiver), letoh64(data->nonce));
(gdb) print bp
$1 = (const u_char *) 0x2c2d3d8044 "\004"
(gdb) print data
$2 = (struct wg_data *) 0x2c2d3d8044
(gdb) print data->receiver
$3 = 3979343260
(gdb) print >receiver
$4 = (uint32_t *) 0x2c2d3d8048
(gdb) print data->nonce
$5 = 2017612633061982208
(gdb) print >nonce
$6 = (uint64_t *) 0x2c2d3d804c
I produced a patch for you, but it's not complete but works around the SIGBUS:
Index: print-wg.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-wg.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 print-wg.c
--- print-wg.c 14 Apr 2021 19:34:56 - 1.6
+++ print-wg.c 3 May 2021 16:29:29 -
@@ -21,6 +21,7 @@
#include
#include
+#include
#include "interface.h"
#include "extract.h"
@@ -104,6 +105,9 @@ wg_print(const u_char *bp, u_int length)
struct wg_data *data = (void *)bp;
u_intcaplen;
+ uint32_treceiver;
+ uint64_tnonce;
+
caplen = snapend - bp;
if (caplen < sizeof(type))
goto trunc;
@@ -142,8 +146,12 @@ wg_print(const u_char *bp, u_int length)
printf("[wg] keepalive ");
if (caplen < offsetof(struct wg_data, mac))
goto trunc;
+
+ memcpy((void *), (void *)>receiver,
sizeof(receiver));
+ memcpy((void *), (void *)>nonce, sizeof(nonce));
+
printf("to 0x%08x nonce %llu",
- letoh32(data->receiver), letoh64(data->nonce));
+ letoh32(receiver), letoh64(nonce));
break;
}
return;
There may be other variables that need the same treatment... if that looks ok
for you I'll work on that and submit the patch formally.
Best Regards,
-peter
> Peter J. Philipp wrote:
>
> > On Mon, May 03, 2021 at 08:27:57AM -0600, Theo de Raadt wrote:
> > > Can you reproduce this, and capture core files?
> >
> > Yes after a reboot I could reproduce it, I didn't even have to cycle the
> > interfaces. I got a coredump like you descriped for me. See below:
> >
> > > Since our tcpdump is a privsep program, getting a core is a bit harder.
> > >
> > > mkdir /var/crash/tcpdump
> > > echo kern.nosuidcoredump=3 >> /etc/sysctl.conf
> > > reboot
> > >
> > > You could recompile tcpdump with -g or -ggdb, to gain better symbols.
> > >
> > > If you manage to create a coredump, run gdb against the unstripped
> > > binary (src/usr.sbin/tcpdump/obj/tcpdump) and let's see what the trace is.
> >
> > Loaded symbols for /usr/libexec/ld.so
> > #0 0x0032fd8d2f74 in wg_print () from /usr/sbin/tcpdump
> > (gdb) bt
> > #0 0x0032fd8d2f74 in wg_print () from /usr/sbin/tcpdump
Re: bus error on octeon
You didn't use a -g binary as I suggested, then gdb will show more. Peter J. Philipp wrote: > On Mon, May 03, 2021 at 08:27:57AM -0600, Theo de Raadt wrote: > > Can you reproduce this, and capture core files? > > Yes after a reboot I could reproduce it, I didn't even have to cycle the > interfaces. I got a coredump like you descriped for me. See below: > > > Since our tcpdump is a privsep program, getting a core is a bit harder. > > > > mkdir /var/crash/tcpdump > > echo kern.nosuidcoredump=3 >> /etc/sysctl.conf > > reboot > > > > You could recompile tcpdump with -g or -ggdb, to gain better symbols. > > > > If you manage to create a coredump, run gdb against the unstripped > > binary (src/usr.sbin/tcpdump/obj/tcpdump) and let's see what the trace is. > > Loaded symbols for /usr/libexec/ld.so > #0 0x0032fd8d2f74 in wg_print () from /usr/sbin/tcpdump > (gdb) bt > #0 0x0032fd8d2f74 in wg_print () from /usr/sbin/tcpdump > #1 0x0032fd891880 in udp_print () from /usr/sbin/tcpdump > #2 0x0032fd88d5f8 in ip_print () from /usr/sbin/tcpdump > #3 0x0032fd88c4f8 in ether_encap_print () from /usr/sbin/tcpdump > #4 0x0032fd88bf10 in ether_tryprint () from /usr/sbin/tcpdump > #5 0x0032fd88bcc4 in ether_if_print () from /usr/sbin/tcpdump > #6 0x003766337f98 in pcap_read (p=0x37aa410e00, cnt=-1, > callback=0x32fd88bc40 , user=0x0) > at /usr/src/lib/libpcap/pcap-bpf.c:188 > #7 0x0037663359d4 in pcap_loop (p=0x37aa410e00, cnt=-1, > callback=0x32fd88bc40 , user=0x0) > at /usr/src/lib/libpcap/pcap.c:76 > #8 0x0032fd8818e8 in main () from /usr/sbin/tcpdump > > It looks like it's in wg_print() I looked at this, but was unable to find > a solution. Perhaps memcpy'ing bp in wg_print() to another aligned buffer > and then trying to get the values out of it. I spent days fixing my programs > on octeon similar to that, but I used an unpack8, unpack16, unpack32, unpack64 > and unpack() to do so, which in the latter case memcpy'd. I know too little > though of how tcpdump is best worked with, just writing memcpy's in there is > probably not a good idea. > > Best Regards, > -peter
Re: bus error on octeon
On Mon, May 03, 2021 at 08:27:57AM -0600, Theo de Raadt wrote: > Can you reproduce this, and capture core files? Yes after a reboot I could reproduce it, I didn't even have to cycle the interfaces. I got a coredump like you descriped for me. See below: > Since our tcpdump is a privsep program, getting a core is a bit harder. > > mkdir /var/crash/tcpdump > echo kern.nosuidcoredump=3 >> /etc/sysctl.conf > reboot > > You could recompile tcpdump with -g or -ggdb, to gain better symbols. > > If you manage to create a coredump, run gdb against the unstripped > binary (src/usr.sbin/tcpdump/obj/tcpdump) and let's see what the trace is. Loaded symbols for /usr/libexec/ld.so #0 0x0032fd8d2f74 in wg_print () from /usr/sbin/tcpdump (gdb) bt #0 0x0032fd8d2f74 in wg_print () from /usr/sbin/tcpdump #1 0x0032fd891880 in udp_print () from /usr/sbin/tcpdump #2 0x0032fd88d5f8 in ip_print () from /usr/sbin/tcpdump #3 0x0032fd88c4f8 in ether_encap_print () from /usr/sbin/tcpdump #4 0x0032fd88bf10 in ether_tryprint () from /usr/sbin/tcpdump #5 0x0032fd88bcc4 in ether_if_print () from /usr/sbin/tcpdump #6 0x003766337f98 in pcap_read (p=0x37aa410e00, cnt=-1, callback=0x32fd88bc40 , user=0x0) at /usr/src/lib/libpcap/pcap-bpf.c:188 #7 0x0037663359d4 in pcap_loop (p=0x37aa410e00, cnt=-1, callback=0x32fd88bc40 , user=0x0) at /usr/src/lib/libpcap/pcap.c:76 #8 0x0032fd8818e8 in main () from /usr/sbin/tcpdump It looks like it's in wg_print() I looked at this, but was unable to find a solution. Perhaps memcpy'ing bp in wg_print() to another aligned buffer and then trying to get the values out of it. I spent days fixing my programs on octeon similar to that, but I used an unpack8, unpack16, unpack32, unpack64 and unpack() to do so, which in the latter case memcpy'd. I know too little though of how tcpdump is best worked with, just writing memcpy's in there is probably not a good idea. Best Regards, -peter
Re: bus error on octeon
Yup I'll try. Give me bit of time to find results. Best Regards, -peter On Mon, May 03, 2021 at 08:27:57AM -0600, Theo de Raadt wrote: > Can you reproduce this, and capture core files? > > Since our tcpdump is a privsep program, getting a core is a bit harder. > > mkdir /var/crash/tcpdump > echo kern.nosuidcoredump=3 >> /etc/sysctl.conf > reboot > > You could recompile tcpdump with -g or -ggdb, to gain better symbols. > > If you manage to create a coredump, run gdb against the unstripped > binary (src/usr.sbin/tcpdump/obj/tcpdump) and let's see what the trace is. > > p...@delphinusdns.org wrote: > > > >Synopsis: Encountered bus error on tcpdumping a cycled interface > > >Category: system > > >Environment: > > System : OpenBSD 6.9 > > Details : OpenBSD 6.9 (GENERIC.MP) #551: Sun Apr 18 03:06:59 MDT > > 2021 > > > > dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP > > > > Architecture: OpenBSD.octeon > > Machine : octeon > > >Description: > > I cycled a vlan (vlan6) interface to down and then back to up with ifconfig > > to > > see if there is traffic flowing I tried tcpdumping and encountered a SIGBUS. > > Here is what I see: > > > > eta# tcpdump -v -n -i vlan6 > > tcpdump: listening on vlan6, link-type EN10MB > > Bus error > > eta# ifconfig vlan6 > > vlan6: flags=8843 mtu 1500 > > lladdr fc:ec:da:04:8d:69 > > description: RPI Freifunk Franken VLAN > > index 11 priority 0 llprio 3 > > encap: vnetid 6 parent cnmac1 txprio packet rxprio outer > > groups: vlan > > media: Ethernet autoselect (1000baseT full-duplex) > > status: active > > inet 192.168.36.1 netmask 0xff00 broadcast 192.168.36.255 > > > > A particular ktrace/kdump revealed this: > > > > 47271 tcpdump RET fstat 0 > > 47271 tcpdump CALL > > mmap(0,0x1,0x3,0x1002,-1,0) > > 47271 tcpdump RET mmap 252174057472/0x3ab6bec000 > > 47271 tcpdump CALL fcntl(1,F_ISATTY) > > 47271 tcpdump RET fcntl 1 > > 47271 tcpdump PSIG SIGBUS SIG_DFL code BUS_ADRALN<1> addr=0x39f0f3c04c > > trapno=0 > > > > I assume the fcntl(... could be an isatty(3). > > >How-To-Repeat: > > No idea, I only upgraded this router today and added some networking > > including wireguard tunnels. > > >Fix: > > Not provided. There is mention in comments at: > > > > /usr/src/sys/arch/mips64/mips64/trap.c under BUS_ADRALN that this may be an > > unaligned memory access. > > > > > > dmesg: > > OpenBSD 6.9 (GENERIC.MP) #551: Sun Apr 18 03:06:59 MDT 2021 > > dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP > > real mem = 536870912 (512MB) > > avail mem = 521322496 (497MB) > > random: good seed from bootblocks > > mainbus0 at root: board 20004 rev 0.16, model CN3xxx/CN5xxx > > cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation > > cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way > > cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation > > cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way > > clock0 at mainbus0: int 5 > > octcrypto0 at mainbus0 > > iobus0 at mainbus0 > > simplebus0 at iobus0: "soc" > > octciu0 at simplebus0 > > octsmi0 at simplebus0 > > octpip0 at simplebus0 > > octgmx0 at octpip0 interface 0 > > cnmac0 at octgmx0: port 0 RGMII, address fc:ec:da:04:8d:68 > > atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2 > > cnmac1 at octgmx0: port 1 RGMII, address fc:ec:da:04:8d:69 > > atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2 > > cnmac2 at octgmx0: port 2 RGMII, address fc:ec:da:04:8d:6a > > atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2 > > com0 at simplebus0: ns16550a, 64 byte fifo > > com0: console > > dwctwo0 at iobus0 base 0x118006800 irq 56 > > usb0 at dwctwo0: USB revision 2.0 > > uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev > > 2.00/1.00 addr 1 > > octrng0 at iobus0 base 0x14000 irq 0 > > umass0 at uhub0 port 1 configuration 1 interface 0 " UDinfo UF2 4GB" rev > > 2.00/1.00 addr 2 > > umass0: using SCSI over Bulk-Only > > scsibus0 at umass0: 2 targets, initiator 0 > > sd0 at scsibus0 targ 1 lun 0: <, UDinfo UF2 4GB, PMAP> removable > > serial.13fe420077C9177D2781 > > sd0: 3824MB, 512 bytes/sector, 7831552 sectors > > vscsi0 at root > > scsibus1 at vscsi0: 256 targets > > softraid0 at root > > scsibus2 at softraid0: 256 targets > > root on sd0a (d5ffec0c72cad730.a) swap on sd0b dump on sd0b > > WARNING: CHECK AND RESET THE DATE! > > > > usbdevs: > > Controller /dev/usb0: > > addr 01: : Octeon, DWC2 root hub > > high speed, self powered, config 1, rev 1.00 > > driver: uhub0 > > addr 02: 13fe:4200 , UDinfo UF2 4GB > > high speed, power 200 mA, config 1, rev 1.00, iSerial 070877C9177D2781 > > driver: umass0 > > > > pcidump: > > > > acpidump: > >
Re: bus error on octeon
Can you reproduce this, and capture core files? Since our tcpdump is a privsep program, getting a core is a bit harder. mkdir /var/crash/tcpdump echo kern.nosuidcoredump=3 >> /etc/sysctl.conf reboot You could recompile tcpdump with -g or -ggdb, to gain better symbols. If you manage to create a coredump, run gdb against the unstripped binary (src/usr.sbin/tcpdump/obj/tcpdump) and let's see what the trace is. p...@delphinusdns.org wrote: > >Synopsis:Encountered bus error on tcpdumping a cycled interface > >Category:system > >Environment: > System : OpenBSD 6.9 > Details : OpenBSD 6.9 (GENERIC.MP) #551: Sun Apr 18 03:06:59 MDT > 2021 > > dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP > > Architecture: OpenBSD.octeon > Machine : octeon > >Description: > I cycled a vlan (vlan6) interface to down and then back to up with ifconfig to > see if there is traffic flowing I tried tcpdumping and encountered a SIGBUS. > Here is what I see: > > eta# tcpdump -v -n -i vlan6 > tcpdump: listening on vlan6, link-type EN10MB > Bus error > eta# ifconfig vlan6 > vlan6: flags=8843 mtu 1500 > lladdr fc:ec:da:04:8d:69 > description: RPI Freifunk Franken VLAN > index 11 priority 0 llprio 3 > encap: vnetid 6 parent cnmac1 txprio packet rxprio outer > groups: vlan > media: Ethernet autoselect (1000baseT full-duplex) > status: active > inet 192.168.36.1 netmask 0xff00 broadcast 192.168.36.255 > > A particular ktrace/kdump revealed this: > > 47271 tcpdump RET fstat 0 > 47271 tcpdump CALL > mmap(0,0x1,0x3,0x1002,-1,0) > 47271 tcpdump RET mmap 252174057472/0x3ab6bec000 > 47271 tcpdump CALL fcntl(1,F_ISATTY) > 47271 tcpdump RET fcntl 1 > 47271 tcpdump PSIG SIGBUS SIG_DFL code BUS_ADRALN<1> addr=0x39f0f3c04c > trapno=0 > > I assume the fcntl(... could be an isatty(3). > >How-To-Repeat: > No idea, I only upgraded this router today and added some networking > including wireguard tunnels. > >Fix: > Not provided. There is mention in comments at: > > /usr/src/sys/arch/mips64/mips64/trap.c under BUS_ADRALN that this may be an > unaligned memory access. > > > dmesg: > OpenBSD 6.9 (GENERIC.MP) #551: Sun Apr 18 03:06:59 MDT 2021 > dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP > real mem = 536870912 (512MB) > avail mem = 521322496 (497MB) > random: good seed from bootblocks > mainbus0 at root: board 20004 rev 0.16, model CN3xxx/CN5xxx > cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation > cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way > cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation > cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way > clock0 at mainbus0: int 5 > octcrypto0 at mainbus0 > iobus0 at mainbus0 > simplebus0 at iobus0: "soc" > octciu0 at simplebus0 > octsmi0 at simplebus0 > octpip0 at simplebus0 > octgmx0 at octpip0 interface 0 > cnmac0 at octgmx0: port 0 RGMII, address fc:ec:da:04:8d:68 > atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2 > cnmac1 at octgmx0: port 1 RGMII, address fc:ec:da:04:8d:69 > atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2 > cnmac2 at octgmx0: port 2 RGMII, address fc:ec:da:04:8d:6a > atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2 > com0 at simplebus0: ns16550a, 64 byte fifo > com0: console > dwctwo0 at iobus0 base 0x118006800 irq 56 > usb0 at dwctwo0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev > 2.00/1.00 addr 1 > octrng0 at iobus0 base 0x14000 irq 0 > umass0 at uhub0 port 1 configuration 1 interface 0 " UDinfo UF2 4GB" rev > 2.00/1.00 addr 2 > umass0: using SCSI over Bulk-Only > scsibus0 at umass0: 2 targets, initiator 0 > sd0 at scsibus0 targ 1 lun 0: <, UDinfo UF2 4GB, PMAP> removable > serial.13fe420077C9177D2781 > sd0: 3824MB, 512 bytes/sector, 7831552 sectors > vscsi0 at root > scsibus1 at vscsi0: 256 targets > softraid0 at root > scsibus2 at softraid0: 256 targets > root on sd0a (d5ffec0c72cad730.a) swap on sd0b dump on sd0b > WARNING: CHECK AND RESET THE DATE! > > usbdevs: > Controller /dev/usb0: > addr 01: : Octeon, DWC2 root hub >high speed, self powered, config 1, rev 1.00 >driver: uhub0 > addr 02: 13fe:4200 , UDinfo UF2 4GB >high speed, power 200 mA, config 1, rev 1.00, iSerial 070877C9177D2781 >driver: umass0 > > pcidump: > > acpidump: >
bus error on octeon
>Synopsis: Encountered bus error on tcpdumping a cycled interface >Category: system >Environment: System : OpenBSD 6.9 Details : OpenBSD 6.9 (GENERIC.MP) #551: Sun Apr 18 03:06:59 MDT 2021 dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP Architecture: OpenBSD.octeon Machine : octeon >Description: I cycled a vlan (vlan6) interface to down and then back to up with ifconfig to see if there is traffic flowing I tried tcpdumping and encountered a SIGBUS. Here is what I see: eta# tcpdump -v -n -i vlan6 tcpdump: listening on vlan6, link-type EN10MB Bus error eta# ifconfig vlan6 vlan6: flags=8843 mtu 1500 lladdr fc:ec:da:04:8d:69 description: RPI Freifunk Franken VLAN index 11 priority 0 llprio 3 encap: vnetid 6 parent cnmac1 txprio packet rxprio outer groups: vlan media: Ethernet autoselect (1000baseT full-duplex) status: active inet 192.168.36.1 netmask 0xff00 broadcast 192.168.36.255 A particular ktrace/kdump revealed this: 47271 tcpdump RET fstat 0 47271 tcpdump CALL mmap(0,0x1,0x3,0x1002,-1,0) 47271 tcpdump RET mmap 252174057472/0x3ab6bec000 47271 tcpdump CALL fcntl(1,F_ISATTY) 47271 tcpdump RET fcntl 1 47271 tcpdump PSIG SIGBUS SIG_DFL code BUS_ADRALN<1> addr=0x39f0f3c04c trapno=0 I assume the fcntl(... could be an isatty(3). >How-To-Repeat: No idea, I only upgraded this router today and added some networking including wireguard tunnels. >Fix: Not provided. There is mention in comments at: /usr/src/sys/arch/mips64/mips64/trap.c under BUS_ADRALN that this may be an unaligned memory access. dmesg: OpenBSD 6.9 (GENERIC.MP) #551: Sun Apr 18 03:06:59 MDT 2021 dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP real mem = 536870912 (512MB) avail mem = 521322496 (497MB) random: good seed from bootblocks mainbus0 at root: board 20004 rev 0.16, model CN3xxx/CN5xxx cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way clock0 at mainbus0: int 5 octcrypto0 at mainbus0 iobus0 at mainbus0 simplebus0 at iobus0: "soc" octciu0 at simplebus0 octsmi0 at simplebus0 octpip0 at simplebus0 octgmx0 at octpip0 interface 0 cnmac0 at octgmx0: port 0 RGMII, address fc:ec:da:04:8d:68 atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2 cnmac1 at octgmx0: port 1 RGMII, address fc:ec:da:04:8d:69 atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2 cnmac2 at octgmx0: port 2 RGMII, address fc:ec:da:04:8d:6a atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2 com0 at simplebus0: ns16550a, 64 byte fifo com0: console dwctwo0 at iobus0 base 0x118006800 irq 56 usb0 at dwctwo0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev 2.00/1.00 addr 1 octrng0 at iobus0 base 0x14000 irq 0 umass0 at uhub0 port 1 configuration 1 interface 0 " UDinfo UF2 4GB" rev 2.00/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: <, UDinfo UF2 4GB, PMAP> removable serial.13fe420077C9177D2781 sd0: 3824MB, 512 bytes/sector, 7831552 sectors vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on sd0a (d5ffec0c72cad730.a) swap on sd0b dump on sd0b WARNING: CHECK AND RESET THE DATE! usbdevs: Controller /dev/usb0: addr 01: : Octeon, DWC2 root hub high speed, self powered, config 1, rev 1.00 driver: uhub0 addr 02: 13fe:4200 , UDinfo UF2 4GB high speed, power 200 mA, config 1, rev 1.00, iSerial 070877C9177D2781 driver: umass0 pcidump: acpidump:
Re: Lenovo Thinkstation Intel Xeon - Fails to boot
Den mån 3 maj 2021 kl 08:36 skrev jeanfrancois : > AMD released their 64 bit extensions with the FX series back in 2005(?), > which Intel later adopted. > Intel had their own 64 bit architecture with itanium, which could run 32 > bit i386 Software, but that was, iirc, emulation. https://ark.intel.com/content/www/us/en/ark/products/123547/intel-xeon-silver-4110-processor-11m-cache-2-10-ghz.html says the Xeon Silver 4110 supports 64bit mode (without being an Itanium), so please do try the amd64 version of OpenBSD. -- May the most significant bit of your life be positive.
Re: Lenovo Thinkstation Intel Xeon - Fails to boot
Le 03/05/2021 à 06:41, Florian Viehweger a écrit : Hi Jean-François, AMD released their 64 bit extensions with the FX series back in 2005(?), which Intel later adopted. Intel had their own 64 bit architecture with itanium, which could run 32 bit i386 Software, but that was, iirc, emulation. greetings, Florian Viehweger Le 02/05/2021 à 22:09, Florian Viehweger a écrit : Hi, Does someone have hints on this issue please ? The type of server is a Levono Thinkstation P720 fit with Intel Silver Xeon Silver 4110 processor. I installed the i386 OpenBSD 6.8. I can have a shell from finishing the install process, this works. It doesn't boot in single user mode, but can boot with boot -c option into user kernel configuration. this CPU has 64 bit support, please test amd64 OpenBSD 6.9 instead of i386 and report back. -- greetings, Florian Viehweger Le 02/05/2021 à 22:09, Florian Viehweger a écrit : Hi, Does someone have hints on this issue please ? The type of server is a Levono Thinkstation P720 fit with Intel Silver Xeon Silver 4110 processor. I installed the i386 OpenBSD 6.8. I can have a shell from finishing the install process, this works. It doesn't boot in single user mode, but can boot with boot -c option into user kernel configuration. this CPU has 64 bit support, please test amd64 OpenBSD 6.9 instead of i386 and report back.
