Alexander Graf wrote: > Alexander Graf wrote: > > [...] > >> Also after two days of permanent stress testing I also got the Intel >> machine w/ current git down: >> >> + sudo -u contain1 env -i /usr/local/bin/qemu-system-x86_64 -localtime >> -kernel virtio-kernel -initrd virtio-initrd -nographic -append 'quiet >> clocksource=acpi_pm cifsuser=contain1 cifspass=contain1 >> root=cifs://contain1:contain1@xxxxxxxxxx/contain1 >> realroot=//172.16.1.1/users/contain1 >> ip=172.16.1.2:172.16.1.1::255.255.255.0::eth0:none console=ttyS0 >> dhcp=off builder=1' -net nic,model=virtio,macaddr=52:54:00:12:34:1 -net >> tap,ifname=tap1,script=/bin/true -m 2000 -nographic -smp 8 /dev/null >> qemu: loading initrd (0x1daf359 bytes) at 0x000000007b240000 >> Stuck ?? >> >> No backtrace here though. That's all I got from the serial console. >> >> > > + sudo -u contain1 env -i /usr/local/bin/qemu-system-x86_64 -localtime > -kernel virtio-kernel -initrd virtio-initrd -nographic -append 'quiet > clocksource=acpi_pm cifsuser=contain1 cifspass=contain1 > root=cifs://contain1:contain1@xxxxxxxxxx/contain1 > realroot=//172.16.1.1/users/contain1 > ip=172.16.1.2:172.16.1.1::255.255.255.0::eth0:none console=ttyS0 > dhcp=off builder=1' -net nic,model=virtio,macaddr=52:54:00:12:34:1 -net > tap,ifname=tap1,script=/bin/true -m 2000 -nographic -smp 8 /dev/null > qemu: loading initrd (0x1daf359 bytes) at 0x000000007b240000 > Stuck ?? > > (qemu) info cpus > * CPU #0: pc=0xffffffff80221f1d thread_id=15211 > CPU #1: pc=0xffffffff80221f1d thread_id=15212 > CPU #2: pc=0xffffffff80221f1d thread_id=15213 > CPU #3: pc=0xffffffff80221f1d thread_id=15214 > CPU #4: pc=0xffffffff8049f7d0 thread_id=15215 > CPU #5: pc=0xffffffff80221f1d thread_id=15216 > CPU #6: pc=0xffffffff80221f1d thread_id=15217 > CPU #7: pc=0x000000000009f02c thread_id=15218 > > (qemu) cpu 7 > (qemu) info registers > EAX=00000c06 EBX=000005b8 ECX=00000000 EDX=00000000 > ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 > EIP=0000002c EFL=00033002 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0 > ES =0000 00000000 0000ffff 0000f300 > CS =9f00 0009f000 0000ffff 0000f300 > SS =0000 00000000 0000ffff 0000f300 > DS =0000 00000000 0000ffff 0000f300 > FS =0000 00000000 0000ffff 0000f300 > GS =0000 00000000 0000ffff 0000f300 > LDT=0000 00000000 0000ffff 00008200 > TR =0000 fffbd000 00002088 00008b00 > GDT= 00000000 0000ffff > IDT= 00000000 0000ffff > CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 > DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 > DR6=ffff0ff0 DR7=00000400 > FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00000000 > FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 > FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 > FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 > FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 > XMM00=00000000000000000000000000000000 > XMM01=00000000000000000000000000000000 > XMM02=00000000000000000000000000000000 > XMM03=00000000000000000000000000000000 > XMM04=00000000000000000000000000000000 > XMM05=00000000000000000000000000000000 > XMM06=00000000000000000000000000000000 > XMM07=00000000000000000000000000000000 > > Is that guest really seriously in BIOS code? After booting Linux? > > (qemu) x /2i $pc-1 > 0x000000000009f02b: hlt > 0x000000000009f02c: jmp 0x9f02b > > Where is this? Looks like panic code to me. > 0x000000000009f000: cli 0x000000000009f001: xor %ax,%ax 0x000000000009f003: mov %ax,%ds 0x000000000009f005: mov $0x510,%ebx 0x000000000009f00b: addr32 mov (%ebx),%ecx 0x000000000009f00f: test %ecx,%ecx 0x000000000009f012: je 0x9f026 0x000000000009f014: addr32 mov 0x4(%ebx),%eax 0x000000000009f019: addr32 mov 0x8(%ebx),%edx 0x000000000009f01e: wrmsr 0x000000000009f020: add $0xc,%ebx 0x000000000009f024: jmp 0x9f00b 0x000000000009f026: lock incw 1856 0x000000000009f02b: hlt 0x000000000009f02c: jmp 0x9f02b Looks a lot like this: smp_ap_boot_code_start: cli xor %ax, %ax mov %ax, %ds mov $SMP_MSR_ADDR, %ebx 11: mov 0(%ebx), %ecx test %ecx, %ecx jz 12f mov 4(%ebx), %eax mov 8(%ebx), %edx wrmsr add $12, %ebx jmp 11b 12: lock incw smp_cpus 1: hlt jmp 1b But that code shouldn't run after Linux booted, right? And without at least a "Power Off" message I'd expect Linux to still be up. The only thing the host's dmesg was saying is this: Ignoring delivery mode 3 (repeated often) Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
