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/fi...
>>>>>
>>>>>
>>>>> 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