Valtteri Kiviniemi
2009-Oct-27 15:22 UTC
[Xen-devel] Latest unstable detects cpu speed incorrectly
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2009-Oct-27 15:27 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Oct-27 15:28 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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
Valtteri Kiviniemi
2009-Oct-27 15:48 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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
Valtteri Kiviniemi
2009-Oct-27 15:51 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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
Keir Fraser
2009-Oct-27 16:02 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Oct-27 16:05 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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
Valtteri Kiviniemi
2009-Oct-27 16:12 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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
Valtteri Kiviniemi
2009-Oct-27 16:14 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Valtteri Kiviniemi
2009-Oct-27 16:15 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 >>> >>> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Oct-27 16:18 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Oct-27 16:26 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Oct-27 16:27 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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
Valtteri Kiviniemi
2009-Oct-27 16:32 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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
Valtteri Kiviniemi
2009-Oct-27 16:34 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Valtteri Kiviniemi
2009-Oct-27 16:36 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Oct-27 16:47 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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
Mr. Teo En Ming (Zhang Enming)
2009-Oct-27 17:20 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Oct-27 17:23 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Oct-27 17:25 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Oct-27 18:22 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Oct-27 18:40 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Oct-27 18:47 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Oct-27 18:56 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Oct-27 18:59 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2009-Oct-27 19:41 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2009-Oct-27 19:46 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2009-Oct-27 19:48 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Valtteri Kiviniemi
2009-Oct-27 21:39 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Valtteri Kiviniemi
2009-Oct-27 21:40 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 >>> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dan Magenheimer
2009-Oct-27 22:15 UTC
RE: [Xen-devel] Latest unstable detects cpu speed incorrectly
> 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. > > -- KeirThis 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?) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2009-Oct-27 22:31 UTC
Re: [Xen-devel] Latest unstable detects cpu speed incorrectly
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel