Latest unstable detects cpu speed incorrectly

Latest unstable detects cpu speed incorrectly

[Valtteri Kiviniemi]

Hi,

We are testing the latest xen-unstable and found an interesting bug. 
dom0 detects cpu speed correctly but when booting domU it detects it 
incorrectly:

"Detected 1000.000 MHz processor."

domU config:

kernel = "/boot/bzImage-domU"
builder = "linux"
memory = "512"
name = "test"
vcpus = "8"
cpus = [ "0", "1", "2", "3", "4", "5", "6", "7" ]
vif = [ "mac=00:50:56:14:89:13, bridge=eth0" ]
disk = [ "phy:/dev/virtuals/test,xvda1,w",
          "phy:/dev/backups/test,xvda2,w" ]
root = "/dev/xvda1 ro"
extra = "console=hvc0"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"

cpu info from domU:

test:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz
stepping        : 6
cpu MHz         : 1000.000
cache size      : 6144 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu de tsc msr pae cx8 sep cmov clflush mmx fxsr sse 
sse2 ss ht syscall nx lm constant_tsc rep_good pni ssse3 cx16 sse4_1 
hypervisor lahf_lm
bogomips        : 2000.00
clflush size    : 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

domU's boot output:

Linux version 2.6.31.4-domU-00396-g9cf89da (root@xen) (gcc version 4.3.4 
(Debian 4.3.4-5) ) #15 SMP Mon Oct 26 19:25:50 EET 2009
Command line: root=/dev/xvda1 ro console=hvc0
KERNEL supported cpus:
   Intel GenuineIntel
   AMD AuthenticAMD
   Centaur CentaurHauls
released 0 pages of unused memory
BIOS-provided physical RAM map:
  Xen: 0000000000000000 - 00000000000a0000 (usable)
  Xen: 00000000000a0000 - 0000000000100000 (reserved)
  Xen: 0000000000100000 - 0000000020000000 (usable)
DMI not present or invalid.
last_pfn = 0x20000 max_arch_pfn = 0x400000000
init_memory_mapping: 0000000000000000-0000000020000000
(6 early reservations) ==> bootmem [0000000000 - 0020000000]
   #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 
0000001000]
   #1 [00015fe000 - 000160d000]   XEN PAGETABLES ==> [00015fe000 - 
000160d000]
   #2 [0000006000 - 0000008000]       TRAMPOLINE ==> [0000006000 - 
0000008000]
   #3 [0001000000 - 00014da804]    TEXT DATA BSS ==> [0001000000 - 
00014da804]
   #4 [00014fb000 - 00015fe000]   XEN START INFO ==> [00014fb000 - 
00015fe000]
   #5 [0000100000 - 00001f0000]          PGTABLE ==> [0000100000 - 
00001f0000]
Zone PFN ranges:
   DMA      0x00000000 -> 0x00001000
   DMA32    0x00001000 -> 0x00100000
   Normal   0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
     0: 0x00000000 -> 0x000000a0
     0: 0x00000100 -> 0x00020000
SMP: Allowing 8 CPUs, 0 hotplug CPUs
No local APIC present
APIC: disable apic facility
Allocating PCI resources starting at 20000000 (gap: 20000000:e0000000)
NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
PERCPU: Allocated 19 4k pages, static data 74976 bytes
Xen: using vcpu_info placement
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 128941
Kernel command line: root=/dev/xvda1 ro console=hvc0
PID hash table entries: 2048 (order: 11, 16384 bytes)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Initializing CPU#0
Memory: 507316k/524288k available (2788k kernel code, 384k absent, 
15860k reserved, 1353k data, 328k init)
SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
NR_IRQS:512
Detected 1000.000 MHz processor.
Console: colour dummy device 80x25
console [tty0] enabled
console [hvc0] enabled
installing Xen timer for CPU 0
Calibrating delay loop (skipped), value calculated using timer 
frequency.. 2000.00 BogoMIPS (lpj=10000000)
Mount-cache hash table entries: 256
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 6144K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
installing Xen timer for CPU 1
SMP alternatives: switching to SMP code
Initializing CPU#1
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 6144K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
installing Xen timer for CPU 2
Initializing CPU#2
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 6144K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
installing Xen timer for CPU 3
Initializing CPU#3
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 6144K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
installing Xen timer for CPU 4
Initializing CPU#4
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 6144K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
installing Xen timer for CPU 5
Initializing CPU#5
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 6144K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
installing Xen timer for CPU 6
Initializing CPU#6
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 6144K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
installing Xen timer for CPU 7
Initializing CPU#7
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 6144K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
Brought up 8 CPUs
Booting paravirtualized kernel on Xen
Xen version: 3.5-unstable (preserve-AD)
Using V2 grant tables.
Grant table initialized
NET: Registered protocol family 16
xenbus_probe wake_waiting
xenbus_probe_init ok
bio: create slab <bio-0> at 0
xenbus_probe_frontend_init bus registered ok
xenbus_probe_devices device
xenbus_probe_devices 1/3 vbd
xenbus_probe_device_type type vbd
xenbus_probe_device_type 1/2 51713
xenbus_probe_device_type 2/2 51714
xenbus_probe_device_type done
xenbus_probe_devices 2/3 vif
xenbus_probe_device_type type vif
xenbus_probe_device_type 1/1 0
xenbus_probe_device_type done
xenbus_probe_devices 3/3 console
xenbus_probe_device_type type console
xenbus_probe_device_type 1/1 0
xenbus_probe_device_type done
xenbus_probe_devices done
frontend_probe_and_watch devices probed ok
frontend_probe_and_watch watch add ok ok
frontend_probe_and_watch all done
xen_balloon: Initialising balloon driver.
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 16384 (order: 5, 131072 bytes)
TCP established hash table entries: 65536 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
TCP reno registered
NET: Registered protocol family 1
platform rtc_cmos: registered platform RTC device (no PNP device found)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
fuse init (API version 7.12)
SGI XFS with ACLs, security attributes, realtime, large block/inode 
numbers, no debug enabled
SGI XFS Quota Management subsystem
msgmni has been set to 992
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler cfq registered (default)
Event-channel device installed.
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
blkfront: xvda1: barriers enabled
Initialising Xen virtual ethernet driver.
blkfront: xvda2: barriers enabled
i8042.c: No controller found.
mice: PS/2 mouse device common for all mice
Netfilter messages via NETLINK v0.30.
nf_conntrack version 0.5.0 (4096 buckets, 16384 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
ctnetlink v0.93: registering with nfnetlink.
NF_TPROXY: Transparent proxy support initialized, version 4.1.0
NF_TPROXY: Copyright (c) 2006-2007 BalaBit IT Ltd.
xt_time: kernel timezone is -0000
ip_tables: (C) 2000-2006 Netfilter Core Team
ClusterIP Version 0.8 loaded successfully
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
NET: Registered protocol family 15
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
registered taskstats version 1
XENBUS: Device with no driver: device/console/0
XFS mounting filesystem xvda1
VFS: Mounted root (xfs filesystem) readonly on device 202:1.
Freeing unused kernel memory: 328k freed
INIT: version 2.86 booting
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...done.
Activating swap...done.
Checking root file system...fsck from util-linux-ng 2.16.1
/sbin/fsck.xfs: XFS file system.
done.
Cleaning up ifupdown....
Checking file systems...fsck from util-linux-ng 2.16.1
/sbin/fsck.xfs: XFS file system.
done.
Setting up networking....
Mounting local filesystems...XFS mounting filesystem xvda2
done.
Activating swapfile swap...done.
Cleaning up temporary files....
Configuring network interfaces...if-up.d/mountnfs[eth0]: waiting for 
interface eth0:1 before doing NFS mounts ... (warning).
done.
Setting kernel variables (/etc/sysctl.conf)...done.
Starting portmap daemon....
Starting NFS common utilities: statd.
Cleaning up temporary files....
INIT: Entering runlevel: 2
Starting Zabbix agent: zabbix_agentd
Starting NFS common utilities: statd.
Starting enhanced syslogd: rsyslogd.
Starting web server: apache2.
Starting periodic command scheduler: cron.
Starting MTA: exim4.
Starting ident daemon: oidentd.
Starting OpenBSD Secure Shell server: sshd.

Debian GNU/Linux squeeze/sid test hvc0

test login:

- Valtteri Kiviniemi

Re: Latest unstable detects cpu speed incorrectly

[Pasi Kärkkäinen]

On Tue, Oct 27, 2009 at 05:22:56PM +0200, Valtteri Kiviniemi wrote:
> Hi,
> 
> We are testing the latest xen-unstable and found an interesting bug. 
> dom0 detects cpu speed correctly but when booting domU it detects it 
> incorrectly:
> 

It's not a bug, it's a feature :)

See: http://lists.xensource.com/archives/html/xen-devel/2009-10/msg01097.html

-- Pasi

> "Detected 1000.000 MHz processor."
> 
> domU config:
> 
> kernel = "/boot/bzImage-domU"
> builder = "linux"
> memory = "512"
> name = "test"
> vcpus = "8"
> cpus = [ "0", "1", "2", "3", "4", "5", "6", "7" ]
> vif = [ "mac=00:50:56:14:89:13, bridge=eth0" ]
> disk = [ "phy:/dev/virtuals/test,xvda1,w",
>          "phy:/dev/backups/test,xvda2,w" ]
> root = "/dev/xvda1 ro"
> extra = "console=hvc0"
> on_poweroff = "destroy"
> on_reboot = "restart"
> on_crash = "restart"
> 
> cpu info from domU:
> 
> test:~# cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 23
> model name      : Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz
> stepping        : 6
> cpu MHz         : 1000.000
> cache size      : 6144 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 10
> wp              : yes
> flags           : fpu de tsc msr pae cx8 sep cmov clflush mmx fxsr sse 
> sse2 ss ht syscall nx lm constant_tsc rep_good pni ssse3 cx16 sse4_1 
> hypervisor lahf_lm
> bogomips        : 2000.00
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 38 bits physical, 48 bits virtual
> power management:
> 
> domU's boot output:
> 
> Linux version 2.6.31.4-domU-00396-g9cf89da (root@xen) (gcc version 4.3.4 
> (Debian 4.3.4-5) ) #15 SMP Mon Oct 26 19:25:50 EET 2009
> Command line: root=/dev/xvda1 ro console=hvc0
> KERNEL supported cpus:
>   Intel GenuineIntel
>   AMD AuthenticAMD
>   Centaur CentaurHauls
> released 0 pages of unused memory
> BIOS-provided physical RAM map:
>  Xen: 0000000000000000 - 00000000000a0000 (usable)
>  Xen: 00000000000a0000 - 0000000000100000 (reserved)
>  Xen: 0000000000100000 - 0000000020000000 (usable)
> DMI not present or invalid.
> last_pfn = 0x20000 max_arch_pfn = 0x400000000
> init_memory_mapping: 0000000000000000-0000000020000000
> (6 early reservations) ==> bootmem [0000000000 - 0020000000]
>   #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 
> 0000001000]
>   #1 [00015fe000 - 000160d000]   XEN PAGETABLES ==> [00015fe000 - 
> 000160d000]
>   #2 [0000006000 - 0000008000]       TRAMPOLINE ==> [0000006000 - 
> 0000008000]
>   #3 [0001000000 - 00014da804]    TEXT DATA BSS ==> [0001000000 - 
> 00014da804]
>   #4 [00014fb000 - 00015fe000]   XEN START INFO ==> [00014fb000 - 
> 00015fe000]
>   #5 [0000100000 - 00001f0000]          PGTABLE ==> [0000100000 - 
> 00001f0000]
> Zone PFN ranges:
>   DMA      0x00000000 -> 0x00001000
>   DMA32    0x00001000 -> 0x00100000
>   Normal   0x00100000 -> 0x00100000
> Movable zone start PFN for each node
> early_node_map[2] active PFN ranges
>     0: 0x00000000 -> 0x000000a0
>     0: 0x00000100 -> 0x00020000
> SMP: Allowing 8 CPUs, 0 hotplug CPUs
> No local APIC present
> APIC: disable apic facility
> Allocating PCI resources starting at 20000000 (gap: 20000000:e0000000)
> NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
> PERCPU: Allocated 19 4k pages, static data 74976 bytes
> Xen: using vcpu_info placement
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 128941
> Kernel command line: root=/dev/xvda1 ro console=hvc0
> PID hash table entries: 2048 (order: 11, 16384 bytes)
> Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
> Initializing CPU#0
> Memory: 507316k/524288k available (2788k kernel code, 384k absent, 
> 15860k reserved, 1353k data, 328k init)
> SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
> NR_IRQS:512
> Detected 1000.000 MHz processor.
> Console: colour dummy device 80x25
> console [tty0] enabled
> console [hvc0] enabled
> installing Xen timer for CPU 0
> Calibrating delay loop (skipped), value calculated using timer 
> frequency.. 2000.00 BogoMIPS (lpj=10000000)
> Mount-cache hash table entries: 256
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 6144K
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 0
> SMP alternatives: switching to UP code
> installing Xen timer for CPU 1
> SMP alternatives: switching to SMP code
> Initializing CPU#1
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 6144K
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 0
> installing Xen timer for CPU 2
> Initializing CPU#2
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 6144K
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 0
> installing Xen timer for CPU 3
> Initializing CPU#3
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 6144K
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 0
> installing Xen timer for CPU 4
> Initializing CPU#4
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 6144K
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 0
> installing Xen timer for CPU 5
> Initializing CPU#5
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 6144K
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 0
> installing Xen timer for CPU 6
> Initializing CPU#6
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 6144K
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 0
> installing Xen timer for CPU 7
> Initializing CPU#7
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 6144K
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 0
> Brought up 8 CPUs
> Booting paravirtualized kernel on Xen
> Xen version: 3.5-unstable (preserve-AD)
> Using V2 grant tables.
> Grant table initialized
> NET: Registered protocol family 16
> xenbus_probe wake_waiting
> xenbus_probe_init ok
> bio: create slab <bio-0> at 0
> xenbus_probe_frontend_init bus registered ok
> xenbus_probe_devices device
> xenbus_probe_devices 1/3 vbd
> xenbus_probe_device_type type vbd
> xenbus_probe_device_type 1/2 51713
> xenbus_probe_device_type 2/2 51714
> xenbus_probe_device_type done
> xenbus_probe_devices 2/3 vif
> xenbus_probe_device_type type vif
> xenbus_probe_device_type 1/1 0
> xenbus_probe_device_type done
> xenbus_probe_devices 3/3 console
> xenbus_probe_device_type type console
> xenbus_probe_device_type 1/1 0
> xenbus_probe_device_type done
> xenbus_probe_devices done
> frontend_probe_and_watch devices probed ok
> frontend_probe_and_watch watch add ok ok
> frontend_probe_and_watch all done
> xen_balloon: Initialising balloon driver.
> SCSI subsystem initialized
> NET: Registered protocol family 2
> IP route cache hash table entries: 16384 (order: 5, 131072 bytes)
> TCP established hash table entries: 65536 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
> TCP: Hash tables configured (established 65536 bind 65536)
> TCP reno registered
> NET: Registered protocol family 1
> platform rtc_cmos: registered platform RTC device (no PNP device found)
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> fuse init (API version 7.12)
> SGI XFS with ACLs, security attributes, realtime, large block/inode 
> numbers, no debug enabled
> SGI XFS Quota Management subsystem
> msgmni has been set to 992
> alg: No test for stdrng (krng)
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
> io scheduler noop registered
> io scheduler cfq registered (default)
> Event-channel device installed.
> Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> blkfront: xvda1: barriers enabled
> Initialising Xen virtual ethernet driver.
> blkfront: xvda2: barriers enabled
> i8042.c: No controller found.
> mice: PS/2 mouse device common for all mice
> Netfilter messages via NETLINK v0.30.
> nf_conntrack version 0.5.0 (4096 buckets, 16384 max)
> CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
> nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
> sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
> ctnetlink v0.93: registering with nfnetlink.
> NF_TPROXY: Transparent proxy support initialized, version 4.1.0
> NF_TPROXY: Copyright (c) 2006-2007 BalaBit IT Ltd.
> xt_time: kernel timezone is -0000
> ip_tables: (C) 2000-2006 Netfilter Core Team
> ClusterIP Version 0.8 loaded successfully
> TCP cubic registered
> Initializing XFRM netlink socket
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
> All bugs added by David S. Miller <davem@redhat.com>
> registered taskstats version 1
> XENBUS: Device with no driver: device/console/0
> XFS mounting filesystem xvda1
> VFS: Mounted root (xfs filesystem) readonly on device 202:1.
> Freeing unused kernel memory: 328k freed
> INIT: version 2.86 booting
> Starting the hotplug events dispatcher: udevd.
> Synthesizing the initial hotplug events...done.
> Waiting for /dev to be fully populated...done.
> Activating swap...done.
> Checking root file system...fsck from util-linux-ng 2.16.1
> /sbin/fsck.xfs: XFS file system.
> done.
> Cleaning up ifupdown....
> Checking file systems...fsck from util-linux-ng 2.16.1
> /sbin/fsck.xfs: XFS file system.
> done.
> Setting up networking....
> Mounting local filesystems...XFS mounting filesystem xvda2
> done.
> Activating swapfile swap...done.
> Cleaning up temporary files....
> Configuring network interfaces...if-up.d/mountnfs[eth0]: waiting for 
> interface eth0:1 before doing NFS mounts ... (warning).
> done.
> Setting kernel variables (/etc/sysctl.conf)...done.
> Starting portmap daemon....
> Starting NFS common utilities: statd.
> Cleaning up temporary files....
> INIT: Entering runlevel: 2
> Starting Zabbix agent: zabbix_agentd
> Starting NFS common utilities: statd.
> Starting enhanced syslogd: rsyslogd.
> Starting web server: apache2.
> Starting periodic command scheduler: cron.
> Starting MTA: exim4.
> Starting ident daemon: oidentd.
> Starting OpenBSD Secure Shell server: sshd.
> 
> Debian GNU/Linux squeeze/sid test hvc0
> 
> test login:
> 
> - Valtteri Kiviniemi
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Latest unstable detects cpu speed incorrectly

[Keir Fraser]

On 27/10/2009 15:22, "Valtteri Kiviniemi" <valtteri.kiviniemi@dataproof.fi>
wrote:

> We are testing the latest xen-unstable and found an interesting bug.
> dom0 detects cpu speed correctly but when booting domU it detects it
> incorrectly:
> 
> "Detected 1000.000 MHz processor."

TSC is emulated at that speed. If you want old behaviour then add
tsc_native=1
to your domain config file.

 -- Keir

Re: Latest unstable detects cpu speed incorrectly

[Valtteri Kiviniemi]

Hi,

Ok, good to know. Is it always at 1GHz or can it be adjusted? Is there 
some other new features different from 3.4.1 that I should know?


- Valtteri Kiviniemi

Keir Fraser kirjoitti:
> On 27/10/2009 15:22, "Valtteri Kiviniemi" <valtteri.kiviniemi@dataproof.fi>
> wrote:
> 
>> We are testing the latest xen-unstable and found an interesting bug.
>> dom0 detects cpu speed correctly but when booting domU it detects it
>> incorrectly:
>>
>> "Detected 1000.000 MHz processor."
> 
> TSC is emulated at that speed. If you want old behaviour then add
> tsc_native=1
> to your domain config file.
> 
>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Latest unstable detects cpu speed incorrectly

[Valtteri Kiviniemi]

Hi,

Seems like that emulation is not quite working as it should be. domU's 
are using all the available cpu and then they crash. I did a fallback 
back to the old behaviour and the virtuals running with tsc_native=1 are 
working fine.

- Valtteri Kiviniemi

Valtteri Kiviniemi kirjoitti:
> Hi,
> 
> Ok, good to know. Is it always at 1GHz or can it be adjusted? Is there 
> some other new features different from 3.4.1 that I should know?
> 
> 
> - Valtteri Kiviniemi
> 
> Keir Fraser kirjoitti:
>> On 27/10/2009 15:22, "Valtteri Kiviniemi" 
>> <valtteri.kiviniemi@dataproof.fi>
>> wrote:
>>
>>> We are testing the latest xen-unstable and found an interesting bug.
>>> dom0 detects cpu speed correctly but when booting domU it detects it
>>> incorrectly:
>>>
>>> "Detected 1000.000 MHz processor."
>>
>> TSC is emulated at that speed. If you want old behaviour then add
>> tsc_native=1
>> to your domain config file.
>>
>>  -- Keir
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 

Re: Latest unstable detects cpu speed incorrectly

[Keir Fraser]

On 27/10/2009 15:48, "Valtteri Kiviniemi" <valtteri.kiviniemi@dataproof.fi>
wrote:

> Hi,
> 
> Ok, good to know. Is it always at 1GHz or can it be adjusted? Is there
> some other new features different from 3.4.1 that I should know?

The emulated clock rate is not adjustable. I don't think there are any other
new features which have such a significant default user-visible change.

 -- Keir

Re: Latest unstable detects cpu speed incorrectly

[Keir Fraser]

Haven't heard any other reports of that. Can you provide more details?

 -- Keir

On 27/10/2009 15:51, "Valtteri Kiviniemi" <valtteri.kiviniemi@dataproof.fi>
wrote:

> Hi,
> 
> Seems like that emulation is not quite working as it should be. domU's
> are using all the available cpu and then they crash. I did a fallback
> back to the old behaviour and the virtuals running with tsc_native=1 are
> working fine.
> 
> - Valtteri Kiviniemi
> 
> Valtteri Kiviniemi kirjoitti:
>> Hi,
>> 
>> Ok, good to know. Is it always at 1GHz or can it be adjusted? Is there
>> some other new features different from 3.4.1 that I should know?
>> 
>> 
>> - Valtteri Kiviniemi
>> 
>> Keir Fraser kirjoitti:
>>> On 27/10/2009 15:22, "Valtteri Kiviniemi"
>>> <valtteri.kiviniemi@dataproof.fi>
>>> wrote:
>>> 
>>>> We are testing the latest xen-unstable and found an interesting bug.
>>>> dom0 detects cpu speed correctly but when booting domU it detects it
>>>> incorrectly:
>>>> 
>>>> "Detected 1000.000 MHz processor."
>>> 
>>> TSC is emulated at that speed. If you want old behaviour then add
>>> tsc_native=1
>>> to your domain config file.
>>> 
>>>  -- Keir
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Latest unstable detects cpu speed incorrectly

[Valtteri Kiviniemi]

Hi,

I have to wait for that to occur again. There were no error messages, 
suddenly domU's with emulated TSC started to use a lot of CPU until they 
were so slow that they had to be destroyed. domU's with native tsc are 
working fine.

Is there any way to track down the problem?

- Valtteri Kiviniemi

Keir Fraser kirjoitti:
> Haven't heard any other reports of that. Can you provide more details?
> 
>  -- Keir
> 
> On 27/10/2009 15:51, "Valtteri Kiviniemi" <valtteri.kiviniemi@dataproof.fi>
> wrote:
> 
>> Hi,
>>
>> Seems like that emulation is not quite working as it should be. domU's
>> are using all the available cpu and then they crash. I did a fallback
>> back to the old behaviour and the virtuals running with tsc_native=1 are
>> working fine.
>>
>> - Valtteri Kiviniemi
>>
>> Valtteri Kiviniemi kirjoitti:
>>> Hi,
>>>
>>> Ok, good to know. Is it always at 1GHz or can it be adjusted? Is there
>>> some other new features different from 3.4.1 that I should know?
>>>
>>>
>>> - Valtteri Kiviniemi
>>>
>>> Keir Fraser kirjoitti:
>>>> On 27/10/2009 15:22, "Valtteri Kiviniemi"
>>>> <valtteri.kiviniemi@dataproof.fi>
>>>> wrote:
>>>>
>>>>> We are testing the latest xen-unstable and found an interesting bug.
>>>>> dom0 detects cpu speed correctly but when booting domU it detects it
>>>>> incorrectly:
>>>>>
>>>>> "Detected 1000.000 MHz processor."
>>>> TSC is emulated at that speed. If you want old behaviour then add
>>>> tsc_native=1
>>>> to your domain config file.
>>>>
>>>>  -- Keir
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 

Re: Latest unstable detects cpu speed incorrectly

[Valtteri Kiviniemi]

Hi,

I'll take that back, now its occuring in every virtual.

xentop shows this:

xentop - 18:13:15   Xen 3.5-unstable
6 domains: 4 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 16758480k total, 4884612k used, 11873868k free    CPUs: 8 @ 2493MHz
       NAME  STATE   CPU(sec) CPU(%)     MEM(k) MEM(%)  MAXMEM(k) 
MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS   VBD_OO   VBD_RD   VBD_WR SSID
        cvx -----r       1239  318.2    1048576    6.3    1048576 
6.3     8    1     4882     2706    2        0     9308     5191    0
         db ------         33   27.6     524288    3.1     524288 
3.1     8    1     1307      920    2        0     7170      518    0
   Domain-0 -----r       2531    4.7     520448    3.1   no limit 
n/a     8    0        0        0    0        0        0        0    0
       game -----r       1407  338.8    1048576    6.3    1048576 
6.3     8    1     1013     1002    2        0     3770      630    0
         gj ------        375   48.0     524288    3.1     524288 
3.1     8    1        0        0    2        0        0        0    0
     markka -----r      14565   62.8    1048576    6.3    1048576 
6.3     8    1    42202    39013    2        0   132016   122133    0


- Valtteri Kiviniemi

Valtteri Kiviniemi kirjoitti:
> Hi,
> 
> I have to wait for that to occur again. There were no error messages, 
> suddenly domU's with emulated TSC started to use a lot of CPU until they 
> were so slow that they had to be destroyed. domU's with native tsc are 
> working fine.
> 
> Is there any way to track down the problem?
> 
> - Valtteri Kiviniemi
> 
> Keir Fraser kirjoitti:
>> Haven't heard any other reports of that. Can you provide more details?
>>
>>  -- Keir
>>
>> On 27/10/2009 15:51, "Valtteri Kiviniemi" 
>> <valtteri.kiviniemi@dataproof.fi>
>> wrote:
>>
>>> Hi,
>>>
>>> Seems like that emulation is not quite working as it should be. domU's
>>> are using all the available cpu and then they crash. I did a fallback
>>> back to the old behaviour and the virtuals running with tsc_native=1 are
>>> working fine.
>>>
>>> - Valtteri Kiviniemi
>>>
>>> Valtteri Kiviniemi kirjoitti:
>>>> Hi,
>>>>
>>>> Ok, good to know. Is it always at 1GHz or can it be adjusted? Is there
>>>> some other new features different from 3.4.1 that I should know?
>>>>
>>>>
>>>> - Valtteri Kiviniemi
>>>>
>>>> Keir Fraser kirjoitti:
>>>>> On 27/10/2009 15:22, "Valtteri Kiviniemi"
>>>>> <valtteri.kiviniemi@dataproof.fi>
>>>>> wrote:
>>>>>
>>>>>> We are testing the latest xen-unstable and found an interesting bug.
>>>>>> dom0 detects cpu speed correctly but when booting domU it detects it
>>>>>> incorrectly:
>>>>>>
>>>>>> "Detected 1000.000 MHz processor."
>>>>> TSC is emulated at that speed. If you want old behaviour then add
>>>>> tsc_native=1
>>>>> to your domain config file.
>>>>>
>>>>>  -- Keir
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>
>>
> 

Re: Latest unstable detects cpu speed incorrectly

[Valtteri Kiviniemi]

Hi,

And the same time Domain-0 dmesg started to flood constantly this:

Attempting to checksum a non-TCP/UDP packet, dropping a protocol 1 packet
Attempting to checksum a non-TCP/UDP packet, dropping a protocol 1 packet

- Valtteri Kiviniemi

Valtteri Kiviniemi kirjoitti:
> Hi,
> 
> I'll take that back, now its occuring in every virtual.
> 
> xentop shows this:
> 
> xentop - 18:13:15   Xen 3.5-unstable
> 6 domains: 4 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
> Mem: 16758480k total, 4884612k used, 11873868k free    CPUs: 8 @ 2493MHz
>       NAME  STATE   CPU(sec) CPU(%)     MEM(k) MEM(%)  MAXMEM(k) 
> MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS   VBD_OO   VBD_RD   VBD_WR SSID
>        cvx -----r       1239  318.2    1048576    6.3    1048576 6.3     
> 8    1     4882     2706    2        0     9308     5191    0
>         db ------         33   27.6     524288    3.1     524288 3.1     
> 8    1     1307      920    2        0     7170      518    0
>   Domain-0 -----r       2531    4.7     520448    3.1   no limit n/a     
> 8    0        0        0    0        0        0        0    0
>       game -----r       1407  338.8    1048576    6.3    1048576 6.3     
> 8    1     1013     1002    2        0     3770      630    0
>         gj ------        375   48.0     524288    3.1     524288 3.1     
> 8    1        0        0    2        0        0        0    0
>     markka -----r      14565   62.8    1048576    6.3    1048576 6.3     
> 8    1    42202    39013    2        0   132016   122133    0
> 
> 
> - Valtteri Kiviniemi
> 
> Valtteri Kiviniemi kirjoitti:
>> Hi,
>>
>> I have to wait for that to occur again. There were no error messages, 
>> suddenly domU's with emulated TSC started to use a lot of CPU until 
>> they were so slow that they had to be destroyed. domU's with native 
>> tsc are working fine.
>>
>> Is there any way to track down the problem?
>>
>> - Valtteri Kiviniemi
>>
>> Keir Fraser kirjoitti:
>>> Haven't heard any other reports of that. Can you provide more details?
>>>
>>>  -- Keir
>>>
>>> On 27/10/2009 15:51, "Valtteri Kiviniemi" 
>>> <valtteri.kiviniemi@dataproof.fi>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Seems like that emulation is not quite working as it should be. domU's
>>>> are using all the available cpu and then they crash. I did a fallback
>>>> back to the old behaviour and the virtuals running with tsc_native=1 
>>>> are
>>>> working fine.
>>>>
>>>> - Valtteri Kiviniemi
>>>>
>>>> Valtteri Kiviniemi kirjoitti:
>>>>> Hi,
>>>>>
>>>>> Ok, good to know. Is it always at 1GHz or can it be adjusted? Is there
>>>>> some other new features different from 3.4.1 that I should know?
>>>>>
>>>>>
>>>>> - Valtteri Kiviniemi
>>>>>
>>>>> Keir Fraser kirjoitti:
>>>>>> On 27/10/2009 15:22, "Valtteri Kiviniemi"
>>>>>> <valtteri.kiviniemi@dataproof.fi>
>>>>>> wrote:
>>>>>>
>>>>>>> We are testing the latest xen-unstable and found an interesting bug.
>>>>>>> dom0 detects cpu speed correctly but when booting domU it detects it
>>>>>>> incorrectly:
>>>>>>>
>>>>>>> "Detected 1000.000 MHz processor."
>>>>>> TSC is emulated at that speed. If you want old behaviour then add
>>>>>> tsc_native=1
>>>>>> to your domain config file.
>>>>>>
>>>>>>  -- Keir
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-devel
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>
> 

Re: Latest unstable detects cpu speed incorrectly

[Mr. Teo En Ming (Zhang Enming)]

I am also experiencing 1000 MHz in my Windows XP HVM domU.

Check out my video here:

http://www.youtube.com/watch?v=3mxuNRiMxDU

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics) BEng(Hons)(Mechanical
Engineering)
Alma Maters:
(1) Singapore Polytechnic
(2) National University of Singapore
Blog URL: http://teo-en-ming-aka-zhang-enming.blogspot.com
Email: space.time.universe@gmail.com
MSN: teoenming@hotmail.com
Mobile Phone: +65-9648-9798
Street: Bedok Reservoir Road
Republic of Singapore



On Wed, Oct 28, 2009 at 12:12 AM, Valtteri Kiviniemi
<valtteri.kiviniemi@dataproof.fi> wrote:
> Hi,
>
> I have to wait for that to occur again. There were no error messages,
> suddenly domU's with emulated TSC started to use a lot of CPU until they
> were so slow that they had to be destroyed. domU's with native tsc are
> working fine.
>
> Is there any way to track down the problem?
>
> - Valtteri Kiviniemi
>
> Keir Fraser kirjoitti:
>>
>> Haven't heard any other reports of that. Can you provide more details?
>>
>>  -- Keir
>>
>> On 27/10/2009 15:51, "Valtteri Kiviniemi"
>> <valtteri.kiviniemi@dataproof.fi>
>> wrote:
>>
>>> Hi,
>>>
>>> Seems like that emulation is not quite working as it should be. domU's
>>> are using all the available cpu and then they crash. I did a fallback
>>> back to the old behaviour and the virtuals running with tsc_native=1 are
>>> working fine.
>>>
>>> - Valtteri Kiviniemi
>>>
>>> Valtteri Kiviniemi kirjoitti:
>>>>
>>>> Hi,
>>>>
>>>> Ok, good to know. Is it always at 1GHz or can it be adjusted? Is there
>>>> some other new features different from 3.4.1 that I should know?
>>>>
>>>>
>>>> - Valtteri Kiviniemi
>>>>
>>>> Keir Fraser kirjoitti:
>>>>>
>>>>> On 27/10/2009 15:22, "Valtteri Kiviniemi"
>>>>> <valtteri.kiviniemi@dataproof.fi>
>>>>> wrote:
>>>>>
>>>>>> We are testing the latest xen-unstable and found an interesting bug.
>>>>>> dom0 detects cpu speed correctly but when booting domU it detects it
>>>>>> incorrectly:
>>>>>>
>>>>>> "Detected 1000.000 MHz processor."
>>>>>
>>>>> TSC is emulated at that speed. If you want old behaviour then add
>>>>> tsc_native=1
>>>>> to your domain config file.
>>>>>
>>>>>  -- Keir
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: Latest unstable detects cpu speed incorrectly

[Mr. Teo En Ming (Zhang Enming)]

My Intel Pentium Dual Core E6300 @ 2.8 GHz seems to outperform AMD
Phenom II 550be clocked at 3.6 GHz.

http://forums.hardwarezone.com.sg/showthread.php?t=2527603&page=12

I did not set tsc_native=1 in my Windows XP HVM config. Should I set it?

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics) BEng(Hons)(Mechanical
Engineering)
Alma Maters:
(1) Singapore Polytechnic
(2) National University of Singapore
Blog URL: http://teo-en-ming-aka-zhang-enming.blogspot.com
Email: space.time.universe@gmail.com
MSN: teoenming@hotmail.com
Mobile Phone: +65-9648-9798
Street: Bedok Reservoir Road
Republic of Singapore



On Wed, Oct 28, 2009 at 12:18 AM, Mr. Teo En Ming (Zhang Enming)
<space.time.universe@gmail.com> wrote:
> I am also experiencing 1000 MHz in my Windows XP HVM domU.
>
> Check out my video here:
>
> http://www.youtube.com/watch?v=3mxuNRiMxDU
>
> --
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics) BEng(Hons)(Mechanical
> Engineering)
> Alma Maters:
> (1) Singapore Polytechnic
> (2) National University of Singapore
> Blog URL: http://teo-en-ming-aka-zhang-enming.blogspot.com
> Email: space.time.universe@gmail.com
> MSN: teoenming@hotmail.com
> Mobile Phone: +65-9648-9798
> Street: Bedok Reservoir Road
> Republic of Singapore
>
>
>
> On Wed, Oct 28, 2009 at 12:12 AM, Valtteri Kiviniemi
> <valtteri.kiviniemi@dataproof.fi> wrote:
>> Hi,
>>
>> I have to wait for that to occur again. There were no error messages,
>> suddenly domU's with emulated TSC started to use a lot of CPU until they
>> were so slow that they had to be destroyed. domU's with native tsc are
>> working fine.
>>
>> Is there any way to track down the problem?
>>
>> - Valtteri Kiviniemi
>>
>> Keir Fraser kirjoitti:
>>>
>>> Haven't heard any other reports of that. Can you provide more details?
>>>
>>>  -- Keir
>>>
>>> On 27/10/2009 15:51, "Valtteri Kiviniemi"
>>> <valtteri.kiviniemi@dataproof.fi>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Seems like that emulation is not quite working as it should be. domU's
>>>> are using all the available cpu and then they crash. I did a fallback
>>>> back to the old behaviour and the virtuals running with tsc_native=1 are
>>>> working fine.
>>>>
>>>> - Valtteri Kiviniemi
>>>>
>>>> Valtteri Kiviniemi kirjoitti:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Ok, good to know. Is it always at 1GHz or can it be adjusted? Is there
>>>>> some other new features different from 3.4.1 that I should know?
>>>>>
>>>>>
>>>>> - Valtteri Kiviniemi
>>>>>
>>>>> Keir Fraser kirjoitti:
>>>>>>
>>>>>> On 27/10/2009 15:22, "Valtteri Kiviniemi"
>>>>>> <valtteri.kiviniemi@dataproof.fi>
>>>>>> wrote:
>>>>>>
>>>>>>> We are testing the latest xen-unstable and found an interesting bug.
>>>>>>> dom0 detects cpu speed correctly but when booting domU it detects it
>>>>>>> incorrectly:
>>>>>>>
>>>>>>> "Detected 1000.000 MHz processor."
>>>>>>
>>>>>> TSC is emulated at that speed. If you want old behaviour then add
>>>>>> tsc_native=1
>>>>>> to your domain config file.
>>>>>>
>>>>>>  -- Keir
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-devel
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>

Re: Latest unstable detects cpu speed incorrectly

[Keir Fraser]

On 27/10/2009 16:14, "Valtteri Kiviniemi" <valtteri.kiviniemi@dataproof.fi>
wrote:

> I'll take that back, now its occuring in every virtual.

Yes it didn't sound like it would really be TSC related. How 'latest' is
your xen-unstable?

 -- Keir

Re: Latest unstable detects cpu speed incorrectly

[Valtteri Kiviniemi]

Hi,

It was downloaded and compiled on 2009-10-26 00:48 GMT+2. Kernel version 
is 2.6.31.4-dom0-00396-g9cf89da.

- Valtteri Kiviniemi

Keir Fraser kirjoitti:
> On 27/10/2009 16:14, "Valtteri Kiviniemi" <valtteri.kiviniemi@dataproof.fi>
> wrote:
> 
>> I'll take that back, now its occuring in every virtual.
> 
> Yes it didn't sound like it would really be TSC related. How 'latest' is
> your xen-unstable?
> 
>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Latest unstable detects cpu speed incorrectly

[Valtteri Kiviniemi]

Hi,

Now they are crashing on bootup:

general protection fault: 0000 [#1] SMP
last sysfs file:
CPU 0
Pid: 1, comm: swapper Not tainted 2.6.31.4-domU-00396-g9cf89da #15
RIP: e030:[<ffffffff8119e25f>]  [<ffffffff8119e25f>] strcmp+0x7/0x19
RSP: e02b:ffff88001f83be58  EFLAGS: 00010246
RAX: 0000000000000073 RBX: ffff88001fa1eb90 RCX: ffff88001fa1eb73
RDX: 0000000000000000 RSI: 0000b67d64d2a30e RDI: ffff88001f806900
RBP: 0000b67d64d2a30e R08: 0000000000000001 R09: ffffffff813c37c8
R10: ffffffff8100e072 R11: 0000000000000000 R12: 0000000000000000
R13: ffffffff81402030 R14: ffffffff8143f6a0 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffc90000000000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000001001000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff88001f83a000, task ffff88001f858000)
Stack:
  ffffffff810c7e84 ffffffff8100e072 ffff88001fa1eb40 0000b67d64d2a30e
<0> ffffffff810c6dc5 ffff88001fa1eb40 0000000000000000 0000000000000000
<0> 0000000000000000 0000b67d64d2a30e 00000000000274b2 0000000000000000
Call Trace:
  [<ffffffff810c7e84>] ? sysfs_find_dirent+0x1b/0x2f
  [<ffffffff8100e072>] ? check_events+0x12/0x20
  [<ffffffff810c6dc5>] ? sysfs_hash_and_remove+0x29/0x59
  [<ffffffff8107cecd>] ? sysfs_slab_alias+0x25/0x81
  [<ffffffff81431a7d>] ? slab_sysfs_init+0xb6/0xe9
  [<ffffffff814319c7>] ? slab_sysfs_init+0x0/0xe9
  [<ffffffff8100a051>] ? do_one_initcall+0x50/0x151
  [<ffffffff8141fb20>] ? kernel_init+0x14b/0x1a1
  [<ffffffff810112aa>] ? child_rip+0xa/0x20
  [<ffffffff810104ac>] ? int_ret_from_sys_call+0x7/0x1b
  [<ffffffff81010c5d>] ? retint_restore_args+0x5/0x6
  [<ffffffff810112a0>] ? child_rip+0x0/0x20
Code: f8 eb 10 48 ff c1 49 ff c0 4c 39 c2 75 08 c6 01 00 eb 0d 45 31 c0 
42 8a 04 06 88 01 84 c0 75 e3 48 89 f8 c3 31 d2 8a 0c 17 88 c8 <2a> 04 
16 84 c0 75 07 48 ff c2 84 c9 75 ed 0f be c0 c3 31 c9 eb
RIP  [<ffffffff8119e25f>] strcmp+0x7/0x19
  RSP <ffff88001f83be58>
---[ end trace a7919e7f17c0a725 ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: swapper Tainted: G      D    2.6.31.4-domU-00396-g9cf89da #15
Call Trace:
  [<ffffffff812b4993>] ? panic+0x86/0x12e
  [<ffffffff812b6919>] ? _spin_lock_irq+0x7/0x1c
  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
  [<ffffffff8100d9bd>] ? xen_force_evtchn_callback+0x9/0xa
  [<ffffffff8100e072>] ? check_events+0x12/0x20
  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
  [<ffffffff812b6995>] ? _write_lock_irq+0x7/0x16
  [<ffffffff8103b2bd>] ? exit_ptrace+0xa7/0x126
  [<ffffffff81036605>] ? do_exit+0x6a/0x5ce
  [<ffffffff8100e072>] ? check_events+0x12/0x20
  [<ffffffff81013eb1>] ? oops_end+0x8e/0x93
  [<ffffffff812b6d45>] ? general_protection+0x25/0x30
  [<ffffffff8100e072>] ? check_events+0x12/0x20
  [<ffffffff8119e25f>] ? strcmp+0x7/0x19
  [<ffffffff810c7e84>] ? sysfs_find_dirent+0x1b/0x2f
  [<ffffffff8100e072>] ? check_events+0x12/0x20
  [<ffffffff810c6dc5>] ? sysfs_hash_and_remove+0x29/0x59
  [<ffffffff8107cecd>] ? sysfs_slab_alias+0x25/0x81
  [<ffffffff81431a7d>] ? slab_sysfs_init+0xb6/0xe9
  [<ffffffff814319c7>] ? slab_sysfs_init+0x0/0xe9
  [<ffffffff8100a051>] ? do_one_initcall+0x50/0x151
  [<ffffffff8141fb20>] ? kernel_init+0x14b/0x1a1
  [<ffffffff810112aa>] ? child_rip+0xa/0x20
  [<ffffffff810104ac>] ? int_ret_from_sys_call+0x7/0x1b
  [<ffffffff81010c5d>] ? retint_restore_args+0x5/0x6
  [<ffffffff810112a0>] ? child_rip+0x0/0x20



- Valtteri Kiviniemi

Valtteri Kiviniemi kirjoitti:
> Hi,
> 
> It was downloaded and compiled on 2009-10-26 00:48 GMT+2. Kernel version 
> is 2.6.31.4-dom0-00396-g9cf89da.
> 
> - Valtteri Kiviniemi
> 
> Keir Fraser kirjoitti:
>> On 27/10/2009 16:14, "Valtteri Kiviniemi" 
>> <valtteri.kiviniemi@dataproof.fi>
>> wrote:
>>
>>> I'll take that back, now its occuring in every virtual.
>>
>> Yes it didn't sound like it would really be TSC related. How 'latest' is
>> your xen-unstable?
>>
>>  -- Keir
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Latest unstable detects cpu speed incorrectly

[Valtteri Kiviniemi]

Hi,

I also noticed that I dont have "[ ]     Paravirtualization layer for 
spinlocks" enabled in kernel. Should that be enabled?

- Valtteri Kiviniemi

Valtteri Kiviniemi kirjoitti:
> Hi,
> 
> Now they are crashing on bootup:
> 
> general protection fault: 0000 [#1] SMP
> last sysfs file:
> CPU 0
> Pid: 1, comm: swapper Not tainted 2.6.31.4-domU-00396-g9cf89da #15
> RIP: e030:[<ffffffff8119e25f>]  [<ffffffff8119e25f>] strcmp+0x7/0x19
> RSP: e02b:ffff88001f83be58  EFLAGS: 00010246
> RAX: 0000000000000073 RBX: ffff88001fa1eb90 RCX: ffff88001fa1eb73
> RDX: 0000000000000000 RSI: 0000b67d64d2a30e RDI: ffff88001f806900
> RBP: 0000b67d64d2a30e R08: 0000000000000001 R09: ffffffff813c37c8
> R10: ffffffff8100e072 R11: 0000000000000000 R12: 0000000000000000
> R13: ffffffff81402030 R14: ffffffff8143f6a0 R15: 0000000000000000
> FS:  0000000000000000(0000) GS:ffffc90000000000(0000) 
> knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000001001000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper (pid: 1, threadinfo ffff88001f83a000, task 
> ffff88001f858000)
> Stack:
>  ffffffff810c7e84 ffffffff8100e072 ffff88001fa1eb40 0000b67d64d2a30e
> <0> ffffffff810c6dc5 ffff88001fa1eb40 0000000000000000 0000000000000000
> <0> 0000000000000000 0000b67d64d2a30e 00000000000274b2 0000000000000000
> Call Trace:
>  [<ffffffff810c7e84>] ? sysfs_find_dirent+0x1b/0x2f
>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>  [<ffffffff810c6dc5>] ? sysfs_hash_and_remove+0x29/0x59
>  [<ffffffff8107cecd>] ? sysfs_slab_alias+0x25/0x81
>  [<ffffffff81431a7d>] ? slab_sysfs_init+0xb6/0xe9
>  [<ffffffff814319c7>] ? slab_sysfs_init+0x0/0xe9
>  [<ffffffff8100a051>] ? do_one_initcall+0x50/0x151
>  [<ffffffff8141fb20>] ? kernel_init+0x14b/0x1a1
>  [<ffffffff810112aa>] ? child_rip+0xa/0x20
>  [<ffffffff810104ac>] ? int_ret_from_sys_call+0x7/0x1b
>  [<ffffffff81010c5d>] ? retint_restore_args+0x5/0x6
>  [<ffffffff810112a0>] ? child_rip+0x0/0x20
> Code: f8 eb 10 48 ff c1 49 ff c0 4c 39 c2 75 08 c6 01 00 eb 0d 45 31 c0 
> 42 8a 04 06 88 01 84 c0 75 e3 48 89 f8 c3 31 d2 8a 0c 17 88 c8 <2a> 04 
> 16 84 c0 75 07 48 ff c2 84 c9 75 ed 0f be c0 c3 31 c9 eb
> RIP  [<ffffffff8119e25f>] strcmp+0x7/0x19
>  RSP <ffff88001f83be58>
> ---[ end trace a7919e7f17c0a725 ]---
> Kernel panic - not syncing: Attempted to kill init!
> Pid: 1, comm: swapper Tainted: G      D    2.6.31.4-domU-00396-g9cf89da #15
> Call Trace:
>  [<ffffffff812b4993>] ? panic+0x86/0x12e
>  [<ffffffff812b6919>] ? _spin_lock_irq+0x7/0x1c
>  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
>  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
>  [<ffffffff8100d9bd>] ? xen_force_evtchn_callback+0x9/0xa
>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
>  [<ffffffff812b6995>] ? _write_lock_irq+0x7/0x16
>  [<ffffffff8103b2bd>] ? exit_ptrace+0xa7/0x126
>  [<ffffffff81036605>] ? do_exit+0x6a/0x5ce
>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>  [<ffffffff81013eb1>] ? oops_end+0x8e/0x93
>  [<ffffffff812b6d45>] ? general_protection+0x25/0x30
>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>  [<ffffffff8119e25f>] ? strcmp+0x7/0x19
>  [<ffffffff810c7e84>] ? sysfs_find_dirent+0x1b/0x2f
>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>  [<ffffffff810c6dc5>] ? sysfs_hash_and_remove+0x29/0x59
>  [<ffffffff8107cecd>] ? sysfs_slab_alias+0x25/0x81
>  [<ffffffff81431a7d>] ? slab_sysfs_init+0xb6/0xe9
>  [<ffffffff814319c7>] ? slab_sysfs_init+0x0/0xe9
>  [<ffffffff8100a051>] ? do_one_initcall+0x50/0x151
>  [<ffffffff8141fb20>] ? kernel_init+0x14b/0x1a1
>  [<ffffffff810112aa>] ? child_rip+0xa/0x20
>  [<ffffffff810104ac>] ? int_ret_from_sys_call+0x7/0x1b
>  [<ffffffff81010c5d>] ? retint_restore_args+0x5/0x6
>  [<ffffffff810112a0>] ? child_rip+0x0/0x20
> 
> 
> 
> - Valtteri Kiviniemi
> 
> Valtteri Kiviniemi kirjoitti:
>> Hi,
>>
>> It was downloaded and compiled on 2009-10-26 00:48 GMT+2. Kernel 
>> version is 2.6.31.4-dom0-00396-g9cf89da.
>>
>> - Valtteri Kiviniemi
>>
>> Keir Fraser kirjoitti:
>>> On 27/10/2009 16:14, "Valtteri Kiviniemi" 
>>> <valtteri.kiviniemi@dataproof.fi>
>>> wrote:
>>>
>>>> I'll take that back, now its occuring in every virtual.
>>>
>>> Yes it didn't sound like it would really be TSC related. How 'latest' is
>>> your xen-unstable?
>>>
>>>  -- Keir
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 

Re: Latest unstable detects cpu speed incorrectly

[Keir Fraser]

On 27/10/2009 16:32, "Valtteri Kiviniemi" <valtteri.kiviniemi@dataproof.fi>
wrote:

> Hi,
> 
> It was downloaded and compiled on 2009-10-26 00:48 GMT+2. Kernel version
> is 2.6.31.4-dom0-00396-g9cf89da.

Are you able to run your existing kernels on the new Xen, or vice versa? My
suspicion would lie with the latest pv kernel bits, but it would be a way to
definitely narrow down the possibilities.

 -- Keir

Re: Latest unstable detects cpu speed incorrectly

[Mr. Teo En Ming (Zhang Enming)]

Hi

What does it mean by reverting to old behavior?

Does setting tsc_native=1 in HVM config increases the performance of domU?

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics) BEng(Hons)(Mechanical
Engineering)
Alma Maters:
(1) Singapore Polytechnic
(2) National University of Singapore
Blog URL: http://teo-en-ming-aka-zhang-enming.blogspot.com
Email: space.time.universe@gmail.com
MSN: teoenming@hotmail.com
Mobile Phone: +65-9648-9798
Street: Bedok Reservoir Road
Republic of Singapore



On Wed, Oct 28, 2009 at 12:47 AM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> On 27/10/2009 16:32, "Valtteri Kiviniemi" <valtteri.kiviniemi@dataproof.fi>
> wrote:
>
>> Hi,
>>
>> It was downloaded and compiled on 2009-10-26 00:48 GMT+2. Kernel version
>> is 2.6.31.4-dom0-00396-g9cf89da.
>
> Are you able to run your existing kernels on the new Xen, or vice versa? My
> suspicion would lie with the latest pv kernel bits, but it would be a way to
> definitely narrow down the possibilities.
>
>  -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: Latest unstable detects cpu speed incorrectly

[Keir Fraser]

On 27/10/2009 17:20, "Mr. Teo En Ming (Zhang Enming)"
<space.time.universe@gmail.com> wrote:

> What does it mean by reverting to old behavior?
> 
> Does setting tsc_native=1 in HVM config increases the performance of domU?

Yes, since it means RDTSC instruction is directly executed in the guest,
rather than being trapped and emulated. Degree of improvement will depend on
the guest and workload.

 -- Keir

Re: Latest unstable detects cpu speed incorrectly

[Mr. Teo En Ming (Zhang Enming)]

How much improvement (in terms of percentages) do you forsee?

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics) BEng(Hons)(Mechanical
Engineering)
Alma Maters:
(1) Singapore Polytechnic
(2) National University of Singapore
Blog URL: http://teo-en-ming-aka-zhang-enming.blogspot.com
Email: space.time.universe@gmail.com
MSN: teoenming@hotmail.com
Mobile Phone: +65-9648-9798
Street: Bedok Reservoir Road
Republic of Singapore

On Wed, Oct 28, 2009 at 1:23 AM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> On 27/10/2009 17:20, "Mr. Teo En Ming (Zhang Enming)"
> <space.time.universe@gmail.com> wrote:
>
>> What does it mean by reverting to old behavior?
>>
>> Does setting tsc_native=1 in HVM config increases the performance of domU?
>
> Yes, since it means RDTSC instruction is directly executed in the guest,
> rather than being trapped and emulated. Degree of improvement will depend on
> the guest and workload.
>
>  -- Keir
>
>
>

Re: Latest unstable detects cpu speed incorrectly

[Mr. Teo En Ming (Zhang Enming)]

I have set tsc_native=1 in my Windows XP HVM configuration file but
there is no noticeable improvement in performance.

Here is the Youtube video of the 2nd iteration of the Super PI 32M
benchmark test.

http://www.youtube.com/watch?v=m7W0OFFcw7I

Have I set the parameter correctly?

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics) BEng(Hons)(Mechanical
Engineering)
Alma Maters:
(1) Singapore Polytechnic
(2) National University of Singapore
Blog URL: http://teo-en-ming-aka-zhang-enming.blogspot.com
Email: space.time.universe@gmail.com
MSN: teoenming@hotmail.com
Mobile Phone: +65-9648-9798
Street: Bedok Reservoir Road
Republic of Singapore



On Wed, Oct 28, 2009 at 1:34 AM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> On 27/10/2009 17:25, "Mr. Teo En Ming (Zhang Enming)"
> <space.time.universe@gmail.com> wrote:
>
>> How much improvement (in terms of percentages) do you forsee?
>
> Small. A percent or two at most in reasonable situations.
>
>  -- Keir
>
>
>

Re: Latest unstable detects cpu speed incorrectly

[Keir Fraser]

On 27/10/2009 18:22, "Mr. Teo En Ming (Zhang Enming)"
<space.time.universe@gmail.com> wrote:

> I have set tsc_native=1 in my Windows XP HVM configuration file but
> there is no noticeable improvement in performance.
> 
> Here is the Youtube video of the 2nd iteration of the Super PI 32M
> benchmark test.
> 
> http://www.youtube.com/watch?v=m7W0OFFcw7I
> 
> Have I set the parameter correctly?

If your Windows gues tthinks its processor speed is other than 1GHz, then
yes.

 -- Keir

Re: Latest unstable detects cpu speed incorrectly

[Mr. Teo En Ming (Zhang Enming)]

It still alternates between 600 MHz and 1000 MHz.

Did I set tsc_native correctly? Please look at my Windows XP HVM
config below. Please also look at my Youtube video as well. Thank you.

#import os, re
#arch = os.uname()[4]
#if re.search('64', arch):
#    arch_libdir = 'lib64'
#else:
#    arch_libdir = 'lib'

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 3072

# Should be at least 2KB per MB of domain memory, plus a few MB per vcpu.
#shadow_memory = 8
name = "winxphome32"
vif = [ 'bridge=eth0' ]
acpi = 1
apic = 1
disk = [ 'phy:/dev/virtualmachines/winxphome32,hda,w',
'phy:/dev/sr0,hdc:cdrom,r' ]

#device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
#device_model = '/usr/' + 'lib' + '/xen/bin/qemu-dm'
device_model = 'qemu-dm'

#-----------------------------------------------------------------------------
# boot on floppy (a), hard disk (c) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot="cd"
sdl=0
vnc=1
vnclisten="192.168.1.2"
vncdisplay=1
vncunused=1
vncconsole=0
vncpasswd=''

#serial='pty'
#usbdevice='tablet'
# onboard
#pci = [ '00:02.0' ]
# nVidia Geforce 8400 GS & firewire controller & HD audio controller
pci = [ '01:00.0','02:01.0','00:1b.0' ]
vcpus=2
# No passthrough
#gfx_passthru=0
# onboard
#gfx_passthru=1
# nvidia
gfx_passthru=2

# Can only pass through one usb device at a time
usb=1
# USB Unity Green Mouse
#usbdevice = 'host:1bcf:0007'
# USB A1pro Black Mouse
usbdevice = 'host:15d9:0a41'
# USB Keyboard
#usbdevice = 'host:0603:00f2'
# USB Sony IC Recorder
#usbdevice = 'host:054c:0271'
# USB Lexmark X1270 Color Printer
#usbdevice = 'host:043d:00ff'
# USB Lexmark X1270 Photo Scanner
#usbdevice = 'host:043d:007d'
# USB Lexmark X1270 Generic Hub
#usbdevice = 'host:043d:007a'
# Hauppauge WinTV PVR USB2 TV Tuner
#usbdevice = 'host:2040:2400'

tsc_native=1


-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics) BEng(Hons)(Mechanical
Engineering)
Alma Maters:
(1) Singapore Polytechnic
(2) National University of Singapore
Blog URL: http://teo-en-ming-aka-zhang-enming.blogspot.com
Email: space.time.universe@gmail.com
MSN: teoenming@hotmail.com
Mobile Phone: +65-9648-9798
Street: Bedok Reservoir Road
Republic of Singapore


On Wed, Oct 28, 2009 at 2:40 AM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> On 27/10/2009 18:22, "Mr. Teo En Ming (Zhang Enming)"
> <space.time.universe@gmail.com> wrote:
>
>> I have set tsc_native=1 in my Windows XP HVM configuration file but
>> there is no noticeable improvement in performance.
>>
>> Here is the Youtube video of the 2nd iteration of the Super PI 32M
>> benchmark test.
>>
>> http://www.youtube.com/watch?v=m7W0OFFcw7I
>>
>> Have I set the parameter correctly?
>
> If your Windows gues tthinks its processor speed is other than 1GHz, then
> yes.
>
>  -- Keir
>
>
>

Re: Latest unstable detects cpu speed incorrectly

[Keir Fraser]

On 27/10/2009 18:47, "Mr. Teo En Ming (Zhang Enming)"
<space.time.universe@gmail.com> wrote:

> It still alternates between 600 MHz and 1000 MHz.

Yours doesn't seem to see 1GHZ clock with or without tsc_native=1. Perhaps
you have not upgraded dom0 tools for a while?

 -- Keir

Re: Latest unstable detects cpu speed incorrectly

[Mr. Teo En Ming (Zhang Enming)]

I am using the latest pvops dom0 2.6.31.4 kernel with Xen 3.5-unstable
changeset 20143.

Please see http://www.youtube.com/watch?v=HHUwg_zxYgw for xm list, xm
dmesg, and xm info output.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics) BEng(Hons)(Mechanical
Engineering)
Alma Maters:
(1) Singapore Polytechnic
(2) National University of Singapore
Blog URL: http://teo-en-ming-aka-zhang-enming.blogspot.com
Email: space.time.universe@gmail.com
MSN: teoenming@hotmail.com
Mobile Phone: +65-9648-9798
Street: Bedok Reservoir Road
Republic of Singapore


On Wed, Oct 28, 2009 at 2:56 AM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> On 27/10/2009 18:47, "Mr. Teo En Ming (Zhang Enming)"
> <space.time.universe@gmail.com> wrote:
>
>> It still alternates between 600 MHz and 1000 MHz.
>
> Yours doesn't seem to see 1GHZ clock with or without tsc_native=1. Perhaps
> you have not upgraded dom0 tools for a while?
>
>  -- Keir
>
>
>

Re: Latest unstable detects cpu speed incorrectly

[Jeremy Fitzhardinge]

On 10/27/09 08:51, Valtteri Kiviniemi wrote:
> Hi,
>
> Seems like that emulation is not quite working as it should be. domU's
> are using all the available cpu and then they crash. I did a fallback
> back to the old behaviour and the virtuals running with tsc_native=1
> are working fine.

What kind of domUs are they?  Windows? Linux?  HVM?  PV?  What versions?

    J

>
> - Valtteri Kiviniemi
>
> Valtteri Kiviniemi kirjoitti:
>> Hi,
>>
>> Ok, good to know. Is it always at 1GHz or can it be adjusted? Is
>> there some other new features different from 3.4.1 that I should know?
>>
>>
>> - Valtteri Kiviniemi
>>
>> Keir Fraser kirjoitti:
>>> On 27/10/2009 15:22, "Valtteri Kiviniemi"
>>> <valtteri.kiviniemi@dataproof.fi>
>>> wrote:
>>>
>>>> We are testing the latest xen-unstable and found an interesting bug.
>>>> dom0 detects cpu speed correctly but when booting domU it detects it
>>>> incorrectly:
>>>>
>>>> "Detected 1000.000 MHz processor."
>>>
>>> TSC is emulated at that speed. If you want old behaviour then add
>>> tsc_native=1
>>> to your domain config file.
>>>
>>>  -- Keir
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: Latest unstable detects cpu speed incorrectly

[Jeremy Fitzhardinge]

On 10/27/09 09:36, Valtteri Kiviniemi wrote:
> Hi,
>
> I also noticed that I dont have "[ ]     Paravirtualization layer for
> spinlocks" enabled in kernel. Should that be enabled?

It's not required.  It may help overall system load on loaded systems
(where there are consistently more runnable vcpus than pcpus), but it
can also slow things down.  I generally recommend turning it off on
problematic systems in order to simplify things (there have been bugs in
that code in the past, and its all fairly subtle).

    J

Re: Latest unstable detects cpu speed incorrectly

[Jeremy Fitzhardinge]

On 10/27/09 09:34, Valtteri Kiviniemi wrote:
> Hi,
>
> Now they are crashing on bootup:

"Now" compared to what?  Is this still related to tsc_native?

    J

>
> general protection fault: 0000 [#1] SMP
> last sysfs file:
> CPU 0
> Pid: 1, comm: swapper Not tainted 2.6.31.4-domU-00396-g9cf89da #15
> RIP: e030:[<ffffffff8119e25f>]  [<ffffffff8119e25f>] strcmp+0x7/0x19
> RSP: e02b:ffff88001f83be58  EFLAGS: 00010246
> RAX: 0000000000000073 RBX: ffff88001fa1eb90 RCX: ffff88001fa1eb73
> RDX: 0000000000000000 RSI: 0000b67d64d2a30e RDI: ffff88001f806900
> RBP: 0000b67d64d2a30e R08: 0000000000000001 R09: ffffffff813c37c8
> R10: ffffffff8100e072 R11: 0000000000000000 R12: 0000000000000000
> R13: ffffffff81402030 R14: ffffffff8143f6a0 R15: 0000000000000000
> FS:  0000000000000000(0000) GS:ffffc90000000000(0000)
> knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000001001000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper (pid: 1, threadinfo ffff88001f83a000, task
> ffff88001f858000)
> Stack:
>  ffffffff810c7e84 ffffffff8100e072 ffff88001fa1eb40 0000b67d64d2a30e
> <0> ffffffff810c6dc5 ffff88001fa1eb40 0000000000000000 0000000000000000
> <0> 0000000000000000 0000b67d64d2a30e 00000000000274b2 0000000000000000
> Call Trace:
>  [<ffffffff810c7e84>] ? sysfs_find_dirent+0x1b/0x2f
>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>  [<ffffffff810c6dc5>] ? sysfs_hash_and_remove+0x29/0x59
>  [<ffffffff8107cecd>] ? sysfs_slab_alias+0x25/0x81
>  [<ffffffff81431a7d>] ? slab_sysfs_init+0xb6/0xe9
>  [<ffffffff814319c7>] ? slab_sysfs_init+0x0/0xe9
>  [<ffffffff8100a051>] ? do_one_initcall+0x50/0x151
>  [<ffffffff8141fb20>] ? kernel_init+0x14b/0x1a1
>  [<ffffffff810112aa>] ? child_rip+0xa/0x20
>  [<ffffffff810104ac>] ? int_ret_from_sys_call+0x7/0x1b
>  [<ffffffff81010c5d>] ? retint_restore_args+0x5/0x6
>  [<ffffffff810112a0>] ? child_rip+0x0/0x20
> Code: f8 eb 10 48 ff c1 49 ff c0 4c 39 c2 75 08 c6 01 00 eb 0d 45 31
> c0 42 8a 04 06 88 01 84 c0 75 e3 48 89 f8 c3 31 d2 8a 0c 17 88 c8 <2a>
> 04 16 84 c0 75 07 48 ff c2 84 c9 75 ed 0f be c0 c3 31 c9 eb
> RIP  [<ffffffff8119e25f>] strcmp+0x7/0x19
>  RSP <ffff88001f83be58>
> ---[ end trace a7919e7f17c0a725 ]---
> Kernel panic - not syncing: Attempted to kill init!
> Pid: 1, comm: swapper Tainted: G      D   
> 2.6.31.4-domU-00396-g9cf89da #15
> Call Trace:
>  [<ffffffff812b4993>] ? panic+0x86/0x12e
>  [<ffffffff812b6919>] ? _spin_lock_irq+0x7/0x1c
>  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
>  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
>  [<ffffffff8100d9bd>] ? xen_force_evtchn_callback+0x9/0xa
>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
>  [<ffffffff812b6995>] ? _write_lock_irq+0x7/0x16
>  [<ffffffff8103b2bd>] ? exit_ptrace+0xa7/0x126
>  [<ffffffff81036605>] ? do_exit+0x6a/0x5ce
>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>  [<ffffffff81013eb1>] ? oops_end+0x8e/0x93
>  [<ffffffff812b6d45>] ? general_protection+0x25/0x30
>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>  [<ffffffff8119e25f>] ? strcmp+0x7/0x19
>  [<ffffffff810c7e84>] ? sysfs_find_dirent+0x1b/0x2f
>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>  [<ffffffff810c6dc5>] ? sysfs_hash_and_remove+0x29/0x59
>  [<ffffffff8107cecd>] ? sysfs_slab_alias+0x25/0x81
>  [<ffffffff81431a7d>] ? slab_sysfs_init+0xb6/0xe9
>  [<ffffffff814319c7>] ? slab_sysfs_init+0x0/0xe9
>  [<ffffffff8100a051>] ? do_one_initcall+0x50/0x151
>  [<ffffffff8141fb20>] ? kernel_init+0x14b/0x1a1
>  [<ffffffff810112aa>] ? child_rip+0xa/0x20
>  [<ffffffff810104ac>] ? int_ret_from_sys_call+0x7/0x1b
>  [<ffffffff81010c5d>] ? retint_restore_args+0x5/0x6
>  [<ffffffff810112a0>] ? child_rip+0x0/0x20
>
>
>
> - Valtteri Kiviniemi
>
> Valtteri Kiviniemi kirjoitti:
>> Hi,
>>
>> It was downloaded and compiled on 2009-10-26 00:48 GMT+2. Kernel
>> version is 2.6.31.4-dom0-00396-g9cf89da.
>>
>> - Valtteri Kiviniemi
>>
>> Keir Fraser kirjoitti:
>>> On 27/10/2009 16:14, "Valtteri Kiviniemi"
>>> <valtteri.kiviniemi@dataproof.fi>
>>> wrote:
>>>
>>>> I'll take that back, now its occuring in every virtual.
>>>
>>> Yes it didn't sound like it would really be TSC related. How
>>> 'latest' is
>>> your xen-unstable?
>>>
>>>  -- Keir
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: Latest unstable detects cpu speed incorrectly

[Valtteri Kiviniemi]

Hi,

Compared to "nothing", just started to crash. Sometimes they boot and 
sometimes they dont. I did a full reboot for the server and now they are 
all working again without cpu spiking. The server was up only couple of 
days before this started, so I think that its going to start crashin in 
48 hours or so.

The problem is both tsc native and emulated. If the domUs wont crash, 
they just start to using 400-800% cpu when just idling.

dmesg on Domain-0 is also flooding this:

"Attempting to checksum a non-TCP/UDP packet, dropping a protocol 1 packet"

- Valtteri Kiviniemi

Jeremy Fitzhardinge kirjoitti:
> On 10/27/09 09:34, Valtteri Kiviniemi wrote:
>> Hi,
>>
>> Now they are crashing on bootup:
> 
> "Now" compared to what?  Is this still related to tsc_native?
> 
>     J
> 
>> general protection fault: 0000 [#1] SMP
>> last sysfs file:
>> CPU 0
>> Pid: 1, comm: swapper Not tainted 2.6.31.4-domU-00396-g9cf89da #15
>> RIP: e030:[<ffffffff8119e25f>]  [<ffffffff8119e25f>] strcmp+0x7/0x19
>> RSP: e02b:ffff88001f83be58  EFLAGS: 00010246
>> RAX: 0000000000000073 RBX: ffff88001fa1eb90 RCX: ffff88001fa1eb73
>> RDX: 0000000000000000 RSI: 0000b67d64d2a30e RDI: ffff88001f806900
>> RBP: 0000b67d64d2a30e R08: 0000000000000001 R09: ffffffff813c37c8
>> R10: ffffffff8100e072 R11: 0000000000000000 R12: 0000000000000000
>> R13: ffffffff81402030 R14: ffffffff8143f6a0 R15: 0000000000000000
>> FS:  0000000000000000(0000) GS:ffffc90000000000(0000)
>> knlGS:0000000000000000
>> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 0000000000000000 CR3: 0000000001001000 CR4: 0000000000002660
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process swapper (pid: 1, threadinfo ffff88001f83a000, task
>> ffff88001f858000)
>> Stack:
>>  ffffffff810c7e84 ffffffff8100e072 ffff88001fa1eb40 0000b67d64d2a30e
>> <0> ffffffff810c6dc5 ffff88001fa1eb40 0000000000000000 0000000000000000
>> <0> 0000000000000000 0000b67d64d2a30e 00000000000274b2 0000000000000000
>> Call Trace:
>>  [<ffffffff810c7e84>] ? sysfs_find_dirent+0x1b/0x2f
>>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>>  [<ffffffff810c6dc5>] ? sysfs_hash_and_remove+0x29/0x59
>>  [<ffffffff8107cecd>] ? sysfs_slab_alias+0x25/0x81
>>  [<ffffffff81431a7d>] ? slab_sysfs_init+0xb6/0xe9
>>  [<ffffffff814319c7>] ? slab_sysfs_init+0x0/0xe9
>>  [<ffffffff8100a051>] ? do_one_initcall+0x50/0x151
>>  [<ffffffff8141fb20>] ? kernel_init+0x14b/0x1a1
>>  [<ffffffff810112aa>] ? child_rip+0xa/0x20
>>  [<ffffffff810104ac>] ? int_ret_from_sys_call+0x7/0x1b
>>  [<ffffffff81010c5d>] ? retint_restore_args+0x5/0x6
>>  [<ffffffff810112a0>] ? child_rip+0x0/0x20
>> Code: f8 eb 10 48 ff c1 49 ff c0 4c 39 c2 75 08 c6 01 00 eb 0d 45 31
>> c0 42 8a 04 06 88 01 84 c0 75 e3 48 89 f8 c3 31 d2 8a 0c 17 88 c8 <2a>
>> 04 16 84 c0 75 07 48 ff c2 84 c9 75 ed 0f be c0 c3 31 c9 eb
>> RIP  [<ffffffff8119e25f>] strcmp+0x7/0x19
>>  RSP <ffff88001f83be58>
>> ---[ end trace a7919e7f17c0a725 ]---
>> Kernel panic - not syncing: Attempted to kill init!
>> Pid: 1, comm: swapper Tainted: G      D   
>> 2.6.31.4-domU-00396-g9cf89da #15
>> Call Trace:
>>  [<ffffffff812b4993>] ? panic+0x86/0x12e
>>  [<ffffffff812b6919>] ? _spin_lock_irq+0x7/0x1c
>>  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
>>  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
>>  [<ffffffff8100d9bd>] ? xen_force_evtchn_callback+0x9/0xa
>>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>>  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
>>  [<ffffffff812b6995>] ? _write_lock_irq+0x7/0x16
>>  [<ffffffff8103b2bd>] ? exit_ptrace+0xa7/0x126
>>  [<ffffffff81036605>] ? do_exit+0x6a/0x5ce
>>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>>  [<ffffffff81013eb1>] ? oops_end+0x8e/0x93
>>  [<ffffffff812b6d45>] ? general_protection+0x25/0x30
>>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>>  [<ffffffff8119e25f>] ? strcmp+0x7/0x19
>>  [<ffffffff810c7e84>] ? sysfs_find_dirent+0x1b/0x2f
>>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>>  [<ffffffff810c6dc5>] ? sysfs_hash_and_remove+0x29/0x59
>>  [<ffffffff8107cecd>] ? sysfs_slab_alias+0x25/0x81
>>  [<ffffffff81431a7d>] ? slab_sysfs_init+0xb6/0xe9
>>  [<ffffffff814319c7>] ? slab_sysfs_init+0x0/0xe9
>>  [<ffffffff8100a051>] ? do_one_initcall+0x50/0x151
>>  [<ffffffff8141fb20>] ? kernel_init+0x14b/0x1a1
>>  [<ffffffff810112aa>] ? child_rip+0xa/0x20
>>  [<ffffffff810104ac>] ? int_ret_from_sys_call+0x7/0x1b
>>  [<ffffffff81010c5d>] ? retint_restore_args+0x5/0x6
>>  [<ffffffff810112a0>] ? child_rip+0x0/0x20
>>
>>
>>
>> - Valtteri Kiviniemi
>>
>> Valtteri Kiviniemi kirjoitti:
>>> Hi,
>>>
>>> It was downloaded and compiled on 2009-10-26 00:48 GMT+2. Kernel
>>> version is 2.6.31.4-dom0-00396-g9cf89da.
>>>
>>> - Valtteri Kiviniemi
>>>
>>> Keir Fraser kirjoitti:
>>>> On 27/10/2009 16:14, "Valtteri Kiviniemi"
>>>> <valtteri.kiviniemi@dataproof.fi>
>>>> wrote:
>>>>
>>>>> I'll take that back, now its occuring in every virtual.
>>>> Yes it didn't sound like it would really be TSC related. How
>>>> 'latest' is
>>>> your xen-unstable?
>>>>
>>>>  -- Keir
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
> 

Re: Latest unstable detects cpu speed incorrectly

[Valtteri Kiviniemi]

Hi,

Forgot to mention that the domUs are Debian testing with XFS filesystem. 
  You can find the bootlog from my previous postings.

- Valtteri Kiviniemi

Valtteri Kiviniemi kirjoitti:
> Hi,
> 
> Compared to "nothing", just started to crash. Sometimes they boot and 
> sometimes they dont. I did a full reboot for the server and now they are 
> all working again without cpu spiking. The server was up only couple of 
> days before this started, so I think that its going to start crashin in 
> 48 hours or so.
> 
> The problem is both tsc native and emulated. If the domUs wont crash, 
> they just start to using 400-800% cpu when just idling.
> 
> dmesg on Domain-0 is also flooding this:
> 
> "Attempting to checksum a non-TCP/UDP packet, dropping a protocol 1 packet"
> 
> - Valtteri Kiviniemi
> 
> Jeremy Fitzhardinge kirjoitti:
>> On 10/27/09 09:34, Valtteri Kiviniemi wrote:
>>> Hi,
>>>
>>> Now they are crashing on bootup:
>>
>> "Now" compared to what?  Is this still related to tsc_native?
>>
>>     J
>>
>>> general protection fault: 0000 [#1] SMP
>>> last sysfs file:
>>> CPU 0
>>> Pid: 1, comm: swapper Not tainted 2.6.31.4-domU-00396-g9cf89da #15
>>> RIP: e030:[<ffffffff8119e25f>]  [<ffffffff8119e25f>] strcmp+0x7/0x19
>>> RSP: e02b:ffff88001f83be58  EFLAGS: 00010246
>>> RAX: 0000000000000073 RBX: ffff88001fa1eb90 RCX: ffff88001fa1eb73
>>> RDX: 0000000000000000 RSI: 0000b67d64d2a30e RDI: ffff88001f806900
>>> RBP: 0000b67d64d2a30e R08: 0000000000000001 R09: ffffffff813c37c8
>>> R10: ffffffff8100e072 R11: 0000000000000000 R12: 0000000000000000
>>> R13: ffffffff81402030 R14: ffffffff8143f6a0 R15: 0000000000000000
>>> FS:  0000000000000000(0000) GS:ffffc90000000000(0000)
>>> knlGS:0000000000000000
>>> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> CR2: 0000000000000000 CR3: 0000000001001000 CR4: 0000000000002660
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> Process swapper (pid: 1, threadinfo ffff88001f83a000, task
>>> ffff88001f858000)
>>> Stack:
>>>  ffffffff810c7e84 ffffffff8100e072 ffff88001fa1eb40 0000b67d64d2a30e
>>> <0> ffffffff810c6dc5 ffff88001fa1eb40 0000000000000000 0000000000000000
>>> <0> 0000000000000000 0000b67d64d2a30e 00000000000274b2 0000000000000000
>>> Call Trace:
>>>  [<ffffffff810c7e84>] ? sysfs_find_dirent+0x1b/0x2f
>>>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>>>  [<ffffffff810c6dc5>] ? sysfs_hash_and_remove+0x29/0x59
>>>  [<ffffffff8107cecd>] ? sysfs_slab_alias+0x25/0x81
>>>  [<ffffffff81431a7d>] ? slab_sysfs_init+0xb6/0xe9
>>>  [<ffffffff814319c7>] ? slab_sysfs_init+0x0/0xe9
>>>  [<ffffffff8100a051>] ? do_one_initcall+0x50/0x151
>>>  [<ffffffff8141fb20>] ? kernel_init+0x14b/0x1a1
>>>  [<ffffffff810112aa>] ? child_rip+0xa/0x20
>>>  [<ffffffff810104ac>] ? int_ret_from_sys_call+0x7/0x1b
>>>  [<ffffffff81010c5d>] ? retint_restore_args+0x5/0x6
>>>  [<ffffffff810112a0>] ? child_rip+0x0/0x20
>>> Code: f8 eb 10 48 ff c1 49 ff c0 4c 39 c2 75 08 c6 01 00 eb 0d 45 31
>>> c0 42 8a 04 06 88 01 84 c0 75 e3 48 89 f8 c3 31 d2 8a 0c 17 88 c8 <2a>
>>> 04 16 84 c0 75 07 48 ff c2 84 c9 75 ed 0f be c0 c3 31 c9 eb
>>> RIP  [<ffffffff8119e25f>] strcmp+0x7/0x19
>>>  RSP <ffff88001f83be58>
>>> ---[ end trace a7919e7f17c0a725 ]---
>>> Kernel panic - not syncing: Attempted to kill init!
>>> Pid: 1, comm: swapper Tainted: G      D   
>>> 2.6.31.4-domU-00396-g9cf89da #15
>>> Call Trace:
>>>  [<ffffffff812b4993>] ? panic+0x86/0x12e
>>>  [<ffffffff812b6919>] ? _spin_lock_irq+0x7/0x1c
>>>  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
>>>  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
>>>  [<ffffffff8100d9bd>] ? xen_force_evtchn_callback+0x9/0xa
>>>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>>>  [<ffffffff811a5e20>] ? dummycon_dummy+0x0/0x3
>>>  [<ffffffff812b6995>] ? _write_lock_irq+0x7/0x16
>>>  [<ffffffff8103b2bd>] ? exit_ptrace+0xa7/0x126
>>>  [<ffffffff81036605>] ? do_exit+0x6a/0x5ce
>>>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>>>  [<ffffffff81013eb1>] ? oops_end+0x8e/0x93
>>>  [<ffffffff812b6d45>] ? general_protection+0x25/0x30
>>>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>>>  [<ffffffff8119e25f>] ? strcmp+0x7/0x19
>>>  [<ffffffff810c7e84>] ? sysfs_find_dirent+0x1b/0x2f
>>>  [<ffffffff8100e072>] ? check_events+0x12/0x20
>>>  [<ffffffff810c6dc5>] ? sysfs_hash_and_remove+0x29/0x59
>>>  [<ffffffff8107cecd>] ? sysfs_slab_alias+0x25/0x81
>>>  [<ffffffff81431a7d>] ? slab_sysfs_init+0xb6/0xe9
>>>  [<ffffffff814319c7>] ? slab_sysfs_init+0x0/0xe9
>>>  [<ffffffff8100a051>] ? do_one_initcall+0x50/0x151
>>>  [<ffffffff8141fb20>] ? kernel_init+0x14b/0x1a1
>>>  [<ffffffff810112aa>] ? child_rip+0xa/0x20
>>>  [<ffffffff810104ac>] ? int_ret_from_sys_call+0x7/0x1b
>>>  [<ffffffff81010c5d>] ? retint_restore_args+0x5/0x6
>>>  [<ffffffff810112a0>] ? child_rip+0x0/0x20
>>>
>>>
>>>
>>> - Valtteri Kiviniemi
>>>
>>> Valtteri Kiviniemi kirjoitti:
>>>> Hi,
>>>>
>>>> It was downloaded and compiled on 2009-10-26 00:48 GMT+2. Kernel
>>>> version is 2.6.31.4-dom0-00396-g9cf89da.
>>>>
>>>> - Valtteri Kiviniemi
>>>>
>>>> Keir Fraser kirjoitti:
>>>>> On 27/10/2009 16:14, "Valtteri Kiviniemi"
>>>>> <valtteri.kiviniemi@dataproof.fi>
>>>>> wrote:
>>>>>
>>>>>> I'll take that back, now its occuring in every virtual.
>>>>> Yes it didn't sound like it would really be TSC related. How
>>>>> 'latest' is
>>>>> your xen-unstable?
>>>>>
>>>>>  -- Keir
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>
> 

RE: Latest unstable detects cpu speed incorrectly

[Dan Magenheimer]

> On 27/10/2009 15:48, "Valtteri Kiviniemi" 
> <valtteri.kiviniemi@dataproof.fi>
> wrote:
> 
> > Hi,
> > 
> > Ok, good to know. Is it always at 1GHz or can it be 
> adjusted? Is there
> > some other new features different from 3.4.1 that I should know?
> 
> The emulated clock rate is not adjustable.
> 
>  -- Keir

This isn't an unreasonable request though.  VMware does
provide a parameter like this.  It's essentially syntactic
sugar but if it avoids confusing customers, it might be
worthwhile to implement this with the default multiplier being
the native frequency of the host machine so the OS-reported
processor frequency displays correctly.  The downside is
of course is that the extra multiply would need to be
done on every emulated TSC (unless maybe it could be folded
into the other required scaling?)

Re: Latest unstable detects cpu speed incorrectly

[Jeremy Fitzhardinge]

On 10/27/09 15:15, Dan Magenheimer wrote:
> The downside is
> of course is that the extra multiply would need to be
> done on every emulated TSC (unless maybe it could be folded
> into the other required scaling?)
>   

Given the speed of multipliers compared to everything else on the
emulation path, I don't think it would be measurable let alone
noticeable (my measurements show that multiply is trivial compared to a
native rdtsc).

The nice thing about a fixed 1GHz emulated tsc is that it makes it clear
that it is emulated.

    J