Zhang, Xiantao wrote: > 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 I have worked out the patch to fix this issue, and will send it out after passing internal test. :) 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
