Am 12.12.23 um 12:26 schrieb Igor Mammedov: > > it's not necessary, but it would help to find out what's going wrong faster. > Otherwise we would need to fallback to debugging over email. > Are you willing to help with testing/providing debug logs to track down > the cause?. > I submitted the dmesg logs in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=218255 > Though debug over email would be slow, so our best option is to revert > offending patches until the cause if found/fixed. > >>>>> Do you have to revert both cc22522fd55e2 and 40613da52b13f to make it >>>>> work reliably? If we have to revert something, reverting one would be >>>>> better than reverting both. >>>> >> >> Just reverting cc22522fd55e2 is not enough (and cc22522fd55e2 fixes >> 40613da52b13f so I can't revert just 40613da52b13f). > > With UEFI setup, it still works for me fine with current master. > > Kernel 6.7.0-rc5-00014-g26aff849438c on an x86_64 (ttyS0) > I also built from current master (still 26aff849438c) to verify and it's still broken for me. > > it still doesn't work with Fedora's 6.7.0-0.rc2.20231125git0f5cc96c367f.26.fc40.x86_64 kernel. > However it's necessary to have -smp 4 for it to break, > with -smp 1 it works fine as well. > For me it's (always with build from current master): -smp 1 -> it worked 5 times out of 5 -smp 2 -> it worked 3 times out of 5 -smp 4 -> it worked 0 times out of 5 -smp 8 -> it worked 0 times out of 5 Best Regards, Fiona