similar to: Re: [RFC PATCH V4 4/5] cpuidle: driver for xen

When booting 2.6.37 (from kernel.org) under Xen 4.1, there are apparently issues with timer interrupts being delivered to the dom0. Repeatedly causing an interrupt (for example, the ACPI power button) will allow the system to boot, as does adding "clocksource=jiffies" to the kernel command line. This is only present under Xen, not when booting the same kernel on real hardware. When boot

On 03/23/2011 08:43 AM, Len Brown wrote: > Why is this patch a step forward? Hi Len, I have basically moved the code for arch default and mwait idle from arch/x86/kernel/process.c to a driver. This was suggested by Venki (https://lkml.org/lkml/2010/10/19/460) as part of pm_idle cleanup and direct call of cpuidle_idle_call(). There is not much new code here. > >> +obj-$(CONFIG_X86)

Hello, The following patches are a solution to a problem we have encountered when using the Xen hypervisor: - Need Pxx/Cxx states to save on power consumption when using Xen (we do want those datacenters to consume less power!), - Also need to figure out the Turbo mode so that the scheduler can properly boost a core for CPU bound guests. In essence the Xen hypervisor requires that

Hi everyone, When I set CONFIG_ACPI_PROCESSOR, CONFIG_CPU_IDLE and CONFIG_INTEL_IDLE to y then I cannot boot Xen; there is a crash. If I turn CONFIG_INTEL_IDLE off then the boot goes well and, after dom0 has booted, xenpm works and gives some sane output, see below. I have tested this with kernels 3.2 to 3.4.6. Is it impossible to use INTEL_IDLE with Xen? If this is a known issue then maybe

Hi everyone, When I set CONFIG_ACPI_PROCESSOR, CONFIG_CPU_IDLE and CONFIG_INTEL_IDLE to y then I cannot boot Xen; there is a crash. If I turn CONFIG_INTEL_IDLE off then the boot goes well and, after dom0 has booted, xenpm works and gives some sane output, see below. I have tested this with kernels 3.2 to 3.4.6. Is it impossible to use INTEL_IDLE with Xen? If this is a known issue then maybe

From ba9abf6ee7e5fe0515e2d51b14743c8d5416285c Mon Sep 17 00:00:00 2001 From: Liu, Jinsong <jinsong.liu@intel.com> Date: Fri, 24 Feb 2012 02:18:02 +0800 Subject: [PATCH 2/2] Xen pad logic This patch implement Xen pad logic, and when getting pad device notification, it hypercalls to Xen hypervisor for core parking. Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> ---

There''re basically two methods to enter a given C-state: legacy (hlt + I/O read), and native(using mwait). MWAIT is always preferred when both underlying CPU and OS support, which is a more efficient way to conduct C-state transition. Xen PM relies on Dom0 to parse ACPI Cx/Px information, which involves one step to notify BIOS about a set of capabilities supported by OSPM. One capability

On 2017-11-16 06:03, Thomas Gleixner wrote: > On Wed, 15 Nov 2017, Peter Zijlstra wrote: > >> On Mon, Nov 13, 2017 at 06:06:02PM +0800, Quan Xu wrote: >>> From: Yang Zhang <yang.zhang.wz at gmail.com> >>> >>> Implement a generic idle poll which resembles the functionality >>> found in arch/. Provide weak arch_cpu_idle_poll function which

.. snip.. >> Both of them (acpi-cpufreq.c and powernow-k8.c) have a symbol >> dependency on drivers/acpi/processor.c > > But them being ''m'' or ''y'' shouldn''t matter in the end. I thought you were saying it matters - as it should be done around the same time as cpufreq drivers were loaded? .. snip.. >> For a), this would mean some

Hi everyone, I would like to ask what the current status of FLR, or better of FLR emulation is in latest Xen and if we can expect better support in the future. I''m asking because with xl (latest build and traditional qemu, not upstream), I always had problems with rebooting domUs which have vga cards passed through to them, because appearently they don''t get reinitialized and

Folks, The second release candidate for Xen 3.4.0 is available at http://xenbits.xensource.com/xen-unstable.hg, tagged as ''3.4.0-rc2''. Please test! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, Jeremy Since now the pv_ops domain0 is approaching, we are considering to port the dom0 power management related code, or more specifically, the Cx/Px ACPI info parsing code, to pv_ops domain0 tree, so that people can utilize Xen power management capability (Cx/PX) under pv_ops domain0. This RFC is a draft version for comments. === Overview === Requirement: Xen hypervisor need Cx/Px ACPI

Hi Michael: Sorry to brother. But I''ve been suffered this issue quite a long time. My test environment is 2.6.32.36 + xen 4.0.1 + bnx2, 2.3. Also cpu idle is disabled in grub. Grub info: title Red Hat Enterprise Linux Server (2.6.32.36xen) kernel /xen-4.0.1.gz iommu=off x2apic=off console=com1,vga com1=115200,8n1 noreboot cpuidle=0 cpufreq=none

Hi, I want to try Xen on ARMv8 Simulator. Can you please provide guidance?. I am looking for information about sources, build and procedure to launch Xen on ARMv8 Thanks & Regards Vijay

It has never been used for anything, and Linux 3.7 doesn''t propagate this information anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- Konrad, on the pv-ops side it may be better to pass zero rather than leaving the field completely uninitialized. --- a/xen/arch/x86/acpi/cpu_idle.c +++ b/xen/arch/x86/acpi/cpu_idle.c @@ -935,7 +935,6 @@ static void set_cx( }

I'm running a server recently installed with centos 4.2. It's running the kernel in the subject line, on an PIII 866Mhz with 512mb ram. The system is running basically two processes: 1) ssh to remote system, receiving a stream of bytes piped into 2) gzip the stream, write to disk file The system is slow, relatively (866Mhz cpu) and the network is fast (gigabit) so the limiting factor

Hi All, We've had a report[1] of the virt_blk driver causing a lot of spew because it's calling a sleeping function from an invalid context. The backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. The reporter is on CC and can give you relevant details. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1113805 [drm] Initialized bochs-drm 1.0.0 20130925 for

Hi All, We've had a report[1] of the virt_blk driver causing a lot of spew because it's calling a sleeping function from an invalid context. The backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. The reporter is on CC and can give you relevant details. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1113805 [drm] Initialized bochs-drm 1.0.0 20130925 for

Enables numa if vnuma topology hypercall is supported and it is domU. Signed-off-by: Elena Ufimtseva <ufimtseva@gmail.com> --- arch/x86/xen/setup.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 68c054f..0aab799 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -20,6 +20,7 @@ #include

When I came into work this morning the console had the following: bio_endio __end_that_request_first scsi_end_request scsi_io_completion scsi_finish_command scsi_softirq __do_softirq do_softirg do_irq command_interrupt default_idle cpu_idle start_kernel Panic I am running software RAID-1 on this machine. I had 2 IDE disks and the machine when down once in a while with similiar messages. I