Unsupported delivery mode 7
We're running kvm-78 in production on Linux 2.6.27 x86_64 on dual quad-core Opteron 'Barcelona' machines. Our kvm modules are built from the kvm-78 sources rather than the older version bundled with the kernel, and we're using the NPT features of the processors.
For the most part, everything is performing very well and running reliably. However, occasionally a guest will hang as it starts (or is reset) with a large number of messages of the form
Unsupported delivery mode 7
in the dmesg. Following this, killing and relaunching the qemu process is usually sufficient to get a working guest.
I'm aware that our versions of the kvm kernel modules and userspace are not the latest release, but because we're running long-lived guests on behalf of clients, it's quite a major operation to upgrade. Does this look like a known bug which has already been fixed or should I try to reproduce it properly on a test machine with an ability to debug, use magic sysrq, etc? (It seems impossible to reproduce on my lower spec desktop machine, for what it's worth. Normally I'd reproduce kernel problems in a KVM virtual machine---but that's obviously not an option here!)
Am I right in suspecting it might be connected to interrupt delivery following page migration when a guest moves from one processor to another, and that a workaround might be to taskset guests to one or other physical CPU until we're able to upgrade to a more recent version of KVM?
Many thanks in advance for any advice anyone can offer.
Cheers,
Chris.
Quoted 5 lines · Chris Webb
We're running kvm-78 in production on Linux 2.6.27
x86_64on dual quad-core Opteron 'Barcelona' machines. Our kvm modules are built from the kvm-78 sources rather than the older version bundled with the kernel, and we're using the NPT features of the processors.
Quoted 8 lines
For the most part, everything is performing very well and running reliably. However, occasionally a guest will hang as it starts (or is reset) with a large number of messages of the form
Unsupported delivery mode 7
in the dmesg. Following this, killing and relaunching the qemu process is usually sufficient to get a working guest.
The reset issue might be fixed in kvm-userspace.git via commit 888cc6aa65369be5f648a27381aa98569755ac61
(http://git.kernel.org/?p=virt/kvm/kvm-userspace.git;a=commitdiff_plain;h=888cc6aa65369be5f648a27381aa98569755ac61).
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 ES-OS Corporate Competence Center Embedded Linux
Quoted 3 lines · Jan Kiszka
The reset issue might be fixed in kvm-userspace.git via commit
888cc6aa65369be5f648a27381aa98569755ac61
(http://git.kernel.org/?p=virt/kvm/kvm-userspace.git;a=commitdiff_plain;h=888cc6aa65369be5f648a27381aa98569755ac61).
Thanks! I'll apply that patch to our local kvm tree and watch to see if the problem has gone. It's much easier for us to switch out the userspace for testing on the live machines than to switch out kernel modules, as we don't need to kill all the existing guests to do it.
Best wishes,
Chris.
Quoted 23 lines · Chris Webb
We're running kvm-78 in production on Linux 2.6.27
x86_64on dual quad-core Opteron 'Barcelona' machines. Our kvm modules are built from the kvm-78 sources rather than the older version bundled with the kernel, and we're using the NPT features of the processors.For the most part, everything is performing very well and running reliably. However, occasionally a guest will hang as it starts (or is reset) with a large number of messages of the form
Unsupported delivery mode 7
in the dmesg. Following this, killing and relaunching the qemu process is usually sufficient to get a working guest.
I'm aware that our versions of the kvm kernel modules and userspace are not the latest release, but because we're running long-lived guests on behalf of clients, it's quite a major operation to upgrade. Does this look like a known bug which has already been fixed or should I try to reproduce it properly on a test machine with an ability to debug, use magic sysrq, etc? (It seems impossible to reproduce on my lower spec desktop machine, for what it's worth. Normally I'd reproduce kernel problems in a KVM virtual machine---but that's obviously not an option here!)
Quoted 6 lines
Am I right in suspecting it might be connected to interrupt delivery following page migration when a guest moves from one processor to another, and that a workaround might be to taskset guests to one or other physical CPU until we're able to upgrade to a more recent version of KVM?
Many thanks in advance for any advice anyone can offer.
On 2.6 guests this kernel option can workaround the bootup problem:
no_timer_check [X86-32,X86_64,APIC] Disables the code which tests for
broken timer IRQ sources.