similar to: Unable to build linux-2.6-xen.hg

Hi, I have successfully installed Xen unstable binary on SuSE 9.3. I am trying to do a source install and I got the following error. Will be glad for any help or guidance. In file included from include/asm-xen/asm/processor.h:18, from include/asm/thread_info.h:17, from include/linux/thread_info.h:21, from include/linux/spinlock.h:12, from include/linux/capability.h:45, from

Hi Armin! I have problems on debian sarge with standard 2.6.8-2-386 kernel. I've installed the packages: kernel-headers-2.6.8-2 kernel-headers-2.6.8-2-386 kernel-image-2.6.8-2-386 kernel-kbuild-2.6-3 kernel-source-2.6.8 Then I unpacked the kernel sources into /usr/src/kernel-source-2.6.8 and made a symlink from /usr/src/linux --> kernel-source-2.6.8 Then I entered

From: Randy Dunlap <randy.dunlap@oracle.com> Since Voyager and Visual WS already define ARCH_SETUP, it looks like PARAVIRT shouldn't be offered for them. In file included from arch/i386/kernel/setup.c:63: include/asm-i386/mach-visws/setup_arch.h:8:1: warning: "ARCH_SETUP" redefined In file included from include/asm/msr.h:5, from include/asm/processor.h:17,

From: Randy Dunlap <randy.dunlap@oracle.com> Since Voyager and Visual WS already define ARCH_SETUP, it looks like PARAVIRT shouldn't be offered for them. In file included from arch/i386/kernel/setup.c:63: include/asm-i386/mach-visws/setup_arch.h:8:1: warning: "ARCH_SETUP" redefined In file included from include/asm/msr.h:5, from include/asm/processor.h:17,

As usual, written and (build-)tested on 2.6.27.4 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2008-11-04/drivers/xen/blktap/blktap.c =================================================================== --- head-2008-11-04.orig/drivers/xen/blktap/blktap.c 2008-10-01 16:35:04.000000000 +0200 +++

Linker changes to add the VMI MACH_TEXT area into the kernel text section. This area layout is heavily influenced by magic to overlap exactly with the 32-byte VMI ROM entry points, allowing the kernel to copy the VMI ROM over the native section. As use of magic is on the decline, this approach is being phased out in favor of the more modern approach of the inline implementation. The translation

Linker changes to add the VMI MACH_TEXT area into the kernel text section. This area layout is heavily influenced by magic to overlap exactly with the 32-byte VMI ROM entry points, allowing the kernel to copy the VMI ROM over the native section. As use of magic is on the decline, this approach is being phased out in favor of the more modern approach of the inline implementation. The translation

The ARM platform has no concept of PVMMU and therefor no HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out when not required. In some similar situations (e.g. P2M) we have defined dummy functions to avoid this, however I think we can/should draw the line at dummying out actual hypercalls. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- arch/x86/xen/Kconfig

tree: git://github.com/ablock84/linux-btrfs.git btrfs-far head: f9a5bb450a8cc7aa5fd4f11d0306b3f48cf2771d commit: 29aefeaaf482ab396ff53c2bbf5c35ce237b91c0 [19/20] fs: add libfarstream support config: make ARCH=s390 allmodconfig All error/warnings: In file included from include/linux/byteorder/big_endian.h:4:0, from arch/s390/include/uapi/asm/byteorder.h:4,

Hi I am writing a freestanding statically linked x86_64 kernel. And now I want to load and use thread-local storage. As I have a freestanding binary I can't use libc/Linux kernel thread-local mechanism and need to implement initialization code by myself. I am trying to find a clear explanation of what is the memory layout for x86 TLS but can't find anything useful. Maybe LLVM developers

Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- tools/virtio/linux/kernel.h | 2 +- tools/virtio/linux/thread_info.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644 tools/virtio/linux/thread_info.h diff --git a/tools/virtio/linux/kernel.h b/tools/virtio/linux/kernel.h index 395521a..fca8381 100644 --- a/tools/virtio/linux/kernel.h +++

tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/mst/vhost.git linux-next head: 39c226b6b576b23d6d558331e6895f02b0892555 commit: 990055c63121520ad29deca72b1167b392563ddd [16/17] virtio-balloon: Add support for providing unused page reports to host config: riscv-allmodconfig (attached as .config) compiler: riscv64-linux-gcc (GCC) 7.4.0 reproduce: wget

Hi, on 2 different servers, running 7.1-stable + zfs, I get this error rather frequently: Feb 5 17:01:03 warhol-00 kernel: impossible packet length (543383918) from nfs server sunfire:/dist Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1936028704) from nfs server sunfire:/dist Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1869363744) from nfs server sunfire:/dist

Hello, I am trying to run xen-3.0 in some of my dell servers. I have tried the binary distribution of xen, but it doesn''t boot in my test system (a dell poweredge 750) because a module driver problem (I get an error message during booting saying it doesn''t load a NFS root filesystem). So I am trying to compile a custom kernel. So I have downloaded linux source 2.6.12. I am

(This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override during mapping") The grant mapping API does m2p_override unnecessarily: only gntdev needs it, for blkback and future netback patches it just cause a lock contention, as those pages never go to userspace. Therefore this series does the following: - the bulk of the original function (everything after the mapping

(This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override during mapping") The grant mapping API does m2p_override unnecessarily: only gntdev needs it, for blkback and future netback patches it just cause a lock contention, as those pages never go to userspace. Therefore this series does the following: - the bulk of the original function (everything after the mapping

So, is everyone happy with this smerge of Ingo and Gerd's work? Reposted below. Thanks, Rusty. -------- Forwarded Message -------- From: Linus Torvalds <torvalds@osdl.org> To: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@osdl.org> Subject: Re: [Fwd: [Fwd: FW: argh]] Date: Wed, 17 May 2006 21:35:51 -0700 (PDT) On Thu, 18 May 2006, Rusty Russell wrote: >

So, is everyone happy with this smerge of Ingo and Gerd's work? Reposted below. Thanks, Rusty. -------- Forwarded Message -------- From: Linus Torvalds <torvalds@osdl.org> To: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@osdl.org> Subject: Re: [Fwd: [Fwd: FW: argh]] Date: Wed, 17 May 2006 21:35:51 -0700 (PDT) On Thu, 18 May 2006, Rusty Russell wrote: >

[ Expand, correct and clarify comments; minor code change. ] Most of the time we can simply use the iret instruction to exit the kernel, rather than having to use the iret hypercall - the only exception is if we're returning into vm86 mode, or from delivering an NMI (which we don't support yet). When running native, iret has the behaviour of testing for a pending interrupt atomically