Backlight on Dell Laptop not adjusting brightness
Hello, I've installed OpenBSD 6.4 on my Dell Latitude 7470 laptop, however I'm having no luck in adjust the brightness of the internal display's backlight. I've basically run into a dead diagnosing this issue and I'm hoping that I might be able to get some assistance and where to look next. Needless to say, I'm really keen to get this one sorted as it's putting quite the dint in my laptop's battery life. Here's what I've tried so far with NO impact on the backlight brightness ... $ xbacklight -display :0 -set 5 $ xbacklight -display :0 -get 5.00 $ wsconsctl display.brightness=5 display.brightness -> 5.00% This laptop is essentially all Intel Skylake under the hood some I'm wondering why it's not playing nice like on the Lenovo / ThinkPads. Below is my dmesg and also Xorg.0.log. I'd really appreciate any advice on what I can try next, it's my first time running OpenBSD as my main system and I'm really enjoying it so far. Thanks in advance, Paul Swanson *** dmesg *** OpenBSD 6.4 (GENERIC.MP) #3: Thu Dec 20 19:19:32 CET 2018 r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8460333056 (8068MB) avail mem = 8194650112 (7815MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xeb460 (106 entries) bios0: vendor Dell Inc. version "1.20.3" date 08/20/2018 bios0: Dell Inc. Latitude E7470 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT LPIT SSDT SSDT SSDT DBGP DBG2 SSDT UEFI SSDT SSDT SLIC TCPA DMAR ASF! BGRT acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) 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-6300U CPU @ 2.40GHz, 2095.64 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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 23MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2095.10 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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-127 acpihpet0 at acpi0: 2399 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus -1 (RP09) acpiprt5 at acpi0: bus -1 (RP10) acpiprt6 at acpi0: bus 2 (RP11) acpiprt7 at acpi0: bus -1 (RP12) acpiprt8 at acpi0: bus -1 (RP13) acpiprt9 at acpi0: bus -1 (RP01) acpiprt10 at acpi0: bus -1 (RP02) acpiprt11 at acpi0: bus -1 (RP03) acpiprt12 at acpi0: bus -1 (RP04) acpiprt13 at acpi0: bus 1 (RP05) acpiprt14 at acpi0: bus -1 (RP06) acpiprt15 at acpi0: bus -1 (RP07) acpiprt16 at acpi0: bus -1 (RP08) acpiprt17 at acpi0: bus -1 (RP17) acpiprt18 at acpi0: bus -1 (RP18) acpiprt19 at acpi0: bus -1 (RP19) acpiprt20 at acpi0: bus -1 (RP20) acpiprt21 at acpi0: bus -1 (RP14) acpiprt22 at acpi0: bus -1 (RP15) acpiprt23 at acpi0: bus -1 (RP16) acpiec0 at acpi0 acpiec at acpi0 not configured acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PG00, resource for PEG0 acpipwrres1 at acpi0: PG01, resource for PEG1 acpipwrres2 at acpi0: PG02, resource for PEG2 acpipwrres3 at acpi0: WRST acpipwrres4 at acpi0: WRST acpipwrres5 at acpi0: WRST acpipwrres6 at acpi0: WRST acpipwrres7 at acpi0: WRST acpipwrres8 at acpi0: WRST acpipwrres9 at acpi0: WRST acpipwrres10 at acpi0: WRST acpipwrres11 at acpi0: WRST acpipwrres12 at acpi0: WRST acpipwrres13 at acpi0
Re: mirror download speed variation
On 2019-01-08, Janne Johansson wrote:
> Den tis 8 jan. 2019 kl 14:26 skrev Mihai Popescu :
>
>> So, I still have two questions about mirrors:
>> Can a mirror limit your download speed ?
>
> Sure they could, I don't think many do though.
>
>> Do a CDN url point to an existing mirror, or is it a diffeent server?
>
> Different servers, spread around the world and you get a dns response
> that is trying to be
> close to you.
>
However: the CDNs are just front-ending existing servers ("origin
servers"). If they have something in cache they'll be fast; if not
they have to fetch it themselves, often from the other side of the
world (further/slower than you'd get by picking a local mirror
that actually has the files).
snapshots in particular are often not going to be in their cache.
Re: Polish localization
> Don't know about the console, Sorry, I meant XTERM. >but to set (default) Polish keyboard in X >you need to run "setxkbmap pl", eg. in your .xsession file. Thank you, that is exactly what I need! I just want to be able to type and display Polish characters in X. Polish interfaces are not obligatorily needed. On Tue, 8 Jan 2019 17:29:22 +0200 Dumitru Moldovan wrote: > On Tue, Jan 08, 2019 at 02:52:21PM +, Radek wrote: > >Hello, > > > >I'm trying to set Polish locales in my new desktop (6.4/amd64, xenodm, > >WindowMaker). > > > > […] > > Don't know about the console, but to set (default) Polish keyboard in X > you need to run "setxkbmap pl", eg. in your .xsession file. > > To have Polish interface displayed (when available) you need to set LANG > and LC_MESSAGES as pl_PL.UTF-8 (not sure if both or only one of it). > Setting LC_ALL will do that too (and more). > > For Firefox there is a separate package for the Polish localization: > firefox-i18n-pl. For the other program, I don't know… Maybe nobody > localized it or the translation was removed? > > HTH! > -- radek
OpenOSPFD (6.4) "depend on" feature forces "type 1"
Hi!
My tests show that OpenOSPFD "depend on" feature forces "type 1"
overriding explicitly specified "type 2". For example this statement
can be used:
redistribute 0.0.0.0/0 set { type 2 } depend on carp1
(or keyword "default" can be used instead of prefix.)
Is it an intended behaviour or it's not?
Is this mail list appropriate for similar topics related to OpenOSPFD
at all or some other mail list should better be used instead?
System information:
* 6.4 GENERIC.MP#3 amd64
* syspatch up to 010_pcbopts installed
--
End of message. Next message?
Re: mirror download speed variation
On 08.01.19 14:24, Mihai Popescu wrote:
> Hi,
>
> I use to retrieve my install sets from a mirror, after I start the
> install procedure with minirootxx.fs
>
> Since the mirrors in my country are updating late and they have some
> problems in doing it right, I used ftp.hostserver.de. The download was
> working fine, something around 3MBps. This mirror started few days ago
> to provide me only with 64KBps constantly, no matter if i do http or
> https.
>
> I tried cdn.openbsd.org too, the download is super fast for me, like
> 30MBps. Still, sometimes it drops to 64KBps too, and stays there. I've
> read some articles about CDN networks, but I am not able to see the
> big picture.
>
> So, I still have two questions about mirrors:
> Can a mirror limit your download speed ?
> Do a CDN url point to an existing mirror, or is it a diffeent server?
>
> Thank you.
I can confirm Mihai's observation: http://ftp.hostserver.de is
remarkable slow for 2~3 weeks, even from within Frankfurt. From memory
I'd say from around the week before xmas download rates dropped to
20kb/s what usually was ~2mb/s. The Austrian mirror gave me this morning
~4mb/s! I fetch like so:
export SERVER=http://ftp2.eu.openbsd.org/pub/OpenBSD/snapshots
export ARCH=amd64
export VERSION=64wget -4 --no-proxy --no-cache --no-cookies --backups=2 \
$SERVER/$ARCH/BOOT{IA32,X64}.EFI \
$SERVER/$ARCH/INSTALL.$ARCH \
$SERVER/$ARCH/BUILDINFO \
$SERVER/$ARCH/index.txt \
$SERVER/$ARCH/SHA256{,.sig} \
$SERVER/$ARCH/bsd{,.mp,.rd} \
$SERVER/$ARCH/{base,comp,man}$VERSION.tgz \
$SERVER/$ARCH/x{base,font,serv,share}$VERSION.tgz
Re: mirror download speed variation
On 2019-01-09, Stefan Wollny wrote: > On 08.01.19 14:24, Mihai Popescu wrote: >> >> So, I still have two questions about mirrors: >> Can a mirror limit your download speed ? >> Do a CDN url point to an existing mirror, or is it a diffeent server? >> >> Thank you. > > I can confirm Mihai's observation: http://ftp.hostserver.de is > remarkable slow for 2~3 weeks, even from within Frankfurt. From memory > I'd say from around the week before xmas download rates dropped to > 20kb/s what usually was ~2mb/s. I'm currently getting 6.7MByte/s over v6 and 3.95MByte/s over v4 from ftp.hostserver.de to the UK. So it's not a global problem. As phessler said, send him traceroute and your source IP offlist.
Re: Odp.: mirror download speed variation
On 2019-01-08, Kamil Monticolo wrote: > There is small program that helps you determine the closest mirror: > > https://github.com/lukensmall/pkg_ping oh, this again. > I also wrote poor's man script to achieve the same: > > https://github.com/kmonticolo/OpenBSD/blob/master/testmirrors.sh > ping time to a mirror does not indicate what download speed you can expect from it.
Re: ubnt unfi stable from ports doesn??t start with rcctl but as root
On 2019-01-08, Bryan Vyhmeister wrote: > On Tue, Jan 08, 2019 at 03:27:39PM +0100, Thomas Huber wrote: >> just upgrade the Unifi Controller net/unifi/stable (version 5.8.30) from >> ports. >> The controller service doesn??t start wit rcctl(8) but works fine when >> running as root. >> My guess is that _unifi is not allowed to start monogd but don??t have a >> clue how to fix this... >> Does it matter if databases/mongo is install from ports or pkg? >> I installed all dependecies manually with pkg_add(1) >> >> Any idea where to look? any output from "rcctl -d start unifi"? anything in logs? > On my UniFi box (which is running -current and unifi-5.9.32), I also enabled > mongod to start at boot. > > rcctl enable mongod > rcctl enable unifi > > It has been running fine for me for years that way. > > Bryan > > That shouldn't be necessary, unifi starts mongod itself with its own dbpath/port/unixSocketPrefix/logpath.
Re: OpenOSPFD (6.4) "depend on" feature forces "type 1"
On Wed, Jan 09, 2019 at 10:47:21PM +0700, Igor Podlesny wrote:
> Hi!
>
> My tests show that OpenOSPFD "depend on" feature forces "type 1"
> overriding explicitly specified "type 2". For example this statement
> can be used:
>
> redistribute 0.0.0.0/0 set { type 2 } depend on carp1
>
> (or keyword "default" can be used instead of prefix.)
>
> Is it an intended behaviour or it's not?
It is not intended. I'll look into it.
> Is this mail list appropriate for similar topics related to OpenOSPFD
> at all or some other mail list should better be used instead?
Next time maybe bugs@.
>
> System information:
> * 6.4 GENERIC.MP#3 amd64
> * syspatch up to 010_pcbopts installed
>
> --
> End of message. Next message?
>
Re: fluctuating error on chromium
> Your user(s) needs access to atleast /dev/drm0, if you want better graphics > support. Not sure if > /dev/drm > 0 are also needed? My user has access to /dev/drm0, but no access to the others /dev/drm?. I don't know if the second is needed. X.org starts using xenodm. I run a few recent snapshots and the errors are there only at first run of chromium. Is there a way to check if an instance of chromium has hardware acceleration? Thank you.
Re: ubnt unfi stable from ports doesn??t start with rcctl but as root
Hi and thanks! On Wed, 9 Jan 2019 at 18:06, Stuart Henderson wrote: > > On 2019-01-08, Bryan Vyhmeister wrote: > > On Tue, Jan 08, 2019 at 03:27:39PM +0100, Thomas Huber wrote: > >> just upgrade the Unifi Controller net/unifi/stable (version 5.8.30) from > >> ports. > >> The controller service doesn??t start wit rcctl(8) but works fine when > >> running as root. > >> My guess is that _unifi is not allowed to start monogd but don??t have a > >> clue how to fix this... > >> Does it matter if databases/mongo is install from ports or pkg? > >> I installed all dependecies manually with pkg_add(1) > >> > >> Any idea where to look? > > any output from "rcctl -d start unifi"? # rcctl -d start unifi doing _rc_parse_conf doing _rc_quirks unifi_flags empty, using default >< doing _rc_parse_conf /var/run/rc.d/unifi doing _rc_quirks doing rc_check unifi doing rc_start doing _rc_wait start doing rc_check doing rc_check Alarm clock doing _rc_write_runfile (ok) # > > anything in logs? yes, there was... sorry that I didn´t look for that by myself at the first time. several files had wrong permissions. I chowned to '_unifi:wheel' and now it seem to work fine. Also I moved the directories 'data' and 'backup' to /var and linked back just like the logs are. Is this a good or bad idea? thanks --mirac
Re: Blocking "shodan.io" - What are my options?
Hi Jordan
I've set it up to try it, but I'm not having much luck. Even when I
trigger more than one, it still doesn't populate the bad_hosts table,
even again when I extend the rate period to 86400 seconds. I've added
logging so I know the rule is triggering. See below.
git# tcpdump -i pflog0
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
08:50:41.100611 111-222-33-45.dyn.isp.net.au.49643 >
git.mydomain.com.telnet: S 3935794887:3935794887(0) win 8192 (DF)
08:50:41.630593 111-222-33-45.dyn.isp.net.au.49643 >
git.mydomain.com.telnet: S 3935794887:3935794887(0) win 8192 (DF)
08:50:42.155612 111-222-33-45.dyn.isp.net.au.49643 >
git.mydomain.com.telnet: S 3935794887:3935794887(0) win 8192 (DF)
08:50:43.496590 111-222-33-45.dyn.isp.net.au.49649 >
git.mydomain.com.telnet: S 2579184023:2579184023(0) win 8192 (DF)
08:50:44.038541 111-222-33-45.dyn.isp.net.au.49649 >
git.mydomain.com.telnet: S 2579184023:2579184023(0) win 8192 (DF)
08:50:44.571563 111-222-33-45.dyn.isp.net.au.49649 >
git.mydomain.com.telnet: S 2579184023:2579184023(0) win 8192 (DF)
08:50:46.879666 111-222-33-45.dyn.isp.net.au.49660 >
git.mydomain.com.telnet: S 1029456025:1029456025(0) win 8192 (DF)
08:50:47.408720 111-222-33-45.dyn.isp.net.au.49660 >
git.mydomain.com.telnet: S 1029456025:1029456025(0) win 8192 (DF)
08:50:47.938650 111-222-33-45.dyn.isp.net.au.49660 >
git.mydomain.com.telnet: S 1029456025:1029456025(0) win 8192 (DF)
^C
9 packets received by filter
0 packets dropped by kernel
git# cat /etc/pf.conf
# $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
ext_if=vio0
ext_ip=111.222.33.44
set skip on lo
block return# block stateless traffic
pass# establish keep-state
block quick from
pass in log on $ext_if proto tcp to $ext_ip port telnet keep state
(max-src-conn-rate 1/86400, overload flush global)
# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010
# Port build user does not need network
block return out log proto {tcp udp} user _pbuild
git#
On Wed, Jan 9, 2019 at 1:30 PM Jordan Geoghegan wrote:
>
>
>
> On 01/08/19 18:08, tomr wrote:
> >
> > On 1/9/19 12:42 PM, Jordan Geoghegan wrote:
> >> Yikes. Everything you are (erroneously) trying to do here can be done
> >> without leaving your pf.conf.
> >>
> >> Remember, KISS.
> >>
> > Is there a way to add an address to a table from within a rule, or
> > something to that effect? I can't see such an option. A la...
> >
> > block in quick on $ext_if to any port ! { $allowed_ports } add-to
> >
> >
> > (Otherwise I don't see how the whole show could be completed without
> > logging, monitoring the log, then running pfctl, ie with leaving your
> > pf.conf)
>
> Without wasting too much time on this, the "overload" example from the
> pf.conf man page could be pretty easily adapted to meet the specified needs:
>
> pass in on egress proto tcp to egress port 22 keep state
> (max-src-conn-rate 1/10, overload flush global)
>
> or to copy basically verbatim from the man page, (with only the
> src-conn-rate and port number adjusted):
>
> block quick from
> pass in on $ext_if proto tcp to $webserver port ssh keep state \
>(max-src-conn-rate 1/10, overload flush global)
>
>
> I havent tested this personally, but it should be adequate.
>
>
>
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
Re: ubnt unfi stable from ports doesn??t start with rcctl but as root
On 2019/01/09 21:47, Thomas Huber wrote: > Hi and thanks! > > On Wed, 9 Jan 2019 at 18:06, Stuart Henderson wrote: > > > > On 2019-01-08, Bryan Vyhmeister wrote: > > > On Tue, Jan 08, 2019 at 03:27:39PM +0100, Thomas Huber wrote: > > >> just upgrade the Unifi Controller net/unifi/stable (version 5.8.30) from > > >> ports. > > >> The controller service doesn??t start wit rcctl(8) but works fine when > > >> running as root. > > >> My guess is that _unifi is not allowed to start monogd but don??t have a > > >> clue how to fix this... > > >> Does it matter if databases/mongo is install from ports or pkg? > > >> I installed all dependecies manually with pkg_add(1) > > >> > > >> Any idea where to look? > > > > any output from "rcctl -d start unifi"? > > # rcctl -d start unifi > > > doing _rc_parse_conf > doing _rc_quirks > unifi_flags empty, using default >< > doing _rc_parse_conf /var/run/rc.d/unifi > doing _rc_quirks > doing rc_check > unifi > doing rc_start > doing _rc_wait start > doing rc_check > doing rc_check > Alarm clock > doing _rc_write_runfile > (ok) > # > > > > > anything in logs? > > yes, there was... sorry that I didn´t look for that by myself at the first > time. > several files had wrong permissions. I chowned to '_unifi:wheel' and now it > seem to work fine. I guess the most likely cause of that would be starting it manually (i.e. outside the rcctl/rc.d system) as a different user (probably root). > Also I moved the directories 'data' and 'backup' to /var and linked back just > like the logs > are. > Is this a good or bad idea? You may have to fix some things up after updating in future. With hindsight that may have been a better choice but a bit awkward to change in the port now.
Re: Backlight on Dell Laptop not adjusting brightness
Paul Swanson wrote: > This laptop is essentially all Intel Skylake under the hood some I'm wondering > why it's not playing nice like on the Lenovo / ThinkPads. There's no guarantee that the screen backlight is actually wired to the graphics chip and not just some acpi buttons. :( > I'd really appreciate any advice on what I can try next, it's my first time > running OpenBSD as my main system and I'm really enjoying it so far. Does it work at the bootloader, before the kernel runs?
Re: Backlight on Dell Laptop not adjusting brightness
Hi Ted, Thanks for your email. ‐‐‐ Original Message ‐‐‐ On Thursday, January 10, 2019 10:09 AM, Ted Unangst wrote: > Paul Swanson wrote: > > > This laptop is essentially all Intel Skylake under the hood some I'm > > wondering > > why it's not playing nice like on the Lenovo / ThinkPads. > > There's no guarantee that the screen backlight is actually wired to the > graphics chip and not just some acpi buttons. :( > That appears to be the case. I've noticed that a number of the Fn buttons don't register keypresses with X, such as the controls for screen and keypad backlights (whereas audio volume does). > > I'd really appreciate any advice on what I can try next, it's my first time > > running OpenBSD as my main system and I'm really enjoying it so far. > > Does it work at the bootloader, before the kernel runs? It seems that in the Dell BIOS I can adjust screen brightness (backlight) and that setting appears to continue to apply after OS boot; so I now have that as a workaround. I'd like to chase this up a bit further and see if there's anything I can do to improve support on this model; Ubuntu has great support so I can perhaps look for there for ideas and inspiration. Ted, do you have any suggestions for what parts of OpenBSD I should be looking at to improve support for these keys and functions? Cheers, Paul S.
iked.conf insanity (passing traffic locally between two tunneled subnets)
Hi, I have two separate subnets (on different interfaces) on a router. I am trying to tunnel both subnets over the internet to another router on my network. I can tunnel one subnet easily and everything works as expected, but when I tunnel the 2nd subnet, then traffic from one local subnet is no longer forwarded to the other subnet, but is unconditionally sent into the ipsec tunnel, bypassing the routing table. Traffic flows between the two subnets as expected when iked is disabled. I thought I should be able to use config like this: ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com ikev2 "Flow" active \ from re1 to tunnel.realconnect.com \ from re1 to stats.realconnect.com \ from 66.63.44.66 to 0.0.0.0/0 \ from 66.63.44.67 to 66.63.0.0/18 \ from 66.63.44.67 to christine-home.realconnect.com \ from home.ouellet.us to 0.0.0.0/0 \ from 66.63.44.96/27 to 0.0.0.0/0 \ peer tunnel.realconnect.com but then I get the problem described above, where traffic stops flowing between the local subnets - machines on subnet 66.63.44.96/27 (behind re1) cannot talk to machines on 66.63.44.64/27 (behind re1) - the traffic is unconditionally sent to enc0 instead. To get this to work, I've had to configure each flow to cover the entire ipv4 space except for the two local subnets. This gets even uglier, because doing so results in lines which are apparently too long to parse, and iked refuses to start unless I break it into multiple smaller flows. Horrific (but working) config below: ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com ikev2 "Flow" active \ from re1 to tunnel.realconnect.com \ from re1 to stats.realconnect.com \ from 66.63.44.66 to 0.0.0.0/2 \ from 66.63.44.66 to 64.0.0.0/8 \ from 66.63.44.66 to 65.0.0.0/8 \ from 66.63.44.66 to 66.0.0.0/11 \ from 66.63.44.66 to 66.32.0.0/12 \ from 66.63.44.66 to 66.48.0.0/13 \ from 66.63.44.66 to 66.56.0.0/14 \ from 66.63.44.66 to 66.60.0.0/15 \ from 66.63.44.66 to 66.62.0.0/16 \ from 66.63.44.66 to 66.63.0.0/19 \ from 66.63.44.66 to 66.63.32.0/21 \ from 66.63.44.66 to 66.63.40.0/22 \ from 66.63.44.66 to 66.63.44.0/26 \ from 66.63.44.66 to 66.63.44.128/25 \ from 66.63.44.66 to 66.63.45.0/24 \ from 66.63.44.66 to 66.63.46.0/23 \ from 66.63.44.66 to 66.63.48.0/22 \ from 66.63.44.66 to 66.63.52.0/22 \ from 66.63.44.66 to 66.63.56.0/21 \ from 66.63.44.66 to 66.64.0.0/10 \ from 66.63.44.66 to 66.128.0.0/9 \ from 66.63.44.66 to 67.0.0.0/8 \ from 66.63.44.66 to 68.0.0.0/6 \ from 66.63.44.66 to 72.0.0.0/5 \ from 66.63.44.66 to 80.0.0.0/4 \ from 66.63.44.66 to 96.0.0.0/3 \ from 66.63.44.66 to 128.0.0.0/1 \ from 66.63.44.67 to 66.63.0.0/19 \ from 66.63.44.67 to 66.63.32.0/21 \ from 66.63.44.67 to 66.63.40.0/22 \ from 66.63.44.67 to 66.63.44.0/26 \ from 66.63.44.67 to 66.63.44.128/25 \ from 66.63.44.67 to 66.63.45.0/24 \ from 66.63.44.67 to 66.63.46.0/23 \ from 66.63.44.67 to 66.63.48.0/22 \ from 66.63.44.67 to 66.63.52.0/22 \ from 66.63.44.67 to 66.63.56.0/21 \ from 66.63.44.67 to christine-home.realconnect.com \ peer tunnel.realconnect.com ikev2 "Flow2" active \ from home.ouellet.us to 0.0.0.0/2 \ from home.ouellet.us to 64.0.0.0/8 \ from home.ouellet.us to 65.0.0.0/8 \ from home.ouellet.us to 66.0.0.0/11 \ from home.ouellet.us to 66.32.0.0/12 \ from home.ouellet.us to 66.48.0.0/13 \ from home.ouellet.us to 66.56.0.0/14 \ from home.ouellet.us to 66.60.0.0/15 \ from home.ouellet.us to 66.62.0.0/16 \ from home.ouellet.us to 66.63.0.0/19 \ from home.ouellet.us to 66.63.32.0/21 \ from home.ouellet.us to 66.63.40.0/22 \ from home.ouellet.us to 66.63.44.0/26 \ from home.ouellet.us to 66.63.44.128/25 \ from home.ouellet.us to 66.63.45.0/24 \ from home.ouellet.us to 66.63.46.0/23 \ from home.ouellet.us to 66.63.48.0/22 \ from home.ouellet.us to 66.63.52.0/22 \ from home.ouellet.us to 66.63.56.0/21 \ from home.ouellet.us to 66.64.0.0/10 \ from home.ouellet.us to 66.128.0.0/9 \ from home.ouellet.us to 67.0.0.0/8 \ from home.ouellet.us to 68.0.0.0/6 \ from home.ouellet.us to 72.0.0.0/5 \ from home.ouellet.us to 80.0.0.0/4 \ from home.ouellet.us to 96.0.0.0/3 \ from home.ouellet.us to 128.0.0.0/1 \ peer tunnel.realconnect.com ikev2 "Flow3" active \ from 66.63.44.96/27 to 0.0.0.0/2 \ from 66.63.44.96/27 to 64.0.0.0/8 \ from 66.63.44.96/27 to 65.0.0.0/8 \ from 66.63.44.96/27 to 66.0.0.0/11 \ from 66.63.44.96/27 to 66.32.0.0/
Slow clock on vmd guest, i386-specific
After looking through the mailing list archives, I'm seeking advice on running an OpenBSD i386 guest successfully without losing too much time. My host is an 8th-gen Intel NUC (dmesg *2 follows), and both the host and any OpenBSD amd64 guest keep time beautifully using the tsc time source. I've needed to make no changes to sysctl or HZ as compiled in the kernel. When firing up an i386 guest to do some release(8) builds, I have no issues with running those tasks, but the system loses time on the order of 4-5 for every 20, even when sitting idle. It appears that there is no tsc source found on i386, and taking a peak at src/sys/arch/i386/i386 indicates that perhaps this isn't available? What's the preferred method to get such a guest in line? I've included various sysctl, ntpd, and dmesg output below. All systems are running 6.4-stable. Thanks! Brian Conway amd64 host kern.timecounter (amd64 guest is similar): # sysctl kern.timecounter kern.timecounter.tick=1 kern.timecounter.timestepwarnings=0 kern.timecounter.hardware=tsc kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) acpitimer0(1000) dummy(-100) i386 guest: kern.timecounter.tick=1 kern.timecounter.timestepwarnings=0 kern.timecounter.hardware=i8254 kern.timecounter.choice=i8254(0) dummy(-100) i386 guest after 20 minutes of uptime (jitter and delay reflect redirection to a local ntp server): - $ ntpctl -s all 4/4 peers valid, 1/1 sensors valid, constraint offset 3s (4 errors), clock unsynced, clock offset is 26743.868ms peer wt tl st next poll offset delay jitter 107.181.191.189 from pool us.pool.ntp.org 1 10 3 1945s 3135s 6537.870ms 1.062ms 0.316ms 142.147.92.5 from pool us.pool.ntp.org 1 10 3 1898s 3086s 5915.575ms 0.854ms 0.082ms 216.229.4.69 from pool us.pool.ntp.org 1 10 3 1928s 3115s 5919.290ms 0.887ms 0.110ms 216.6.2.70 from pool us.pool.ntp.org 1 10 3 1825s 3017s 3889.790ms 0.852ms 0.115ms sensor wt gd st next poll offset correction vmmci0 1 1 0 10s 15s 1277789.475ms 0.000ms - i386 guest ntpd logs: - Jan 10 01:41:46 b64-i386 ntpd[5306]: ntp engine ready Jan 10 01:41:47 b64-i386 ntpd[98096]: set local clock to Thu Jan 10 01:41:47 UTC 2019 (offset 0.647554s) Jan 10 01:41:47 b64-i386 savecore: no core dump Jan 10 01:41:49 b64-i386 ntpd[5306]: constraint reply from 172.217.2.228: offset 2.592767 Jan 10 01:42:09 b64-i386 ntpd[5306]: peer 216.229.4.69 now valid Jan 10 01:42:11 b64-i386 ntpd[5306]: peer 216.6.2.70 now valid Jan 10 01:42:12 b64-i386 ntpd[5306]: peer 142.147.92.5 now valid Jan 10 01:42:14 b64-i386 ntpd[5306]: peer 107.181.191.189 now valid Jan 10 01:43:05 b64-i386 ntpd[81307]: adjusting local clock by 33.008869s Jan 10 01:44:06 b64-i386 ntpd[5306]: reply from 216.6.2.70: constraint check failed Jan 10 01:44:08 b64-i386 ntpd[5306]: reply from 107.181.191.189: constraint check failed Jan 10 01:44:10 b64-i386 ntpd[5306]: reply from 142.147.92.5: constraint check failed Jan 10 01:44:11 b64-i386 ntpd[5306]: reply from 216.229.4.69: constraint check failed ... - amd64 host dmesg: - OpenBSD 6.4-stable (GENERIC.MP) #3: Mon Jan 7 01:46:29 UTC 2019 bcon...@nc.int.rcesoftware.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8452431872 (8060MB) avail mem = 8187002880 (7807MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7a9a4000 (76 entries) bios0: vendor Intel Corp. version "BECFL357.86A.0056.2018.1128.1717" date 11/28/2018 bios0: Intel(R) Client Systems NUC8i5BEH acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT HPET SSDT SSDT UEFI LPIT SSDT SSDT DBGP DBG2 SSDT DMAR BGRT WSMT acpi0: wakeup devices SIO1(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(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-8259U CPU @ 2.30GHz, 2195.91 MHz, 06-8e-0a cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 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-8259U CPU @ 2.30GHz, 2194.93 MHz,
Re: mirror download speed variation => Back to normal
Am 09.01.19 um 17:53 schrieb Stuart Henderson: > On 2019-01-09, Stefan Wollny wrote: >> On 08.01.19 14:24, Mihai Popescu wrote: >>> ... > > I'm currently getting 6.7MByte/s over v6 and 3.95MByte/s over v4 > from ftp.hostserver.de to the UK. So it's not a global problem. > As phessler said, send him traceroute and your source IP offlist. > > Apparently they (phessler@/benno@) have taken care of the issue. This morning download rates are back to what I usually had in the past. THANK YOU very much! Well apprecciated. Best, STEFAN
Re: Slow clock on vmd guest, i386-specific
On Wed, Jan 09, 2019 at 11:18:16PM -0600, Brian Conway wrote: > After looking through the mailing list archives, I'm seeking advice on > running an OpenBSD i386 guest successfully without losing too much > time. My host is an 8th-gen Intel NUC (dmesg *2 follows), and both the > host and any OpenBSD amd64 guest keep time beautifully using the tsc > time source. I've needed to make no changes to sysctl or HZ as > compiled in the kernel. > > When firing up an i386 guest to do some release(8) builds, I have no > issues with running those tasks, but the system loses time on the > order of 4-5 for every 20, even when sitting idle. It appears that > there is no tsc source found on i386, and taking a peak at > src/sys/arch/i386/i386 indicates that perhaps this isn't available? > > What's the preferred method to get such a guest in line? I've included > various sysctl, ntpd, and dmesg output below. All systems are running > 6.4-stable. Thanks! > > Brian Conway > > amd64 host kern.timecounter (amd64 guest is similar): > # sysctl kern.timecounter > kern.timecounter.tick=1 > kern.timecounter.timestepwarnings=0 > kern.timecounter.hardware=tsc > kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) > acpitimer0(1000) dummy(-100) > > i386 guest: > kern.timecounter.tick=1 > kern.timecounter.timestepwarnings=0 > kern.timecounter.hardware=i8254 > kern.timecounter.choice=i8254(0) dummy(-100) > > i386 guest after 20 minutes of uptime (jitter and delay reflect > redirection to a local ntp server): > - > $ ntpctl -s all > 4/4 peers valid, 1/1 sensors valid, constraint offset 3s (4 errors), > clock unsynced, clock offset is 26743.868ms > > peer >wt tl st next poll offset delay jitter > 107.181.191.189 from pool us.pool.ntp.org > 1 10 3 1945s 3135s 6537.870ms 1.062ms 0.316ms > 142.147.92.5 from pool us.pool.ntp.org > 1 10 3 1898s 3086s 5915.575ms 0.854ms 0.082ms > 216.229.4.69 from pool us.pool.ntp.org > 1 10 3 1928s 3115s 5919.290ms 0.887ms 0.110ms > 216.6.2.70 from pool us.pool.ntp.org > 1 10 3 1825s 3017s 3889.790ms 0.852ms 0.115ms > > sensor >wt gd st next poll offset correction > vmmci0 > 1 1 0 10s 15s 1277789.475ms 0.000ms > - > > i386 guest ntpd logs: > - > Jan 10 01:41:46 b64-i386 ntpd[5306]: ntp engine ready > Jan 10 01:41:47 b64-i386 ntpd[98096]: set local clock to Thu Jan 10 > 01:41:47 UTC 2019 (offset 0.647554s) > Jan 10 01:41:47 b64-i386 savecore: no core dump > Jan 10 01:41:49 b64-i386 ntpd[5306]: constraint reply from > 172.217.2.228: offset 2.592767 > Jan 10 01:42:09 b64-i386 ntpd[5306]: peer 216.229.4.69 now valid > Jan 10 01:42:11 b64-i386 ntpd[5306]: peer 216.6.2.70 now valid > Jan 10 01:42:12 b64-i386 ntpd[5306]: peer 142.147.92.5 now valid > Jan 10 01:42:14 b64-i386 ntpd[5306]: peer 107.181.191.189 now valid > Jan 10 01:43:05 b64-i386 ntpd[81307]: adjusting local clock by 33.008869s > Jan 10 01:44:06 b64-i386 ntpd[5306]: reply from 216.6.2.70: constraint > check failed > Jan 10 01:44:08 b64-i386 ntpd[5306]: reply from 107.181.191.189: > constraint check failed > Jan 10 01:44:10 b64-i386 ntpd[5306]: reply from 142.147.92.5: > constraint check failed > Jan 10 01:44:11 b64-i386 ntpd[5306]: reply from 216.229.4.69: > constraint check failed > ... > - > > amd64 host dmesg: > - > OpenBSD 6.4-stable (GENERIC.MP) #3: Mon Jan 7 01:46:29 UTC 2019 > bcon...@nc.int.rcesoftware.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8452431872 (8060MB) > avail mem = 8187002880 (7807MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7a9a4000 (76 entries) > bios0: vendor Intel Corp. version "BECFL357.86A.0056.2018.1128.1717" > date 11/28/2018 > bios0: Intel(R) Client Systems NUC8i5BEH > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT HPET SSDT > SSDT UEFI LPIT SSDT SSDT DBGP DBG2 SSDT DMAR BGRT WSMT > acpi0: wakeup devices SIO1(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) > PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) > RP06(S4) PXSX(S4) RP07(S4) PXSX(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-8259U CPU @ 2.30GHz, 2195.91 MHz, 06-8e-0a > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core
