X11 Freeze and Crash on Lenovo Thinkpad T14 AMD GEN1
Hi, X11 randomly freeze and crash on Lenovo Thinkpad T14 AMD GEN1 with OpenBSD-current (OpenBSD 6.9 GENERIC.MP#461 amd64). I tried to reproduce it, but, it seems to be totally random. It crashed 2 times in one week due to segmentation fault. The last time it froze the whole system, leaving the system unusable without access to SSH or other running service on the system. This error is present in Xorg.0.log file but there no trace of it in other logs. Does someone have the same issue? Here Xorg.0.log file and dmesg is available on nycbug.org (https://dmesgd.nycbug.org/index.cgi?do=view&id=6009). [38.304] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem (Operation not permitted) Check that you have set 'machdep.allowaperture=1' in /etc/sysctl.conf and reboot your machine refer to xf86(4) for details [38.304]linear framebuffer access unavailable [38.340] (--) Using wscons driver on /dev/ttyC4 [38.362] X.Org X Server 1.20.10 X Protocol Version 11, Revision 0 [38.362] Build Operating System: OpenBSD 6.9 amd64 [38.362] Current Operating System: OpenBSD lyn.puffy 6.9 GENERIC.MP#461 amd64 [38.362] Build Date: 11 April 2021 06:02:54PM [38.362] [38.362] Current version of pixman: 0.38.4 [38.362]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [38.362] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [38.363] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Apr 12 13:47:49 2021 [38.364] (==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d" [38.366] (==) No Layout section. Using the first Screen section. [38.367] (==) No screen section available. Using defaults. [38.367] (**) |-->Screen "Default Screen Section" (0) [38.367] (**) | |-->Monitor "" [38.369] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [38.369] (==) Automatically adding devices [38.369] (==) Automatically enabling devices [38.369] (==) Not automatically adding GPU devices [38.370] (==) Max clients allowed: 256, resource mask: 0x1f [38.370] (==) 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/ [38.370] (==) ModulePath set to "/usr/X11R6/lib/modules" [38.370] (II) The server relies on wscons to provide the list of input devices. If no devices become available, reconfigure wscons or disable AutoAddDevices. [38.370] (II) Loader magic: 0xf1789c60f10 [38.370] (II) Module ABI versions: [38.370]X.Org ANSI C Emulation: 0.4 [38.370]X.Org Video Driver: 24.1 [38.370]X.Org XInput driver : 24.1 [38.370]X.Org Server Extension : 10.0 [38.371] (--) PCI:*(8@0:0:0) 1002:1636:17aa:5081 rev 209, Mem @ 0xc6000/268435456, 0xc7000/2097152, 0xfd30/524288, I/O @ 0x1000/256 [38.371] (II) LoadModule: "glx" [38.373] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so [38.395] (II) Module glx: vendor="X.Org Foundation" [38.395]compiled for 1.20.10, module version = 1.0.0 [38.395]ABI class: X.Org Server Extension, version 10.0 [38.395] (==) Matched ati as autoconfigured driver 0 [38.395] (==) Matched modesetting as autoconfigured driver 1 [38.395] (==) Assigned the driver to the xf86ConfigLayout [38.395] (II) LoadModule: "ati" [38.396] (II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.so [38.396] (II) Module ati: vendor="X.Org Foundation" [38.396]compiled for 1.20.10, module version = 19.1.0 [38.396]Module class: X.Org Video Driver [38.396]ABI class: X.Org Video Driver, version 24.1 [38.402] (II) LoadModule: "amdgpu" [38.403] (II) Loading /usr/X11R6/lib/modules/drivers/amdgpu_drv.so [38.407] (II) Module amdgpu: vendor="X.Org Foundation" [38.407]compiled for 1.20.10, module version = 19.1.0 [38.407]Module class: X.Org Video Driver [38.407]ABI class: X.Org Video Driver, version 24.1 [38.407] (II) LoadModule: "modesetting" [38.408] (II) Loading /usr/X11R6/lib/modules/drivers/modesetting_drv.so [38.410] (II) Module modesetting: vendor="X.Org Foundation" [38.410]compiled for 1.20.10, module version = 1.20.10 [38.410]Module class: X.Org Video Driver [38.410]ABI class: X.Org Video Driver, version 24.1 [38.410] (II) AMDGPU: Driver for AMD Radeon: All GPUs supported by the amdgpu kernel driver [38.410] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [38.419] (II) AMDGPU(0): [KMS] Kernel modeset
WireGuard, keepalive time doubled?
Hello! I was experimenting with wireguard keepalive and noticed that keepalive packets seems to be sent on double the time that I have set which I find a bit unintuitive. The peer is setup like this on side a wgpeer k wgpsk (present) wgpka 60 (sec) wgendpoint b.b.b.174 tx: 868, rx: 496 last handshake: 96 seconds ago wgaip c.c.c.33/32 debug log on side a 11:41:04 wg /bsd: wg0: Sending handshake initiation to peer 4 11:41:04 wg /bsd: wg0: Receiving handshake response from peer 4 11:41:04 wg /bsd: wg0: Sending keepalive packet to peer 4 11:41:04 wg /bsd: wg0: Receiving keepalive packet from peer 4 11:43:03 wg /bsd: wg0: Sending keepalive packet to peer 4 11:45:03 wg /bsd: wg0: Sending handshake initiation to peer 4 11:45:03 wg /bsd: wg0: Receiving handshake response from peer 4 11:45:03 wg /bsd: wg0: Sending keepalive packet to peer 4 11:45:03 wg /bsd: wg0: Receiving keepalive packet from peer 4 11:47:03 wg /bsd: wg0: Sending keepalive packet to peer 4 11:49:03 wg /bsd: wg0: Sending handshake initiation to peer 4 11:49:03 wg /bsd: wg0: Receiving handshake response from peer 4 11:49:03 wg /bsd: wg0: Sending keepalive packet to peer 4 11:49:03 wg /bsd: wg0: Receiving keepalive packet from peer 4 11:51:03 wg /bsd: wg0: Sending keepalive packet to peer 4 tcpdump on side b show the following traffic 11:41:03 a.a.a.64. > b.b.b.174.: [wg] initiation from 0x 11:41:03 b.b.b.174. > a.a.a.64.: [wg] response from 0x to 0x 11:41:04 a.a.a.64. > b.b.b.174.: [wg] keepalive to 0x nonce 0 11:41:04 b.b.b.174. > a.a.a.64.: [wg] keepalive to 0x nonce 0 11:43:03 a.a.a.64. > b.b.b.174.: [wg] keepalive to 0x nonce 1 11:45:03 a.a.a.64. > b.b.b.174.: [wg] initiation from 0x 11:45:03 b.b.b.174. > a.a.a.64.: [wg] response from 0x to 0x 11:45:03 a.a.a.64. > b.b.b.174.: [wg] keepalive to 0x nonce 0 11:45:03 b.b.b.174. > a.a.a.64.: [wg] keepalive to 0x nonce 0 11:47:03 a.a.a.64. > b.b.b.174.: [wg] keepalive to 0x nonce 1 11:49:03 a.a.a.64. > b.b.b.174.: [wg] initiation from 0x 11:49:03 b.b.b.174. > a.a.a.64.: [wg] response from 0x to 0x 11:49:03 a.a.a.64. > b.b.b.174.: [wg] keepalive to 0x nonce 0 11:49:03 b.b.b.174. > a.a.a.64.: [wg] keepalive to 0x nonce 0 11:51:03 a.a.a.64. > b.b.b.174.: [wg] keepalive to 0x nonce 1 Is this to be expected or am I missing something? Both sides run OpenBSD 6.8 amd64 if that affects anything. Best regards, Jan J
IKEv1 support with IKEv2 on the same router
Hello all! I have several partners working with different IKE versions. Is it possible to run iked and isakmpd on the same machine if I have two public IP addresses on it? On iksampd (IKEv1) it's simple, for example: /etc/isakmpd/isakmpd.conf [General] Listen-on=X.X.X.X Retransmits=32 Exchange-max-time=240 DPD-check-interval=30 Default-phase-1-lifetime=86400,60:86400 Default-phase-2-lifetime=86400,60:86400 But how to bind iked (IKEv2) to another address Y.Y.Y.Y? $ uname -r 6.7 -- wbr, Denis
Re: IKEv1 support with IKEv2 on the same router
On Wed, Apr 14, 2021 at 03:28:31PM +0300, Dev Op wrote: > Hello all! > > I have several partners working with different IKE versions. Is it possible > to run iked and isakmpd on the same machine if I have two public > IP addresses on it? > > On iksampd (IKEv1) it's simple, for example: > /etc/isakmpd/isakmpd.conf > [General] > Listen-on=X.X.X.X > Retransmits=32 > Exchange-max-time=240 > DPD-check-interval=30 > Default-phase-1-lifetime=86400,60:86400 > Default-phase-2-lifetime=86400,60:86400 > > But how to bind iked (IKEv2) to another address Y.Y.Y.Y? Running both on the same system isn't possible. As far as I understand it's not just about the UDP listening ports. It isn't possible to share the kernel's IPsec flow table cleanly between the two deamons. You should be able to work around this limitation by running one of the daemons in a virtual machine, e.g. in vmm(4), provided your hardware supports this. Check: grep ^vmm0 /var/run/dmesg.boot It is possible to bridge the VM's host-side network interface with the physical network interface. This way, the VM could directly use one of the two IP addresses, eliminating the need for NAT. > $ uname -r > 6.7 You should upgrade to 6.8 now. The 6.9 release is just around the corner.
Re: IKEv1 support with IKEv2 on the same router
Now it's clear to me. Thanks a lot! ср, 14 апр. 2021 г. в 15:54, Stefan Sperling : > On Wed, Apr 14, 2021 at 03:28:31PM +0300, Dev Op wrote: > > Hello all! > > > > I have several partners working with different IKE versions. Is it > possible > > to run iked and isakmpd on the same machine if I have two public > > IP addresses on it? > > > > On iksampd (IKEv1) it's simple, for example: > > /etc/isakmpd/isakmpd.conf > > [General] > > Listen-on=X.X.X.X > > Retransmits=32 > > Exchange-max-time=240 > > DPD-check-interval=30 > > Default-phase-1-lifetime=86400,60:86400 > > Default-phase-2-lifetime=86400,60:86400 > > > > But how to bind iked (IKEv2) to another address Y.Y.Y.Y? > > Running both on the same system isn't possible. As far as I understand > it's not just about the UDP listening ports. It isn't possible to share > the kernel's IPsec flow table cleanly between the two deamons. > > You should be able to work around this limitation by running one of the > daemons in a virtual machine, e.g. in vmm(4), provided your hardware > supports this. Check: grep ^vmm0 /var/run/dmesg.boot > It is possible to bridge the VM's host-side network interface with the > physical network interface. This way, the VM could directly use one of > the two IP addresses, eliminating the need for NAT. > > > $ uname -r > > 6.7 > > You should upgrade to 6.8 now. The 6.9 release is just around the corner. > -- С уважением, Денис *Это сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Уведомляем Вас о том, что использование, копирование, распространение информации, содержащейся в настоящем сообщении, запрещено.*
Re: X11 Freeze and Crash on Lenovo Thinkpad T14 AMD GEN1
niamkik writes: > Hi, > > Just got the same issue, this time, my connection was still present. Here the > message from dmesg after going into single-user mode by killing init process. > > [drm] *ERROR* ring sdma0 timeout, signaled seq=30079, emitted seq=30079 > [drm] *ERROR* Process information: process pid 0 thread pid 0 > > Xorg process was a zombie at this time. This behavior seems to be generated > when the screen is going blank, in my case, when xautolock is executed or > screensaver is set. My first crash was on 2nd April, just after using the > last current version at this time. It seems a user with a T14s with similar hardware reported issues with hibernate. [1] Does your system properly suspend/resume and hibernate/resume? I'm sadly no eXpert on X or drm...but if you're getting a segfault, it might be helpful to get the core dump and see what the stack was via gdb. -Dave [1] https://marc.info/?l=openbsd-bugs&m=161654860102192&w=2
Re: OT: Dell EMC switches
On 4/13/21 9:38 PM, Ivo Chutkin wrote: > Hello guys, > > Thanks for replies. To add some more info for the case. > > We have DWDM network with star topology. Switches will be connected to > center point with 100G uplink (currently 10G or 2x10G) via DWDM lambda. > Customers are connected to 10G ports. > > We carry Internet traffic and IPTV multicast to regional ISPs over VLANs. > > What is important for me is switch to be capable to carry traffic on > wire speed without packet loss. Latency is not big issue here. > > I will also have a look at Arista switches. > > Thanks a lot for the help, > Ivo In a previous day job, I did large-scale benchmarking of switches and routers from Arista, Cisco, Huawei, Juniper, and many other vendors. Switch ASICs have been commodities for years. Anything sold to enterprises or service providers runs at wire speed* without loss, provided the traffic pattern doesn't create oversubscription. You can force loss by creating an oversubscribed traffic topology (e.g., directing traffic from two or more ingress ports to one egress port), but then the loss is due to the traffic pattern (and to a small extent, the amount of buffer memory), not the switching silicon. Key point is that in terms of the RFC 1242 definition of throughput, you're going to see wire-speed performance for pretty much any enterprise-class switch, for any frame length. You're likely to see differences in latency and jitter, but not throughput. dn *This is really an edge case, but the definition of "wire speed" can differ between transmitting and receiving Ethernet ports because (a) Ethernet is asynchronous (each device uses its own free-running clock) and (b) device clocks can run at slightly different speeds and (c) even within a single device, its clock will vary around that speed by different amounts, depending on the precision of its clocking chip (a timing crystal with 10-ppm precision costs a LOT more than one with 100-ppm precision). As a result, you will see frame loss over time if a transmitter's clock runs slightly faster than a receiver's clock. Many benchmarks are run for a relatively short duration (e.g., 60-300 seconds) where buffering will cover for clocking differences. Run a test long enough, and frame loss may occur. There's no one correct answer here. The IEEE spec says every Ethernet interface must tolerate +/- 100 ppm of clocking variation, which can lead to loss for the reasons discussed above. The IETF RFC 1242/2544 and 2285/2889 specifications on router and switch testing define throughput as a zero-loss condition. There's been much discussion at the IETF about an acceptable loss threshold, but the only number everyone agrees on is zero. > > On 10.4.2021 г. 00:10 ч., Tom Smyth wrote: >> +1 re arista switches... >> >> On Friday, 9 April 2021, Diana Eichert wrote: >> >>> I second Arista switches, in my day job we use a lot of Arista >>> switches. Though one of the "issues" we see is Arista >>> drops older tech regularly. I believe their last presentation to us >>> was 25G/100G/400G switches. >>> >>> On Thu, Apr 8, 2021 at 1:18 PM Mischa wrote: Hi Ivo, I don’t have any experience with the Dell switches but what about the >>> Arista DCS-7050QX-32 or DCS-7050QX-32S? 32x40G QSFP+ for the 7050QX-32 32x40G QSFP+ of which one QSFP+ can act as a dual personality to 4xSFP+ >>> for the 7050QX-32S. (mind the S) There are converters for the QSFP+ to turn them into a SFP+ port if you >>> need more 10G but want to have a way to migrate to 40G. You can do this with the Mellanox 655902-001 QSA adapter. Which is pretty much what we have in production. :) Are you planning to buy new or eBay? There are some pretty good deals on >>> eBay. Mischa >>> >>> >> >
Re: X11 Freeze and Crash on Lenovo Thinkpad T14 AMD GEN1
Hi, Just got the same issue, this time, my connection was still present. Here the message from dmesg after going into single-user mode by killing init process. [drm] *ERROR* ring sdma0 timeout, signaled seq=30079, emitted seq=30079 [drm] *ERROR* Process information: process pid 0 thread pid 0 Xorg process was a zombie at this time. This behavior seems to be generated when the screen is going blank, in my case, when xautolock is executed or screensaver is set. My first crash was on 2nd April, just after using the last current version at this time.
Re: Working with encapsulated traffic using PF (pass incoming IPv4 from IPv6 gif tunnel)
> On 9 Apr 2021, at 18:55, Martin wrote: > > Hello list, > > I have working IPv4 OpenBSD router. There are no problems with native IPv4 > and IPv6 traffic filtering/redirecting at all. > > Now stuck with filtering IPv4 traffic encapsulated in IPv6 tunnel using gif > interface. > > IPv6 interface is tun0 which has assigned unique IPv6 address, and gif0 has > the same unique IPv6 as tun0 with wrapped IPv4 into IPv6 as shows in configs. > > The same configuration from the opposite side, except IPv4 and IPv6 source > and destination addresses reversed to make a tunnel. > > I'm not sure if I needed to use a bridge between tun0 and gif0 to have it > working. > > Looking for appropriate PF filtering rule to pass IPv4 encapsulated traffic > appearing on tun0 and blocks by "block all" PF rule for some reason. > > Any ideas welcome. > > === Side-a === > > # cat /etc/hostname.gif0 > # gif0 > up > description 'IPv4 over IPv6 tunnel' > # tunnel [src IPv6] [dst IPv6] > tunnel :::::18b5 :::::a503 > inet alias 10.190.0.1 > dest 10.190.0.2 > > # ifconfig tun0 > tun0: flags=8051 mtu 1500 >index 44 priority 0 llprio 3 >groups: tun >status: active >inet6 fe80::5054:ffc:fe04:f824%tun0 -> prefixlen 64 scopeid 0x2c >inet6 :::::18b5 -> prefixlen 48 > > === Side-b === > > # cat /etc/hostname.gif0 > # gif0 > up > description 'IPv4 over IPv6 tunnel' > # tunnel [src IPv6] [dst IPv6] > tunnel :::::a503 :::::18b5 > inet alias 10.190.0.2 > dest 10.190.0.1 > > # ifconfig tun0 > tun0: flags=8051 mtu 1500 >index 44 priority 0 llprio 3 >groups: tun >status: active >inet6 fe80::2a15:f3af:fefb:a3b0%tun0 -> prefixlen 64 scopeid 0x2c >inet6 :::::a503 -> prefixlen 48 > Hi Martin, bridge(4) only works with Ethernet interfaces, there is no equivalent to bridge(4) for tunnels. I don't think that's related or necessary for solving your problem though. Without a look at your ipv6 routing table it's hard to tell what could be happening here. My first impression is that your routers don't have routes for the IPv6 endpoints over the tun0 interfaces. For this to work, I'd expect to see something like this in your tun0 output: === Side-a === # ifconfig tun0 tun0: flags=8051 mtu 1500 index 44 priority 0 llprio 3 groups: tun status: active inet6 fe80::5054:ffc:fe04:f824%tun0 -> prefixlen 64 scopeid 0x2c inet6 :::::18b5 -> :::::a503 prefixlen 128 and: === Side-b === # ifconfig tun0 tun0: flags=8051 mtu 1500 index 44 priority 0 llprio 3 groups: tun status: active inet6 fe80::2a15:f3af:fefb:a3b0%tun0 -> prefixlen 64 scopeid 0x2c inet6 :::::a503 -> :::::18b5 prefixlen 128 This isn't strictly necessary though, the important thing is that the route to the dst IPv6 endpoint is over tun0. You should be able to check if that is the case with "route get [dst IPv6]" and looking for tun0 in the "interface:" line. You could also be able to ping6 between the IPv6 tunnel endpoints too. If ping6 isn't working, then I wouldn't expect gif traffic to work either. Cheers, dlg
