Re: Wallpaper artwork created for OpenBSD
On 2018-11-09, Alex wrote: > Hi Stuart, Thanks for your suggestions. I will remove them. Mingjing Thank you. For reference, the general policy for artwork is on https://www.openbsd.org/art1.html (ads on the app are a problem with the "do not make profit from them").
Re: Wallpaper artwork created for OpenBSD
On 星期五, 2018-11-09 17:03:56 Stuart Henderson wrote On 2018-11-09, Alex wrote: > Hi Stuart, Thanks for your suggestions. I will remove them. Mingjing Thank you. For reference, the general policy for artwork is on https://www.openbsd.org/art1.html (ads on the app are a problem with the "do not make profit from them"). Yes. I totally agreed with your point. They were removed from the Play Store. Thanks Mingjing
latest iridium-browser on amd64-current core dumps
Unfortunatelly I have to meet deadlines, can't investigate further into the following: $ pkg_info | grep iridium iridium-2018.11.70 Iridium browser $ /usr/local/bin/iridium [1109/094309.877362:ERROR:icu_util.cc(172)] Invalid file descriptor to ICU data received. Trace/BPT trap (core dumped) This happens disregarding if started with or without "--enable-unveil". Will this be solved with the next snapshots? (dmesg below) Sorry - but today I am unable to provide more information. Best, STEFAN OpenBSD 6.4-current (GENERIC.MP) #425: Sun Nov 4 21:32:53 MST 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17079074816 (16287MB) avail mem = 16552189952 (15785MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb500 (35 entries) bios0: vendor American Megatrends Inc. version "1.03.06" date 06/25/2014 bios0: Notebook W65_67SZ acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT ASF! SSDT SSDT SSDT MCFG HPET SSDT SSDT SSDT DMAR acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(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-4210M CPU @ 2.60GHz, 3093.33 MHz, 06-3c-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,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 MHz, 06-3c-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,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 MHz, 06-3c-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,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 MHz, 06-3c-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,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (RP01) acpiprt2 at acpi0: bus 3 (RP03) acpiprt3 at acpi0: bus 4 (RP04) acpiprt4 at acpi0: bus 1 (P0P2) acpiprt5 at acpi0: bus -1 (P0PA) acpiprt6 at acpi0: bus -1 (P0PB) acpiprt7 at acpi0: bus 1 (PEG0) acpiec0 at acpi0 acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpitz0 at acpi0: critical temperature is 120 degC acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x acpicmos0 at acpi0 "PNPC000" at acpi0 not configured acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB acpibtn2 at acpi0: LID0 acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 model "BAT" serial 0001 type LION oem "Notebook" "PNP0C14" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: LCD0 cpu0: Enhanced
Re: latest iridium-browser on amd64-current core dumps
Quick update: Am 09.11.18 um 10:25 schrieb Stefan Wollny: [ ... ] > > Will this be solved with the next snapshots? > Short answer: No! $ dmesg | grep Open OpenBSD 6.4-current (GENERIC.MP) #427: Fri Nov 9 01:09:51 MST 2018 (new full dmesg at the end) $ pkg_info | grep iridium iridium-2018.11.70 Iridium browser $ iridium --version Iridium 2018.11 $ /usr/local/bin/iridium [1109/150939.014189:ERROR:icu_util.cc(172)] Invalid file descriptor to ICU data received. Trace/BPT trap (core dumped) $ doas gdb /usr/local/iridium/iridium iridium.core [ ... ] Core was generated by `iridium'. Program terminated with signal 5, Trace/breakpoint trap. Reading symbols from /usr/lib/libpthread.so.25.1...done. Loaded symbols for /usr/lib/libpthread.so.25.1 Loaded symbols for /usr/local/iridium/iridium Reading symbols from /usr/X11R6/lib/libX11.so.16.1...done. Loaded symbols for /usr/X11R6/lib/libX11.so.16.1 Reading symbols from /usr/X11R6/lib/libX11-xcb.so.2.0...done. Loaded symbols for /usr/X11R6/lib/libX11-xcb.so.2.0 Reading symbols from /usr/X11R6/lib/libxcb.so.4.0...done. Loaded symbols for /usr/X11R6/lib/libxcb.so.4.0 Reading symbols from /usr/X11R6/lib/libXcomposite.so.4.0...done. Loaded symbols for /usr/X11R6/lib/libXcomposite.so.4.0 Reading symbols from /usr/X11R6/lib/libXcursor.so.5.0...done. Loaded symbols for /usr/X11R6/lib/libXcursor.so.5.0 Reading symbols from /usr/X11R6/lib/libXdamage.so.4.0...done. Loaded symbols for /usr/X11R6/lib/libXdamage.so.4.0 Reading symbols from /usr/X11R6/lib/libXext.so.13.0...done. Loaded symbols for /usr/X11R6/lib/libXext.so.13.0 Reading symbols from /usr/X11R6/lib/libXfixes.so.6.0...done. Loaded symbols for /usr/X11R6/lib/libXfixes.so.6.0 Reading symbols from /usr/X11R6/lib/libXi.so.12.1...done. Loaded symbols for /usr/X11R6/lib/libXi.so.12.1 Reading symbols from /usr/X11R6/lib/libXrender.so.6.0...done. Loaded symbols for /usr/X11R6/lib/libXrender.so.6.0 Reading symbols from /usr/X11R6/lib/libXtst.so.11.0...done. Loaded symbols for /usr/X11R6/lib/libXtst.so.11.0 Reading symbols from /usr/local/lib/libgmodule-2.0.so.4200.7...done. Loaded symbols for /usr/local/lib/libgmodule-2.0.so.4200.7 Reading symbols from /usr/local/lib/libgobject-2.0.so.4200.7...done. Loaded symbols for /usr/local/lib/libgobject-2.0.so.4200.7 Reading symbols from /usr/local/lib/libglib-2.0.so.4201.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.4201.0 Reading symbols from /usr/local/lib/libintl.so.6.0...done. Loaded symbols for /usr/local/lib/libintl.so.6.0 Reading symbols from /usr/local/lib/libpcre.so.3.0...done. Loaded symbols for /usr/local/lib/libpcre.so.3.0 Reading symbols from /usr/local/lib/libsmime3.so.53.0...done. Loaded symbols for /usr/local/lib/libsmime3.so.53.0 Reading symbols from /usr/local/lib/libnss3.so.53.0...done. Loaded symbols for /usr/local/lib/libnss3.so.53.0 Reading symbols from /usr/local/lib/libnssutil3.so.53.0...done. Loaded symbols for /usr/local/lib/libnssutil3.so.53.0 Reading symbols from /usr/local/lib/libplds4.so.24.0...done. Loaded symbols for /usr/local/lib/libplds4.so.24.0 Reading symbols from /usr/local/lib/libplc4.so.24.0...done. Loaded symbols for /usr/local/lib/libplc4.so.24.0 Reading symbols from /usr/local/lib/libnspr4.so.24.0...done. Loaded symbols for /usr/local/lib/libnspr4.so.24.0 Reading symbols from /usr/local/lib/libcups.so.6.4...done. Loaded symbols for /usr/local/lib/libcups.so.6.4 Reading symbols from /usr/local/lib/libgio-2.0.so.4200.7...done. Loaded symbols for /usr/local/lib/libgio-2.0.so.4200.7 Reading symbols from /usr/lib/libexpat.so.12.0...done. Loaded symbols for /usr/lib/libexpat.so.12.0 Reading symbols from /usr/local/lib/libdbus-1.so.11.2...done. Loaded symbols for /usr/local/lib/libdbus-1.so.11.2 Reading symbols from /usr/lib/libevent.so.4.1...done. Loaded symbols for /usr/lib/libevent.so.4.1 Reading symbols from /usr/lib/libm.so.10.1...done. Loaded symbols for /usr/lib/libm.so.10.1 Reading symbols from /usr/lib/libz.so.5.0...done. Loaded symbols for /usr/lib/libz.so.5.0 Reading symbols from /usr/local/lib/libuuid.so.14.0...done. Loaded symbols for /usr/local/lib/libuuid.so.14.0 Reading symbols from /usr/X11R6/lib/libdrm.so.7.6...done. Loaded symbols for /usr/X11R6/lib/libdrm.so.7.6 Reading symbols from /usr/X11R6/lib/libXss.so.6.0...done. Loaded symbols for /usr/X11R6/lib/libXss.so.6.0 Reading symbols from /usr/X11R6/lib/libXrandr.so.7.1...done. Loaded symbols for /usr/X11R6/lib/libXrandr.so.7.1 Reading symbols from /usr/local/lib/libatk-1.0.so.21809.2...done. Loaded symbols for /usr/local/lib/libatk-1.0.so.21809.2 Reading symbols from /usr/local/lib/libatk-bridge-2.0.so.0.0...done. Loaded symbols for /usr/local/lib/libatk-bridge-2.0.so.0.0 Reading symbols from /usr/local/lib/libatspi.so.0.2...done. Loaded symbols for /usr/local/lib/libatspi.so.0.2 Reading symbols from /usr/local/lib/libpangocairo-1.0.so.3800.1...done. Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.3800.1 Reading symbols from /usr/local/lib/libpangoft2-
Re: latest iridium-browser on amd64-current core dumps
Additional info from gdb: [ ... ] > Loaded symbols for /usr/local/lib/libgmp.so.10.0 > Reading symbols from /usr/libexec/ld.so...done. > Loaded symbols for /usr/libexec/ld.so > #0 0x1e4c44b648e5 in ChromeMain () from /usr/local/iridium/iridium > (gdb) bt #0 0x134869f648e5 in ChromeMain () from /usr/local/iridium/iridium #1 0x13486c445689 in ChromeMain () from /usr/local/iridium/iridium #2 0x13486c44fc52 in ChromeMain () from /usr/local/iridium/iridium #3 0x13486c444ffe in ChromeMain () from /usr/local/iridium/iridium #4 0x134869f6328b in ChromeMain () from /usr/local/iridium/iridium #5 0x134869f63056 in _start () from /usr/local/iridium/iridium #6 0x in ?? () (gdb) l 1 /* $OpenBSD: boot.c,v 1.16 2018/10/23 04:01:45 guenther Exp $ */ 2 3 /* 4* Copyright (c) 1998 Per Fogelstrom, Opsycon AB 5* 6* Redistribution and use in source and binary forms, with or without 7* modification, are permitted provided that the following conditions 8* are met: 9* 1. Redistributions of source code must retain the above copyright 10 *notice, this list of conditions and the following disclaimer. (gdb) bt full #0 0x134869f648e5 in ChromeMain () from /usr/local/iridium/iridium No symbol table info available. #1 0x13486c445689 in ChromeMain () from /usr/local/iridium/iridium No symbol table info available. #2 0x13486c44fc52 in ChromeMain () from /usr/local/iridium/iridium No symbol table info available. #3 0x13486c444ffe in ChromeMain () from /usr/local/iridium/iridium No symbol table info available. #4 0x134869f6328b in ChromeMain () from /usr/local/iridium/iridium No symbol table info available. #5 0x134869f63056 in _start () from /usr/local/iridium/iridium No symbol table info available. #6 0x in ?? () No symbol table info available. (gdb) f #0 0x134869f648e5 in ChromeMain () from /usr/local/iridium/iridium (gdb) info f Stack level 0, frame at 0x7f7f62e0: rip = 0x134869f648e5 in ChromeMain; saved rip 0x13486c445689 called by frame at 0x7f7f6400 Arglist at 0x7f7f62c8, args: Locals at 0x7f7f62c8, Previous frame's sp is 0x7f7f62e0 Saved registers: rbp at 0x7f7f62d0, rip at 0x7f7f62d8 (gdb) Any other info I can provide? Best, STEFAN
Re: "relay as" domain rewrite in new smtpd.conf syntax
Gilles Chehade writes: > On Thu, Nov 08, 2018 at 12:40:51PM -0500, Allan Streib wrote: >> Prior to 6.4, in smtpd.conf(5), the relay directive supported the "as" >> parameter: >> >> If the as parameter is specified, smtpd(8) will rewrite the sender >> advertised in the SMTP session. address may be a user, a domain >> prefixed with "@", or an email address, causing smtpd(8) to rewrite >> the user-part, the domain-part, or the entire address, respectively. >> >> In the new smtpd.conf(5) syntax, how is that rewrite achieved, >> specifically the "@" prefix behavior to rewrite the domain part? >> > > The relay delivery methods also support additional options: > >[...] > > mail-from mailaddr > Use mailaddr as the MAIL FROM address within the SMTP > transaction. > > > so this would be something like: > >action relay_00 relay mail-from "@foobar.org" > >match [...] action relay_00 Thanks! I didn't realize that the mail-from option would support the same forms as the old "as" parameter. Allan
Re: xfce4-terminal crash in openbsd 6.4
Updating with the solution for reference: I was also seeing this problem with LibreOffice which wouldn't even launch past the splash screen. Running pkg_add -u didn't fix it. Un- and re-installing libreoffice did fix it. I discovered this by installing inkscape, which must be providing some dependency. When I removed inkscape and also ran "pkg_delete -avV" the problem returned. Then removing libreoffice, followed by another "pkg_delete -avV", and reinstalling libreoffice made it work again. And probably I should have tried that before posting. Somehow, installing inkscape fixed it. On 11-07 09:53:32-0700, Luke A. Call wrote: > This happens in OpenBSD 6.4 but I'm fairly confident didn't happen in > 6.3 (definitely didn't happen at some point in the recent past; I don't > recall if I tried this while I was using snapshots between 6.3 and 6.4): > > If I start xfce4-terminal (either from xterm or the xfce4 "Run Program" > dialog), and if I try to access the menus (either by clicking or alt-__ > key combination like alt-e), then xfce4-terminal exits. In the xterm > window, I can see that xfce4-terminal has reported this error before > exiting: > > Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion > failed (error == NULL): Failed to load > /usr/local/share/icons/Adwaita/16x16/status/image-missing.png: > Unrecognized image file format (gdk-pixbuf-error-quark, 3) > > (Alternatively, if there is a way to do a text search across the > scrollback buffer in xterm, that would let me stop my intermittent use > of xfce4-terminal, but I haven't found that. I know konsole has that > search feature but it has many more binary dependencies that get > installed with it.) > > Ending with my dmesg which includes content farther down indicating > the upgrade to 6.4. Thanks much! > > OpenBSD 6.4-beta (GENERIC.MP) #327: Wed Sep 26 12:52:56 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 16033533952 (15290MB) > avail mem = 15538348032 (14818MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf90 (49 entries) > bios0: vendor American Megatrends Inc. version "204" date 11/20/2014 > bios0: ASUSTeK COMPUTER INC. X550ZA > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT ECDT MCFG MSDM HPET UEFI SSDT SSDT CRAT > SSDT SSDT SSDT SSDT > acpi0: wakeup devices LOM_(S4) SBAZ(S4) ECIR(S4) OHC1(S4) EHC1(S4) OHC2(S4) > EHC2(S4) OHC3(S4) EHC3(S4) OHC4(S4) XHC0(S4) XHC1(S4) ODD8(S3) GLAN(S4) > LID_(S5) SLPB(S4) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 16 (boot processor) > cpu0: AMD A10-7400P Radeon R6, 10 Compute Cores 4C+6G, 2496.40 MHz, 15-30-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,ITSC,FSGSBASE,BMI1,XSAVEOPT > cpu0: 96KB 64b/line 3-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line > 16-way L2 cache > cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, IBE > cpu1 at mainbus0: apid 17 (application processor) > cpu1: AMD A10-7400P Radeon R6, 10 Compute Cores 4C+6G, 2495.34 MHz, 15-30-01 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,ITSC,FSGSBASE,BMI1,XSAVEOPT > cpu1: 96KB 64b/line 3-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line > 16-way L2 cache > cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 18 (application processor) > cpu2: AMD A10-7400P Radeon R6, 10 Compute Cores 4C+6G, 2495.34 MHz, 15-30-01 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,ITSC,FSGSBASE,BMI1,XSAVEOPT > cpu2: 96KB 64b/line 3-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line > 16-way L2
Re: Reduced network performance since installing 6.4
misc@, I am happy to report the problem disappeared without the tweaks mentioned in my last email upon a cold reboot. In fact, I am now observing performance gains over 6.3. Out of curiosity, is it possible that warm reboots do not completely initialize everything cold reboots do, either at the OS level or lower? Sincerely, Colton Lewis On Sun, Nov 4, 2018 at 7:23 PM Colton Lewis wrote: > > misc@, > > Since installing 6.4, I have noticed a significant reduction in download > speeds > during ordinary desktop use with my wifi adapter on the order of > a 75% decrease and a much greater frequency of stalled downloads. > > I regret I am at a loss to describe the problem in much greater > detail, but I have > been tweaking system parameters and have discovered that setting > net.inet.tcp.always_keepalive=1 results in an improvement, gaining back much > of the lost performance. > > Does anyone have an idea what my issue might be? > > athn0 at pci6 dev 0 function 0 "Atheros AR9287" rev 0x01: apic 8 int 17 > athn0: AR9287 rev 2 (2T2R), ROM rev 4, address c0:25:e9:10:9f:a7 > > -- > Sincerely, > Colton Lewis
Re: Severe clock problems with OpenBSD VM on OpenBSD Host
Here is an update on the situation: I installed -current on this VM, clean install, and the ntpd error does not happen anymore. But the clock issues remain, even with ntpd running. The ntpd starts without complaints now, and seems to be running with its regular processes: _ntp 70093 0.0 0.5 920 2540 ?? S wrote: > Hi everyone, > > I am having an issue where an OpenBSD VM running on vmd is having > serious clock skew issues. > > I am relatively new to OpenBSD, so I am not sure how to properly debug > this. What I hope is that I can provide a good amount of data and folks > here can give me some hints and ask me for additional information to > get to the root cause of this. > > So first some facts and symptoms: > > - Both Host and Guest are running OpenBSD 6.4. The host runs GENERIC.MP > and the guest GENERIC. > - The host runs 50 guests, all OpenBSD (openbsd.amsterdam) > - Only this VM is having this clock issue (is this correct, or were > there others?) > > - The guest has kern.timecounter.hardware=tsc > - The time on the VM was set with rdate a couple of days ago, and as of > now the VM is running about 4 hours behind. > - ntpd is running (main process, dns engine, ntp engine) > - when started or restarted, ntpd complains about "pipe write error > (from main): No such file or directory" but does seem to start > > - I just ran rdate nl.pool.ntp.org and the date was properly updated > - One minute after running rdate, the clock is already 7 seconds slow > > - The guest also has some severe networking issues. often I cannot type > more than a few characters before a ~15 second delays happens. > Interactive typing is difficult. > - I can SSH into the Host and have none of these issues, ruling out > connectivity issues between me (Toronto) and the Host (Amsterdam) > > It would be easy to blame this on NTPd, which does have an unexplained > error message. However, I think even without running NTPd, the clock > skew should not be this extreme. > > Somehow I have a gut feeling that the clock issues and the networking > issues are related. > > I am root on the VM but I am not on the host. I do have vmctl access. > However, the host admin is friendly (Hi Mischa) and is happy to help to > debug this issue. > > I tried to ktrace ntpd to get more insight in the "pipe write error > (from main): No such file or directory" error but I did not get useful > info out of it. This may be because of my unfamiliarity with those > tools. > > Help appreciated :-) > > S. > >
Re: Severe clock problems with OpenBSD VM on OpenBSD Host
I recently built a new vmm with 6.4 and noticed this morning that it had a clock problem too, however all my other vmm's didn't. FWIW, I don't have an issue with timekeeping on VMM clients on 6.4: # uptime 4:40PM up 4 days, 22:29, 1 user, load averages: 0.00, 0.00, 0.00 # ntpctl -s all 1/1 sensors valid, clock synced, stratum 1 sensor wt gd st next poll offset correction vmmci0 * 1 1 0 15s 15s-0.227ms 0.000ms I have same kern.timecounter values as you. However I rely on NTP of the host to keep good time. The clients are simply: # ntpd.conf for our VMs # sensor * While ntpd.conf for the host is the default: # servers pool.ntp.org sensor * constraints from "https://www.google.com"; And keeps time within a millisecond or so: $ ntpctl -s all 4/4 peers valid, constraint offset 0s, clock synced, stratum 4 peer wt tl st next poll offset delay jitter 69.17.158.101 from pool pool.ntp.org 1 10 3 207s 329s-0.050ms72.067ms 7.430ms 72.38.129.202 from pool pool.ntp.org 1 10 2 285s 317s 1.819ms80.729ms 2.943ms 198.50.139.209 from pool pool.ntp.org 1 10 2 278s 322s-5.043ms87.529ms 8.652ms 207.34.48.31 from pool pool.ntp.org * 1 10 3 1524s 1554s-0.425ms30.868ms 3.349ms Host CPU is old AMD: OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD E-450 APU with Radeon(tm) HD Graphics, 6421.62 MHz, 14-02-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, IBE --John
Re: Severe clock problems with OpenBSD VM on OpenBSD Host
One more update .. when I look at `ntpctl -sa` now, it does not show any "peer not valid" errors. However, it still rons a good 14 seconds behind. And it gets worse every minute. # ntpctl -sa 4/4 peers valid, 1/1 sensors valid, constraint offset -115s (4 errors), clock unsynced peer wt tl st next poll offset delay jitter 213.154.236.182 from pool pool.ntp.org 1 10 2 3080s 3153s 2298.229ms 3.482ms 1.359ms 83.98.201.134 from pool pool.ntp.org 1 10 2 3154s 3220s 2764.077ms 2.686ms 0.703ms 217.23.3.234 from pool pool.ntp.org 1 10 2 2952s 3020s 2682.053ms 2.880ms 0.528ms 185.92.220.131 from pool pool.ntp.org 1 10 2 2999s 3076s 2266.144ms 2.287ms 0.937ms sensor wt gd st next poll offset correction vmmci0 1 1 06s 15s 14607.577ms 0.000ms On Fri, Nov 9, 2018 at 7:18 PM Stefan Arentz wrote: > Here is an update on the situation: > > I installed -current on this VM, clean install, and the ntpd error does > not happen anymore. But the clock issues remain, even with ntpd running. > > > The ntpd starts without complaints now, and seems to be running with its > regular processes: > > _ntp 70093 0.0 0.5 920 2540 ?? S ntp engine (ntpd) > _ntp 51912 0.0 0.5 736 2464 ?? Isp7:04PM0:00.01 ntpd: > dns engine (ntpd) > root 46674 0.0 0.3 792 1640 ?? S /usr/sbin/ntpd -s > > > I have set kern.timecounter.hardware to tsc: > > # systctl kern.timecounter > kern.timecounter.tick=1 > kern.timecounter.timestepwarnings=0 > kern.timecounter.hardware=tsc > kern.timecounter.choice=i8254(0) tsc(-1000) dummy(-100) > > > trondd asked for the output of ntpctl -sa, which shows me the following: > > # ntpctl -sa > 0/4 peers valid, 1/1 sensors valid, constraint offset -3s, clock unsynced, > clock offset is 12771.710ms > > peer >wt tl st next poll offset delay jitter > 213.154.236.182 from pool pool.ntp.org > 1 2 - 152s 300s peer not valid > 83.98.201.134 from pool pool.ntp.org > 1 2 - 152s 300s peer not valid > 217.23.3.234 from pool pool.ntp.org > 1 2 - 152s 300s peer not valid > 185.92.220.131 from pool pool.ntp.org > 1 2 - 152s 300s peer not valid > > sensor >wt gd st next poll offset correction > vmmci0 > 1 1 0 15s 15s 18001.915ms 0.000ms > > > I am not sure how to interpret these numbers. I also don't understand the > "peer not valid" messages here. I have another OpenBSD VM which has the > exact same ntpd.conf and it does not complain about any of the peers. > > > I think my conclusion is that this is not something that can be solved at > the VM level. > > S. > > > On Sat, Nov 3, 2018 at 8:10 PM Stefan Arentz > wrote: > >> Hi everyone, >> >> I am having an issue where an OpenBSD VM running on vmd is having >> serious clock skew issues. >> >> I am relatively new to OpenBSD, so I am not sure how to properly debug >> this. What I hope is that I can provide a good amount of data and folks >> here can give me some hints and ask me for additional information to >> get to the root cause of this. >> >> So first some facts and symptoms: >> >> - Both Host and Guest are running OpenBSD 6.4. The host runs GENERIC.MP >> and the guest GENERIC. >> - The host runs 50 guests, all OpenBSD (openbsd.amsterdam) >> - Only this VM is having this clock issue (is this correct, or were >> there others?) >> >> - The guest has kern.timecounter.hardware=tsc >> - The time on the VM was set with rdate a couple of days ago, and as of >> now the VM is running about 4 hours behind. >> - ntpd is running (main process, dns engine, ntp engine) >> - when started or restarted, ntpd complains about "pipe write error >> (from main): No such file or directory" but does seem to start >> >> - I just ran rdate nl.pool.ntp.org and the date was properly updated >> - One minute after running rdate, the clock is already 7 seconds slow >> >> - The guest also has some severe networking issues. often I cannot type >> more than a few characters before a ~15 second delays happens. >> Interactive typing is difficult. >> - I can SSH into the Host and have none of these issues, ruling out >> connectivity issues between me (Toronto) and the Host (Amsterdam) >> >> It would be easy to blame this on NTPd, which does have an unexplained >> error message. However, I think even without running NTPd, the clock >> skew should not be this extreme. >> >> Somehow I have a gut feeling that the clock issues and the networking >> issues are related. >> >> I am root on the VM but I am not on the host. I do have vmctl access. >> However, the host admin is friendly (Hi Mischa) and is happy to help to >> debug this issue. >> >> I tried to ktrace ntpd to get more insight in the "pipe write error >> (from main): No such file or directory" error but
Re: Severe clock problems with OpenBSD VM on OpenBSD Host
Oh that is interesting ... # ntpctl -s all 0/1 sensors valid, clock unsynced sensor wt gd st next poll offset correction vmmci0 1 0 0 13s 15s - sensor not valid - sensor not valid - why would that happen? I have no idea about the inner workings of vmd .. but maybe this host has so many VMs that it is hitting some limit? S. On Fri, Nov 9, 2018 at 7:43 PM wrote: > > >I recently built a new vmm with 6.4 and noticed this morning that it > > had > >a clock problem too, however all my other vmm's didn't. > > > > FWIW, I don't have an issue with timekeeping on VMM clients on 6.4: > > # uptime > 4:40PM up 4 days, 22:29, 1 user, load averages: 0.00, 0.00, 0.00 > # ntpctl -s all > 1/1 sensors valid, clock synced, stratum 1 > > sensor > wt gd st next poll offset correction > vmmci0 > * 1 1 0 15s 15s-0.227ms 0.000ms > > I have same kern.timecounter values as you. However I rely on NTP of > the host > to keep good time. The clients are simply: > > # ntpd.conf for our VMs > # > sensor * > > While ntpd.conf for the host is the default: > > # > servers pool.ntp.org > sensor * > constraints from "https://www.google.com"; > > And keeps time within a millisecond or so: > > $ ntpctl -s all > 4/4 peers valid, constraint offset 0s, clock synced, stratum 4 > > peer > wt tl st next poll offset delay jitter > 69.17.158.101 from pool pool.ntp.org > 1 10 3 207s 329s-0.050ms72.067ms 7.430ms > 72.38.129.202 from pool pool.ntp.org > 1 10 2 285s 317s 1.819ms80.729ms 2.943ms > 198.50.139.209 from pool pool.ntp.org > 1 10 2 278s 322s-5.043ms87.529ms 8.652ms > 207.34.48.31 from pool pool.ntp.org > * 1 10 3 1524s 1554s-0.425ms30.868ms 3.349ms > > > > Host CPU is old AMD: > > OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD E-450 APU with Radeon(tm) HD Graphics, 6421.62 MHz, 14-02-00 > cpu0: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC > cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 16-way L2 cache > cpu0: 8 4MB entries fully associative > cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully > associative > cpu0: smt 0, core 0, package 0 > cpu0: apic clock running at 199MHz > cpu0: mwait min=64, max=64, IBE > > > --John > >
Issue with pkg_add against snapshots
Example: https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/compton-0.1_beta2p2.tgz: ftp: SSL write error: handshake failed: error:1404C044:SSL routines:ST_OK:internal error signify: gzheader truncated Basically all my packages are showing this after a doas pkg_add -uUvVm Checking the link it resolves, tried another mirror, smae thing... Ken
Re: Severe clock problems with OpenBSD VM on OpenBSD Host
On Wed, Nov 07, 2018 at 06:40:20PM +, Gareth Ansell scribbled:
# Hi, I can confirm that this is also happening on my VM, also hosted at
# openbsd.amsterdam.
# Gareth
Same here, and none of the tricks I was finding worked. I was also
unsatisfied with the idea of running rdate or restarting ntpd often
enough to keep things in sync. Making use of the vmmci(4) timedelta
sensor, I found and modified a piece of existing code by Ted U. to
work around this problem until someone far smarter than I figures out
a proper solution.
Attached, but linked as well in case the attachment doesn't make it.
https://slite.zenbsd.net/~jontow/vmtimed.c
Neither perfect nor desirable, but workable! It makes a lot of
adjustments and has been doing an ok job so far. Doesn't seem to
perfectly keep the clock in a synced state according to "ntpctl -sa".
Here's what it looks like running, and these are the sorts of deltas
it regularly sees and applies.
Nov 6 00:54:43 frea vmtimed: fixing time! -1.152683
Nov 6 00:56:11 frea vmtimed: fixing time! -1.045395
Nov 6 00:58:08 frea vmtimed: fixing time! -1.236222
Here's "ntpctl -sa" as of right now:
4/4 peers valid, 1/1 sensors valid, constraint offset -198s (16 errors), clock
synced, stratum 1
peer
wt tl st next poll offset delay jitter
80.127.152.30 from pool pool.ntp.org
1 10 2 332s 3126s 705.111ms 5.394ms 0.974ms
195.242.98.57 from pool pool.ntp.org
1 10 2 245s 3183s 657.527ms 2.126ms 0.410ms
93.94.224.67 from pool pool.ntp.org
1 10 2 53s 3147s 687.997ms 1.931ms 0.532ms
95.211.212.5 from pool pool.ntp.org
1 10 2 2657s 3118s73.136ms 2.432ms 0.829ms
sensor
wt gd st next poll offset correction
vmmci0
* 1 1 08s 15s 689.722ms 0.000ms
-- Jonathan Towne
/*
* Original code by Ted Unangst
* https://https.www.google.com.tedunangst.com/flak/post/vmtimed
*
* Lightly modified by Jonathan Towne
* For use in vmd(8) hosted VMs using vmmci(4) timedelta sensor.
* Still probably works with VMware vmt(4), but untested.
* Works best in concert with ntpd(8) running normally.
*/
/* If time drifts more than +/- SENSITIVITY seconds, hard adjust */
#define SENSITIVITY 1
/* Check timedelta sensor value every SLEEPFOR seconds */
#define SLEEPFOR 15
#undef DEBUG
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
void
error(const char *msg)
{
syslog(LOG_DAEMON | LOG_ERR, "%s", msg);
exit(1);
}
int
findvmt0(void)
{
struct sensordev sdev;
size_t slen;
int mib[5];
int i;
mib[0] = CTL_HW;
mib[1] = HW_SENSORS;
for (i = 0; i < 20; i++) {
mib[2] = i;
slen = sizeof(sdev);
if (sysctl(mib, 3, &sdev, &slen, NULL, 0) == -1)
break;
if (strcmp(sdev.xname, "vmmci0") == 0)
return i;
if (strcmp(sdev.xname, "vmt0") == 0)
return i;
}
return -1;
}
void
timeloop(int vmt0)
{
struct sensor sensor;
size_t slen;
int mib[5];
struct timeval tv;
double delta;
mib[0] = CTL_HW;
mib[1] = HW_SENSORS;
mib[2] = vmt0;
mib[3] = SENSOR_TIMEDELTA;
mib[4] = 0;
while (1) {
slen = sizeof(sensor);
if (sysctl(mib, 5, &sensor, &slen, NULL, 0) == -1)
err(1, "sysctl");
delta = sensor.value / 10.0;
#ifdef DEBUG
printf("%f: timeloop()\n", delta);
#endif
if (delta < (-1 * SENSITIVITY) || delta > SENSITIVITY) {
syslog(LOG_DAEMON | LOG_NOTICE,
"fixing time! %f\n", delta);
if (gettimeofday(&tv, NULL) == -1)
error("gettimeofday");
tv.tv_sec -= delta;
if (settimeofday(&tv, NULL) == -1)
error("settimeofday");
}
sleep(SLEEPFOR);
}
}
int
main(int argc, char **argv)
{
int vmt0;
vmt0 = findvmt0();
if (vmt0 == -1)
error("can't find vmt0");
timeloop(vmt0);
}
Re: Severe clock problems with OpenBSD VM on OpenBSD Host
Oh that is interesting ... # ntpctl -s all 0/1 sensors valid, clock unsynced sensor wt gd st next poll offset correction vmmci0 1 0 0 13s 15s - sensor not valid - sensor not valid - why would that happen? I have no idea about the inner workings of vmd .. but maybe this host has so many VMs that it is hitting some limit? Don't forget that ntpd requires numerous polling cycles (at 15 seconds each) to convince itself about how reliable it's time sources are. Give it 5 minutes after restart, or even longer, before deciding for yourself that it is not going to sync. Another reason it may not sync is that the client current time is "too far away" from the external ntp time sources. You need to jump the time manually to fix that. --John
Re: Issue with pkg_add against snapshots
Ken M writes: > Example: > > https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/compton-0.1_beta2p2.tgz: > ftp: SSL write error: handshake failed: error:1404C044:SSL > routines:ST_OK:internal error > signify: gzheader truncated > > Basically all my packages are showing this after a doas pkg_add -uUvVm > > Checking the link it resolves, tried another mirror, smae thing... > > Ken There was some error in libssl which has been already fixed. I did cvs up in /usr/src/lib/libssl and 'make install' in there to fix it. Also the HTTP mirrors should work too while new snapshot is made. timo
