https://bugzilla.kernel.org/show_bug.cgi?id=208893 --- Comment #12 from Gordon (gordon@xxxxxxxxxxxxxx) --- I'm not certain but: - uint32_t cur_value, i, timeout = adev->usec_timeout * 10; if adev_usec_timeout is the microseconds timeout, then most likely the * 10 is wrong, as the below for loop uses microseconds too, so possibly they meant to add there too. Each iteration is 1 micro second, and the below code makes it 10 times that for the timeout, i think this explains the 'hanging' but not why it inconsistently breaks. Another few thoughts were: - Perhaps there is a period of messages on 'init' / startup where we are sending more. - I can only think the flaky behaviour is a memory issue, or a problem where the GPU is not being reset fully on boot. As it makes zero sense it works 'sometimes'. - When the message / error occours the 'timeout' is 10 times the value, thus blocking messages for the other startup events. - The display port being connected / or being interfaced with on init might be preventing the normal startup messages to be sent to the GPU. These GPUs have a problem in general with loss of display output, so if there is an electronics issue, maybe we don't have the 'hack' to make it work. IDK for sure, I'm new to kernel devel. I mainly work on Godot. -- You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
