[CentOS-virt] KVM instance keep crashing

Sun Oct 17 02:26:44 UTC 2010
Eric Searcy <emsearcy at gmail.com>

On Oct 16, 2010, at 4:47 PM, Akemi Yagi wrote:
[trim]
> However, what is strange is (now this is going to be off-topic here)
> that systems loaded with kmod-kvm show:
> 
> $ cat /proc/sys/kernel/tainted
> 64
> $ rpm -qi kmod-kvm | grep License
> Size        : 4614945                          License: GPLv2
> 
> Despite the fact the kvm module is GPL'd, the value of tainted is
> non-zero.  This kernel is supposed to be NOT tainted.  Could someone
> using kvm confirm this ?

Following that thought, I hadn't thought to check that, but yes my KVM systems have that set to 64 as well.  Probably not due to licensing, that would add a 1 bit which neither of us have (the OPer does).

Note: one of my KVM systems that has '64' has HP Proliant Support Pack installed, which includes some kernel modules (GPLed though they be), the rest are Dell with OMSA packages installed, but I don't think OMSA loads any kernel modules (though 64 does appear to be related to userland, so PSP/OMSA could be related).  Guess a third person with KVM and only distribution-based hardware support could chime in...

Also, there wasn't a taint warning in the kernel traces on my machine (just had some kernel errors last week due to a perennial problem of mine: RHEL Cluster Suite) so "64" must be less significant (i.e. I still think the OP is going to need to get rid of the "1" flag before going to LKML).

Maybe there wouldn't be a taint flag, but here it is.  And remember this is from a machine has a tainted value of 64:

Oct 15 07:57:44 ha7 kernel: INFO: task clvmd:6804 blocked for more than 120 seconds.
Oct 15 07:57:44 ha7 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 15 07:57:44 ha7 kernel: clvmd         D ffff810001003420     0  6804      1                6488 (NOTLB)
Oct 15 07:57:44 ha7 kernel:  ffff81033dfefdb8 0000000000000082 000a81000000000a 0000000000000202
Oct 15 07:57:44 ha7 kernel:  00000110000000f5 0000000000000009 ffff81012d6fc040 ffff81010b734080
Oct 15 07:57:44 ha7 kernel:  00089588d2b6e851 000000000000adc7 ffff81012d6fc228 0000000100000000
Oct 15 07:57:44 ha7 kernel: Call Trace:
Oct 15 07:57:44 ha7 kernel:  [<ffffffff800646ac>] __down_read+0x7a/0x92
Oct 15 07:57:44 ha7 kernel:  [<ffffffff88505468>] :dlm:dlm_user_request+0x2d/0x175
Oct 15 07:57:44 ha7 kernel:  [<ffffffff8008c7d2>] deactivate_task+0x28/0x5f
Oct 15 07:57:44 ha7 kernel:  [<ffffffff8012abc9>] file_has_perm+0x94/0xa3
Oct 15 07:57:44 ha7 kernel:  [<ffffffff8850c707>] :dlm:device_write+0x2f5/0x5e5
Oct 15 07:57:44 ha7 kernel:  [<ffffffff80016a17>] vfs_write+0xce/0x174
Oct 15 07:57:44 ha7 kernel:  [<ffffffff800988b7>] recalc_sigpending+0xe/0x25
Oct 15 07:57:44 ha7 kernel:  [<ffffffff800172e4>] sys_write+0x45/0x6e
Oct 15 07:57:44 ha7 kernel:  [<ffffffff8005d116>] system_call+0x7e/0x83

Further thought: I have other machines with HP PSP and Dell OMSA, why not check them?

HP PSP, no virt: 0
Dell OMSA, no virt: 0
Dell OMSA, Xen Dom0: 0
HP PSP, VMware Server 2: 66

So I guess 64 is from kmod-kvm.  (Hard to search online or the code for "64" taint flag when "64 bit" is already so heavily all over the place bit...)

Eric