Hi, On 6/15/22 07:01, Ian Laurie wrote: > On 6/12/22 14:34, Sérgio Basto wrote: >> On Sun, 2022-06-12 at 13:59 +1000, Ian Laurie wrote: >>> On 6/12/22 11:20, Ian Laurie wrote: >>>> On 6/12/22 09:46, Ian Laurie wrote: >>>>> On 6/12/22 00:58, Hans de Goede wrote: >>>>>> Hi, >>>>>> >>>>>> On 6/11/22 01:02, Alexander G. M. Smith wrote: >>>>>>> On 2022-06-08 15:00, Alexander G. M. Smith wrote: >>>>>>>> Ian Laurie wrote on Friday, 3 June 2022 at 11:17 p.m.: >>>>>>>>> Is anyone else seeing crashes and other strange events in >>>>>>>>> VirtualBox >>>>>>>>> 6.1.34 (from RPMFusion) with Linux guests when the Linux >>>>>>>>> host is >>>>>>>>> running >>>>>>>>> Fedora 36 with kernel-5.17.12? >>>>>>>> [...] >>>>>>>> The weird thing is that it works on other CPUs, an AMD >>>>>>>> Athlon X2 >>>>>>>> and an Intel 10th generation i5-10500H. Just my Ivy Bridge >>>>>>>> Intel >>>>>>>> i7-4820K has the problem. I did try the kernel boot >>>>>>>> parameter >>>>>>>> mitigations=off, in case the Spectre or other workarounds >>>>>>>> were >>>>>>>> wrong for Ivy Bridge, but it still didn't work. >>>>>>> One more data point. It fails on an Intel i5-750 too. Same >>>>>>> broken >>>>>>> data connections and failed checksums. >>>>>>> >>>>>>> My go-to test is to use "dnf clean" followed by "dnf upgrade" >>>>>>> running as root in a console (thus no networking is between >>>>>>> keyboard and computer - pipes often fail). My server >>>>>>> snapshot >>>>>>> fails to get through the complete dnf upgrade on kernel >>>>>>> 5.17.13, >>>>>>> works fine if booting the host with the earlier kernel >>>>>>> 5.17.11 >>>>>>> (using the GRUB boot menu to pick the older OS). >>>>>>> >>>>>>> So, should we report this to VirtualBox? They seem like the >>>>>>> most >>>>>>> appropriate people. Kernel people would be a possibility? >>>>>>> >>>>>>> Found a relevant bug report: >>>>>>> https://www.virtualbox.org/ticket/20976 >>>>>>> >>>>>>> And a forum discussion: >>>>>>> https://forums.virtualbox.org/viewtopic.php?f=7&t=106071 >>>>>>> >>>>>>> Though they don't know that it only happens on certain CPUs >>>>>>> (or >>>>>>> motherboards or ?). I'll add some notes about that there. >>>>>> Note the rpmfusion VirtualBox packages now include this fix: >>>>>> https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_kernel_5.18.patch?expand=1 >>>>>> >>>>>> >>>>>> See: >>>>>> https://koji.rpmfusion.org/koji/buildinfo?buildID=22655 >>>>>> >>>>>> Which is supposed to fix this. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Hans >>>>> I'm currently running this version, with the 5.18 fixes, but it's >>>>> not >>>>> working with kernels 5.17.12/13 or 14. A person reporting >>>>> success >>>>> with 5.18.3 reported not having problems with the 5.17 kernels, >>>>> so >>>>> maybe there are multiple issues (has been suggested it may be >>>>> CPU/chipset related). I have not yet tried it on 5.18 but I >>>>> certainly will today. >>>>> >>>>> Ian >>>>> >>>> If I understand Sérgio's comment #15 correctly, the 5.18 kernel >>>> fixes >>>> don't address the CPU issues possibly created by CVE-2022-1789 >>>> fixes, >>>> so there is probably no point in me trying an early 5.18. So the >>>> CPU >>>> issues are common to both later 5.17 and 5.18. Sadly all my >>>> hardware >>>> here falls under the broken category: >>>> >>>> [1] ASUS G750JS 1 x Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz >>>> Intel Corporation 4th Gen Core Processor Integrated Graphics >>>> Controller (rev 06) >>>> NVIDIA Corporation GK104M [GeForce GTX 870M] (rev a1) >>>> Fedora 36 >>>> >>>> [2] Intel NUC i7 NUC11PAH 1 x 11th Gen Intel(R) Core(TM) i7-1165G7 >>>> @ >>>> 2.80GHz >>>> Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) >>>> Fedora 36 >>>> >>> Since it was going to cost me nothing but time, I tested >>> kernel-5.18.3-200.fc36.x86_64 with my existing >>> VirtualBox-6.1.34-4.fc36.x86_64 (RPMFusion updates-testing) and to my >>> astonishment it seems to be working. On both platforms mentioned >>> above. So maybe my understanding about the CVE fixes was not >>> correct. >>> Or something got fixed between 5.18.2 and 5.18.3 ? Anyway the 5.18.3 >>> Fedora kernel on Koji with the latest VirtualBox from RPMFusion still >>> in >>> testing seems to be working on 2 h/w platforms that were previously >>> failing from 5.17.12. >> thank you for the feedback , yes you understand me well, but I hadn't >> made tests with kernel-5.18.x >> >> After read this thread this afternoon , I realize that I also have one >> Intel(R) Core(TM), I have the i5-9300H CPU and I noticed have network >> issues with kernel-5.17.12. so I downgrade the kernel kernel-5.17.9- >> 200.fc35.x86_64 and I confirmed that I hadn't the issues with network. >> >> So I was also affected by kernel-5.17.12, but just had weird network >> issues ... >> >> So now, I not sure anymore if we have 2 issues or if it all the same >> i.e. kvm mitigations which was in first place on kernels 5.18, or even >> if virtualbox kernel-5.18 patch is unrelated. The important for me is >> kernel-5.18 patch for virtualbox don't have regressions . >> > Sérgio, > > Now that 5.18.3 & 5.18.4 are working as VirtualBox hosts, we seem to have problems with 5.18.x as a guest. For me, 5.18.x kernels are not seeing the network interface. I am seeing this with 5.18.3 and 5.18.4 in the guest, regardless of the outer host. In fact I am seeing this on both Linux and Windows 10 hosts. This is due the e1000 nic driver accidentally being disabled in the 5.18 kernels. This is fixed in 5.18.4-301 / 5.18.4-201 / 5.18.4-101 Regards, Hans _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
