Re: heavy CPU consumption and laggy/stuttering video on thinkpad x230
The issue lies in here: Config - USB USB UEFI BIOS Support -> Enabled Always On USB - Disabled Config - Thunderbolt 3 Thunderbolt BIOS Assist Mode -> Enabled
Re: heavy CPU consumption and laggy/stuttering video on thinkpad x230
On Tue, Nov 19, 2019, at 10:06, Josh wrote: > Have you tried on 6.5? > > My X1rev6 did not like the upgrade to 6.6. heavy cpu consumption, > super hot, laggy when browsing and fan spinning consistently. > > I've reinstalled 6.5 and been using the same settings as yours. > everything is back to normal. I guess I will wait for 6.7... I've been running the latest 6.6-current on my x1c6 and it works great. Really fast, wakes from suspend/hibernate. Isn't laggy, doesn't get too hot unless I'm doing a long build. However, I did somehow hit on some BIOS settings that made it behave as you describe. I was also seeing some failures to suspend, and it seemed like lid-action events might be getting missed. I could shut the lid and then ssh in. Sometimes for a while after boot a single core would be pegged for a few minutes. To fix it, I reset the BIOS to defaults, then set the following: Config - Power Sleep State -> Linux 8254 Timer Clock Gating -> Auto Config - USB USB UEFI BIOS Support -> Enabled Always On USB - Disabled Config - Thunderbolt 3 Thunderbolt BIOS Assist Mode -> Enabled Security - I/O Port Access Bluetooth -> Disabled (OpenBSD doesn't support it anyway) Memory Card Slot -> Disabled (I read on the Arch Wiki (1.) some reports of this sucking power, and I don't use it.) Fingerprint Reader -> Disabled Security - Secure Boot Configuration Secure Boot -> Disabled Boot UEFI/Legacy Boot -> Both UEFI/Legacy Boot -> Priority UEFI First CSM Support - Yes I'm not sure all of the above are necessary, but mine works wonderfully since I set it up this way. I'm also running BIOS version 1.43, which is the latest. 1. https://wiki.archlinux.org/index.php/Lenovo_ThinkPad_X1_Carbon_(Gen_6)
Re: Best Practices for growing disk partitions on a server
On 2019-11-19, Steve Litt wrote: > In OpenBSD is there such a thing as a bind mount like they have in > Linux? No. The closest is probably "mount from 127.0.0.1 over NFS".
Re: pkg_info -Q bug?
On 2019-11-19, Marc Espie wrote: > On Tue, Nov 19, 2019 at 12:13:37PM +0200, Dumitru Moldovan wrote: >> On Mon, Nov 18, 2019 at 11:15:05AM +0100, Antonio Bibiano wrote: >> > Hello, >> > I just wanted to add to this thread that I incurred in the same >> > issue on a fresh 6.6 installation. >> > I also tried with a different mirror in /etc/installurl and receive >> > the same partial response from pkg_info -Q. >> > What makes it even more odd is that pkg_add finds the correct package. >> >> Thanks Antonio for double-checking this! I have also tested it on a >> fresh installation at the time and got the same results. >> >> Maybe the behaviour is undefined if PKG_PATH is not set, which is fine >> by me. But still, it's quite puzzling and against the principle of >> least surprise. > > It's one of those little things that is well known, but that won't change > until I have time to look at it, and it's definitely not a high priority > problem right now. > > As a workaround (but also something that would be more likely to give the results wanted than a properly-working pkg_info -Q which doesn't match filenames inside the packages), you might like to "pkg_add pkglocatedb" and use the "pkglocate" tool that this provides.
Re: pvclock stability
On Tue, 19 Nov 2019 at 21:20, Ian Gregory wrote: > I can > confirm that change resolved the precision issue described in the > linked thread, but it also seems to have resulted in much improved > clock stability (4 steps in 24hr, 1.0s, 1.0s, 0.5s, 0.5s). Correction - there were actually 3 instances of 1.0s time steps (clock lags real time by 3.0s) Ian
Re: pvclock stability
As a final update to this (for now): I was unable to work out why the
correct timestamps from pvclock_get_timecount() were not being used to
correct the system clock. I suspect I don't have a full enough
understanding of how the return value from this function used by the
kernel timekeeping processes.
I did notice a thread on bugs@
(https://marc.info/?l=openbsd-bugs=157403970412386=2) which
included a patch with a correction to the shift parameter sent from
vmm to the pvclock driver. Although I couldn't test this particular
patch (I don't control the hypervisor) I was able to set the shift
parameter in pvclock.c to 12 to achieve the same net result. I can
confirm that change resolved the precision issue described in the
linked thread, but it also seems to have resulted in much improved
clock stability (4 steps in 24hr, 1.0s, 1.0s, 0.5s, 0.5s).
At this point ntpd is able to keep the clock synced so in the absence
of further lines of investigation I'm inclined to leave as-is and
continue to monitor. I will update the list if I discover anything
new.
Ian
On Fri, 15 Nov 2019 at 09:17, Ian Gregory wrote:
>
> I continued to investigate this and added some debugging output to the
> pvclock driver to attempt to work out what was going on.
>
> In my most recent test I rebooted the client VM at 08:10 yesterday.
> Over the following 24h, there were 16 "clock step" events which caused
> the time to lag real time by a total of 21.3 seconds. In all but 3 of
> the steps, the change in the offset was 1.0 seconds almost exactly.
> During the test the VM was loaded with it's usual workload (running
> net/zabbix) and ntpd was disabled.
>
> I added a printf to the end of pvclock_get_timecount which outputs the
> state of the variables within the function for each 10 steps
> of system_time.
>
> Here is an example of the output. The prefixed date is from syslog and
> is the incorrect system time. The actual time of the log entry (as
> reported from a reliable NTP source) was 09:05:23
>
> Nov 15 09:05:02 starbug /bsd: pvclock:
> tsc_timestamp=3627858654285868 rdtsc=3627858654563637 delta_1=277769
> shift=-20 delta=0 mul_frac=342781 system_time=1573808723797914701
> ctr=1573808723797914701
>
> The ctr value is the return value of pvclock_get_timecount - the value
> 1573808723797914701 translates to Fri Nov 15 09:05:23.797
>
> I'm no expert in kernel timekeeping internals (far from it), but it
> seems that the pvclock driver is returning correct timestamps from
> pvclock_get_timecount and thus I conclude both the pvclock device in
> vmm and the pvclock driver in the kernel are working as designed.
>
> Can anyone advise if I've missed something? Happy to provide further
> data if needed.
>
> Thanks
> Ian
>
>
>
> On Fri, 8 Nov 2019 at 13:53, Ian Gregory wrote:
> >
> > Hi
> >
> > Since the 6.6 release I've been experimenting with using pvclock as
> > the selected timecounter on a virtual machine running under vmm. Both
> > the host and guest are running 6.6-stable (the environment is provided
> > by openbsd.amsterdam).
> >
> > With 6.5 and the tsc source, the clock would drift linearly by about 2
> > seconds per minute. This was too large a drift for ntpd to compensate
> > for and so I used a cron job to force-correct the clock at regular
> > intervals.
> >
> > With 6.6 I have changed the timecounter source to pvclock. In
> > frequency terms this has proven to be much more stable, with minimal
> > drift. However, at irregular intervals the clock will step out of time
> > by a small whole number of seconds. Over 24 hours following a reboot
> > the clock now differs from real time (verified against multiple ntp
> > sources) by just over 23 seconds, it having stepped 9 times during
> > that time window
> >
> > I ran the following command every 60s following a reboot of the guest
> > to log the output
> > echo -n `date` && rdate -pv time.cloudflare.com | tail -1 | awk
> > '{ print " " $6 }'
> > Note that the data points are not consistently 60s apart - I'm using
> > 'sleep' to delay the loop.
> >
> > Raw data and chart of the offset over the 24 hours is available in
> > this Google sheet: http://bit.ly/34NTaUh
> >
> > Is this likely to point to a bug in the pvclock implementation or an
> > environment/configuration issue?
> >
> > Thanks
> > Ian
> >
> >
> > dmesg (guest)
> > =
> >
> > OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 06:47:50 MDT 2019
> >
> > r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> > real mem = 2130698240 (2031MB)
> > avail mem = 2053558272 (1958MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf3f40 (10 entries)
> > bios0: vendor SeaBIOS version "1.11.0p2-OpenBSD-vmm" date 01/01/2011
> > bios0: OpenBSD VMM
> > acpi at bios0 not configured
> > cpu0 at mainbus0: (uniprocessor)
> > cpu0: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3062.26 MHz, 06-2c-02
> > cpu0:
> >
Re: Best Practices for growing disk partitions on a server
On Tue, 19 Nov 2019 12:52:52 +0200 Dumitru Moldovan wrote: > > 1. Install the same OS on new hardware, in your case with a better > partitioned drive. > > 2. rsync everything relevant to the new machine (but make sure it > still boots afterwards and functions as expected, so amend boot > manager files, hardware-dependant configs etc.). > > 3. Update relevant DNS records for affected services AND set packet > redirection for services on the old machines until DNS propagation > does its thing (which is usually much longer than expected, esp. > for public services, even if you lower TTLs well in advance). > > If you don't have spare hardware for the migration, I guess you could > use a spare VM until you repartition drives in your old hardware as > needed. Also rsync to a USB hard drive, so even if everything including your VM goes to hell you can still restore. I just bought a 5TB USB drive for $99 at Costco. SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Re: Best Practices for growing disk partitions on a server
On Mon, 18 Nov 2019 18:28:55 - (UTC) Stuart Henderson wrote: > On 2019-11-17, Lev Lazinskiy wrote: > > Hi folks, > > > > I am new to openBSD, so forgive me if I am missing something > > obvious. > > > > I recently installed openBSD on a server using the auto-partition > > layout during installation and am quickly starting to run out of > > disk space. > > > > I have read the section in the FAQ [1] regarding how to grow a disk > > partition, but I am confused on the best way to actually do this. > > > > Specifically, I am trying to grow /usr and /home but they are "busy" > > when I try to follow these steps on a running server. > > > > Is the assumption that you are supposed to reboot the server with > > the ISO attached and pop into a shell to complete these steps? > > > > [1] https://www.openbsd.org/faq/faq14.html#GrowPartition > > > > This faq entry tells you to use growfs, which won't work for /usr > from a standard auto-defaults install because it requires empty space > immediately following the partition to grow into. > > On a larger disk it often will work for /home because auto-defaults > place it at the end of the disk, size it at max 300G, and leave the > space following it empty. > > Sometimes you can shunt things around - if you have free space at the > end of the disk you can move files from the filesystem immediately > following /usr there, and growfs into the now-vacated space - > sometimes you have another partition that is A) larger than /usr and > B) that is larger than you need, in which case you copy files so you > can swap them around. Or again if you have free space at the end of > the disk, after what you'd want to grow /home into, you can make a > new partition there, copy the files, and leave the former /usr > partition empty. But it's quite delicate work and is often easier to > reinstall. In OpenBSD is there such a thing as a bind mount like they have in Linux? SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Re: unwind: is it possible to prevent using a dhcp callback?
Hi Otto,
I have to apologize. After trying your proposal it is working as expected.
Thank you for your help and sorry for the noise.
Kind regards
Felix
On 2019-11-19 20:40, Otto Moerbeek wrote:
On Tue, Nov 19, 2019 at 08:33:39PM +0100, Felix Maschek wrote:
I want to use DHCP to get an IP address and the gateway address. But I want
to use my explicit defined nameserver (not the one given by DHCP).
Is that possible?
Why don't you try what I told you? It does exactly what you are
asking. You can also read about in in man dhclient.conf.
-Otto
Kind regards
Felix
On 2019-11-19 20:06, Otto Moerbeek wrote:
On Tue, Nov 19, 2019 at 06:33:43PM +0100, Felix Maschek wrote:
I've got the following report from the webpage:
You use 12 DNS servers:
46.182.19.48 Germany AS43847 Martin Prager trading as NbIServ
217.237.150.89 Germany AS3320 Deutsche Telekom AG
217.237.150.90 Germany AS3320 Deutsche Telekom AG
217.237.150.91 Germany AS3320 Deutsche Telekom AG
217.237.150.92 Germany AS3320 Deutsche Telekom AG
217.237.150.93 Germany AS3320 Deutsche Telekom AG
217.237.150.94 Germany AS3320 Deutsche Telekom AG
217.237.150.95 Germany AS3320 Deutsche Telekom AG
217.237.150.96 Germany AS3320 Deutsche Telekom AG
217.237.151.215 Germany AS3320 Deutsche Telekom AG
217.237.151.217 Germany AS3320 Deutsche Telekom AG
217.237.151.221 Germany AS3320 Deutsche Telekom AG
Kind regards
If you do not want to use dhcp at all you can use
supersede domain-name-servers 127.0.0.1;
(instead of prepend) in dhclient.conf
-Otto
Felix
On 2019-11-19 18:10, Felix Maschek wrote:
Hi,
status is showing:
vatrox$ unwindctl status
captive portal is unchecked
selected type status
* DoT validating
recursor validating
When I check with https://bash.ws/dnsleak, which DNS are contacted then
I can see, that not only the configured DNS is called. There are several
DNS as given by DHCP called, too. They, of course are supporting DoT as
well.
Kind regards
Felix
On 2019-11-19 16:56, Otto Moerbeek wrote:
On Tue, Nov 19, 2019 at 04:51:09PM +0100, Felix Maschek wrote:
Hi,
I have a running unwind configuration:
/etc/unwind.conf
forwarder 46.182.19.48 port 853 authentication name
dns2.digitalcourage.de DoT
preference { DoT recursor }
Unfortunately this DNS from Digitalcourage is sometimes slow and
so the DNS
learned from DHCP (which is supporting DoT, too) is called.
Is it possible to prevent this fallback so that only calls to
the specified
DNS are made?
Kind regards
Felix
What does unwindctl status show?
-Otto
Re: unwind: is it possible to prevent using a dhcp callback?
On Tue, Nov 19, 2019 at 08:33:39PM +0100, Felix Maschek wrote:
> I want to use DHCP to get an IP address and the gateway address. But I want
> to use my explicit defined nameserver (not the one given by DHCP).
>
> Is that possible?
Why don't you try what I told you? It does exactly what you are
asking. You can also read about in in man dhclient.conf.
-Otto
>
> Kind regards
>
> Felix
>
> On 2019-11-19 20:06, Otto Moerbeek wrote:
> > On Tue, Nov 19, 2019 at 06:33:43PM +0100, Felix Maschek wrote:
> >
> > > I've got the following report from the webpage:
> > >
> > > You use 12 DNS servers:
> > > 46.182.19.48 Germany AS43847 Martin Prager trading as NbIServ
> > > 217.237.150.89 Germany AS3320 Deutsche Telekom AG
> > > 217.237.150.90 Germany AS3320 Deutsche Telekom AG
> > > 217.237.150.91 Germany AS3320 Deutsche Telekom AG
> > > 217.237.150.92 Germany AS3320 Deutsche Telekom AG
> > > 217.237.150.93 Germany AS3320 Deutsche Telekom AG
> > > 217.237.150.94 Germany AS3320 Deutsche Telekom AG
> > > 217.237.150.95 Germany AS3320 Deutsche Telekom AG
> > > 217.237.150.96 Germany AS3320 Deutsche Telekom AG
> > > 217.237.151.215 Germany AS3320 Deutsche Telekom AG
> > > 217.237.151.217 Germany AS3320 Deutsche Telekom AG
> > > 217.237.151.221 Germany AS3320 Deutsche Telekom AG
> > >
> > > Kind regards
> > If you do not want to use dhcp at all you can use
> >
> > supersede domain-name-servers 127.0.0.1;
> >
> > (instead of prepend) in dhclient.conf
> >
> > -Otto
> >
> >
> > >
> > > Felix
> > >
> > >
> > >
> > > On 2019-11-19 18:10, Felix Maschek wrote:
> > > > Hi,
> > > >
> > > > status is showing:
> > > >
> > > > vatrox$ unwindctl status
> > > > captive portal is unchecked
> > > >
> > > > selected type status
> > > > * DoT validating
> > > > recursor validating
> > > >
> > > > When I check with https://bash.ws/dnsleak, which DNS are contacted then
> > > > I can see, that not only the configured DNS is called. There are several
> > > > DNS as given by DHCP called, too. They, of course are supporting DoT as
> > > > well.
> > > >
> > > > Kind regards
> > > >
> > > > Felix
> > > >
> > > > On 2019-11-19 16:56, Otto Moerbeek wrote:
> > > > > On Tue, Nov 19, 2019 at 04:51:09PM +0100, Felix Maschek wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I have a running unwind configuration:
> > > > > >
> > > > > > /etc/unwind.conf
> > > > > >
> > > > > > forwarder 46.182.19.48 port 853 authentication name
> > > > > > dns2.digitalcourage.de DoT
> > > > > >
> > > > > > preference { DoT recursor }
> > > > > >
> > > > > >
> > > > > > Unfortunately this DNS from Digitalcourage is sometimes slow and
> > > > > > so the DNS
> > > > > > learned from DHCP (which is supporting DoT, too) is called.
> > > > > >
> > > > > > Is it possible to prevent this fallback so that only calls to
> > > > > > the specified
> > > > > > DNS are made?
> > > > > >
> > > > > > Kind regards
> > > > > >
> > > > > > Felix
> > > > > >
> > > > > What does unwindctl status show?
> > > > >
> > > > > -Otto
> > > > >
>
Re: unwind: is it possible to prevent using a dhcp callback?
I want to use DHCP to get an IP address and the gateway address. But I
want to use my explicit defined nameserver (not the one given by DHCP).
Is that possible?
Kind regards
Felix
On 2019-11-19 20:06, Otto Moerbeek wrote:
On Tue, Nov 19, 2019 at 06:33:43PM +0100, Felix Maschek wrote:
I've got the following report from the webpage:
You use 12 DNS servers:
46.182.19.48 Germany AS43847 Martin Prager trading as NbIServ
217.237.150.89 Germany AS3320 Deutsche Telekom AG
217.237.150.90 Germany AS3320 Deutsche Telekom AG
217.237.150.91 Germany AS3320 Deutsche Telekom AG
217.237.150.92 Germany AS3320 Deutsche Telekom AG
217.237.150.93 Germany AS3320 Deutsche Telekom AG
217.237.150.94 Germany AS3320 Deutsche Telekom AG
217.237.150.95 Germany AS3320 Deutsche Telekom AG
217.237.150.96 Germany AS3320 Deutsche Telekom AG
217.237.151.215 Germany AS3320 Deutsche Telekom AG
217.237.151.217 Germany AS3320 Deutsche Telekom AG
217.237.151.221 Germany AS3320 Deutsche Telekom AG
Kind regards
If you do not want to use dhcp at all you can use
supersede domain-name-servers 127.0.0.1;
(instead of prepend) in dhclient.conf
-Otto
Felix
On 2019-11-19 18:10, Felix Maschek wrote:
Hi,
status is showing:
vatrox$ unwindctl status
captive portal is unchecked
selected type status
* DoT validating
recursor validating
When I check with https://bash.ws/dnsleak, which DNS are contacted then
I can see, that not only the configured DNS is called. There are several
DNS as given by DHCP called, too. They, of course are supporting DoT as
well.
Kind regards
Felix
On 2019-11-19 16:56, Otto Moerbeek wrote:
On Tue, Nov 19, 2019 at 04:51:09PM +0100, Felix Maschek wrote:
Hi,
I have a running unwind configuration:
/etc/unwind.conf
forwarder 46.182.19.48 port 853 authentication name
dns2.digitalcourage.de DoT
preference { DoT recursor }
Unfortunately this DNS from Digitalcourage is sometimes slow and
so the DNS
learned from DHCP (which is supporting DoT, too) is called.
Is it possible to prevent this fallback so that only calls to
the specified
DNS are made?
Kind regards
Felix
What does unwindctl status show?
-Otto
Re: heavy CPU consumption and laggy/stuttering video on thinkpad x230
On Tue, 2019-11-19 at 12:54 -0600, Dave Trudgian wrote: > On Tue, 2019-11-19 at 19:06 +0100, Josh wrote: > > Have you tried on 6.5? > > > > My X1rev6 did not like the upgrade to 6.6. heavy cpu consumption, > > super hot, laggy when browsing and fan spinning consistently. > > > > I've reinstalled 6.5 and been using the same settings as yours. > > everything is back to normal. I guess I will wait for 6.7... > > I guess I should try this with relation to the other thread I posted > about power draw on my T430. I'm not seeing heavy CPU or much lag - > but > it is unexpectly thirsty and the fan does go all the time. I'll try > 6.5 > this evening if I get a chance. Sorry for the noise decided to try quickly over lunch on my T430. With 6.6 I was seeing a power draw of ~15W sitting at an idle GUI session. Fan runs slowly, but constantly. With 6.5 I see a power draw of ~10.5W sitting at an idle GUI session. Fan does not run. The 6.5 figure compares fairly well to ~8W on Linux with everything powertop can tune there. Going to stay at 6.5 for a while on this machine given the above... but I have 2 drives in this laptop, so I can relatively easily try things out on 6.6 if there are any pointers to try, or useful diagnostic information I can obtain. DT
Re: Iked/unbound ~ more info.
Stuart, I'm going to try just changing resolv.conf to 10.0.1.1 when connected to IKED. Either that or, like you say, unbound-control a stub in a script with ikectl couple. Thanks again! I'm understanding things a lot better now. Much appreciated! Dale
Re: unwind: is it possible to prevent using a dhcp callback?
On Tue, Nov 19, 2019 at 06:33:43PM +0100, Felix Maschek wrote:
> I've got the following report from the webpage:
>
> You use 12 DNS servers:
> 46.182.19.48 Germany AS43847 Martin Prager trading as NbIServ
> 217.237.150.89 Germany AS3320 Deutsche Telekom AG
> 217.237.150.90 Germany AS3320 Deutsche Telekom AG
> 217.237.150.91 Germany AS3320 Deutsche Telekom AG
> 217.237.150.92 Germany AS3320 Deutsche Telekom AG
> 217.237.150.93 Germany AS3320 Deutsche Telekom AG
> 217.237.150.94 Germany AS3320 Deutsche Telekom AG
> 217.237.150.95 Germany AS3320 Deutsche Telekom AG
> 217.237.150.96 Germany AS3320 Deutsche Telekom AG
> 217.237.151.215 Germany AS3320 Deutsche Telekom AG
> 217.237.151.217 Germany AS3320 Deutsche Telekom AG
> 217.237.151.221 Germany AS3320 Deutsche Telekom AG
>
> Kind regards
If you do not want to use dhcp at all you can use
supersede domain-name-servers 127.0.0.1;
(instead of prepend) in dhclient.conf
-Otto
>
>
> Felix
>
>
>
> On 2019-11-19 18:10, Felix Maschek wrote:
> > Hi,
> >
> > status is showing:
> >
> > vatrox$ unwindctl status
> > captive portal is unchecked
> >
> > selected type status
> > * DoT validating
> > recursor validating
> >
> > When I check with https://bash.ws/dnsleak, which DNS are contacted then
> > I can see, that not only the configured DNS is called. There are several
> > DNS as given by DHCP called, too. They, of course are supporting DoT as
> > well.
> >
> > Kind regards
> >
> > Felix
> >
> > On 2019-11-19 16:56, Otto Moerbeek wrote:
> > > On Tue, Nov 19, 2019 at 04:51:09PM +0100, Felix Maschek wrote:
> > >
> > > > Hi,
> > > >
> > > > I have a running unwind configuration:
> > > >
> > > > /etc/unwind.conf
> > > >
> > > > forwarder 46.182.19.48 port 853 authentication name
> > > > dns2.digitalcourage.de DoT
> > > >
> > > > preference { DoT recursor }
> > > >
> > > >
> > > > Unfortunately this DNS from Digitalcourage is sometimes slow and
> > > > so the DNS
> > > > learned from DHCP (which is supporting DoT, too) is called.
> > > >
> > > > Is it possible to prevent this fallback so that only calls to
> > > > the specified
> > > > DNS are made?
> > > >
> > > > Kind regards
> > > >
> > > > Felix
> > > >
> > > What does unwindctl status show?
> > >
> > > -Otto
> > >
> >
>
Re: heavy CPU consumption and laggy/stuttering video on thinkpad x230
On Tue, 2019-11-19 at 19:06 +0100, Josh wrote: > Have you tried on 6.5? > > My X1rev6 did not like the upgrade to 6.6. heavy cpu consumption, > super hot, laggy when browsing and fan spinning consistently. > > I've reinstalled 6.5 and been using the same settings as yours. > everything is back to normal. I guess I will wait for 6.7... I guess I should try this with relation to the other thread I posted about power draw on my T430. I'm not seeing heavy CPU or much lag - but it is unexpectly thirsty and the fan does go all the time. I'll try 6.5 this evening if I get a chance. Thanks, DT
Re: heavy CPU consumption and laggy/stuttering video on thinkpad x230
Have you tried on 6.5? My X1rev6 did not like the upgrade to 6.6. heavy cpu consumption, super hot, laggy when browsing and fan spinning consistently. I've reinstalled 6.5 and been using the same settings as yours. everything is back to normal. I guess I will wait for 6.7... On Fri, Nov 15, 2019 at 4:58 PM Michael H wrote: > > *laptop: thinkpad x230, i7 processor, 8G ram, intel hd 4000 gpu* > *New OpenBSD user with a fresh install.* > > My user account is created from the install process and has "staff" class - > though i haven't increased the datasize-cur, datasize-max for staff yet. > Additionally, apmd has been set to -A as suggested by the faq. > > Basically, whenever I play a video, CPU0, CPU2(shown in top) spike up to > about 30-58%. The heatsink/fan/ventilation area of the laptop gets > extremely hot. > > Videos buffer pretty slowly, and most importantly, when I am watching a > live stream via players such as mpv, it's basically unwatchable because the > video stops every 3-4 seconds. > > *Here is a log file of messages from mpv while playing a stream: * > https://pastebin.com/3VRWgv3K > *Here is a log file of messages from mpv while playing a youtube video: * > https://pastebin.com/mn0wEXMf > > *here is my dmesg:* > http://ix.io/21Bg > *here is my Xorg.0.log:* > http://ix.io/21Bb > > *Here are the firmwares that have been downloaded during installation:* > intel-firmware-20190918v0 microcode update binaries for Intel CPUs > inteldrm-firmware-20181218 firmware binary images for inteldrm(4) driver > iwn-firmware-5.11p1 firmware binary images for iwn(4) driver > uvideo-firmware-1.2p3 firmware binary images for uvideo(4) driver > vmm-firmware-1.11.0p2 firmware binary images for vmm(4) driver > > *Is this an issue with the system somehow using the modesetting driver > instead of the inteldrm* *driver*? if so, why is that and how should i best > remedy this problem? I thought old thinkpads are generally fully supported > by OpenBSD? > > Anyways, if anyone could help i would really appreciate it! > > *and if anyone is using this exact machine (thinkpad x230), could you also > recommend some of the other optimizations you have done for this machine? * > > thanks in advance!
Re: unwind: is it possible to prevent using a dhcp callback?
I've got the following report from the webpage:
You use 12 DNS servers:
46.182.19.48 Germany AS43847 Martin Prager trading as NbIServ
217.237.150.89 Germany AS3320 Deutsche Telekom AG
217.237.150.90 Germany AS3320 Deutsche Telekom AG
217.237.150.91 Germany AS3320 Deutsche Telekom AG
217.237.150.92 Germany AS3320 Deutsche Telekom AG
217.237.150.93 Germany AS3320 Deutsche Telekom AG
217.237.150.94 Germany AS3320 Deutsche Telekom AG
217.237.150.95 Germany AS3320 Deutsche Telekom AG
217.237.150.96 Germany AS3320 Deutsche Telekom AG
217.237.151.215 Germany AS3320 Deutsche Telekom AG
217.237.151.217 Germany AS3320 Deutsche Telekom AG
217.237.151.221 Germany AS3320 Deutsche Telekom AG
Kind regards
Felix
On 2019-11-19 18:10, Felix Maschek wrote:
Hi,
status is showing:
vatrox$ unwindctl status
captive portal is unchecked
selected type status
* DoT validating
recursor validating
When I check with https://bash.ws/dnsleak, which DNS are contacted
then I can see, that not only the configured DNS is called. There are
several DNS as given by DHCP called, too. They, of course are
supporting DoT as well.
Kind regards
Felix
On 2019-11-19 16:56, Otto Moerbeek wrote:
On Tue, Nov 19, 2019 at 04:51:09PM +0100, Felix Maschek wrote:
Hi,
I have a running unwind configuration:
/etc/unwind.conf
forwarder 46.182.19.48 port 853 authentication name
dns2.digitalcourage.de DoT
preference { DoT recursor }
Unfortunately this DNS from Digitalcourage is sometimes slow and so
the DNS
learned from DHCP (which is supporting DoT, too) is called.
Is it possible to prevent this fallback so that only calls to the
specified
DNS are made?
Kind regards
Felix
What does unwindctl status show?
-Otto
Re: unwind: is it possible to prevent using a dhcp callback?
Hi,
status is showing:
vatrox$ unwindctl status
captive portal is unchecked
selected type status
* DoT validating
recursor validating
When I check with https://bash.ws/dnsleak, which DNS are contacted then
I can see, that not only the configured DNS is called. There are several
DNS as given by DHCP called, too. They, of course are supporting DoT as
well.
Kind regards
Felix
On 2019-11-19 16:56, Otto Moerbeek wrote:
On Tue, Nov 19, 2019 at 04:51:09PM +0100, Felix Maschek wrote:
Hi,
I have a running unwind configuration:
/etc/unwind.conf
forwarder 46.182.19.48 port 853 authentication name
dns2.digitalcourage.de DoT
preference { DoT recursor }
Unfortunately this DNS from Digitalcourage is sometimes slow and so the DNS
learned from DHCP (which is supporting DoT, too) is called.
Is it possible to prevent this fallback so that only calls to the specified
DNS are made?
Kind regards
Felix
What does unwindctl status show?
-Otto
Re: unwind: is it possible to prevent using a dhcp callback?
On Tue, Nov 19, 2019 at 04:51:09PM +0100, Felix Maschek wrote:
> Hi,
>
> I have a running unwind configuration:
>
> /etc/unwind.conf
>
> forwarder 46.182.19.48 port 853 authentication name
> dns2.digitalcourage.de DoT
>
> preference { DoT recursor }
>
>
> Unfortunately this DNS from Digitalcourage is sometimes slow and so the DNS
> learned from DHCP (which is supporting DoT, too) is called.
>
> Is it possible to prevent this fallback so that only calls to the specified
> DNS are made?
>
> Kind regards
>
> Felix
>
What does unwindctl status show?
-Otto
unwind: is it possible to prevent using a dhcp callback?
Hi,
I have a running unwind configuration:
/etc/unwind.conf
forwarder 46.182.19.48 port 853 authentication name
dns2.digitalcourage.de DoT
preference { DoT recursor }
Unfortunately this DNS from Digitalcourage is sometimes slow and so the
DNS learned from DHCP (which is supporting DoT, too) is called.
Is it possible to prevent this fallback so that only calls to the
specified DNS are made?
Kind regards
Felix
Invalid signing key OpenBSD 6.6 release
Hello, if too easy a question I apologize for any noise caused. Hardware Thinkpad 201 Software: OpenBSD 6.6 release Encrypted Softraid HD Issue: when trying to upgrade my OpenBSD 6.5 release (fully patched) to OpenBSD 6.6 I used doas sysupgrade and see feeback that two items are being checked and then get Invalid signing key message. So I think maybe some issue. Then I get from ftp toronto the bsd.rd and the signing key and get via signify a correct sign. I then reboot and choose after login in encrypted hd the bootoption bsd.rd, It starts and offers me option to install new, upgrade or command prompt. I choose new install and perform standard steps, automatic layout, I did this presuming this would be clean install ontop encrypted HD. After full setup and thus new install I do again doas sysupgrade and again get message Invalid signing key. Everything else works and I can system upgrade without sysupgrade via the bsd.rd method, however I am curious as why I get message when running upgrade script that signing key is invalid. Anyone concrete feedback please, Thank you, vitalae
T430 power draw unexpectedly high
Hello, I've been using OpenBSD 6.6, and now latest snapshot, for a couple of weeks on a Thinkpad T430. Performance and stability is fine and am very much enjoying using this setup, but the battery life is unexpectedly bad, vs what I'd expect having read around OpenBSD supporting c-states and throttling. Under OpenBSD with the system sitting idle at a GUI, WiFi active, 50% brightness I see ~15W power draw from the battery. This is with `apmd -A` and the output of `apm` showing that it is throttled to 1200MHz. The CPU fan is running at a constant low speed. Under Linux, I see an idle power draw sitting in the GUI, WiFi active, 50% brightness of ~8W. The CPU fan is mostly idle. >From reading around I was expecting more in the range of 70-80% of the Linux battery life, rather than ~50%. I understand several people may be using T430 machines with OpenBSD. Would be grateful for any info r.e. is this power draw typical, or any hints for other things I can look into? Many thanks, Dave Trudgian
Re: pkg_info -Q bug?
On Tue, Nov 19, 2019 at 12:13:37PM +0200, Dumitru Moldovan wrote: > On Mon, Nov 18, 2019 at 11:15:05AM +0100, Antonio Bibiano wrote: > > Hello, > > I just wanted to add to this thread that I incurred in the same > > issue on a fresh 6.6 installation. > > I also tried with a different mirror in /etc/installurl and receive > > the same partial response from pkg_info -Q. > > What makes it even more odd is that pkg_add finds the correct package. > > Thanks Antonio for double-checking this! I have also tested it on a > fresh installation at the time and got the same results. > > Maybe the behaviour is undefined if PKG_PATH is not set, which is fine > by me. But still, it's quite puzzling and against the principle of > least surprise. It's one of those little things that is well known, but that won't change until I have time to look at it, and it's definitely not a high priority problem right now.
Re: Iked/unbound ~ more info.
On 2019-11-19, Dale C. wrote: > I don't know how unbound will be aware of iked couple/decouple, so I > wonder how I'd specify "as appropriate" in this case short of a DNS > failover from the remote side using forward-zones in unbound. It won't be aware unless you tell it. But if you're scripting you can use unbound-control's forward_remove/forward_add commands so could, for example, tell it to use your (known) server address. > I'll > take a look at unwind... unwind is more designed for doing things automatically (either recursing itself or picking up forwarders from DHCP), though you could set "forwarder" in the config file and reload it. Or if you're happy with an external provider you could set it to use e.g. 9.9.9.9 (which does support DoT) all the time.
Re: Best Practices for growing disk partitions on a server
On Tue, Nov 19, 2019 at 12:31:25PM +0200, Dumitru Moldovan wrote: On Sun, Nov 17, 2019 at 03:12:06PM -0800, Lev Lazinskiy wrote: This makes sense, but I was curious what the recommended approach is for a server that you cannot simply reinstall. A humble piece of advice from a fellow system admin... Never ever build a system that "you cannot simply reinstall." There should be at least two ways to redo everything: 1. From scratch using documentation or preferably a modern deployment system such as Ansible, Salt, etc. 2. From backup. This should be drilled from time to time, even without a practical need, just to make sure things work as expected. Yes, practice is not as simple as theory and I admit being guilty at times of every possible mistake in not following the above. :-] But, realistically speaking, as long as a system still functions, it should be reproducible. Document the setup, backup its configs and saved data, etc. May be bad advice for your situation, but this is what I used to do when migrating setups that were not documented or easy to redeploy: 1. Install the same OS on new hardware, in your case with a better partitioned drive. 2. rsync everything relevant to the new machine (but make sure it still boots afterwards and functions as expected, so amend boot manager files, hardware-dependant configs etc.). 3. Update relevant DNS records for affected services AND set packet redirection for services on the old machines until DNS propagation does its thing (which is usually much longer than expected, esp. for public services, even if you lower TTLs well in advance). If you don't have spare hardware for the migration, I guess you could use a spare VM until you repartition drives in your old hardware as needed. If you don't care about service disruption, I guess you could skip redirection. Hope that helps!
Re: Best Practices for growing disk partitions on a server
On Sun, Nov 17, 2019 at 03:12:06PM -0800, Lev Lazinskiy wrote: This makes sense, but I was curious what the recommended approach is for a server that you cannot simply reinstall. A humble piece of advice from a fellow system admin... Never ever build a system that "you cannot simply reinstall." There should be at least two ways to redo everything: 1. From scratch using documentation or preferably a modern deployment system such as Ansible, Salt, etc. 2. From backup. This should be drilled from time to time, even without a practical need, just to make sure things work as expected. Yes, practice is not as simple as theory and I admit being guilty at times of every possible mistake in not following the above. :-] But, realistically speaking, as long as a system still functions, it should be reproducible. Document the setup, backup its configs and saved data, etc.
Re: pkg_info -Q bug?
On Mon, Nov 18, 2019 at 11:15:05AM +0100, Antonio Bibiano wrote: Hello, I just wanted to add to this thread that I incurred in the same issue on a fresh 6.6 installation. I also tried with a different mirror in /etc/installurl and receive the same partial response from pkg_info -Q. What makes it even more odd is that pkg_add finds the correct package. Thanks Antonio for double-checking this! I have also tested it on a fresh installation at the time and got the same results. Maybe the behaviour is undefined if PKG_PATH is not set, which is fine by me. But still, it's quite puzzling and against the principle of least surprise.
