similar to: [PATCH 1/5] Skip timer works.patch

Isolate some of the non-VMI timer related changes in Linux. This patch moves the cyc_2_ns conversion code into a common location, eliminating redundant code in hpet and tsc timer implementations, and introduces some macros that may be redefined by the sub-architecture to avoid dependence on APIC routing, CMOS time sync, and testing for broken time hardware (which presumably, does not happen in a

Isolate some of the non-VMI timer related changes in Linux. This patch moves the cyc_2_ns conversion code into a common location, eliminating redundant code in hpet and tsc timer implementations, and introduces some macros that may be redefined by the sub-architecture to avoid dependence on APIC routing, CMOS time sync, and testing for broken time hardware (which presumably, does not happen in a

And I think current issue with "Kernel panic - not syncing: IO-APIC + timer doesn't work!" is also clear. timer_irq_works(void) never returns 1: https://github.com/torvalds/linux/blob/d966564fcdc19e13eb6ba1fbe6b8101070339c3d/arch/x86/kernel/apic/io_apic.c#L1641 I think it happens because of jiffies (http://www.makelinux.net/books/lkd2/ch10lev1sec3#ch10fig01) It should have the

OK, I need to do something like this to io_apic.c - split the hardware specific parts out under mach-default, so we can override them for other subarchitectures. It's not finished, needs header file and makefile work. Would you be willing to take this if I do it? I'm not going to bother if you're not, such refactorings are a pig to maintain out of tree. Frankly, io_apic.c needs a

OK, I need to do something like this to io_apic.c - split the hardware specific parts out under mach-default, so we can override them for other subarchitectures. It's not finished, needs header file and makefile work. Would you be willing to take this if I do it? I'm not going to bother if you're not, such refactorings are a pig to maintain out of tree. Frankly, io_apic.c needs a

Maybe that is https://reviews.llvm.org/D30171. On Mon, Feb 20, 2017 at 11:16 PM, Dmitry Golovin <dima at golovin.in> wrote: > Hi, > > I can't build the Linux kernel anymore. With the latest kernel source and > latest LLVM and LLD (with D30163) I can only get this error message when > linking vmlinux: > > ld.lld: error: unable to move location counter backward >

Keir: When thinking more about IO_APIC virtualization in Itanium, I got a confuse: How is io_apic.c used in xenlinux (X86)? It looks like all the machine resource of io_apic is handled in xen (xen/arch/x86/irq.c), and the PIRQ based on event channel can be handled by pirq_type in linux/arch/xen/kernel/evtchn.c pretty well? Then what is the function of file io_apic.c? thx,eddie

Package: xen Version: 4.1.0-3 Severity: important Tags: wheezy sid User: debian-gcc at lists.debian.org Usertags: ftbfs-gcc-4.6 ftbfs-werror This package builds with -Werror, and GCC 4.6 triggers new warnings which will make the package fail to build. Currently a Debian patch just passes -Wno-error=unused-but-set-variable and -Wno-error=unused-but-set-parameter to avoid build failures,

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1304937815 -3600 # Node ID 35abcbcdf8bcabab6e0bbd929f69b613e167edfd # Parent 4b0692880dfa557d4e1537c7a58c412c1286a416 xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables gcc 4.6 complains: io_apic.c: In function 'restore_IO_APIC_setup':

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1304937815 -3600 # Node ID 35abcbcdf8bcabab6e0bbd929f69b613e167edfd # Parent 4b0692880dfa557d4e1537c7a58c412c1286a416 xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables gcc 4.6 complains: io_apic.c: In function 'restore_IO_APIC_setup':

There are BIOSes that want to map the IO-APIC MMIO region from some ACPI method(s), and there is at least one BIOS flavor that wants to use this mapping to clear an RTE''s mask bit. While we can''t allow the latter, we can permit reads and simply drop write attempts, leveraging the already existing infrastructure introduced for dealing with AMD IOMMUs'' representation as

Also, rename to MOVE_CLEANUP_VECTOR to be in line with the other IPI names. This requires bumping LAST_HIPRIORITY_VECTOR, but does mean that the range FIRST-LAST_HIPRIORITY_VECTORs are free once again. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/apic.c --- a/xen/arch/x86/apic.c Mon Sep 05 15:10:28 2011 +0100 +++

> -----Original Message----- > From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] > On Behalf Of Yijing Wang > Sent: Saturday, July 26, 2014 8:39 AM > To: linux-kernel at vger.kernel.org > Cc: Xinwei Hu; Wuyun; Bjorn Helgaas; linux-pci at vger.kernel.org; > Paul.Mundt at huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm- > kernel at

> -----Original Message----- > From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] > On Behalf Of Yijing Wang > Sent: Saturday, July 26, 2014 8:39 AM > To: linux-kernel at vger.kernel.org > Cc: Xinwei Hu; Wuyun; Bjorn Helgaas; linux-pci at vger.kernel.org; > Paul.Mundt at huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm- > kernel at

The timer_irq_works() boot check may sometimes fail in a VM, when the Host is overcommitted or when the Guest is running nested. Since the intended check is unnecessary on VMware's virtual hardware, this change by-passes it. Signed-off-by: Renat Valiullin <rvaliullin at vmware.com> Acked-by: Alok N Kataria <akataria at vmware.com> --- arch/x86/kernel/cpu/vmware.c | 5 +++++ 1

The timer_irq_works() boot check may sometimes fail in a VM, when the Host is overcommitted or when the Guest is running nested. Since the intended check is unnecessary on VMware's virtual hardware, this change by-passes it. Signed-off-by: Renat Valiullin <rvaliullin at vmware.com> Acked-by: Alok N Kataria <akataria at vmware.com> --- arch/x86/kernel/cpu/vmware.c | 5 +++++ 1

The patch moves the struct IO_APIC_route_entry to a common place. This allows us to share the struct with iosapic. Thanks, -- Dexuan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

The formatting of the IO-APIC debug key info has niggled me for a while, and with the latest interrupt bug I am chasing, has finally motivated me to fix it. The attached patch causes all columns to line up, and removes the comma which served no purpose in combination with the spaces already present. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900,

Thanks for your ideas, Sean ! >The bug is not likely to be corrupted data in the decompressed output (that is just calling into a gzip routine or something). You shouldn't have to dump/printf->trace from memory during boot to see that data since the "real" kernel binary that is being decompressed into that memory region is probably already somewhere > in your build tree

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine