ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | divide by zero in kvm_write_tsc | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Pavel V. Sumin <4pavel_v> |
| Component: | kernel-image-std-def | Assignee: | Vitaly Chikunov <vt> |
| Status: | NEW --- | QA Contact: | qa-sisyphus |
| Severity: | major | ||
| Priority: | P3 | CC: | aen, asy, kernelbot, placeholder, vt |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
|
Description
Pavel V. Sumin
2014-01-16 13:25:30 MSK
(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/ Там же, но другой. |
