Jes Sorensen wrote: > Jes Sorensen wrote: >> Now I am seeing this in my syslog: >> >> Oct 10 07:21:34 a4700rac kernel: vcpu 5 irq check >> Oct 10 07:21:34 a4700rac kernel: vcpu 3 irq check >> Oct 10 07:21:34 a4700rac kernel: vcpu 2 irq check >> Oct 10 07:21:34 a4700rac kernel: vcpu 5 irq check >> Oct 10 07:21:34 a4700rac kernel: vcpu 3 irq check >> Oct 10 07:21:34 a4700rac kernel: vcpu 2 irq check >> Oct 10 07:21:34 a4700rac kernel: vcpu 5 irq check >> Oct 10 07:21:34 a4700rac kernel: vcpu 3 irq check >> Oct 10 07:21:34 a4700rac kernel: vcpu 2 irq check >> Oct 10 07:21:34 a4700rac kernel: vcpu 5 irq check >> Oct 10 07:21:34 a4700rac kernel: vcpu 3 irq check >> Oct 10 07:21:34 a4700rac kernel: vcpu 2 irq check >> Oct 10 07:21:34 a4700rac kernel: vcpu 5 irq check >> Oct 10 07:21:34 a4700rac kernel: vcpu 3 irq check >> >> Note that I never seem to see irq checks for cpus 4, 6, 7 ..... maybe >> syslog is chewing them up though, but it seems strange that they >> never seem to appear. > > Now, this is where it gets strange - I pulled out the above snapshot > why the system was stuck in the boot process. However after a bit it > came back and irqs showed up on cpu 4, 6, 7 as well..... adding the > printk seems to have have an impact.... strange. Hi, Jes I just did a simple try with disabling pal_halt_light emulation, and guests boot well! So this is an issue caused by guest's halt handling. I remembered a guy of x86 side modified the halt logic(common code in kvm_main.c) days ago. So this should be possible rootcause which cause the issue. :) Thanks Xiantao -- To unsubscribe from this list: send the line "unsubscribe kvm-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
