Both 4k and non-4k displays had the same kernel lock-up issue. By lock-up, I meant the kernel freezes - the screen was black, neither the keyboard or serial terminal was responsive. This is one those those weird cases where no kernel oops printed. I’d recommend to check the differences between R27.1 and R28.1 during the display device initialization process, esp. places where the interrupt is locally and/or globally disabled.
Because HDMI non-4k is definitely covered within the test before we ship out rel-28.1, I don’t think it would be a general case…
How many monitors can you test? Sometimes there are display-modes which our kernel driver does not support.
Is kernel-lockup always with watchdog_timer crashed log? Could you provide the “full log” when error happens instead of the successful boot-up one?
That was the complete log and at its last line, the kernel locked up. I tested two monitors, one 4k and one 2560x1440, both lock up immediately after boot. For the 4k one, I’ve seen mostly wdt reset, and for the non-4k one, I have seen occasional successful boot but mostly just lock-up without even wdt reset.
Then, I would like to know
Non-4k edid + non-4k lock-up error log. The log in previous comment seems a successful one, right?
Just want make sure that are you using devkit? Because I hacked my device with your edid but got no kernel panic while boot up.