On Mon, Jul 25, 2022 at 12:21:00PM +0100, Chris Narkiewicz wrote: > > to see ioctls you can use ktrace/kdump > > Thank you for the hints. I'll try ktrace/kdump and I'll come back with > the results, probably somehere tomorrow. > > > what value do you mean by infinite? > > libiris sends ioctl() with timeout set to 0, which drm code in kernel > translates to INT64_MAX nanoseconds before converting it to jiffies. > > > drm_syncobj_array_wait_timeout() calls schedule_timeout() which calls > > sleep_setup() with timo 0 if the argument is MAX_SCHEDULE_TIMEOUT. > > It calls schedule_timeout(2147483646) exactly here: > https://github.com/ezaquarii/src/commit/0047e0f206896aa5287cad250c6bee1c994cdf88#r79272404
2147483646 is 0x7ffffffe, MAX_SCHEDULE_TIMEOUT - 1, which would come from drm_timeout_abs_to_jiffies() > > > A sleep without a timeout itself is not a problem as a wakeup would > > come from another part of the kernel. > > Apparently it does not get woken up and if I pkill -9 X in this state, > it locks up the machine. I have no access to serial port on this hardware, > so can't say if there is a kernel panic behind, but perhaps there is a method > to dump some data that would be accessible after power cycle? If you do sysctl ddb.panic=0 or set it in sysctl.conf, instead of going to the kernel debugger a crash dump will be written. This can take a while. savecore(8) can then stash it in /var/crash. See crash(8). If it is a hard lockup that won't help.
