|
> Date: Fri, 15 Apr 2011 14:22:29 -0700 > From: jeremy@xxxxxxxx > To: tinnycloud@xxxxxxxxxxx > CC: giamteckchoon@xxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx; konrad.wilk@xxxxxxxxxx > Subject: Re: Kernel BUG at arch/x86/mm/tlb.c:61 > > On 04/15/2011 05:23 AM, MaoXiaoyun wrote: > > Hi: > > > > Could the crash related to this patch ? > > http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=commitdiff;h=45bfd7bfc6cf32f8e60bb91b32349f0b5090eea3 > > > > Since now TLB state change to TLBSTATE_OK(mmu_context.h:40) is before > > cpumask_clear_cpu(line 49). > > Could it possible that right after execute line 40 of mmu_context.h, > > CPU revice IPI from other CPU to > > flush the mm, and when in interrupt, find the TLB state happened to be > > TLBSTATE_OK. Which conflicts. > > Does reverting it help? > > J Hi Jeremy: The lastest test result shows the reverting didn't help. Kernel panic exactly at the same place in tlb.c. I have question about TLB state, from the stack, xen_do_hypervisor_callback-> xen_evtchn_do_upcall->... ->drop_other_mm_ref What cpu_tlbstate.state should be, could TLBSTATE_OK or TLBSTATE_LAZY all be possible? That is after a hypercall from userspace, state will be TLBSTATE_OK, and if from kernel space, state will be TLBSTATE_LAZE ? thanks. [<ffffffff8100e4a4>] drop_other_mm_ref+0x2a/0x53 [<ffffffff81087224>] generic_smp_call_function_single_interrupt+0xd8/0xfc [<ffffffff810100e8>] xen_call_function_single_interrupt+0x13/0x28 [<ffffffff810a936a>] handle_IRQ_event+0x66/0x120 [<ffffffff810aac5b>] handle_percpu_irq+0x41/0x6e [<ffffffff8128c1a8>] __xen_evtchn_do_upcall+0x1ab/0x27d [<ffffffff8128dcf9>] xen_evtchn_do_upcall+0x33/0x46 [<ffffffff81013efe>] xen_do_hypervisor_callback+0x1e/0x30
|
_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel