From mboxrd@z Thu Jan 1 00:00:00 1970 From: MaoXiaoyun Subject: RE: Kernel BUG at arch/x86/mm/tlb.c:61 Date: Thu, 14 Apr 2011 15:56:49 +0800 Message-ID: References: , , , , , , , <4DA3438A.6070503@goop.org>, , , <20110412100000.GA15647@dumpdata.com>, , Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0024717207==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: giamteckchoon@gmail.com Cc: jeremy@goop.org, xen devel , konrad.wilk@oracle.com List-Id: xen-devel@lists.xenproject.org --===============0024717207== Content-Type: multipart/alternative; boundary="_f47789e7-8408-4b92-825b-0558efcdbf75_" --_f47789e7-8408-4b92-825b-0558efcdbf75_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable =20 > Date: Thu, 14 Apr 2011 15:26:14 +0800 > Subject: Re: Kernel BUG at arch/x86/mm/tlb.c:61 > From: giamteckchoon@gmail.com > To: tinnycloud@hotmail.com > CC: xen-devel@lists.xensource.com; jeremy@goop.org; konrad.wilk@oracle.= com >=20 > 2011/4/14 MaoXiaoyun : > > Hi: > > > > I've done test with "cpuidle=3D0 cpufreq=3Dnone", two machine c= rashed. > > > > blktap_sysfs_destroy > > blktap_sysfs_destroy > > blktap_sysfs_create: adding attributes for dev ffff8800ad581000 > > blktap_sysfs_create: adding attributes for dev ffff8800a48e3e00 > > ------------[ cut here ]------------ > > kernel BUG at arch/x86/mm/tlb.c:61! > > invalid opcode: 0000 [#1] SMP > > last sysfs file: /sys/block/tapdeve/dev > > CPU 0 > > Modules linked in: 8021q garp blktap xen_netback xen_blkback blkback_= pagemap nbd bridge stp llc autofs4 ipmi_devintf ipmi_si ipmi_ms > > ghandler lockd sunrpc bonding ipv6 xenfs dm_multipath video output sb= s sbshc parport_pc lp parport ses enclosure snd_seq_dummy bnx2 > > serio_raw snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_p= cm_oss snd_mixer_oss snd_pcm i2c_i801 snd_timer i2c_core snd iT > > CO_wdt pata_acpi soundcore iTCO_vendor_ > > support ata_generic snd_page_alloc pcspkr ata_piix shpchp mptsas mpts= csih mptbase [last unloa > > ded: freq_table] > > Pid: 8022, comm: khelper Not tainted 2.6.32.36xen #1 Tecal RH2285 > > RIP: e030:[] [] leave_mm+0x15/0x= 46 > > RSP: e02b:ffff88002803ee48 EFLAGS: 00010046 > > RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff81675980 > > RDX: ffff88002803ee78 RSI: 0000000000000000 RDI: 0000000000000000 > > RBP: ffff88002803ee48 R08: ffff8800a4929000 R09: dead000000200200 > > R10: dead000000100100 R11: ffffffff81447292 R12: ffff88012ba07b80 > > R13: ffff880028046020 R14: 00000000000004fb R15: 0000000000000000 > > FS: 00007f410af416e0(0000) GS:ffff88002803b000(0000) knlGS:000000000= 0000000 > > CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b > > CR2: 0000000000469000 CR3: 00000000ad639000 CR4: 0000000000002660 > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > > Process khelper (pid: 8022, threadinfo ffff8800a4846000, task ffff880= 0a9ed0000) > > Stack: > > ffff88002803ee68 ffffffff8100e4a4 0000000000000001 ffff880097de3b88 > > <0> ffff88002803ee98 ffffffff81087224 ffff88002803ee78 ffff88002803ee= 78 > > <0> ffff88015f808180 00000000000004fb ffff88002803eea8 ffffffff810100= e8 > > Call Trace: > > > > [] drop_other_mm_ref+0x2a/0x53 > > [] generic_smp_call_function_single_interrupt+0xd8= /0xfc > > [] xen_call_function_single_interrupt+0x13/0x28 > > [] handle_IRQ_event+0x66/0x120 > > [] handle_percpu_irq+0x41/0x6e > > [] __xen_evtchn_do_upcall+0x1ab/0x27d > > [] xen_evtchn_do_upcall+0x33/0x46 > > [] xen_do_hypervisor_callback+0x1e/0x30 > > > > [] ? _spin_unlock_irqrestore+0x15/0x17 > > [] ? xen_restore_fl_direct_end+0x0/0x1 > > [] ? flush_old_exec+0x3ac/0x500 > > [] ? load_elf_binary+0x0/0x17ef > > [] ? load_elf_binary+0x0/0x17ef > > [] ? load_elf_binary+0x398/0x17ef > > [] ? need_resched+0x23/0x2d > > > > [] ? process_measurement+0xc0/0xd7 > > [] ? load_elf_binary+0x0/0x17ef > > [] ? search_binary_handler+0xc8/0x255 > > [] ? do_execve+0x1c3/0x29e > > [] ? sys_execve+0x43/0x5d > > [] ? __call_usermodehelper+0x0/0x6f > > [] ? kernel_execve+0x68/0xd0 > > [] ? __call_usermodehelper+0x0/0x6f > > [] ? xen_restore_fl_direct_end+0x0/0x1 > > [] ? ____call_usermodehelper+0x113/0x11e > > [] ? child_rip+0xa/0x20 > > [] ? __call_usermodehelper+0x0/0x6f > > [] ? int_ret_from_sys_call+0x7/0x1b > > [] ? retint_restore_args+0x5/0x6 > > [] ? c > > hild_rip+0x0/0x20 > > Code: 41 5e 41 5f c9 c3 55 48 89 e5 0f 1f 44 00 00 e8 17 ff ff ff c9 = c3 55 48 89 e5 0f 1f 44 00 00 65 8b 04 25 c8 55 01 00 ff c8 75 04 <0f> 0b= eb fe 65 48 8b 34 25 c0 55 01 00 48 81 c6 b8 02 00 00 e8 > > RIP [] leave_mm+0x15/0x46 > > RSP > > ---[ end trace 1522f17fdfc9162d ]--- > > Kernel panic - not syncing: Fatal exception in interrupt > > Pid: 8022, comm: khelper Tainted: G D 2.6.32.36xen #1 > > Call Trace: > > [] panic+0xe0/0x19a > > [] ? init_amd+0x296/0x37a >=20 > Hmmm... both machines are using AMD CPU? Did you hit the same bug on In= tel CPU? >=20 >=20 =20 It is Intel CPU, not AMD.=20 =20 model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz =20 > > [] ? xen_force_evtchn_callback+0xd/0xf > > [] ? check_events+0x12/0x20 > > [] ? xen_restore_fl_direct_end+0x0/0x1 > > [] ? print_oops_end_marker+0x23/0x25 > > [] oops_end+0xb6/0xc6 > > [] die+0x5a/0x63 > > [] do_trap+0x115/0x124 > > [] do_invalid_op+0x9c/0xa5 > > [] ? leave_mm+0x15/0x46 > > [] ? xen_clocksource_read+0x21/0x23 > > [] ? HYPERVISOR_vcpu_op+0xf/0x11 > > [] ? xen_vcpuop_set_next_event+0x52/0x67 > > [] invalid_op+0x1b/0x20 > > [] ? _spin_unlock_irqrestore+0x15/0x17 > > [] ? leave_mm+0x15/0x46 > > [] drop_other_mm_ref+0x2a/0x53 > > [] generic_smp_call_function_single_interrupt+0xd8= /0xfc > > [] xen_call_function_single_interrupt+0x13/0x28 > > [] handle_IRQ_event+0x66/0x120 > > [] handle_percpu_irq+0x41/0x6e > > [] __xen_evtchn_do_upcall+0x1ab/0x27d > > [] xen_evtchn_do_upcall+0x33/0x46 > > [] xen_do_hypervisor_callback+0x1e/0x30 > > [] ? _spin_unlock_irqrestore+0x15/0x17 > > [] ? xen_restore_fl_direct_end+0x0/0x1 > > [] ? flush_old_exec+0x3ac/0x500 > > [] ? load_elf_binary+0x0/0x17ef > > [] ? load_elf_binary+0x0/0x17ef > > [] ? load_elf_binary+0x398/0x17ef > > [] ? need_resched+0x23/0x > > 2d > > [] ? process_measurement+0xc0/0xd7 > > [] ? load_elf_binary+0x0/0x17ef > > [] ? search_binary_handler+0xc8/0x255 > > [] ? do_execve+0x1c3/0x29e > > [] ? sys_execve+0x43/0x5d > > [] ? __call_usermodehelper+0x0/0x6f > > [] ? kernel_execve+0x68/0xd0 > > [] ? __call_usermodehelper+0x0/0x6f > > [] ? xen_restore_fl_direct_end+0x0/0x1 > > [] ? ____call_usermodehelper+0x113/0x11e > > [] ? child_rip+0xa/0x20 > > [] ? __call_usermodehelper+0x0/0x6f > > [] ? int_ret_from_sys_call+0x7/0x1b > > [] ? retint_restore_args+0x5/0x6 > > [] ? child_rip+0x0/0x20 > > (XEN) Domain 0 crashed: 'noreboot' set - not rebooting. > > > >> Date: Tue, 12 Apr 2011 06:00:00 -0400 > >> From: konrad.wilk@oracle.com > >> To: tinnycloud@hotmail.com > >> CC: xen-devel@lists.xensource.com; giamteckchoon@gmail.com; > >> jeremy@goop.org > >> Subject: Re: Kernel BUG at arch/x86/mm/tlb.c:61 > >> > >> On Tue, Apr 12, 2011 at 05:11:51PM +0800, MaoXiaoyun wrote: > >> > > >> > Hi : > >> > > >> > We are using pvops kernel 2.6.32.36 + xen 4.0.1, but confront a ke= rnel > >> > panic bug. > >> > > >> > 2.6.32.36 Kernel: > >> > http://git.kernel.org/?p=3Dlinux/kernel/git/jeremy/xen.git;a=3Dcom= mit;h=3Dbb1a15e55ec665a64c8a9c6bd699b1f16ac01ff4 > >> > Xen 4.0.1 http://xenbits.xen.org/hg/xen-4.0-testing.hg/rev/b536ebf= ba183 > >> > > >> > Our test is simple, 24 HVMS(Win2003 ) on a single host, each HVM l= oopes > >> > in restart every 15minutes. > >> > >> What is the storage that you are using for your guests? AoE? Local d= isks? > >> > >> > About 17 machines are invovled in the test, after 10 hours run, on= e > >> > confrontted a crash at arch/x86/mm/tlb.c:61 > >> > > >> > Currently I am trying "cpuidle=3D0 cpufreq=3Dnone" tests based on = Teck's > >> > suggestion. > >> > > >> > Any comments, thanks. > >> > =20 --_f47789e7-8408-4b92-825b-0558efcdbf75_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

> Date: Thu, 14 Apr 2011 15:26:14 +0800
> Subject: Re: Kernel BU= G at arch/x86/mm/tlb.c:61
> From: giamteckchoon@gmail.com
> T= o: tinnycloud@hotmail.com
> CC: xen-devel@lists.xensource.com; jere= my@goop.org; konrad.wilk@oracle.com
>
> 2011/4/14 MaoXiaoyun= <tinnycloud@hotmail.com>:
> > Hi:
> >
> &g= t;       I've done test with "cpuidle=3D0 cpufre= q=3Dnone", two machine crashed.
> >
> > = blktap_sysfs_destroy
> > blktap_sysfs_destroy
> > blkta= p_sysfs_create: adding attributes for dev ffff88= 00ad581000
> > blktap_sysfs_create: adding attributes&= nbsp;for dev ffff8800a48e3e00
> > ------------[ c= ut here ]------------
> > kernel BUG at = ;arch/x86/mm/tlb.c:61!
> > invalid opcode: 0000 [= #1] SMP
> > last sysfs&nbs p;file: /sys/block/tapdeve/dev
> > CPU 0
> >= Modules linked in: 8021q garp blktap xen_n= etback xen_blkback blkback_pagemap nbd bridge st= p llc autofs4 ipmi_devintf ipmi_si ipmi_ms
&g= t; > ghandler lockd sunrpc bonding ipv6 xenfs= dm_multipath video output sbs sbshc parpor= t_pc lp parport ses enclosure snd_seq_dummy = ;bnx2
> > serio_raw snd_seq_oss snd_seq_midi_event&nbs= p;snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss sn= d_pcm i2c_i801 snd_timer i2c_core snd iT
>= > CO_wdt pata_acpi soundcore iTCO_vendor_
> >= support ata_generic snd_page_alloc pcspkr ata_piix&n= bsp;shpchp mptsas mptscsih mptbase [last unloa> > ded: freq_table]
>=20 > Pid: 8022, comm: khelper Not tainted = 2.6.32.36xen #1 Tecal RH2285
> > RIP: e030:[= <ffffffff8103a3cb>]  [<ffffffff8103a3cb>] leav= e_mm+0x15/0x46
> > RSP: e02b:ffff88002803ee48  EF= LAGS: 00010046
> > RAX: 0000000000000000 RBX:&nbs= p;0000000000000001 RCX: ffffffff81675980
> > RDX: = ;ffff88002803ee78 RSI: 0000000000000000 RDI: 00000000= 00000000
> > RBP: ffff88002803ee48 R08: ffff8800a= 4929000 R09: dead000000200200
> > R10: dead000000= 100100 R11: ffffffff81447292 R12: ffff88012ba07b80> > R13: ffff880028046020 R14: 00000000000004fb&nbs= p;R15: 0000000000000000
> > FS:  00007f410af416e0= (0000) GS:ffff88002803b000(0000) knlGS:0000000000000000
>= > CS:  e033 DS: 00 00 ES: 0000 CR0: 000000008005003b
> > CR2:&= nbsp;0000000000469000 CR3: 00000000ad639000 CR4: 0000= 000000002660
> > DR0: 0000000000000000 DR1: 00000= 00000000000 DR2: 0000000000000000
> > DR3: 000000= 0000000000 DR6: 00000000ffff0ff0 DR7: 000000000000040= 0
> > Process khelper (pid: 8022, threadinfo= ffff8800a4846000, task ffff8800a9ed0000)
> > Sta= ck:
> > ffff88002803ee68 ffffffff8100e4a4 000000= 0000000001 ffff880097de3b88
> > <0> ffff88002803= ee98 ffffffff81087224 ffff88002803ee78 ffff88002803ee78> > <0> ffff88015f808180 00000000000004fb fff= f88002803eea8 ffffffff810100e8
> > Call Trace:
>= > <IRQ>
> > [<ffffffff8100e4a4>]&nbs= p;drop_other_mm_ref+0x2a/0x53
> > [<ffffffff81087224>] generic_smp_call_function_single_= interrupt+0xd8/0xfc
> > [<ffffffff810100e8>] xe= n_call_function_single_interrupt+0x13/0x28
> > [<ffffff= ff810a936a>] handle_IRQ_event+0x66/0x120
> > [<= ffffffff810aac5b>] handle_percpu_irq+0x41/0x6e
> > = ;[<ffffffff8128c1a8>] __xen_evtchn_do_upcall+0x1ab/0x27d
&g= t; > [<ffffffff8128dcf9>] xen_evtchn_do_upcall+0x33/0= x46
> > [<ffffffff81013efe>] xen_do_hypervisor_= callback+0x1e/0x30
> > <EOI>
> > [<= ;ffffffff81447292>] ? _spin_unlock_irqrestore+0x15/0x17
&= gt; > [<ffffffff8100f8af>] ? xen_restore_fl_dire= ct_end+0x0/0x1
> > [<ffffffff81113f75>] ? = flush_old_exec+0x3ac/0x500
> > [<ffffffff81150dc9>]&= nbsp;? load_elf_binary+0x0/0x17ef
> > [<ffffffff81150dc9>] ? load_elf_binary+0= x0/0x17ef
> > [<ffffffff81151161>] ? load_= elf_binary+0x398/0x17ef
> > [<ffffffff81042fcf>]&nbs= p;? need_resched+0x23/0x2d
> >
> > [<ffffffff81= 1f463c>] ? process_measurement+0xc0/0xd7
> > = [<ffffffff81150dc9>] ? load_elf_binary+0x0/0x17ef
>= > [<ffffffff81113098>] ? search_binary_handler+= 0xc8/0x255
> > [<ffffffff81114366>] ? do_e= xecve+0x1c3/0x29e
> > [<ffffffff8101155d>] ?&nb= sp;sys_execve+0x43/0x5d
> > [<ffffffff8106fc45>]&nbs= p;? __call_usermodehelper+0x0/0x6f
> > [<ffffffff8= 1013e28>] ? kernel_execve+0x68/0xd0
> > [<= ffffffff8106fc45>] ? __call_usermodehelper+0x0/0x6f
> = > [<ffffffff8100f8af>] ;? xen_restore_fl_direct_end+0x0/0x1
> > [<ffffff= ff8106fb64>] ? ____call_usermodehelper+0x113/0x11e
> &= gt; [<ffffffff81013daa>] ? child_rip+0xa/0x20
&g= t; > [<ffffffff8106fc45>] ? __call_usermodehelpe= r+0x0/0x6f
> > [<ffffffff81012f91>] ? int_= ret_from_sys_call+0x7/0x1b
> > [<ffffffff8101371d>]&= nbsp;? retint_restore_args+0x5/0x6
> > [<ffffffff8= 1013da0>] ? c
> > hild_rip+0x0/0x20
> > Co= de: 41 5e 41 5f c9 c3 55 48 = 89 e5 0f 1f 44 00 00 e8 17 f= f ff ff c9 c3 55 48 89 e5 0f= 1f 44 00 00 65 8b 04 25 c8&= nbsp;55 01 00 ff c8 75 04 <0f>&n= bsp;0b eb fe 65 48&nbs p;8b 34 25 c0 55 01 00 48 81&nbs= p;c6 b8 02 00 00 e8
> > RIP  = [<ffffffff8103a3cb>] leave_mm+0x15/0x46
> > RSP= <ffff88002803ee48>
> > ---[ end trace = ;1522f17fdfc9162d ]---
> > Kernel panic - no= t syncing: Fatal exception in interrupt
> = > Pid: 8022, comm: khelper Tainted: G &n= bsp;    D    2.6.32.36xen #1=
> > Call Trace:
> > <IRQ>  = [<ffffffff8105682e>] panic+0xe0/0x19a
> > [<= ffffffff8144006a>] ? init_amd+0x296/0x37a
>
> H= mmm... both machines are using AMD CPU? Did you hit the same bug on Intel= CPU?
>
>

It is Intel CPU, not AMD.

model name      : Intel(R) Xeon(R) CPU &nbs= p;         E5620 @ 2.40GHz<= BR>

> > [<ffffffff8100f169>] ? xen_force_evtc= hn_callback+0xd/0xf
> > [<ffffffff8100f8c2>] ?&= nbsp;check_events+0x12/0x20
> > [<ffffffff8100f8af>]= ? xen_restore_fl_direct_end+0x0/0x1
> > [<ff= ffffff81056487>] ? print_oops_end_marker+0x23/0x25
> &= gt; [<ffffffff81448165>] oops_end+0xb6/0xc6
> >= [<ffffffff810166e5>] die+0x5a/0x63
> > [= <ffffffff81447a3c>] do_trap+0x115/0x124
> > [&l= t;ffffffff810148e6>] do_invalid_op+0x9c/0xa5
> > [= <ffffffff8103a3cb>] ? leave_mm+0x15/0x46
> > &nb= sp;[<ffffffff8100f6e6>] ? xen_clocksource_read+0x21/0x23<= BR>> > [<ffffffff8100f258>] ? HYPERVISOR_vcpu= _op+0xf/0x11
> > [<ffffffff8100f753>] ? xe= n_vcpuop_set_next_event+0x52/0x67
> > [<ffffffff81013b3b>] invalid_op+0x1b/0x20
>= > [<ffffffff81447292>] ? _spin_unlock_irqrestor= e+0x15/0x17
> > [<ffffffff8103a3cb>] ? lea= ve_mm+0x15/0x46
> > [<ffffffff8100e4a4>] drop_o= ther_mm_ref+0x2a/0x53
> > [<ffffffff81087224>] = generic_smp_call_function_single_interrupt+0xd8/0xfc
> > [= <ffffffff810100e8>] xen_call_function_single_interrupt+0x13/0x= 28
> > [<ffffffff810a936a>] handle_IRQ_event+0x= 66/0x120
> > [<ffffffff810aac5b>] handle_percpu= _irq+0x41/0x6e
> > [<ffffffff8128c1a8>] __xen_e= vtchn_do_upcall+0x1ab/0x27d
> > [<ffffffff8128dcf9>]= xen_evtchn_do_upcall+0x33/0x46
> > [<ffffffff8101= 3efe>] xen_do_hypervisor_callback+0x1e/0x30
> > &l= t;EOI>  [<ffffffff81447292 >] ? _spin_unlock_irqrestore+0x15/0x17
> > [= <ffffffff8100f8af>] ? xen_restore_fl_direct_end+0x0/0x1> > [<ffffffff81113f75>] ? flush_old_exec+0= x3ac/0x500
> > [<ffffffff81150dc9>] ? load= _elf_binary+0x0/0x17ef
> > [<ffffffff81150dc9>] = ;? load_elf_binary+0x0/0x17ef
> > [<ffffffff811511= 61>] ? load_elf_binary+0x398/0x17ef
> > [<= ffffffff81042fcf>] ? need_resched+0x23/0x
> > 2d> > [<ffffffff811f463c>] ? process_measureme= nt+0xc0/0xd7
> > [<ffffffff81150dc9>] ? lo= ad_elf_binary+0x0/0x17ef
> > [<ffffffff81113098>]&nb= sp;? search_binary_handler+0xc8/0x255
> > [<ffffff= ff81114366>] ? do_execve+0x1c3/0x29e
> > [<= ;ffffffff8101155d>] ? sys_exe cve+0x43/0x5d
> > [<ffffffff8106fc45>] ? = __call_usermodehelper+0x0/0x6f
> > [<ffffffff81013e28&g= t;] ? kernel_execve+0x68/0xd0
> > [<ffffffff8= 106fc45>] ? __call_usermodehelper+0x0/0x6f
> > &nbs= p;[<ffffffff8100f8af>] ? xen_restore_fl_direct_end+0x0/0x= 1
> > [<ffffffff8106fb64>] ? ____call_user= modehelper+0x113/0x11e
> > [<ffffffff81013daa>] = ;? child_rip+0xa/0x20
> > [<ffffffff8106fc45>]&= nbsp;? __call_usermodehelper+0x0/0x6f
> > [<ffffff= ff81012f91>] ? int_ret_from_sys_call+0x7/0x1b
> > &= nbsp;[<ffffffff8101371d>] ? retint_restore_args+0x5/0x6> > [<ffffffff81013da0>] ? child_rip+0x0/0x= 20
> > (XEN) Domain 0 crashed: 'noreboot'&nb= sp;set - not rebooting.
> >
> >> Date: Tue, 12 Apr 2011 06:00:00 -0400
>= >> From: konrad.wilk@oracle.com
> >> To: tinnycloud@ho= tmail.com
> >> CC: xen-devel@lists.xensource.com; giamteckcho= on@gmail.com;
> >> jeremy@goop.org
> >> Subject: = Re: Kernel BUG at arch/x86/mm/tlb.c:61
> >>
> >> = On Tue, Apr 12, 2011 at 05:11:51PM +0800, MaoXiaoyun wrote:
> >&= gt; >
> >> > Hi :
> >> >
> >>= ; > We are using pvops kernel 2.6.32.36 + xen 4.0.1, but confront a ke= rnel
> >> > panic bug.
> >> >
> >&= gt; > 2.6.32.36 Kernel:
> >> > http://git.kernel.org/?p= =3Dlinux/kernel/git/jeremy/xen.git;a=3Dcommit;h=3Dbb1a15e55ec665a64c8a9c6= bd699b1f16ac01ff4
> >> > Xen 4.0.1 http://xenbits.xen.org/= hg/xen-4.0-testing.hg/rev/b536ebfba183
> >> >
> >= > > Our test is simple, 24 HVMS(Win2003 )=20 on a single host, each HVM loopes
> >> > in restart every= 15minutes.
> >>
> >> What is the storage that yo= u are using for your guests? AoE? Local disks?
> >>
> &= gt;> > About 17 machines are invovled in the test, after 10 hours r= un, one
> >> > confrontted a crash at arch/x86/mm/tlb.c:61=
> >> >
> >> > Currently I am trying "cpuid= le=3D0 cpufreq=3Dnone" tests based on Teck's
> >> > sugges= tion.
> >> >
> >> > Any comments, thanks.> >> >

--_f47789e7-8408-4b92-825b-0558efcdbf75_-- --===============0024717207== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0024717207==--