Re: radeon driver bug?
I updated my -current version today, and found that the skeletal 3D animation runs very fine. Of course, any other models run fine, too. Thank you developpers to update drm drivers of amdgpu! It still has sometime to freeze the move (yes, about 30 seconds) when I do something like stop the motion etc,, however, I cannot confirm the precise condition of it yet... Kenji 2018年12月19日(水) 15:49 岡本健二 : > I made FreeBSD 12-Release on another disk of the same graphic (HD 6450 > graphic card), > and got success to run Jahshaka 3D animation. Yes, no animation stop! > It uses mesa-18.1.9. > Its colors are not so good as OpenBSD's mesa version, however, it works. > > Kenji > > > 2018年12月11日(火) 13:14 岡本健二 : > >> Ok, I upgraded my OpenBSD system to -current, and rebuild the Jahshaka. >> After all, the results are same as before. >> >> Skeletal Animations runs for less than 1 second, and halt for about 35 >> seconds, >> and then runs for less than 1 second, and halt for about 35 second(yes, >> it's same)... >> Above cycle continues eternally. >> >> Kenji >> >> >> 2018年12月10日(月) 1:23 tfrohw...@fastmail.com : >> >>> On December 9, 2018 1:22:42 AM UTC, "岡本健二" wrote: >>> >I found mesa-libs-18.1.9 for FreeBSD ports. >>> >How can I get it without FreeBSD system? >>> > >>> >Kenji >>> > >>> > >>> >2018年12月8日(土) 14:48 岡本健二 : >>> > >>> >> I installed Ubuntu 18.04 to a AMD 6450 graphic card, and played >>> >> Jahshaka. It has mesa version 18.2, and runs Jahshaka very >>> >> smoothly. >>> >> >>> >> The colors I reported before are same in this machine, so that >>> >> report was not correct. >>> >> >>> >> Kenji >>> >> >>> >> 2018年12月7日(金) 11:09 岡本健二 : >>> >> >>> >>> I checked mesa-18.3.0 sources under src/gallium/drivers/r600 and >>> >compared >>> >>> with those >>> >>> of xenocara. File names are all same, however, individual sizes are >>> >very >>> >>> different for >>> >>> most of those, which would not permit me to copy those to >>> >xenocara... >>> >>> >>> >>> Kenji >>> >>> >>> >>> >>> >>> 2018年12月6日(木) 15:14 岡本健二 : >>> >>> >>> also, it stull has some bugs, because the colors of some >>> parts are different from those of original ones. >>> >>> Kenji >>> >>> >>> 2018年12月6日(木) 15:10 岡本健二 : >>> >>> > Sorry, I'm a novice to OpenBSD. >>> > Yes, it's current branch of xenocara. >>> > I updated my xenocara (stable) to that current, and build new >>> >xenocara >>> > here. >>> > >>> > Wow, it makes the Jahshaka works! >>> > >>> > However, it still has some bugs, because it moves and stop >>> >suddenly and >>> > then >>> > move again. Whine the animation stops, the system seems to >>> >halting... >>> > >>> > Anyway it makes much advance, I included the screenshot of it. >>> > >>> > Kenji >>> > >>> > PS: sorry tfrohwein, this is doubled to you >>> > >>> > 2018年12月6日(木) 13:26 岡本健二 : >>> > >>> >> in-current means stable 6.4? >>> >> >>> >> Kenji >>> >> >>> >> 2018年12月5日(水) 23:58 tfrohw...@fastmail.com >>> >: >>> >> >>> >>> On December 5, 2018 9:41:44 AM UTC, "岡本健二" >>> >>> wrote: >>> >>> >This errors come from >>> >>> >>> >>/usr/xenocara/lib/mesa/src/gallium/drivers/r600/r600_state_common.c. >>> >>> >The mesa version of OpenBSD6.4 is 13.0.6. >>> >>> >I'm running this Jahshaka on Ubutu 18.04, where the mesa >>> >version is >>> >>> >18.x. >>> >>> > >>> >>> >So, it may be the mesa problem... >>> >>> > >>> >>> >Kenji >>> >>> > >>> >>> > >>> >>> >2018年12月4日(火) 16:19 岡本健二 : >>> >>> > >>> >>> >> I'm using AMD HD6450 graphic card which I reported before, >>> >and >>> >>> faced >>> >>> >a >>> >>> >> curious thing >>> >>> >> during running Jahshaka Studio (dev version 7.03a). >>> >>> >> To run Jahshaka on OpenBSD 6.4 I needed to delete google >>> >breakpad >>> >>> >> temporally, which >>> >>> >> is not the problem now. >>> >>> >> >>> >>> >> After start to run 'Jahshaka Studio', I got start 3D >>> >animation >>> >>> sample >>> >>> >> 'Skeletal Animation' data to load, then >>> >>> >> I got many errors included below which seems to come from >>> >radeon >>> >>> drm >>> >>> >> driver's bug to me. >>> >>> >> If you interested please check it. >>> >>> >> >>> >>> >> Thanks in advance >>> >>> >> >>> >>> >> Kenji >>> >>> >> >>> >>> >> >>> >>> >>> >>> There's a known bug where the shader on r600 uses too many >>> >registers: >>> >>> >>> >>> https://bugs.freedesktop.org/show_bug.cgi?id=99349 >>> >>> >>> >>> I encountered this bug with godot on a Radeon HD 7570, too, and >>> >it >>> >>> went away with the updated mesa that's in -current. >>> >>> >>> >> >>> >>> I think you are asking for way more than you (or most misc@ readers) >>> can handle. Porting low-level libraries from FreeBSD is far from trivial. >>> >>> My advice remains: if
[no subject]
unregister
Re: iked.conf insanity (passing traffic locally between two tunneled subnets)
On 2019-01-10, Daniel Ouellet wrote: >> OpenBSD's implementation of ipsec doesn't use the routing table, if you >> want that (unless you make code changes) you will need to use a >> different tunnel interface (gif or others) and just use ipsec to protect >> the gif traffic. > > The point is to keep the configuration simple and gif doesn't make it > so. But when the source is with changing IP's often it end up not being > very possible is it... > > So not really an option. > > May be time to check wireguard instead then. But not having it into the > kernel or fully mature yet on OpenBSD is also limiting. Or OpenVPN, or openconnect/ocserv, or ssh vpn, or strongswan, or [...] >> Sounds like you want bypass flows for 66.63.44.96/27 <> 66.63.44.64/27. >> IIRC you can still use ipsecctl/ipsec.conf to configure them even >> with iked running (the only bypass flows iked will add itself are the >> automatic "mess with v6 traffic" ones, there's no iked.conf way to do >> this flexibly). > > The point of ikev2 was to keep things simple and light. Doing the full > ipsec even doable is really a real pain in the butts. ikev2 is full ipsec. Maybe you misunderstood - I am just talking about a couple of lines in ipsec.conf to setup the bypass flow, but still use iked for the actual vpn connection.
Compile error at eglglobals.c in CURRENT version of Xenocara
Hi!
Anybody else having this issue with compiling CURRENT Xenocara?
/usr/xenocara/lib/mesa/src/egl/main/eglglobals.c:166:8: error: implicit decla
ration of function 'mincore' is invalid in C99 [-Werror,-Wimplicit-function-d
eclaration]
if (mincore((void *) addr, page_size, &valid) < 0) {
^
1 error generated.
I'm getting the above error on all of my amd64 hosts. i386 appears to compile
ok.
Have I missed something in Following the CURRENT?
- Jyri
--
+358-404-177133 (24/7)
jyri.hov...@turvamies.fi
smtpd - help needed tranlsating to new virtual map syntax
[Cross-posting here before I give up and switch to Postfix -Adam]
I have an old instance that uses smtpd's virtual to rewrite *sender*
addresses.
Reading the 6.4-STABLE version of the smtpd.conf(5) manpage, I can't see how to
accomplish my goal any more - it looks impossible.
I don't want to upgrade a working mail relay server to something that might be
broken, so I'm seeking assistance first.
The purpose of this system is purely to relay mail from internal, semi-broken-ish systems
out to our Office365 tenant, but I need to clean up bogus MAIL FROM / "From:"
headers first, lest they be flagged as spam.
In general, I think I'm asking how to use virtual with the "relay" action
in the new syntax - the manual tells me this is impossible!?
Thanks,
-Adam
Old smtpd.conf:
===start===
listen on 0.0.0.0
listen on ::
table aliases db:/etc/opensmtpd/aliases.db
table vmap db:/etc/opensmtpd/vmap.db
table localnets { 192.168.10.0/24, 192.168.100.0/24, 192.168.157.0/24,
192.168.158.0/24, 192.168.101.0/24, 10.158.0.0/16 }
accept from local for anyrelay via
smtp://XXX-ca.mail.protection.outlook.com hostname remote.XXX.ca
accept from source 192.168.158.63 for domain 192.168.158.63 virtual
deliver to lmtp localhost:25
accept from source 192.168.100.63 for domain 192.168.100.63 virtual
deliver to lmtp localhost:25
accept from source 192.168.158.63 for anyrelay via smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca hostname
remote.XXX.ca
accept from source 192.168.100.63 for anyrelay via smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca hostname
remote.XXX.ca
accept from source for anyrelay via
smtp://XXX-ca.mail.protection.outlook.com hostname remote.XXX.ca
===end===
old vmap:
===start===
ilom-alert@192.168.100.63: sys...@xxx.ca
sys...@xxx.ca: sys...@xxx.ca
sys...@ad.xxx.ca: sys...@xxx.ca
root@XXX.local: sys...@xxx.ca
===end===
Re: smtpd - help needed tranlsating to new virtual map syntax
It would be helpful if you show what you have tried.
Should be as simple as:
action "relay-01" lmtp /var/run/lmtp.sock virtual
match from src action "relay-01"
Edgar
On Jan 16, 2019 7:37 AM, Adam Thompson wrote:
>
> [Cross-posting here before I give up and switch to Postfix -Adam]
>
>
> I have an old instance that uses smtpd's virtual to rewrite *sender*
> addresses.
> Reading the 6.4-STABLE version of the smtpd.conf(5) manpage, I can't see how
> to accomplish my goal any more - it looks impossible.
>
> I don't want to upgrade a working mail relay server to something that might
> be broken, so I'm seeking assistance first.
>
> The purpose of this system is purely to relay mail from internal,
> semi-broken-ish systems out to our Office365 tenant, but I need to clean up
> bogus MAIL FROM / "From:" headers first, lest they be flagged as spam.
>
> In general, I think I'm asking how to use virtual with the "relay"
> action in the new syntax - the manual tells me this is impossible!?
>
> Thanks,
> -Adam
>
>
> Old smtpd.conf:
>
> ===start===
> listen on 0.0.0.0
> listen on ::
> table aliases db:/etc/opensmtpd/aliases.db
> table vmap db:/etc/opensmtpd/vmap.db
> table localnets { 192.168.10.0/24, 192.168.100.0/24, 192.168.157.0/24,
> 192.168.158.0/24, 192.168.101.0/24, 10.158.0.0/16 }
> accept from local for any relay via
> smtp://XXX-ca.mail.protection.outlook.com hostname remote.XXX.ca
> accept from source 192.168.158.63 for domain 192.168.158.63 virtual
> deliver to lmtp localhost:25
> accept from source 192.168.100.63 for domain 192.168.100.63 virtual
> deliver to lmtp localhost:25
> accept from source 192.168.158.63 for any relay via
> smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca hostname
> remote.XXX.ca
> accept from source 192.168.100.63 for any relay via
> smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca hostname
> remote.XXX.ca
> accept from source for any relay via
> smtp://XXX-ca.mail.protection.outlook.com hostname remote.XXX.ca
> ===end===
>
> old vmap:
>
> ===start===
> ilom-alert@192.168.100.63: sys...@xxx.ca
> sys...@xxx.ca: sys...@xxx.ca
> sys...@ad.xxx.ca: sys...@xxx.ca
> root@XXX.local: sys...@xxx.ca
> ===end===
>
>
Re: smtpd - help needed tranlsating to new virtual map syntax
As I said, I haven't tried anything yet as I don't want to break a working
system, and I don't have a good way to test this in parallel right now.
The manpage says "The local delivery methods support additional options: [...]
virtual" without specifying which delivery methods are "local". My assumption
was that only "mbox" and "mda" were local, as lmtp can, and often does, point
to another server.
Some brief experiments with a VM only got me syntax errors, so I didn't pursue
that very thoroughly before asking for clarification.
-Adam
-Original Message-
From: Edgar Pettijohn
Sent: Wednesday, January 16, 2019 8:12 AM
To: Adam Thompson ; misc@openbsd.org
Subject: Re: smtpd - help needed tranlsating to new virtual map syntax
It would be helpful if you show what you have tried.
Should be as simple as:
action "relay-01" lmtp /var/run/lmtp.sock virtual
match from src action "relay-01"
Edgar
On Jan 16, 2019 7:37 AM, Adam Thompson wrote:
>
> [Cross-posting here before I give up and switch to Postfix -Adam]
>
>
> I have an old instance that uses smtpd's virtual to rewrite *sender*
> addresses.
> Reading the 6.4-STABLE version of the smtpd.conf(5) manpage, I can't see how
> to accomplish my goal any more - it looks impossible.
>
> I don't want to upgrade a working mail relay server to something that might
> be broken, so I'm seeking assistance first.
>
> The purpose of this system is purely to relay mail from internal,
> semi-broken-ish systems out to our Office365 tenant, but I need to clean up
> bogus MAIL FROM / "From:" headers first, lest they be flagged as spam.
>
> In general, I think I'm asking how to use virtual with the "relay"
> action in the new syntax - the manual tells me this is impossible!?
>
> Thanks,
> -Adam
>
>
> Old smtpd.conf:
>
> ===start===
> listen on 0.0.0.0
> listen on ::
> table aliases db:/etc/opensmtpd/aliases.db table vmap
> db:/etc/opensmtpd/vmap.db table localnets { 192.168.10.0/24,
> 192.168.100.0/24, 192.168.157.0/24, 192.168.158.0/24,
> 192.168.101.0/24, 10.158.0.0/16 } accept from local
> for anyrelay via
> smtp://XXX-ca.mail.protection.outlook.com hostname remote.XXX.ca
> accept from source 192.168.158.63 for domain 192.168.158.63 virtual
> deliver to lmtp localhost:25 accept from source 192.168.100.63
> for domain 192.168.100.63 virtual deliver to lmtp localhost:25
> accept from source 192.168.158.63 for anyrelay via
> smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca hostname
> remote.XXX.ca accept from source 192.168.100.63 for any
> relay via smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca
> hostname remote.XXX.ca accept from source for any
>
> relay via smtp://XXX-ca.mail.protection.outlook.com hostname
> remote.XXX.ca ===end===
>
> old vmap:
>
> ===start===
> ilom-alert@192.168.100.63: sys...@xxx.ca
> sys...@xxx.ca: sys...@xxx.ca
> sys...@ad.xxx.ca: sys...@xxx.ca
> root@XXX.local: sys...@xxx.ca
> ===end===
>
>
Re: Compile error at eglglobals.c in CURRENT version of Xenocara
On 2019-01-16, Jyri Hovila [Turvamies.fi] wrote:
> Hi!
>
> Anybody else having this issue with compiling CURRENT Xenocara?
>
>
> /usr/xenocara/lib/mesa/src/egl/main/eglglobals.c:166:8: error: implicit decla
> ration of function 'mincore' is invalid in C99 [-Werror,-Wimplicit-function-d
> eclaration]
>if (mincore((void *) addr, page_size, &valid) < 0) {
>^
> 1 error generated.
>
>
> I'm getting the above error on all of my amd64 hosts. i386 appears to compile
> ok.
>
> Have I missed something in Following the CURRENT?
>
> - Jyri
> --
> +358-404-177133 (24/7)
> jyri.hov...@turvamies.fi
>
>
Wipe your build directory and try again. Most likely it has some
cache files from a previous autoconf run (mincore recently moved to
libc).
Re: iked.conf insanity (passing traffic locally between two tunneled subnets)
On Thu, Jan 10, 2019 at 5:13 AM Stuart Henderson wrote: > > On 2019-01-10, Daniel Ouellet wrote: > > 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. > > OpenBSD's implementation of ipsec doesn't use the routing table, if you > want that (unless you make code changes) you will need to use a > different tunnel interface (gif or others) and just use ipsec to protect > the gif traffic. > Dear all, Can someone point out an example of this gif+ipsec setup somewhere ? I failed at finding any GIF ref when looking IPSEC+OPENBSD, also man ipsec does not list gif, only enc. Best. -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
reorder_kernel: kernel relinking failed
Hello,
While rebooting on a freshly new installed OpenBSD 6.4 VM (using VMM on an
OpenBSD 6.4 server) I noticed that the kernel does not get relinked:
reorder_kernel: kernel relinking failed; see
/usr/share/relink/kernel/GENERIC/relink.log
The content of the /usr/share/relink/kernel/GENERIC/relink.log file shows:
(SHA256) /bsd: OK
LD="ld" sh makegap.sh 0x
ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS}
ioconf.o:(.data+0x37b8): undefined reference to `lii_ca'
ioconf.o:(.data+0x37c0): undefined reference to `lii_cd'
ioconf.o:(.data+0x6ee0): undefined reference to `loopattach'
i915_dma.o:(.rodata+0x4d0): undefined reference to `i915_gem_userptr_ioctl'
i915_gem.o: In function `i915_gem_init':
/usr/src/sys/dev/pci/drm/i915/i915_gem.c:5411: undefined reference to
`i915_gem_init_userptr'
*** Error 1 in /usr/share/relink/kernel/GENERIC (Makefile:985 'newbsd': @echo
ld -T ld.script -X --warn-common -nopie -o newbsd '${SYSTEM_HE...)
Anyone has an idea what it could be?
My VM has only 1 GB of memory, maybe that's not enough?
Regards,
Mabi
Re: Compile error at eglglobals.c in CURRENT version of Xenocara
Hi! > Wipe your build directory and try again. Most likely it has some > cache files from a previous autoconf run (mincore recently moved to > libc). You were spot on: rm -rf /usr/xenocara/* fixed it. Thank you! - Jyri
Re: vmm(4) on apu2c4
> > > > Are you using the -b option to vmctl? That seems to have a problem on AMD > CPUs. > > Try installing from install64.fs/.iso if that's the case. > > You are right, booting form the install64.iso works better than from bsd.rd. Thanks for the hint and your incredible work on vmd. After using linux/kvm for a long time vmd(8) and vmctl(8) feel like a fresh breath of mountain air.
Re: iked.conf insanity (passing traffic locally between two tunneled subnets)
> Maybe you misunderstood - I am just talking about a couple of lines in > ipsec.conf to setup the bypass flow, but still use iked for the > actual vpn connection. That's fair. May be I miss understood you, I thought that you recommended to actually switch to use the ipsec one instead. The setup the bypass flow doesn't it actually need to be up and running first, meaning setup both side of the vpn fro this? As for other solutions, sure there is other choice, but for decades I stick to the most simpler solution possible and call me stuburn, I do everything with OpenBSD, sure some stuff may be best with something else, but over time I got so comfortable with OpenBSd that I am welling to have a bit weird setup at times, or less efficient as well, just use more hardware when that happens. At my age I value piece of mind and sleep without disruption. The last time I use something else was NetBSD 1.61, Solaris 9, Debian Woody if I recall properly, The last release of BSDI, only commercial version I even used, RedHat 5.0 and FreeBSD 3.2. I tried Caldera in that same era, but could never setup it up properly so never touched it again after that wasted time with it. believe I tried 2 more distribution of Linux/GNU, but I can't recall them nor do I really care too either! So, call me OpenBSD limited mind fan boy and I will accept that. My son does! (; You reach an age where searching for days to try to find how to do something on the net with Linux or others, is really not where I want to pend my time and the fact that the man page on opneBSD are so good, yes I time they drive me crazy as some example are missing a bit, but after to get it to work once then after that fact you understand what they mean by their example in the man page. That's my one critic really. Sometime it take me a few days to get new stuff done, but still better then searching for weeks to find the version of Linus, of freebsd, or what not to try. My last test with with FreeBSD, just a few months ago and their NAT is in uselan and performance sucked real bad as my son convince me to give FreeBSD a trial on router performance that I needed, but that was a show stopper for me. So, yes Stuart, there is other choice out there you are 100% right, but consider me a stuborn bastard that like simple clean setup, that's why I will spend more time trying to have OpenBSD do what I need even if that might not be the best tool for the job simply because I am very comfortable with it and I trust it without questions! I have no clue how old you are and that's none of my business, but you will see as time goes, you will too try to make your life simpler and value the time you have more. (; So, if there is a way to do the flow bypass without having the full ikev1 running between the tunnels, I sure will give it a run. I didn't understood your statement as such sorry for my bad. Daniel
Where can I find X server's core files?
X server crashes and I can't find its core file for debugging purposes. [20.105] (--) checkDevMem: using aperture driver /dev/xf86 [20.121] (--) Using wscons driver on /dev/ttyC4 [20.172] X.Org X Server 1.19.6 Release Date: 2017-12-20 [20.172] X Protocol Version 11, Revision 0 [20.172] Build Operating System: OpenBSD 6.4 amd64 [20.172] Current Operating System: OpenBSD leo.lan 6.4 GENERIC.MP#618 amd64 [20.173] Build Date: 15 January 2019 04:38:07PM [20.173] [20.173] Current version of pixman: 0.34.0 [20.173]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [20.173] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [20.173] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jan 16 21:52:36 2019 [20.194] (==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d" [20.195] (==) No Layout section. Using the first Screen section. [20.195] (==) No screen section available. Using defaults. [20.195] (**) |-->Screen "Default Screen Section" (0) [20.195] (**) | |-->Monitor "" [20.198] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [20.198] (==) Automatically adding devices [20.198] (==) Automatically enabling devices [20.198] (==) Not automatically adding GPU devices [20.207] (==) Max clients allowed: 256, resource mask: 0x1f [20.317] (==) FontPath set to: /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/OTF/, /usr/X11R6/lib/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/100dpi/, /usr/X11R6/lib/X11/fonts/75dpi/ [20.317] (==) ModulePath set to "/usr/X11R6/lib/modules" [20.317] (II) The server relies on wscons to provide the list of input devices. If no devices become available, reconfigure wscons or disable AutoAddDevices. [20.327] (II) Loader magic: 0x3bfd918c000 [20.327] (II) Module ABI versions: [20.327]X.Org ANSI C Emulation: 0.4 [20.327]X.Org Video Driver: 23.0 [20.327]X.Org XInput driver : 24.1 [20.327]X.Org Server Extension : 10.0 [20.341] (--) PCI:*(0:0:1:0) 1002:1313:1462:7721 rev 0, Mem @ 0xc000/268435456, 0xd000/8388608, 0xfeb0/262144, I/O @ 0xf000/256, BIOS @ 0x/131072 [20.342] (II) LoadModule: "glx" [20.359] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so [20.520] (II) Module glx: vendor="X.Org Foundation" [20.521]compiled for 1.19.6, module version = 1.0.0 [20.521]ABI class: X.Org Server Extension, version 10.0 [20.570] (==) Matched ati as autoconfigured driver 0 [20.570] (==) Assigned the driver to the xf86ConfigLayout [20.570] (II) LoadModule: "ati" [20.570] (II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.so [20.581] (II) Module ati: vendor="X.Org Foundation" [20.581]compiled for 1.19.6, module version = 18.1.0 [20.581]Module class: X.Org Video Driver [20.581]ABI class: X.Org Video Driver, version 23.0 [20.582] (II) LoadModule: "radeon" [20.585] (II) Loading /usr/X11R6/lib/modules/drivers/radeon_drv.so [20.612] (II) Module radeon: vendor="X.Org Foundation" [20.612]compiled for 1.19.6, module version = 18.1.0 [20.612]Module class: X.Org Video Driver [20.612]ABI class: X.Org Video Driver, version 23.0 [20.613] (II) RADEON: Driver for ATI/AMD Radeon chipsets: ATI Radeon Mobility X600 (M24), ATI FireMV 2400, ATI Radeon Mobility X300 (M24), ATI FireGL M24 GL, ATI Radeon X600 (RV380), ATI FireGL V3200 (RV380), ATI Radeon IGP320 (A3), ATI Radeon IGP330/340/350 (A4), ATI Radeon 9500, ATI Radeon 9600TX, ATI FireGL Z1, ATI Radeon 9800SE, ATI Radeon 9800, ATI FireGL X2, ATI Radeon 9600, ATI Radeon 9600SE, ATI Radeon 9600XT, ATI FireGL T2, ATI Radeon 9650, ATI FireGL RV360, ATI Radeon 7000 IGP (A4+), ATI Radeon 8500 AIW, ATI Radeon IGP320M (U1), ATI Radeon IGP330M/340M/350M (U2), ATI Radeon Mobility 7000 IGP, ATI Radeon 9000/PRO, ATI Radeon 9000, ATI Radeon X800 (R420), ATI Radeon X800PRO (R420), ATI Radeon X800SE (R420), ATI FireGL X3 (R420), ATI Radeon Mobility 9800 (M18), ATI Radeon X800 SE (R420), ATI Radeon X800XT (R420), ATI Radeon X800 VE (R420), ATI Radeon X850 (R480), ATI Radeon X850 XT (R480), ATI Radeon X850 SE (R480), ATI Radeon X850 PRO (R480), ATI Radeon X850 XT PE (R480), ATI Radeon Mobility M7, ATI Mobility FireGL 7800 M7, ATI Radeon Mobility M6, ATI FireGL Mobility 9000 (M9), ATI Radeon Mobility 9000 (M9), ATI Radeon 9700 Pro, ATI Radeon 9700/9500Pro, ATI FireGL X1,
Re: Where can I find X server's core files?
On 1/16/2019 12:44 PM, Leonid Bobrov wrote: X server crashes and I can't find its core file for debugging purposes. #find / -name '*.core'
Re: Where can I find X server's core files?
On 2019-01-16, Leonid Bobrov wrote: > --QoubChxHWbb7Nqw2 > Content-Type: text/plain; charset="utf-8" > Content-Disposition: inline > > X server crashes and I can't find its core file for debugging purposes. See "How to get a core file out of the X server?" in /usr/xenocara/README if you have a checkout, otherwise read it via cvsweb.
Re: Where can I find X server's core files?
On Wed, Jan 16, 2019 at 12:57:30PM -0800, Misc User wrote: > On 1/16/2019 12:44 PM, Leonid Bobrov wrote: > > X server crashes and I can't find its core file for debugging purposes. > > > > #find / -name '*.core' Before asking that question I did this check.
Re: vultr
On Tue, Jan 15, 2019 at 09:47:52PM +, Étienne wrote: > On 06/01/2019 16:38, Juan Francisco Cantero Hurtado wrote: > > > > Use their default OpenBSD install. They have a special config on the > > host for OpenBSD and the clock drifting problem. > > > Can you tell us more? Do you mean they change a setting on the host machine > just for the OpenBSD guest, that they wouldn't otherwise? They use the sysctl kvm-intel.preemption_timer=0 on the Linux host when you select OpenBSD. That fixes the clock drifting problem. The technical details: https://marc.info/?l=openbsd-bugs&m=151439799628499&w=2 > > Then download bsd.rd from an official OpenBSD mirror, check the file > > with signify, copy the file to /, reboot the system, run "boot bsd.rd" > > in the boot prompt and reinstall everything cleaning the whole disk. > > > Thanks for the tip, been wondering for a while how to fix this. > > -- > Étienne > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: iked.conf insanity (passing traffic locally between two tunneled subnets)
> Maybe you misunderstood - I am just talking about a couple of lines in > ipsec.conf to setup the bypass flow, but still use iked for the > actual vpn connection. I should have added that may not be the best idea but I was/am trying rdomain for this, (having the bypass in rdomain 1 as an idea) not being successful yet at having a rdomain working to know the answer to this at this time, I was/am trying to find out if iked address space that it interact on is ONLY what would it normally be seen in the rdomain 0 or not. Is that the case and safe to assume that what ever address space you have in other rdomain, when iked have flow configure what ever they might be, will not interact with the table of other rdomain unless specifically sent there (rdomain 0) by pf or by route added specifically to that effect in the routing table? In other words are the flow of iked or when you do the ipsecctl -sf They will affect ONLY the space normally in rdomain 0 or any/all of them regardless of their rdomain space?
Re: iked.conf insanity (passing traffic locally between two tunneled subnets)
> Can someone point out an example of this gif+ipsec setup somewhere ? > > I failed at finding any GIF ref when looking IPSEC+OPENBSD, also man > ipsec does not list gif, only enc. This is dated obviously and for full disclosure I didn't try it, so look at it as such. https://undeadly.org/cgi?action=article&sid=20131105075303 There is more then what you asked, however the idea is the same I suppose. It may be what you need or not.
Re: iked.conf insanity (passing traffic locally between two tunneled subnets)
On 2019-01-16, Daniel Ouellet wrote: >> Maybe you misunderstood - I am just talking about a couple of lines in >> ipsec.conf to setup the bypass flow, but still use iked for the >> actual vpn connection. > > That's fair. May be I miss understood you, I thought that you > recommended to actually switch to use the ipsec one instead. > > The setup the bypass flow doesn't it actually need to be up and running > first, meaning setup both side of the vpn fro this? Not afaik. I haven't tested setting it up before bringing up a VPN but I don't see any reason why it wouldn't work whether it's setup before or after. It just creates an entry in the kernel's flow database. You don't actually even need an ipsec.conf file, you could just do $ echo 'flow from 192.0.2.1/32 to 192.0.2.2/32 type bypass' | doas ipsecctl -vf - (though it's easier to have it configured automatically if you do have the file present, you then just set "ipsec=yes" in rc.conf.local). > As for other solutions, sure there is other choice, but for decades I > stick to the most simpler solution possible and call me stuburn, I do > everything with OpenBSD, sure some stuff may be best with something > else, but over time I got so comfortable with OpenBSd that I am welling > to have a bit weird setup at times, or less efficient as well, just use > more hardware when that happens. The problem with weird setups is that, by definition, you're running things which aren't particularly likely to be tested by others. Meaning that there's less chance of others finding bugs that might affect your configuration before you find them the hard way :-) > I have no clue how old you are and that's none of my business, but you > will see as time goes, you will too try to make your life simpler and > value the time you have more. (; Old enough to value simplicity :) > So, if there is a way to do the flow bypass without having the full > ikev1 running between the tunnels, I sure will give it a run. > > I didn't understood your statement as such sorry for my bad. No worries! Sorry for skipping the bits about rdomains, I have only run with them in very simple cases and 0 experience mixing with ipsec.
Re: iked.conf insanity (passing traffic locally between two tunneled subnets)
On 2019-01-16, sven falempin wrote: > On Thu, Jan 10, 2019 at 5:13 AM Stuart Henderson wrote: >> >> On 2019-01-10, Daniel Ouellet wrote: >> > 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. >> >> OpenBSD's implementation of ipsec doesn't use the routing table, if you >> want that (unless you make code changes) you will need to use a >> different tunnel interface (gif or others) and just use ipsec to protect >> the gif traffic. >> > > Dear all, > > Can someone point out an example of this gif+ipsec setup somewhere ? > > I failed at finding any GIF ref when looking IPSEC+OPENBSD, also man > ipsec does not list gif, only enc. Briefly, gif(4) is an L3 tunnel interface which can transport IP(v4/v6)/MPLS inside other IP packets. Alternatively there is gre(4) which is a different but similar protocol (actually the docs in the gre manual are a bit more complete so that might be an easier starting point - for this use you can ignore all the EGRE/NVGRE bits - I generally use gif where possible as it has a little lower per-packet overhead, config for gif is similar to gre). These are general purpose tunnel protocols and can run either with or without ipsec - in the case of ipsec you would setup ipsec in transport mode just to protect communications between the addresses of the two routers, and run the tunnel over that. I suggest trying just setting up a simple tunnel without ipsec for starters to get a feel for how it works, when you have it working then look at adding ipsec. (Beware old guides for gif+vether bridges - gif used to be a "dual mode" layer 2 or layer 3 tunnel device - guides using gif+vether were using the L2 mode which has since been moved to etherip - you could also do what you're looking for that way, but it's higher overhead again because you have ethernet *and* a second set of IP headers).
Re: iked.conf insanity (passing traffic locally between two tunneled subnets)
> You don't actually even need an ipsec.conf file, you could just do > > $ echo 'flow from 192.0.2.1/32 to 192.0.2.2/32 type bypass' | doas ipsecctl > -vf - That would actually be a very simple solution and I would sure love it! But testing doesn't show that as being the case. packets are still being forwarded to enc0 even if they show as being bypass in the ipsecctl -sf I did the forward and reverse entry to see the results. Setup two server real quick to test and here the results with the simpler shorter version of iked.conf and adding the bypass: gateway$ doas cat /etc/iked.conf 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/28 to 0.0.0.0/0 \ peer tunnel.realconnect.com gateway$ echo 'flow from 66.63.44.96/28 to 66.63.44.64/27 type bypass' | doas ipsecctl -vf - gateway$ echo 'flow from 66.63.44.64/27 to 66.63.44.96/28 type bypass' | doas ipsecctl -vf - And then check the flow to see if the bypass are present and they are as below: gateway$ doas ipsecctl -sf flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 0.0.0.0/0 to 66.63.44.96/28 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.0.0/18 to 66.63.44.67 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.5.245 to 66.63.44.65 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.5.250 to 66.63.44.65 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.5.250 to 100.36.20.77 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.44.64/27 to 66.63.44.96/28 type bypass flow esp in from 66.63.44.96/28 to 66.63.44.64/27 type bypass flow esp in from 216.15.33.137 to 66.63.44.67 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp out from 66.63.44.64/27 to 66.63.44.96/28 type bypass flow esp out from 66.63.44.65 to 66.63.5.245 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.65 to 66.63.5.250 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.66 to 0.0.0.0/0 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.67 to 66.63.0.0/18 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.67 to 216.15.33.137 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.90 to 0.0.0.0/0 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.96/28 to 0.0.0.0/0 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.96/28 to 66.63.44.64/27 type bypass flow esp out from 100.36.20.77 to 66.63.5.250 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from ::/0 to ::/0 type deny But the packets are still sent to the enc0 however. tcpdump show that: gateway$ doas tcpdump -nli enc0 | grep icmp tcpdump: listening on enc0, link-type ENC 17:29:15.778857 (authentic,confidential): SPI 0x1a672fb3: 66.63.44.90 > 66.63.44.99: icmp: echo request (encap) 17:29:15.784287 (authentic,confidential): SPI 0xac2b658e: 66.63.44.90 > 66.63.44.99: icmp: echo request (encap) 17:29:16.789014 (authentic,confidential): SPI 0x1a672fb3: 66.63.44.90 > 66.63.44.99: icmp: echo request (encap) 17:29:16.793698 (authentic,confidential): SPI 0xac2b658e: 66.63.44.90 > 66.63.44.99: icmp: echo request (encap) 17:29:17.799066 (authentic,confidential): SPI 0x1a672fb3: 66.63.44.90 > 66.63.44.99: icmp: echo request (encap) 17:29:17.803543 (authentic,confidential): SPI 0xac2b658e: 66.63.44.90 > 66.63.44.99: icmp: echo request (encap) ^C 44 packets received by filter 0 packets dropped by kernel if the bypass was active it shouldn't reach enc0 but go between re1 and re2 as shown in the routing table for the test: gateway$ doas route -n show -inet Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default100.36.20.1
Re: reorder_kernel: kernel relinking failed
On Wed, Jan 16, 2019 at 03:04:49PM +, mabi wrote:
> Hello,
>
> While rebooting on a freshly new installed OpenBSD 6.4 VM (using VMM on an
> OpenBSD 6.4 server) I noticed that the kernel does not get relinked:
>
> reorder_kernel: kernel relinking failed; see
> /usr/share/relink/kernel/GENERIC/relink.log
>
> The content of the /usr/share/relink/kernel/GENERIC/relink.log file shows:
>
> (SHA256) /bsd: OK
> LD="ld" sh makegap.sh 0x
> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o
> ${OBJS}
> ioconf.o:(.data+0x37b8): undefined reference to `lii_ca'
> ioconf.o:(.data+0x37c0): undefined reference to `lii_cd'
> ioconf.o:(.data+0x6ee0): undefined reference to `loopattach'
> i915_dma.o:(.rodata+0x4d0): undefined reference to `i915_gem_userptr_ioctl'
> i915_gem.o: In function `i915_gem_init':
> /usr/src/sys/dev/pci/drm/i915/i915_gem.c:5411: undefined reference to
> `i915_gem_init_userptr'
> *** Error 1 in /usr/share/relink/kernel/GENERIC (Makefile:985 'newbsd': @echo
> ld -T ld.script -X --warn-common -nopie -o newbsd '${SYSTEM_HE...)
>
> Anyone has an idea what it could be?
>
> My VM has only 1 GB of memory, maybe that's not enough?
>
> Regards,
> Mabi
>
>
Looks like your /usr/share/relink/kernel/GENERIC.MP/*.o files got trashed
somehow? Or perhaps you ran out of space?
-ml
Re: iked.conf insanity (passing traffic locally between two tunneled subnets)
Just to add more on this, something that makes no sense to me and that I do not understand. Just adding to what's below a simple additional flow as this gateway$ doas echo 'flow from 66.63.44.90 to 66.63.44.100 type bypass' | ipsecctl -vf - even if there isn't anything at 66.63.44.100, will make the flow from 66.63.44.90 to anything else all work Looks like somehow the bypass flows will not process CIDR properly without some additional one. gateway# ipsecctl -sf flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 0.0.0.0/0 to 66.63.44.96/28 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.0.0/18 to 66.63.44.67 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.5.245 to 66.63.44.65 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.5.250 to 66.63.44.65 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.5.250 to 100.36.20.77 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.44.64/27 to 66.63.44.96/28 type bypass flow esp in from 66.63.44.96/28 to 66.63.44.64/27 type bypass flow esp in from 66.63.44.100 to 66.63.44.90 type bypass flow esp in from 216.15.33.137 to 66.63.44.67 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp out from 66.63.44.64/27 to 66.63.44.96/28 type bypass flow esp out from 66.63.44.65 to 66.63.5.245 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.65 to 66.63.5.250 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.66 to 0.0.0.0/0 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.67 to 66.63.0.0/18 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.67 to 216.15.33.137 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.90 to 0.0.0.0/0 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.90 to 66.63.44.100 type bypass flow esp out from 66.63.44.96/28 to 0.0.0.0/0 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from 66.63.44.96/28 to 66.63.44.64/27 type bypass flow esp out from 100.36.20.77 to 66.63.5.250 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type require flow esp out from ::/0 to ::/0 type deny On 1/16/19 5:36 PM, Daniel Ouellet wrote: >> You don't actually even need an ipsec.conf file, you could just do >> >> $ echo 'flow from 192.0.2.1/32 to 192.0.2.2/32 type bypass' | doas ipsecctl >> -vf - > > That would actually be a very simple solution and I would sure love it! > > But testing doesn't show that as being the case. packets are still being > forwarded to enc0 even if they show as being bypass in the ipsecctl -sf > > I did the forward and reverse entry to see the results. Setup two server > real quick to test and here the results with the simpler shorter version > of iked.conf and adding the bypass: > > gateway$ doas cat /etc/iked.conf > 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/28 to 0.0.0.0/0 \ > peer tunnel.realconnect.com > > gateway$ echo 'flow from 66.63.44.96/28 to 66.63.44.64/27 type bypass' | > doas ipsecctl -vf - > > gateway$ echo 'flow from 66.63.44.64/27 to 66.63.44.96/28 type bypass' | > doas ipsecctl -vf - > > And then check the flow to see if the bypass are present and they are as > below: > > gateway$ doas ipsecctl -sf > flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 0.0.0.0/0 to 66.63.44.96/28 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 66.63.0.0/18 to 66.63.44.67 peer 66.63.5.250 srcid >
mouse not recognized
Hello, When I plug in my USB mouse after starting xenodm it does not seem to be recognized by X: it cannot move the cursor and there is no output in xev, while the builtin touchpad functions normally. It is recognized by the kernel, though; the following is printed to dmesg when I unplug and replace it: wskbd1: disconnecting from wsdisplay0 wskbd1 detached ukbd0 detached uhidev0 detached wsmouse1 detached ums0 detached uhid0 detached uhid1 detached uhid2 detached uhid3 detached uhidev1 detached uhidev0 at uhub0 port 2 configuration 1 interface 0 "Logitech USB Receiver" rev 2.00/15.00 addr 5 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 variable keys, 6 key codes wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev1 at uhub0 port 2 configuration 1 interface 1 "Logitech USB Receiver" rev 2.00/15.00 addr 5 uhidev1: iclass 3/1, 17 report ids ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir wsmouse1 at ums0 mux 0 uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 uhid2 at uhidev1 reportid 16: input=6, output=6, feature=0 uhid3 at uhidev1 reportid 17: input=19, output=19, feature=0 When the mouse is present when xenodm is started or reset after exiting a wm, it works as expected, even after being later unplugged and replaced. pledge.txt.sig Description: PGP signature
Re: reorder_kernel: kernel relinking failed
‐‐‐ Original Message ‐‐‐ On Wednesday, January 16, 2019 11:48 PM, Mike Larkin wrote: > Looks like your /usr/share/relink/kernel/GENERIC.MP/*.o files got trashed > somehow? Or perhaps you ran out of space? So in the GENERIC directory there are 1311 *.o files, exactly the same amount as another OpenBSD 6.4 VM which does not have this issue. Maybe one of these files are corrupt, I didn't test for integrity. My /usr partition is 5 GB and has 0.6 GB used so I don't think it's the space. As this system is new I might just re-install the VM today and keep you posted.
