search for: 80000008

On 06/17/2013 05:41 PM, Michael Giardino wrote: > Kashyap: I have not tried integrating your guest xml but I will look > over it today when I get a chance. Thank you. > > Martin: Below is the output from /proc/cpuinfo. Let me know if there is > anything else that would be helpful in debugging this. Thank you, > Unfotunately, my guess was wrong. If you could run 'cpuid

...00 00000000 00000000 00000008 00000000 00000000 00000000 00000000 00000009 00000000 00000000 00000000 00000000 0000000a 07300403 00000000 00000000 00000603 0000000b 00000000 00000000 0000006f 00000001 0000000c 00000000 00000000 00000000 00000000 0000000d 00000000 00000000 00000000 00000000 80000000 80000008 00000000 00000000 00000000 80000001 00000000 00000000 00000021 2c100800 80000002 65746e49 2952286c 726f4320 4d542865 80000003 37692029 3737342d 50432030 20402055 80000004 30342e33 007a4847 00000000 00000000 80000005 00000000 00000000 00000000 00000000 80000006 00000000 00000000 01006040 00000000 80...

...80 kernel: printing eip: May 19 12:19:19 ip-10-234-90-180 kernel: c01123c4 May 19 12:19:19 ip-10-234-90-180 kernel: 00589000 -> *pde = 00000003:b9f9a027 May 19 12:19:19 ip-10-234-90-180 kernel: 0058a000 -> *pme = 00000003:146e0067 May 19 12:19:19 ip-10-234-90-180 kernel: 005c4000 -> *pte = 80000008:10392063 May 19 12:19:19 ip-10-234-90-180 kernel: Oops: 0003 [#1] May 19 12:19:19 ip-10-234-90-180 kernel: SMP May 19 12:19:19 ip-10-234-90-180 kernel: Modules linked in: fuse dm_mirror dm_multipath dm_mod May 19 12:19:19 ip-10-234-90-180 kernel: CPU: 0 May 19 12:19:19 ip-10-234-90-180 kernel: E...

...00000000 00000000 00000000 00000000 > 00000009 00000000 00000000 00000000 00000000 > 0000000a 07300403 00000000 00000000 00000603 > 0000000b 00000000 00000000 0000006f 00000001 > 0000000c 00000000 00000000 00000000 00000000 > 0000000d 00000000 00000000 00000000 00000000 > 80000000 80000008 00000000 00000000 00000000 > 80000001 00000000 00000000 00000021 2c100800 > 80000002 65746e49 2952286c 726f4320 4d542865 > 80000003 37692029 3737342d 50432030 20402055 > 80000004 30342e33 007a4847 00000000 00000000 > 80000005 00000000 00000000 00000000 00000000 > 80000006 00000000...

...;Tim. > >At 13:07 +0800 on 30 Sep (1159621646), Li, Xin B wrote: >> After applying this patch, while booting a 2 vCPUs PAE SMP >Windows 2003 server in VMX, I got: >> >> (XEN) sh error: sh_remove_shadows(): can''t find all shadows >of mfn 23ecf7 (shadow_flags=80000008) >> (XEN) domain_crash called from common.c:2197 >> (XEN) Domain 1 (vcpu#0) crashed on cpu#3: >> (XEN) ----[ Xen-3.0-unstable x86_64 debug=n Not tainted ]---- >> (XEN) CPU: 3 >> (XEN) RIP: 0008:[<000000008086bf9b>] >> (XEN) RFLAGS: 0000000000010283...

...00000000 00000009 00000000 00000000 00000000 00000000 0000000a 07300403 00000000 00000000 00000603 -0000000b 00000000 00000000 000000e8 0000002c +0000000b 00000000 00000000 0000006f 0000002c 0000000c 00000000 00000000 00000000 00000000 0000000d 00000000 00000000 00000000 00000000 80000000 80000008 00000000 00000000 00000000 -80000001 00000000 00000000 00000001 2c100000 +80000001 00000000 00000000 00000001 2c100800 80000002 20202020 6e492020 286c6574 58202952 80000003 286e6f65 43202952 45205550 36322d35 80000004 204c3035 20402030 30382e31 007a4847 Could this be enough difference to thr...

...nificance in libvirt code since we only > call cpuid functions 0x00000001, 0x00000007 and 0x80000001 (which is > enough for us to determine all we need). > >> 0000000c 00000000 00000000 00000000 00000000 >> 0000000d 00000000 00000000 00000000 00000000 >> 80000000 80000008 00000000 00000000 00000000 >> -80000001 00000000 00000000 00000001 2c100000 >> +80000001 00000000 00000000 00000001 2c100800 > But this is something. > > This means in second run the CPU reports it has "syscall" and in the > first one it doesn't. Since "s...

...e we only > > call cpuid functions 0x00000001, 0x00000007 and 0x80000001 (which is > > enough for us to determine all we need). > > > >> 0000000c 00000000 00000000 00000000 00000000 > >> 0000000d 00000000 00000000 00000000 00000000 > >> 80000000 80000008 00000000 00000000 00000000 > >> -80000001 00000000 00000000 00000001 2c100000 > >> +80000001 00000000 00000000 00000001 2c100800 > > But this is something. > > > > This means in second run the CPU reports it has "syscall" and in the > > first one...

...his one has *probably* no significance in libvirt code since we only call cpuid functions 0x00000001, 0x00000007 and 0x80000001 (which is enough for us to determine all we need). > 0000000c 00000000 00000000 00000000 00000000 > 0000000d 00000000 00000000 00000000 00000000 > 80000000 80000008 00000000 00000000 00000000 > -80000001 00000000 00000000 00000001 2c100000 > +80000001 00000000 00000000 00000001 2c100800 But this is something. This means in second run the CPU reports it has "syscall" and in the first one it doesn't. Since "syscall" is x86_64 ins...

On 03/03/2014 10:44, Martin Kletzander wrote: > On Mon, Mar 03, 2014 at 10:30:11AM +0000, Struan Bartlett wrote: >> Hi Martin >> >> Thanks for your response. Here's the output of that grep: >> >> # grep ^flags /proc/cpuinfo | sort -u >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca >> cmov pat pse36 clflush dts acpi mmx