search for: 2c100000

...94.el5xen version : #1 SMP Fri Apr 2 16:16:54 EDT 2010 machine : i686 nr_cpus : 12 nr_nodes : 1 sockets_per_node : 1 cores_per_socket : 6 threads_per_core : 2 cpu_mhz : 2932 hw_caps : bfebfbff:2c100000:00000000:00000140:029ee3ff:00000000:00000001 total_memory : 15861 free_memory : 383 Should I reinstall the system and use 64Bit kernel, or have better solution? Thanks! -- View this message in context: http://xen.1045712.n5.nabble.com/total-memory-incorrect-tp3397992p339799...

...03 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 throw cpu-detection off? Struan >>> Martin >>> >>&...

...000007 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 instruction used > instead of i386's "int 0x80&...

...s > > 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 instruction used > > instead...

...d 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 instruction used instead of i386's "int 0x80" (IIRC) it makes sense...

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