Re: VM with default gateway on different subnet, not working

2020-06-20 Thread Travis Cole 
On Sat, Jun 20, 2020, at 13:13, Pierre Emeriaud wrote:
> Try this:
> 
> $ cat /etc/hostname.vio0
> inet 158.69.128.109 255.255.255.255
> !route add 198.27.74.254 -link -iface vio0
> 
> The "gateway" to 198.27.74.254 should show as its mac address.

Awesome, this fixed it. -link was the thing I'd missed.

Now I have:
$ cat /etc/hostname.vio0
inet 158.69.128.109 255.255.255.255
!route add 198.27.74.254 -link -iface vio0
!route add default 198.27.74.254

And it works, thank you!

VM with default gateway on different subnet, not working

2020-06-19 Thread Travis Cole 
Hi there,

I've been struggling with this one for a while, so figured it was time to ask. 
After searching around a lot, I did find this very similar thread a few years 
back: https://marc.info/?t=148164912800052=1=2 but no fixes that address my 
issue.

Some background.

I have a dedicated server at OVH running FreeBSD 12.1 with bhyve. I'm trying to 
get an OpenBSD VM on the network, and so far failing.

OVH gave me a set of IPs to use for my VMs, but the default gateway is on a 
different subnet, so I need to tell the VMs what interface the default gateway 
is directly attached to. I'm bridging the VMs to the physical network.

The routing table on the OpenBSD 6.7 VM looks like this:

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 198.27.74.254 UGS 0 14 - 8 vio0
224/4 127.0.0.1 URS 0 15890 32768 8 lo0
127/8 127.0.0.1 UGRS 0 0 32768 8 lo0
127.0.0.1 127.0.0.1 UHhl 1 12 32768 1 lo0
158.69.128.109 02:00:00:4a:78:a8 UHLl 0 59138 - 1 vio0
158.69.128.109/32 158.69.128.109 UCn 0 0 - 4 vio0
198.27.74.254 158.69.128.109 UHSh 1 1848 - 8 vio0

And if I ping the gateway:
two$ ping 198.27.74.254
PING 198.27.74.254 (198.27.74.254): 56 data bytes
ping: sendmsg: Invalid argument
ping: wrote 198.27.74.254 64 chars, ret=-1
ping: sendmsg: Invalid argument
ping: wrote 198.27.74.254 64 chars, ret=-1
ping: sendmsg: Invalid argument
ping: wrote 198.27.74.254 64 chars, ret=-1
ping: sendmsg: Invalid argument
ping: wrote 198.27.74.254 64 chars, ret=-1
^C
--- 198.27.74.254 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

Arp shows nothing:
$ arp -an
Host Ethernet Address Netif Expire Flags
158.69.128.109 02:00:00:4a:78:a8 vio0 permanent l


I have a Linux vm on the same host and it works fine.

It's routing table looks like this:
$ ip route
default via 198.27.74.254 dev enp0s5
198.27.74.254 dev enp0s5 scope link


Ping and arp on the Linux vm also show what I'd expect:

$ ping 198.27.74.254
PING 198.27.74.254 (198.27.74.254) 56(84) bytes of data.
64 bytes from 198.27.74.254: icmp_seq=1 ttl=255 time=39.1 ms
64 bytes from 198.27.74.254: icmp_seq=2 ttl=255 time=0.593 ms
^C
--- 198.27.74.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 4ms
rtt min/avg/max/mdev = 0.593/19.852/39.112/19.260 ms
$ arp -an
? (198.27.74.254) at 00:07:b4:00:01:01 [ether] on enp0s5

Am I missing something obvious?

Re: heavy CPU consumption and laggy/stuttering video on thinkpad x230

2019-11-19 Thread Travis Cole 
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: xenocara xcursor issues?

2019-09-29 Thread Travis Cole 
On Sun, Sep 29, 2019, at 18:53, Jonathan Gray wrote:
> 
> suspend/resume currently does not work on amdgpu.
> 
> There is a problem with hardware cursor state on amdgpu. As a workaround
> try creating an /etc/X11/xorg.conf with:
> 
> Section "Device"
> Identifier "amdgpu"
> Option "SWcursor" "True"
> EndSection
> 
> 

That fixed it! Thank you!

xenocara xcursor issues?

2019-09-29 Thread Travis Cole 
I've been banging my head on this one long enough that I figured I'd just ask 
the list if anyone else is seeing this behavior.

I'm getting really inconsistent xcursor behavior.

I've tried setting a few xcursor themes, and they seem to only take 
inconsistently. 
On certain areas of applications they inconsistently default back to the X 
cursor 
(XC_X_cursor) and the xcursor often doesn't change how it's supposed to.

But this does seem to be triggered when crossing areas where the cursor is
supposed to change.

I spent a bunch of time hacking on dwm/st to see if the issue was there.
But finally just ran my same dwm/st config on an Arch Linux laptop I have
and the xcursors behave just fine there.

I also tried as a new user to rule out any dotfiles issues. The problem 
persists.

Finally, I installed gnome/gdm from ports, and same issue. Gnome sets
it's default xcursor theme, which works sometimes. But I also get it flipping
back to the X shaped xcursor and sometimes the xcursor will stick at the wrong
one, like stay at the window resize xcursor after resizing a window.

It seems like maybe some xcursor change events are getting missed
and or defaulting back to XC_X_cursor. 

For reference, this is on  the latest -CURRENT snapshot. On a Lenovo 
Thinkpad X395, which incidentally also has X crash on wake from sleep when 
trying to 
enable the graphics adapter.

Here is my dmesg for reference:

OpenBSD 6.6-beta (GENERIC.MP) #334: Sun Sep 29 17:32:12 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6298578944 (6006MB)
avail mem = 6094983168 (5812MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xb9ecc000 (63 entries)
bios0: vendor LENOVO version "R13ET37W(1.11 )" date 08/22/2019
bios0: LENOVO 20NLCTO1WW
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT SSDT TPM2 SSDT MSDM BATB HPET APIC MCFG SBST 
WSMT IVRS SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI
acpi0: wakeup devices GPP0(S3) GPP1(S3) GPP2(S3) GPP3(S3) GPP4(S3) L850(S3) 
GPP5(S3) GPP6(S3) GP17(S3) XHC0(S3) XHC1(S3) GP18(S3) LID_(S3) SLPB(S3)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.33 MHz, 17-18-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,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
tsc_timecounter_init: TSC skew=0 observed drift=0
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
TSC skew=0
cpu1: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.04 MHz, 17-18-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,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
tsc_timecounter_init: TSC skew=0 observed drift=0
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
TSC skew=0
cpu2: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.04 MHz, 17-18-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,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu2: ITLB 64 4KB entries

Re: Prometheus node_exporter on OpenBSD - anyone managed ?

2019-09-20 Thread Travis Cole 


> On Sep 20, 2019, at 01:38, Rachel Roch
> 
> Regarding the other gmake suggestion, that possibility occurred to me after 
> sending yesterday's email, but I guess I would have to edit various source 
> files to make sure its calling the right command.  Not rocket science I 
> guess, but equally could be time consuming to make sure I've caught all the 
> right spots in the code.

I tested it before sending the suggestion. I just ran gmake and it built fine.

Re: Prometheus node_exporter on OpenBSD - anyone managed ?

2019-09-19 Thread Travis Cole 


Looks like they are assuming GNU make.


Try doing the build with 'gmake'.


If you don't already have gmake installed:


# pkg_add gmake

On Thu, Sep 19, 2019 at 11:49:20PM +0200, Rachel Roch wrote:
> Hi,
> 
> The official Prometheus github repo 
> (https://github.com/prometheus/node_exporter) 
>  appears to suggest in multiple 
> places that node_exporter is capable of working on OpenBSD.
> 
> But although they provide pre-compiled binaries for multiple platforms 
> including NetBSD (https://github.com/prometheus/node_exporter/releases) 
>  they seemingly don't 
> provide a binary for OpenBSD.
> 
> So I tried downloading the source and compiling it, but I get a screenful of 
> nasty sounding messages, e.g.:
> Bad modifier: , ,$(shell $(GO) env GOPATH)))  
>    
> Bad modifier: , ,$(shell $(GO) env GOPATH)))  
>    
> No closing parenthesis in archive specification   
>    
> *** Parse error: Error in archive specification: "(, \.'))" 
> (Makefile.common:41)  
>    
> *** Parse error: Need an operator in 'else' (Makefile.common:51)  
>    
> *** Parse error: Need an operator in '' (Makefile.common:54)  
>    
> *** Parse error: Need an operator in '' (Makefile.common:55)  
>    
> *** Parse error: Need an operator in 'endif' (Makefile.common:61) 
>    
> Bad modifier: , ,$(shell go env GOPATH))) 
>    
> Bad modifier: , ,$(shell go env GOPATH))) 
> 
> 
> Given the popularity of Prometheus, I'm sure someone on-list must be actively 
> running it ?
> 
> Thanks !
> 
> Rachel
>