Bug 1633267
Summary: | virtio_blk: probe of virtio2 failed with error -2, virtio_console virtio1: Error -2 initializing vqs and similar errors | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Cagney <cagney> |
Component: | qemu | Assignee: | Fedora Virtualization Maintainers <virt-maint> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 28 | CC: | amit, berrange, cfergeau, crobinso, dwmw2, itamar, pbonzini, rjones, virt-maint, xinglp |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-05-21 15:19:50 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Cagney
2018-09-26 14:39:18 UTC
I have same issue with kernel 4.18.11 qemu-2.7.1 eudev-3.2.6, and my system is LFS. "virtio_blk: probe of virtio1 failed with error -2" But another PC with same system but different hardware has no such issue. Adding "--network none" seems to stop the kernel explosion (not surprising given the explosion looks like a timeout in the network code). However, things still eventually fail. Presumably because those pci devices were never properly initialized. Trying F27 guest gets similar results: [ 13.600501] dracut-initqueue[581]: Got message type=method_return sender=n/a destination=n/a object=n/a interface=n/a member=n/a cookie=329 reply_cookie=1 error=n/a [ 13.776116] dracut-initqueue[581]: calling: settle [ 73.320191] systemd-udevd[491]: seq 1364 '/devices/pci0000:00/0000:00:06.0/virtio3' is taking a long time [ 73.322786] systemd-udevd[491]: seq 1371 '/devices/pci0000:00/0000:00:04.0/virtio1/block/vda' is taking a long time [ 133.985318] systemd-journald[164]: Sent WATCHDOG=1 notification. [ 134.071825] dracut-initqueue[581]: calling: settle For what its worth, the host cpu is: vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz stepping : 11 microcode : 0xba cpu MHz : 2659.910 cache size : 4096 KB physical id : 0 siblings : 4 core id : 3 cpu cores : 4 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti tpr_shadow vnmi flexpriority dtherm bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf bogomips : 5319.82 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: I guess unsurprisingly, '--virt-type qemu' gets around the problem :-/ Actually, --virt-type qemu doesn't really help. It gets further but then times out (oh, so slow) in (yes, inst.text was passed in): Anaconda 28.22.10-1.fc28 for Fedora 28 started. * installation log files are stored in /tmp during the installation * shell is available on TTY2 * if the graphical installation interface fails to start, try again with the inst.text bootoption to start text installation * when reporting a bug add logs from /tmp as separate text/plain attachments 16:58:45 Anaconda DBus modules failed to start on time. 16:58:45 Anaconda DBus modules failed to start on time. Pane is dead This is a bug caused by upstream kernel commit kvm: x86: Set highest physical address bits in non-present/reserved SPTEs It's fixed in 4.19, and only affects certain older hardware. kernel 4.18.14 fixed this issue on my mathine. But I still have to do "modprobe virtio_pci" manually. kernel 4.18.14 works for me This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Sounds like this was fixed in the kernel |