15161 2023-07-14 13:07:54 +0000 qemuarm/nodistro/ linux-yocto 6.4 fails parselogs 2023-08-10 14:52:13 +0000 1 1 7 Build System, Metadata & Runtime OE-Core kernel 4.3 x86 Multiple RESOLVED FIXED High normal 4.3 M3 1 ross.burton ross.burton jdmason jon.mason randy.macleod tom.zanussi --- --- No (bug/feature does not impact docs) oldest_to_newest 95923 0 ross.burton 2023-07-14 13:07:54 +0000 Since linux-yocto upgraded to 6.4, qemuarm for nodistro fails in testimage's parselogs because the virtio framebuffer doesn't behave as before: [ 49.134] (DB) xf86MergeOutputClassOptions unsupported bus type 0 [ 49.138] (II) FBDEV(0): checking modes against framebuffer device... [ 49.144] (II) FBDEV(0): mode "640x480" test failed [ 49.148] (II) FBDEV(0): mode "640x480" test failed [ 49.153] (II) FBDEV(0): mode "640x480" test failed [ 49.157] (II) FBDEV(0): mode "640x480" test failed [ 49.159] (II) FBDEV(0): mode "640x480" not found Interestingly it works with poky, so presumably enabling GL in xserver results in a different codepath. 96016 1 ross.burton 2023-07-21 16:22:41 +0000 Jon bisected the kernel change down to: commit ee4cce0a8f03a3332ccf48ef8b420a65d02d1fcf (refs/bisect/bad) Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Apr 4 21:40:38 2023 +0200 drm/fb-helper: fix input validation gaps in check_var Apparently drivers need to check all this stuff themselves, which for most things makes sense I guess. And for everything else we luck out, because modern distros stopped supporting any other fbdev drivers than drm ones and I really don't want to argue anymore about who needs to check stuff. Therefore fixing all this just for drm fbdev emulation is good enough. Note that var->active is not set or validated. This is just control flow for fbmem.c and needs to be validated in there as needed. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230404194038.472803-3-daniel.vetter@ffwll.ch 96025 2 jon.mason 2023-07-24 14:45:42 +0000 It appears that this patch is zero'ing variables that were not touched previous, which is causing the issue. Specifically in __fill_var, var->left_margin = var->right_margin = 0; var->upper_margin = var->lower_margin = 0; var->hsync_len = var->vsync_len = 0; if those lines are removed, then it is happy again. The investigation as to why this was changed continues 96233 3 ross.burton 2023-08-10 14:52:13 +0000 Fixed in oe-core 366d7876a70ab8833ccc0cb6607aac7e8a0311b8.