Kernel Crash bei Aufwachen aus gespeicherter qemu-kvm Sessio

[ralfi]

Hallo siducer.

ich habe mit libvirt-bin 1.0.4.-1, Kernel 3.8-7.towo-686-pae und einem Win-7 Image das Problem, dass die Funktion des Wakeups aus einem gespeicherten Zustand meinen Rechner ins Nirwana schickt.

Folgendes steht im Log:

Apr 17 08:15:35 pcxxx kernel: [60172.878303] divide error: 0000 [#1] PREEMPT SMP
Apr 17 08:15:35 pcxxx kernel: [60172.878351] Modules linked in: nfnetlink_log nfnetlink tun ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 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 bridge stp llc af_packet parport_pc ppdev lp parport pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) nfsv3 nfsv4 vboxdrv(O) cpufreq_conservative cpufreq_stats cpufreq_powersave binfmt_misc nfsd auth_rpcgss nfs_acl nfs lockd fscache sunrpc loop fuse saa7134_alsa tda1004x tda10048 saa7134_dvb ir_kbd_i2c tda827x videobuf_dvb snd_hda_codec_hdmi tda18271 rc_terratec_slim_2 tda18218 af9013 tda8290 tuner coretemp kvm_intel hid_logitech_dj kvm crc32c_intel snd_hda_codec_realtek ipmi_si ipmi_msghandler aesni_intel i7core_edac ir_lirc_codec lirc_dev ir_mce_kbd_decoder ir_sanyo_decoder ir_sony_decoder dvb_usb_af9015 usb_storage ir_jvc_decoder dvb_usb_v2 ir_rc6_decoder dv
b_core ir_rc5_decoder ir_nec_decoder rc_hauppauge iTCO_wdt fschmd iTCO_vendor_support evdev mxm_wmi aes_i586 xts lrw gf128mul ablk_helper cryptd psmouse pcspkr serio_raw saa7134 tveeprom videobuf_dma_sg videobuf_core rc_core v4l2_common videodev media snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_seq snd_seq_device i2c_i801 snd_timer lpc_ich snd radeon edac_core i2c_algo_bit ttm drm_kms_helper container drm tpm_infineon acpi_cpufreq soundcore mperf wmi button processor ext4 crc16 jbd2 mbcache dm_mod hid_generic usbhid hid sg sr_mod sd_mod crc_t10dif cdrom uhci_hcd ehci_pci xhci_hcd ehci_hcd microcode ahci libahci libata scsi_mod r8169 mii usbcore usb_common
Apr 17 08:15:35 pcxxx kernel: [60172.879729] Pid: 6826, comm: qemu-system-i38 Tainted: G           O 3.8-7.towo-siduction-686-pae #1 FUJITSU                          CELSIUS R570-2                /D2628-C1
Apr 17 08:15:35 pcxxx kernel: [60172.879827] EIP: 0060:[<fa5da5ba>] EFLAGS: 00210006 CPU: 2
Apr 17 08:15:35 pcxxx kernel: [60172.879875] EIP is at kvm_write_tsc+0x96/0x301 [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.879909] EAX: 8e63b140 EBX: 000003e8 ECX: a0e90f48 EDX: 002cded4
Apr 17 08:15:35 pcxxx kernel: [60172.879950] ESI: 0028969f EDI: e7183740 EBP: f6f76000 ESP: f72b7d4c
Apr 17 08:15:35 pcxxx kernel: [60172.879992]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Apr 17 08:15:35 pcxxx kernel: [60172.880028] CR0: 80050033 CR2: b7e0dd40 CR3: 2700d000 CR4: 000027f0
Apr 17 08:15:35 pcxxx kernel: [60172.880069] DR0: 000000a0 DR1: 00000000 DR2: 00000003 DR3: 000000b0
Apr 17 08:15:35 pcxxx kernel: [60172.880110] DR6: ffff0ff0 DR7: 00000400
Apr 17 08:15:35 pcxxx kernel: [60172.880137] Process qemu-system-i38 (pid: 6826, ti=f72b6000 task=e5e741a0 task.ti=f72b6000)
Apr 17 08:15:35 pcxxx kernel: [60172.880191] Stack:
Apr 17 08:15:35 pcxxx kernel: [60172.880205]  00000000 b1f7a290 00000ba0 5b10b465 ffff7971 8e63b140 002cded4 fa5db622
Apr 17 08:15:35 pcxxx kernel: [60172.880277]  f767f780 59e7d844 000036dd f6f77590 f72b7dbc 00200292 00000010 e7183740
Apr 17 08:15:35 pcxxx kernel: [60172.880348]  f72b7dbc b1f7a290 fb1272f2 e710a400 2af825ec 00000000 b1f7a290 00000ba0
Apr 17 08:15:35 pcxxx kernel: [60172.880418] Call Trace:
Apr 17 08:15:35 pcxxx kernel: [60172.880447]  [<fa5db622>] ? kvm_set_msr_common+0x667/0xf57 [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.880492]  [<fb1272f2>] ? vmx_set_msr+0x8c/0x188 [kvm_intel]
Apr 17 08:15:35 pcxxx kernel: [60172.880539]  [<fa5dc1e2>] ? kvm_set_msr+0x9/0xa [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.880582]  [<fa5dc231>] ? do_set_msr+0x21/0x27 [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.880626]  [<fa5dc210>] ? emulator_set_msr+0x2d/0x2d [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.880672]  [<fa5da152>] ? msr_io+0x7c/0xdf [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.880713]  [<fa5dc210>] ? emulator_set_msr+0x2d/0x2d [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.880760]  [<fa5dc891>] ? kvm_arch_vcpu_ioctl+0x326/0xa81 [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.880804]  [<fb124e34>] ? vmx_set_cr4+0x82/0x88 [kvm_intel]
Apr 17 08:15:35 pcxxx kernel: [60172.880845]  [<fb125274>] ? vmx_set_segment+0x110/0x25b [kvm_intel]
Apr 17 08:15:35 pcxxx kernel: [60172.880889]  [<fb1271c6>] ? vmx_set_cr0+0x437/0x44c [kvm_intel]
Apr 17 08:15:35 pcxxx kernel: [60172.880938]  [<fa5ef63b>] ? kvm_lapic_get_cr8+0x11/0x3b [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.880985]  [<fa5d9370>] ? update_cr8_intercept+0x53/0x56 [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.881034]  [<fa5ded1d>] ? kvm_arch_vcpu_ioctl_set_sregs+0x308/0x319 [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.881082]  [<c104f841>] ? try_to_wake_up+0x167/0x167
Apr 17 08:15:35 pcxxx kernel: [60172.881125]  [<fa5dc48a>] ? kvm_arch_vcpu_load+0xcc/0x1ad [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.881172]  [<fa5d33df>] ? kvm_vcpu_ioctl+0x36c/0x3d0 [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.881211]  [<c1091d77>] ? perf_event_task_tick+0x1d/0x1a8
Apr 17 08:15:35 pcxxx kernel: [60172.881249]  [<c104802a>] ? hrtimer_forward+0x13b/0x153
Apr 17 08:15:35 pcxxx kernel: [60172.881292]  [<fa5d3073>] ? vcpu_put+0x42/0x42 [kvm]
Apr 17 08:15:35 pcxxx kernel: [60172.881326]  [<c10dd890>] ? vfs_ioctl+0x18/0x21
Apr 17 08:15:35 pcxxx kernel: [60172.881357]  [<c10de328>] ? do_vfs_ioctl+0x3f3/0x433
Apr 17 08:15:35 pcxxx kernel: [60172.881392]  [<c1061a87>] ? ktime_get+0x42/0x6a
Apr 17 08:15:35 pcxxx kernel: [60172.881423]  [<c102177c>] ? apic_write+0xc/0xd
Apr 17 08:15:35 pcxxx kernel: [60172.881454]  [<c10217e7>] ? lapic_next_event+0xc/0xf
Apr 17 08:15:35 pcxxx kernel: [60172.881489]  [<c1066eb4>] ? clockevents_program_event+0xc7/0xe4
Apr 17 08:15:35 pcxxx kernel: [60172.881529]  [<c10512a5>] ? sched_clock_cpu+0x10/0x163
Apr 17 08:15:35 pcxxx kernel: [60172.881564]  [<c1067cea>] ? tick_program_event+0x1f/0x22
Apr 17 08:15:35 pcxxx kernel: [60172.881600]  [<c100dfea>] ? __cycles_2_ns+0x1a/0x88
Apr 17 08:15:35 pcxxx kernel: [60172.881634]  [<c10de3ad>] ? sys_ioctl+0x45/0x64
Apr 17 08:15:35 pcxxx kernel: [60172.881666]  [<c12f5a4d>] ? sysenter_do_call+0x12/0x28
Apr 17 08:15:35 pcxxx kernel: [60172.881700] Code: 89 c8 69 f3 e8 03 00 00 bb e8 03 00 00 89 54 24 28 f7 e3 01 f2 8b b7 28 1c 00 00 89 44 24 14 8b 44 24 14 89 54 24 18 8b 54 24 18 <f7> fe 31 d2 89 44 24 14 8b 44 24 24 89 54 24 18 8b 54 24 28 2b
Apr 17 08:15:35 pcxxx kernel: [60172.882029] EIP: [<fa5da5ba>] kvm_write_tsc+0x96/0x301 [kvm] SS:ESP 0068:f72b7d4c
Apr 17 08:15:35 pcxxx kernel: [60172.896621] ---[ end trace 75a0e1dab5182fd7 ]---
Apr 17 08:15:35 pcxxx kernel: [60172.896687] note: qemu-system-i38[6826] exited with preempt_count 1

Funktioniert das Aufwachen mit Win7 qemu-kvm-Images nicht? Bin für jeden Tipp dankbar.

[michaa7]

...
Folgendes steht im Log:

Apr 17 08:15:35 pcxxx kernel: [60172.878303] divide error: 0000  [#1] PREEMPT SMP...

...

Also ich habe von virtualisierung etc. keine ahnung, aber wenn ich die fehlermeldung lese frage ich mich ob das nicht schlichtweg ein kernelbug ist, ob "divide error: 0000" nicht darauf hinweist, dass sich eine unzulässige division durch "0" ergeben hat. Das scheint passieren zu können wenn der kernel irgendwelche werte manipuliert und nicht ausreichend gegen diese verbotene rechenoperation absichert.

Wenn ich recht habe, wäre dies ein fall für den kernel bugtracker. Oder gegen das paket "libvirt-bin", die wissen dort ggf. auch, wohin sie den bug weitermelden müssten ...

Aber nichts gewisses weiß ich nicht ...

[towo]

Nur damit ich das richtig verstehe, Du suspendest den Host bei laufender VM?

[ralfi]

Hi towo, nö, vielleicht etwas verwuckselt ausgedrückt. Ich suspende natürlich nur die VM (also genauer gesagt will ich die Funktion "pausieren" nutzen) und will sie dann wieder erwecken. Und dabei kracht es dann.

Als Würgaround habe ich jetzt herausgefunden, dass man diese VM zwar nicht mehr erwecken aber dafür Klonen kann. Die geklonte VM hat per default einen "ausgeschalteten" Zustand und kann danach wieder problemlos hochgefahren werden.

[towo]

Da wird es schon schwieriger.
Die Frage ist, wie setzt libvirt die vm in den suspend.
Nutzt libvirt qemu selbst oder ist das eine, in libvirt implementierte eigene Funktion.
Eine vm kann man ja leicht per

Code Select Expand

savevm /path/to/save.file
im qemu-monitor suspenden und per

Code Select Expand

qemu -loadvm /path/to/save.file
wieder aufwecken, das solltest Du vielleicht mal testen.
Ob ich einem PAE-Kernel überhaupt das Managen einer Virtualisierung überlassen würde weiss ich grad nicht.

[ralfi]

Das war nur halb richtig, was ich schrieb. Das "Pausieren" und Wiederaufnehmen der Win-7 VM funktioniert fehlerfrei, das "Speichern" funktioniert auch richtig, nur das Wiederaufnehmen aus dem gespeicherten Zustand führt zum Crash.

Nach dem Klonen - ich hab mich ein bisschen zu früh gefreut - funktioniert die Win-7 VM bis auf das Herunterfahren fehlerfrei. Dabei kommt es steht zu einem IRQ-NOT-LESS-uswusf Fehler. Ich werde mal versuchen, im abgesicherten Modus zu starten und die Win-7 Installation zu reparieren.

Ansonsten kann ich nur sagen, dass die PAE- (seit einiger Zeit nur noch mit Deinem siduction) Kernel ausgesprochen gut funktionieren. Ich möchte sogar behaupten, dass es ohne PAE gar nicht geht, zumindest nicht wenn man wie ich zumeist 3-4 virtuelle Images gleichzeitig laufen hat. Da hatte ich ohne PAE immer merkwürdigste Symptome die ich mir nicht erklären konnte.

[towo]

Ich bezog das PAE eher darauf, daß ich mit 32bit nicht Virtualisieren würde.

[ralfi]

Ich musste mir die Kiste aus nur wenigen Möglichkeiten aussuchen und da war der Xeon zumindest was die Rechenleistung anbetrifft schon ned übel.

[towo]

Der Xeon kann doch aber 64bit, deshalb fragte ich.

[ralfi]

Bei mir hat diese CPU

Code Select Expand


CPU:       Hexa core Intel Xeon CPU X5650 (-MCP-) cache: 12288 KB flags: (lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 31920.1        


den X64-Kernel nie gestartet und immer gemeckert, dass es die falsche Plattform ist. Ich gebe gern zu, da habe ich mir keine weiteren Gedanken drüber gemacht.

[towo]

Also ein amd64 Kernel läuuft da drauf mit Sicherheit.

[ralfi]

Jo, Schei... wars und keine Schokolade!

Ich hab die Kiste vor etwa 16 Monaten installiert und es ist mir schleierhaft, wieso ich damals nicht die X64 Version genommen habe. Soeben mal ein X64-Image ins PXE-System eingebunden, Rechner darüber gestartet und läuft natürlich ohne Fehl und Tadel. Mist.

Gibt es da eine Möglichkeit zu migrieren ohne neu zu installieren?

[towo]

Gibt es da eine Möglichkeit zu migrieren ohne neu zu installieren?

Keine, die den Aufwand rechtfertigen würde.

[ralfi]

Na da werde ich wohl mal neu installieren. Im Übrigen tritt der von mir hier

http://www.siduction.org/index.php?name=PNphpBB2&file=index

beschriebene Fehler seit Kernel 3.8-6 nicht mehr auf.