Re: EvolveIII laptop X quit working
On Tue, Jul 26, 2022 at 04:17:18AM +0100, Chris Narkiewicz wrote: > On Mon, Jul 25, 2022 at 11:02:25PM -0400, Nick Holland wrote: > > here's what got added to dmesg after I built and installed a kernel with > > that patch on my "problem" machine: > > > > ... snip ... > > drm_syncobj_array_wait_timeout:1173: schedule timeout 2147483646 > > You've hit the same problem as me. Could you also try some advice from > @jsg given on tech@ in topic "Xorg hanging on StarLabs Lite IV - > infinite sleep in ioctl drm_syncobj_array_wait_timeout"? > > He advised to check X without /usr/X11R6/lib/modules/dri/iris_dri.so > or by forcing i965 driver. It will probably start without DRI, but worth > checking for consistency. that doesn't fallback the way I thought it did instead try MESA_LOADER_DRIVER_OVERRIDE=i965 startx tested on a broadwell machine which defaults to iris $ xdriinfo Screen 0: i965 $ glxinfo -B name of display: :0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086) Device: Mesa DRI Intel(R) HD Graphics 5500 (BDW GT2) (0x1616) Version: 21.3.8 Accelerated: yes Video memory: 3072MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.6 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.1 OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (BDW GT2) OpenGL core profile version string: 4.6 (Core Profile) Mesa 21.3.8 OpenGL core profile shading language version string: 4.60 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 3.0 Mesa 21.3.8 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL ES profile version string: OpenGL ES 3.1 Mesa 21.3.8 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 When running iris "Open Source Technology Center" is not in the vendor string $ xdriinfo Screen 0: iris $ glxinfo -B name of display: :0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel (0x8086) Device: Mesa Intel(R) HD Graphics 5500 (BDW GT2) (0x1616) Version: 22.1.4 Accelerated: yes Video memory: 1536MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.6 Max compat profile version: 4.6 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) HD Graphics 5500 (BDW GT2) OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.1.4 OpenGL core profile shading language version string: 4.60 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.1.4 OpenGL shading language version string: 4.60 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.1.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
Re: EvolveIII laptop X quit working
On 7/25/22 4:34 PM, Chris Narkiewicz wrote: On Mon, Jul 25, 2022 at 03:48:19PM -0400, Nick Holland wrote: Sigh. collect info, leave out most basic part: what I mean by "X quit working"... I checked your Xorg.0.log and it looks familiar. Please look for post "X11 hangs on StarLabs Mk IV - snapshot 06-06-2022" in the bugs@ archive and recent discussion in t...@openbsd.org: "Xorg hanging on StarLabs Lite IV - infinite sleep in ioctl drm_syncobj_array_wait_timeout" Also, if you can boot a custom kernel, you could apply this patch to confirm my findings: https://github.com/ezaquarii/src/commit/0047e0f206896aa5287cad250c6bee1c994cdf88 https://github.com/ezaquarii/xenocara/commit/1d6e50bf668adfc07a4da0860d6c8f738ec1228a Once applied, it dumps some traces via stdout (xenocara) and dmesg (kernel). In my case, X hangs, but I can still SSH into the machine to dump dmesg and do some things. When pkill -9 X, it locks the machine for good. I hope we are on some path to fix it. @jsg FYI - it looks like we have another case of the Xorg hang on intel. Best regards, Chris Narkiewicz Thanks to Chris for a bit of hand-holding on getting diffs and files out of github. here's what got added to dmesg after I built and installed a kernel with that patch on my "problem" machine: ... wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 wsdisplay0: screen 1-5 added (std, vt100 emulation) drm_syncobj_wait_ioctl(): /usr/src/sys/dev/pci/drm/drm_syncobj.c:1340 drm_syncobj_wait_ioctl(): /usr/src/sys/dev/pci/drm/drm_syncobj.c:1363: array wait drm_syncobj_array_wait:1255: timeline: 0 jiffies from 0 ns drm_syncobj_array_wait_timeout:1120: fence add wait drm_syncobj_array_wait_timeout:1124 drm_syncobj_fence_add_wait:254: spinlock drm_syncobj_fence_add_wait:260: dma_fence_get drm_syncobj_fence_add_wait:263: dma_fence_put drm_syncobj_array_wait_timeout:1130: set interruptible drm_syncobj_array_wait_timeout:1159: done? drm_syncobj_array_wait_timeout:1178: set running drm_syncobj_array_wait_timeout:1182 cleanup drm_syncobj_array_wait_timeout:1185 [0/1] removed wait drm_syncobj_array_wait_timeout:1191 put fence drm_syncobj_array_wait_timeout:1194 cleanup done drm_syncobj_array_wait_timeout:1200 return drm_syncobj_wait_ioctl(): /usr/src/sys/dev/pci/drm/drm_syncobj.c:1340 drm_syncobj_wait_ioctl(): /usr/src/sys/dev/pci/drm/drm_syncobj.c:1363: array wait drm_syncobj_array_wait:1255: timeline: 0 jiffies from 287089654978 ns drm_syncobj_array_wait_timeout:1182 cleanup drm_syncobj_array_wait_timeout:1185 [0/1] removed wait drm_syncobj_array_wait_timeout:1191 put fence drm_syncobj_array_wait_timeout:1194 cleanup done drm_syncobj_array_wait_timeout:1200 return drm_syncobj_wait_ioctl(): /usr/src/sys/dev/pci/drm/drm_syncobj.c:1340 drm_syncobj_wait_ioctl(): /usr/src/sys/dev/pci/drm/drm_syncobj.c:1363: array wait drm_syncobj_array_wait:1255: timeline: 0 jiffies from 287092414092 ns drm_syncobj_array_wait_timeout:1120: fence add wait drm_syncobj_array_wait_timeout:1130: set interruptible drm_syncobj_array_wait_timeout:1139: check drm_syncobj_array_wait_timeout:1156: check done drm_syncobj_array_wait_timeout:1159: done? drm_syncobj_array_wait_timeout:1178: set running drm_syncobj_array_wait_timeout:1182 cleanup drm_syncobj_array_wait_timeout:1185 [0/1] removed wait drm_syncobj_array_wait_timeout:1187 [0/1] callback drm_syncobj_array_wait_timeout:1191 put fence drm_syncobj_array_wait_timeout:1194 cleanup done drm_syncobj_array_wait_timeout:1200 return drm_syncobj_wait_ioctl(): /usr/src/sys/dev/pci/drm/drm_syncobj.c:1340 drm_syncobj_wait_ioctl(): /usr/src/sys/dev/pci/drm/drm_syncobj.c:1363: array wait drm_syncobj_array_wait:1255: timeline: 0 jiffies from 287094029901 ns drm_syncobj_array_wait_timeout:1120: fence add wait drm_syncobj_array_wait_timeout:1130: set interruptible drm_syncobj_array_wait_timeout:1139: check drm_syncobj_array_wait_timeout:1156: check done drm_syncobj_array_wait_timeout:1159: done? drm_syncobj_array_wait_timeout:1178: set running drm_syncobj_array_wait_timeout:1182 cleanup drm_syncobj_array_wait_timeout:1185 [0/1] removed wait drm_syncobj_array_wait_timeout:1187 [0/1] callback drm_syncobj_array_wait_timeout:1191 put fence drm_syncobj_array_wait_timeout:1194 cleanup done drm_syncobj_array_wait_timeout:1200 return drm_syncobj_wait_ioctl(): /usr/src/sys/dev/pci/drm/drm_syncobj.c:1340 drm_syncobj_wait_ioctl(): /usr/src/sys/dev/pci/drm/drm_syncobj.c:1363: array wait drm_syncobj_array_wait:1255: timeline: 0 jiffies from 0 ns drm_syncobj_array_wait_timeout:1120: fence add wait drm_syncobj_array_wait_timeout:1124 drm_syncobj_fence_add_wait:254: spinlock drm_syncobj_fence_add_wait:260: dma_fence_get drm_syncobj_fence_add_wait:263: dma_fence_put drm_syncobj_array_wait_timeout:1130: set interruptible drm_syncobj_array_wait_timeout:1159: done? drm_syncobj_array_wait_timeout:1178: set running drm_syncobj_array_wait_timeout:1182 cleanup drm_syncobj_array_wait_timeout:1185 [0/1] removed wait drm_syncobj_a
Re: EvolveIII laptop X quit working
On 7/25/22 3:27 PM, Nick Holland wrote: Somewhere between 7.1 release and -current, X quit working on this machine. It is a really lousy machine, wireless doesn't work, slow, etc., and it cost $80 new (and is currently $60), so "What do you expect?" is a valid response. But in case someone cares... On 7.1, X "just worked". By May 12's snapshot, X had quit working (that's when I bought it, I went "back" to 7.1-rel to test it). ... Sigh. collect info, leave out most basic part: what I mean by "X quit working"... When running "startx", it blanks the screen, nothing more is seen on the screen. CTRL-ALT-F1, CTRL-ALT-F5, CTRL-ALT-Backspace all have no effect. Capslock key still results in change of the capslock light. If I ssh into the box, I can still look around, but a "reboot" results in a hung system, requiring a hard power down. top shows X is running, but attempting to kill it results in a hung box (caps lock quits responding, too). Same things happen with xenodm. Trying to isolate the task that causes the lockup, I was able to shutdown xenodm without problem, but the hang happened when I did a kill of this task: evolveiii# ps -ax |grep X 17869 ?? Zp 0:00.00 (Xorg) 88658 ?? I0:02.10 /usr/X11R6/bin/X :0 vt05 -auth /etc/X11/xenodm/authdir/authfiles/A:0-PkNh6u (Xorg) 21819 p0 R+/3 0:00.00 grep X evolveiii# kill 88658 evolveiii# ps -ax |grep X 17869 ?? Zp 0:00.00 (Xorg) 88658 ?? S0:02.10 /usr/X11R6/bin/X :0 vt05 -auth /etc/X11/xenodm/authdir/authfiles/A:0-PkNh6u (Xorg) 65248 p0 R+/2 0:00.00 grep X evolveiii# kill -9 88658 [hang] Nick.
Re: New release of C-Kermit
On 2022/07/24 15:26, Frank da Cruz wrote: > (Not a bug but I can't find any other email address at openbsd.org...) Hi Frank. Thanks for the notice, for the record po...@openbsd.org is the best place for mails about ports which don't have a specific maintainer . > You guys have the C-Kermit package here: > > http://ports.su/comms/kermit btw that site is out of date - the best places to check are cvsweb or the github mirror of the ports tree e.g. https://cvsweb.openbsd.org/ports/comms/kermit/ (the other 3rd-party site that people often find is openports.se which is also rather hit and miss, their parsing of the ports tree is a bit broken and they don't respond to our feedback). > And if you have any trouble building it, I'd appreciate it if you could let > me know. This patch is still needed; OpenBSD got rid of sys/timeb.h a while ago: https://cvsweb.openbsd.org/ports/comms/kermit/patches/patch-ckufio_c?rev=1.4&content-type=text/x-cvsweb-markup
