(In reply to comment #0)

> Похожий случай: https://bugzilla.redhat.com/show_bug.cgi?id=859282

По поводу похожести, я на лог из первого сообщения с форума смотрел, там было

Oct 31 15:34:53 vmbase3 kernel: [   41.316033] BUG: sleeping function called from invalid context at kernel/rwsem.c:20
Oct 31 15:34:53 vmbase3 kernel: [   41.316033] in_atomic(): 1, irqs_disabled(): 1, pid: 4049, name: qemu-kvm
Oct 31 15:34:53 vmbase3 kernel: [   41.316033] CPU: 0 PID: 4049 Comm: qemu-kvm Tainted: G      D      3.10.12-std-def-alt1 #1

(В ответ на комментарий №1)
> (In reply to comment #0)
> 
> > Похожий случай: https://bugzilla.redhat.com/show_bug.cgi?id=859282
Этот патч (https://bugzilla.redhat.com/attachment.cgi?id=709835) присутствует в нашем ядре.

Первый лог - без обновленного ядра, текущий - последнее ядро.
Если патч присутствует в нашем ядре, то почему возникает ошибка? 
Какие мои дальнейшие действия? Как проверить, что патч задействован?

Править свои комментарии тут нельзя :(
Так же волнует вопрос: почему система при установке и после этого нормально работала. По идее ничего же не менялось. Почему данный косяк проявляется со временем. Причем заранее не известно, когда это произойдет следующий раз.
В прошлые разы просто брал и по быстрому переустанавливал систему, импортировал виртуальные машинки и работал дальше. Но тогда я грешил на то, что это тестовый сервер, ставил кучу не нужного софта. Сейчас самый минимум для виртуализации.

(В ответ на комментарий №3)
> Первый лог - без обновленного ядра, текущий - последнее ядро.
> Если патч присутствует в нашем ядре, то почему возникает ошибка? 
Значит это похожая, но всё-таки другая ошибка.

> Какие мои дальнейшие действия?
Пока попробовать другие ядра (el-def, например). Во всяком случае, я пока совершенно не могу понять, как в этом месте может возникнуть такая ошибка после исправлений Marcelo Tosatti в марте прошлого года.

(В ответ на комментарий №5)
> Пока попробовать другие ядра (el-def, например). Во всяком случае, я пока
> совершенно не могу понять, как в этом месте может возникнуть такая ошибка после
> исправлений Marcelo Tosatti в марте прошлого года.
С другими ядрами, другие проблемы :(. Уже точно не могу вспомнить какие проблемы были с ovz-el(когда только тестировал всю свою связку), но самым без проблемным оказался std-def.
С программированием под линукс опыта очень мало, практически нет. Заранее извиняюсь за возможную корявость изложения, но есть следующее предложение.
Можно ли как-то создать/написать аналог данной функции с выводом отладочной информации в консоль/фаил? Или скрипт написать? Что бы его запустить прям на моем сервере и посмотреть, что не так? Потом проанализировать, подправить и опять запустить?

(В ответ на комментарий №6)
> С другими ядрами, другие проблемы :(. Уже точно не могу вспомнить какие
> проблемы были с ovz-el(когда только тестировал всю свою связку), но самым без
> проблемным оказался std-def.
Проверьте ещё led-ws.

(В ответ на комментарий №7)
> (В ответ на комментарий №6)
> > С другими ядрами, другие проблемы :(. Уже точно не могу вспомнить какие
> > проблемы были с ovz-el(когда только тестировал всю свою связку), но самым без
> > проблемным оказался std-def.
> Проверьте ещё led-ws.
Все тоже самое:

[root@vmbase3 ~]# uname -r
3.4.77-led-ws-alt0.M70P.1

cat /var/log/messages

Jan 20 12:15:27 vmbase3 libvirtd: libvirtd startup succeeded
Jan 20 12:15:27 vmbase3 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Jan 20 12:15:27 vmbase3 kernel: nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
Jan 20 12:15:27 vmbase3 avahi-daemon[3664]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1.
Jan 20 12:15:27 vmbase3 avahi-daemon[3664]: New relevant interface virbr0.IPv4 for mDNS.
Jan 20 12:15:27 vmbase3 avahi-daemon[3664]: Registering new address record for 192.168.122.1 on virbr0.IPv4.
Jan 20 12:15:27 vmbase3 kernel: ADDRCONF(NETDEV_UP): virbr0: link is not ready
Jan 20 12:15:27 vmbase3 avahi-daemon[3664]: Interface virbr0.IPv4 no longer relevant for mDNS.
Jan 20 12:15:27 vmbase3 avahi-daemon[3664]: Leaving mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1.
Jan 20 12:15:27 vmbase3 avahi-daemon[3664]: Withdrawing address record for 192.168.122.1 on virbr0.
Jan 20 12:15:27 vmbase3 dhcpcd[2918]: manage_link: No such device or address
Jan 20 12:15:27 vmbase3 avahi-daemon[3664]: Withdrawing workstation service for virbr0.
Jan 20 12:15:28 vmbase3 kernel: Ebtables v2.0 registered
Jan 20 12:15:28 vmbase3 kernel: ip6_tables: (C) 2000-2006 Netfilter Core Team
Jan 20 12:15:32 vmbase3 kernel: device vnet0 entered promiscuous mode
Jan 20 12:15:32 vmbase3 kernel: breth0: port 2(vnet0) entered forwarding state
Jan 20 12:15:32 vmbase3 kernel: breth0: port 2(vnet0) entered forwarding state
Jan 20 12:15:33 vmbase3 avahi-daemon[3664]: Registering new address record for fe80::fc54:ff:fe7d:dec4 on vnet0.*.
Jan 20 12:15:34 vmbase3 kernel: divide error: 0000 [#1] PREEMPT SMP
Jan 20 12:15:34 vmbase3 kernel: Modules linked in: vhost_net macvtap macvlan ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables sunrpc af_packet bridge stp llc ipv6 dm_multipath scsi_dh mousedev sr_mod kvm_intel(O) kvm(O) cdrom coretemp ahci acpi_cpufreq dm_mod mperf r8169 microcode libahci pata_jmicron 8250_pnp psmouse ppdev mii pcspkr i2c_i801 firmware_class 8250 serial_core intel_agp processor uhci_hcd intel_gtt parport_pc ehci_hcd agpgart parport thermal_sys asus_atk0110 hwmon tun ext4 crc16 jbd2 mbcache ata_piix ata_generic pata_acpi serio_raw libata evdev mac_hid
Jan 20 12:15:34 vmbase3 kernel:
Jan 20 12:15:34 vmbase3 kernel: Pid: 4954, comm: qemu-kvm Tainted: G           O 3.4.77-led-ws-alt0.M70P.1 #1 System manufacturer System Product Name/P5B
Jan 20 12:15:34 vmbase3 kernel: EIP: 0060:[<f85c1a1d>] EFLAGS: 00210016 CPU: 0
Jan 20 12:15:34 vmbase3 kernel: EIP is at kvm_write_tsc+0xfd/0x440 [kvm]
Jan 20 12:15:34 vmbase3 kernel: EAX: a5fc7b38 EBX: f4cfc000 ECX: 001c817f EDX: 00175de4
Jan 20 12:15:34 vmbase3 kernel: ESI: 00175c78 EDI: f470fdd4 EBP: f4738000 ESP: f470fd48
Jan 20 12:15:34 vmbase3 kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Jan 20 12:15:34 vmbase3 kernel: CR0: 8005003b CR2: b75e62f0 CR3: 346da000 CR4: 000027d0
Jan 20 12:15:34 vmbase3 kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Jan 20 12:15:34 vmbase3 kernel: DR6: ffff0ff0 DR7: 00000400
Jan 20 12:15:34 vmbase3 kernel: Process qemu-kvm (pid: 4954, ti=f470e000 task=f54d8860 task.ti=f470e000)
Jan 20 12:15:34 vmbase3 kernel: Stack:
Jan 20 12:15:34 vmbase3 kernel:  5d5998b3 000005fb 39cf93d7 00000019 00175c78 00000000 b2afa37f 00000018
Jan 20 12:15:34 vmbase3 kernel:  0258ff59 000005c0 f4cfd540 f470fdd4 a5fc7b38 00175de4 00200296 00000003
Jan 20 12:15:34 vmbase3 kernel:  0000006c 14825bd7 00000010 000005fb f4738000 5d5998b3 f865cff7 00000277
Jan 20 12:15:34 vmbase3 kernel: Call Trace:
Jan 20 12:15:35 vmbase3 kernel:  [<f865cff7>] ? vmx_read_l1_tsc+0x2d17/0xa453 [kvm_intel]
Jan 20 12:15:35 vmbase3 kernel:  [<f865a4f3>] ? vmx_read_l1_tsc+0x213/0xa453 [kvm_intel]
Jan 20 12:15:35 vmbase3 kernel:  [<f85bf6f0>] ? kvm_enable_efer_bits+0x20/0x180 [kvm]
Jan 20 12:15:35 vmbase3 kernel:  [<f85bf71b>] ? kvm_enable_efer_bits+0x4b/0x180 [kvm]
Jan 20 12:15:35 vmbase3 kernel:  [<f85c1081>] ? kvm_set_cr8+0x201/0x280 [kvm]
Jan 20 12:15:35 vmbase3 kernel:  [<f85c47c5>] ? kvm_arch_vcpu_ioctl+0x535/0xd30 [kvm]
Jan 20 12:15:35 vmbase3 kernel:  [<f865c4fe>] ? vmx_read_l1_tsc+0x221e/0xa453 [kvm_intel]
Jan 20 12:15:35 vmbase3 kernel:  [<f865c6f6>] ? vmx_read_l1_tsc+0x2416/0xa453 [kvm_intel]
Jan 20 12:15:35 vmbase3 kernel:  [<f85c768f>] ? kvm_arch_vcpu_ioctl_set_sregs+0x2df/0x410 [kvm]
Jan 20 12:15:35 vmbase3 kernel:  [<f85c40f0>] ? kvm_arch_vcpu_load+0x50/0x1f0 [kvm]
Jan 20 12:15:35 vmbase3 kernel:  [<f85bd151>] ? vcpu_put+0x1f1/0x560 [kvm]
Jan 20 12:15:35 vmbase3 kernel:  [<c10570a8>] ? trigger_load_balance+0x48/0x280
Jan 20 12:15:35 vmbase3 kernel:  [<f85bcfc0>] ? vcpu_put+0x60/0x560 [kvm]
Jan 20 12:15:35 vmbase3 kernel:  [<c1100cba>] ? do_vfs_ioctl+0x7a/0x550
Jan 20 12:15:35 vmbase3 kernel:  [<c101b863>] ? lapic_next_event+0x13/0x20
Jan 20 12:15:35 vmbase3 kernel:  [<c106a81e>] ? clockevents_program_event+0x9e/0x150
Jan 20 12:15:35 vmbase3 kernel:  [<c106b9b1>] ? tick_program_event+0x21/0x30
Jan 20 12:15:35 vmbase3 kernel:  [<c10486bb>] ? hrtimer_interrupt+0x16b/0x280
Jan 20 12:15:35 vmbase3 kernel:  [<c11011fa>] ? sys_ioctl+0x6a/0x80
Jan 20 12:15:35 vmbase3 kernel:  [<c1339125>] ? syscall_call+0x7/0xb
Jan 20 12:15:35 vmbase3 kernel:  [<c1330000>] ? rcu_init_percpu_data+0x92/0xc6
Jan 20 12:15:35 vmbase3 kernel: Code: 8b 44 24 30 69 f2 e8 03 00 00 89 74 24 10 be e8 03 00 00 f7 e6 8b 74 24 10 01 f2 89 44 24 30 8b 44 24 30 89 54 24 34 8b 54 24 34 <f7> f9 31 d2 89 44 24 10 8b 44 24 08 89 54 24 14 8b 54 24 0c 2b
Jan 20 12:15:35 vmbase3 kernel: EIP: [<f85c1a1d>] kvm_write_tsc+0xfd/0x440 [kvm] SS:ESP 0068:f470fd48
Jan 20 12:15:35 vmbase3 kernel: ---[ end trace 246409d94e521933 ]---
Jan 20 12:15:35 vmbase3 kernel: note: qemu-kvm[4954] exited with preempt_count 1
Jan 20 12:15:47 vmbase3 kernel: breth0: port 2(vnet0) entered forwarding state

(В ответ на комментарий №2)
> (В ответ на комментарий №1)
> > (In reply to comment #0)
> > 
> > > Похожий случай: https://bugzilla.redhat.com/show_bug.cgi?id=859282
> Этот патч (https://bugzilla.redhat.com/attachment.cgi?id=709835) присутствует в
> нашем ядре.

https://bugzilla.redhat.com/show_bug.cgi?id=969644
https://patchwork.kernel.org/patch/2707801/
Там же, но другой.

Репорт 2014 года про ядро 3.12; flavour std-def удалён, код KVM с тех пор переписан. Если воспроизводится на текущем kernel-image-6.x — просьба завести новый репорт.