On 16/04/21(Fri) 16:50, Jérôme Frgacic wrote: > Thanks for your answer. :) > > > Could you set "sysctl kern.splassert=2" in order to get a useful stacktrace > > for this issue? This is probably where some attention is required. > > Sure, here is the new output I get. > > splassert: assertwaitok: want 0 have 9 > Starting stack trace... > assertwaitok() at assertwaitok+0x3c > malloc(5b8,91,d) at malloc+0x55 > intel_atomic_state_alloc(ffff800000202078) at intel_atomic_state_alloc+0x2f > drm_client_modeset_commit_atomic(ffff800000cf9a00,1) at > drm_client_modeset_commit_atomic+0x40 > drm_client_modeset_commit_locked(ffff800000cf9a00) at > drm_client_modeset_commit_locked+0x53 > drm_fb_helper_restore_fbdev_mode_unlocked(ffff800000cf9a00) at > drm_fb_helper_restore_fbdev_mode_unlocked+0x44 > intel_fbdev_restore_mode(ffff800000202078) at intel_fbdev_restore_mode+0x33 > db_ktrap(1,0,ffff800022e1c730) at db_ktrap+0x2c > kerntrap(ffff800022e1c730) at kerntrap+0x8e > alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b > db_enter() at db_enter+0x10 > internal_command(ffff80000064b600,ffff800022e1c88c,f420,1b) at > internal_command+0x281 > wskbd_translate(ffffffff82163d18,2,1) at wskbd_translate+0xdf > wskbd_input(ffff80000064b600,2,1) at wskbd_input+0x80 > pckbcintr_internal(ffffffff82175308,ffff800000647e80) at > pckbcintr_internal+0x11d > intr_handler(ffff800022e1c9c0,ffff800000647f80) at intr_handler+0x38
It seems that the DRM code that needs to be executed as a result of switching console, in wsdisplay_enter_ddb(), isn't playing nicely with ddb(4). Getting rid of the SPL checks is easy but then there's the way CPUs are parked and the relation with the sleeping points. Maybe we should simply disable this key combination when entered from a tty other than ttyC0 if drm(4) is used.
