Hi Zack, On 4/11/22 16:24, Zack Rusin wrote: > On Mon, 2022-04-11 at 10:52 +0200, Hans de Goede wrote: >> Hi All, >> >> Fedora has received a bug report here: >> >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D2072556&data=04%7C01%7Czackr%40vmware.com%7C3664ddfe25334b16109108da1b98a6af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637852639719382480%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GpkMy6OuPW06f%2Fzj%2FBGzoq8xT8pNsE6KtH0MTvN5FoA%3D&reserved=0 >> >> That Fedora rawhide VMs no longer boot under the VirtualBox >> hypervisor >> after the VM has been updated to a 5.18-rc# kernel. >> >> Switching the emulated GPU from vmwaregfx to VirtualBoxSVGA fixes >> this, so this seems to be a vmwgfx driver regression. >> >> Note I've not investigated/reproduced this myself due to -ENOTIME. > > Thanks for letting us know. Unfortunately we do not support vmwgfx on > VirtualBox. I'd be happy to review patches related to this, but it's > very unlikely we'd have to time to look at this ourselves. I somewhat understand where you are coming from, but this is not how the kernels "no regressions" policy works. For the end user a regression is a regression and as maintainers we are supposed to make sure any regressions noticed are fixed before a new kernel hits end user's systems. At a minimum it would have been good if you had tried to at least reproduce this bug by installing Fedora rawhide inside an actual vmware VM. I've just spend a couple of hours debugging this and the bug definitely impacts vmware VMs too; and thus very likely also reproduces there. I've a patch fixing this, which I will send out right after this email. Regards, Hans
