Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Xen 2.6.25 dom0 kernel ebuild
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
microcosm
n00b
n00b


Joined: 05 Jul 2009
Posts: 11

PostPosted: Fri Jul 10, 2009 9:55 am    Post subject: Reply with quote

I get same warning as you, but that's it. I have an amd64 arch on the other hand.

However compiling with

Code:
< > Export Xen attributes in sysfs


checked, then it halts with following message:

Code:
ERROR: "xenbus_xsd_state" [drivers/xen/core/xen_sysfs.ko] undefined!
ERROR: "paddr_vmcoreinfo_xen" [drivers/xen/core/xen_sysfs.ko] undefined!
ERROR: "vmcoreinfo_size_xen" [drivers/xen/core/xen_sysfs.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2


Although sysfs never shows up in menuconfig, it's in the .config:

Code:
CONFIG_SYSFS=y


So it shouldn't be the lack of sysfs, right?
Not sure if anyone gets any wiser from this... but might be of use for the kernel people.
Back to top
View user's profile Send private message
andylyon
n00b
n00b


Joined: 13 Jun 2006
Posts: 74

PostPosted: Sat Jul 11, 2009 9:10 pm    Post subject: Reply with quote

microcosm wrote:
I get same warning as you, but that's it. I have an amd64 arch on the other hand.

However compiling with

Code:
< > Export Xen attributes in sysfs


checked, then it halts with following message:

Code:
ERROR: "xenbus_xsd_state" [drivers/xen/core/xen_sysfs.ko] undefined!
ERROR: "paddr_vmcoreinfo_xen" [drivers/xen/core/xen_sysfs.ko] undefined!
ERROR: "vmcoreinfo_size_xen" [drivers/xen/core/xen_sysfs.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2


Although sysfs never shows up in menuconfig, it's in the .config:

Code:
CONFIG_SYSFS=y


So it shouldn't be the lack of sysfs, right?
Not sure if anyone gets any wiser from this... but might be of use for the kernel people.


I will be releasing a updated set of patches soon which will fix this issue and some other problems, please bear with me as I've recently been in hospital so not able to respond as quickly as I usually do.

andy
Back to top
View user's profile Send private message
2bbionic
Tux's lil' helper
Tux's lil' helper


Joined: 24 Mar 2005
Posts: 143

PostPosted: Sat Jul 11, 2009 9:17 pm    Post subject: Reply with quote

Don't bustle ! It's a great work you are doing here !

BTW; could you explain us, how you create these patchsets and ebuilds? Perhaps, in a howto? I'm very interested in these things but had no success with it...

2bbionic
Back to top
View user's profile Send private message
andylyon
n00b
n00b


Joined: 13 Jun 2006
Posts: 74

PostPosted: Sat Jul 11, 2009 9:39 pm    Post subject: Reply with quote

2bbionic wrote:
Don't bustle ! It's a great work you are doing here !

BTW; could you explain us, how you create these patchsets and ebuilds? Perhaps, in a howto? I'm very interested in these things but had no success with it...

2bbionic


Of course, its very simple, Jan Beulich @ Suse does the hard work!, I just make some minor changes, I download the latest kernel-source rpm which can be found in several places , they are not always updated in sync so I just get the latest one for the version I am working on, unfortunately because the current supported openSUSE kernel version is 2.6.27 the patches are kept up to date with bleeding edge kernel.org source, so for example I had to grab 2.6.29 quickly before they moved on to 2.6.30-git1 etc, Jan recently sent me the last 2.6.30 version patches so that is what I will be using for the next release as they will soon move to 2.6.31-rc2-git7 etc.

Download the source from:

http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_Factory/src/
http://download.opensuse.org/factory/repo/src-oss/suse/src/
http://download.opensuse.org/repositories/Base:/Kernel/standard/src/
ftp://ftp.suse.com/pub/projects/kernel/kotd/HEAD/x86_64/

I rpm2targz the rpm and then extract patches-xen.tar.bz2 and try to apply the patches to the appropriate vanilla kernel source, there are always some failures but they are usually quite easy to fix.

I do not use all of the opensuse patches that are contained in patches-xen.tar.bz2, as some of them are for backwards compatibility, are Xen specific fixes for other opensuse kernel patches, or require patches to xen-tools, for example I believe opensuse supports adding cpu's to a linux domU by starting with for example 8 cpus, then hot unplugging all but 1, thus allowing them to be increased while the domain is running, a nice feature but I don't want to start maintaining Xen patches as well!

When I finish the next version I will post a diff output showing just how small the changes are.

Andy
Back to top
View user's profile Send private message
trikolon
Apprentice
Apprentice


Joined: 04 Dec 2004
Posts: 297
Location: Erlangen

PostPosted: Sun Jul 12, 2009 9:20 am    Post subject: Reply with quote

Quote:
Of course, its very simple, Jan Beulich @ Suse does the hard work!, I just make some minor changes, I download the latest kernel-source rpm which can be found in several places , they are not always updated in sync so I just get the latest one for the version I am working on, unfortunately because the current supported openSUSE kernel version is 2.6.27 the patches are kept up to date with bleeding edge kernel.org source, so for example I had to grab 2.6.29 quickly before they moved on to 2.6.30-git1 etc, Jan recently sent me the last 2.6.30 version patches so that is what I will be using for the next release as they will soon move to 2.6.31-rc2-git7 etc.

Download the source from:

http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_Factory/src/
http://download.opensuse.org/factory/repo/src-oss/suse/src/
http://download.opensuse.org/repositories/Base:/Kernel/standard/src/
ftp://ftp.suse.com/pub/projects/kernel/kotd/HEAD/x86_64/

I rpm2targz the rpm and then extract patches-xen.tar.bz2 and try to apply the patches to the appropriate vanilla kernel source, there are always some failures but they are usually quite easy to fix.

I do not use all of the opensuse patches that are contained in patches-xen.tar.bz2, as some of them are for backwards compatibility, are Xen specific fixes for other opensuse kernel patches, or require patches to xen-tools, for example I believe opensuse supports adding cpu's to a linux domU by starting with for example 8 cpus, then hot unplugging all but 1, thus allowing them to be increased while the domain is running, a nice feature but I don't want to start maintaining Xen patches as well!

When I finish the next version I will post a diff output showing just how small the changes are.

Andy


nice, but how do you figure out what the right patch-order is? thats the point where i usually mess everything up ;)

ben
Back to top
View user's profile Send private message
andylyon
n00b
n00b


Joined: 13 Jun 2006
Posts: 74

PostPosted: Sun Jul 12, 2009 5:39 pm    Post subject: Reply with quote

trikolon wrote:
Quote:
Of course, its very simple, Jan Beulich @ Suse does the hard work!, I just make some minor changes, I download the latest kernel-source rpm which can be found in several places , they are not always updated in sync so I just get the latest one for the version I am working on, unfortunately because the current supported openSUSE kernel version is 2.6.27 the patches are kept up to date with bleeding edge kernel.org source, so for example I had to grab 2.6.29 quickly before they moved on to 2.6.30-git1 etc, Jan recently sent me the last 2.6.30 version patches so that is what I will be using for the next release as they will soon move to 2.6.31-rc2-git7 etc.

Download the source from:

http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_Factory/src/
http://download.opensuse.org/factory/repo/src-oss/suse/src/
http://download.opensuse.org/repositories/Base:/Kernel/standard/src/
ftp://ftp.suse.com/pub/projects/kernel/kotd/HEAD/x86_64/

I rpm2targz the rpm and then extract patches-xen.tar.bz2 and try to apply the patches to the appropriate vanilla kernel source, there are always some failures but they are usually quite easy to fix.

I do not use all of the opensuse patches that are contained in patches-xen.tar.bz2, as some of them are for backwards compatibility, are Xen specific fixes for other opensuse kernel patches, or require patches to xen-tools, for example I believe opensuse supports adding cpu's to a linux domU by starting with for example 8 cpus, then hot unplugging all but 1, thus allowing them to be increased while the domain is running, a nice feature but I don't want to start maintaining Xen patches as well!

When I finish the next version I will post a diff output showing just how small the changes are.

Andy


nice, but how do you figure out what the right patch-order is? thats the point where i usually mess everything up ;)

ben


Oops, I forgot to explain that step, after converting the kernel source rpm to a tarball and extracting it there will be a file called series.conf which contains a full list of all of the opensuse kernel patches in the order they are applied, series.conf is used by guards which is run as part of the rpm build process, e.g. ./guards i386 x86_64 <series.conf , but I just open the series.conf directly as it includes some info/descriptions of the patches, just make sure that you don't include patches which are commented out with # or +.

So then we have a list of the Xen patches that rpm would apply, the next step is to comment out any that were created by xen-port-patches.py from other opensuse kernel patches, there is a easy way to do that:

ubermicro patches.xen # pwd
/usr/src/suse_kernels/suse-kernel-source-2.6.30-50.1/patches.xen
ubermicro patches.xen # grep "Automatically created" * | grep "xen-port-patches.py" | grep -v "patches.kernel.org"
xen3-driver-core-misc-add-nodename-support-for-misc-devices.patch:Automatically created from "patches.suse/driver-core-misc-add-nodename-support-for-misc-devices.patch" by xen-port-patches.py
xen3-kdb-x86:Automatically created from "patches.suse/kdb-x86" by xen-port-patches.py
xen3-panic-on-io-nmi.diff:Automatically created from "patches.suse/panic-on-io-nmi.diff" by xen-port-patches.py
xen3-seccomp-disable-tsc-option:Automatically created from "patches.fixes/seccomp-disable-tsc-option" by xen-port-patches.py
xen3-stack-unwind:Automatically created from "patches.suse/stack-unwind" by xen-port-patches.py
xen3-x86-mark_rodata_rw.patch:Automatically created from "patches.suse/x86-mark_rodata_rw.patch" by xen-port-patches.py
xen3-x86_64-unwind-annotations:Automatically created from "patches.arch/x86_64-unwind-annotations" by xen-port-patches.py

None of these will work unless the corresponding patch is applied to the kernel first so I comment them out, I also open each patch and read the description as some others e.g. patches.xen/tmem are for bleeding edge features which most users don't need

I don't actually repeat this process each time a new kernel rpm is released, I just update my existing patches list, here is the one I used for the 2.6.30-r1 ebuild:

#both uml framebuffer and xen need this one.
patches.xen/add-console-use-vt
#split out patches
patches.xen/linux-2.6.19-rc1-kexec-move_segment_code-i386.patch
patches.xen/linux-2.6.19-rc1-kexec-move_segment_code-x86_64.patch
patches.xen/ipv6-no-autoconf
patches.xen/pci-guestdev
patches.xen/pci-reserve
patches.xen/sfc-driverlink
patches.xen/sfc-resource-driver
patches.xen/sfc-driverlink-conditional
patches.xen/sfc-external-sram
# bulk stuff, new files for xen
#patches.xen/tmem
patches.xen/xen3-auto-xen-arch.diff
patches.xen/xen3-auto-xen-drivers.diff
patches.xen/xen3-auto-include-xen-interface.diff
# kconfig bits for xen
patches.xen/xen3-auto-xen-kconfig.diff
# common code changes
patches.xen/xen3-auto-common.diff
patches.xen/xen3-auto-arch-x86.diff
patches.xen/xen3-auto-arch-i386.diff
patches.xen/xen3-auto-arch-x86_64.diff
# fixups due to upstream Xen parts
patches.xen/xen3-fixup-xen
patches.xen/sfc-sync-headers
patches.xen/sfc-endianness
# changes outside arch/{i386,x86_64}/xen
patches.xen/xen3-fixup-kconfig
patches.xen/xen3-fixup-common
patches.xen/xen3-fixup-arch-x86
# ports of other patches
patches.xen/xen3-patch-2.6.18
patches.xen/xen3-patch-2.6.19
patches.xen/xen3-patch-2.6.20
patches.xen/xen3-patch-2.6.21
patches.xen/xen3-patch-2.6.22
patches.xen/xen3-patch-2.6.23
patches.xen/xen3-patch-2.6.24
patches.xen/xen3-patch-2.6.25
patches.xen/xen3-patch-2.6.26
patches.xen/xen3-patch-2.6.27
patches.xen/xen3-patch-2.6.28
patches.xen/xen3-patch-2.6.29
patches.xen/xen3-patch-2.6.30
#patches.xen/xen3-seccomp-disable-tsc-option not required
#patches.xen/xen3-driver-core-misc-add-nodename-support-for-misc-devices.patch
#patches.xen/xen3-kdb-x86
#patches.xen/xen3-stack-unwind suse feature
#patches.xen/xen3-panic-on-io-nmi.diff
#patches.xen/xen3-x86_64-unwind-annotations
patches.xen/xen-balloon-max-target
#patches.xen/xen-modular-blktap backwards compatability old module name
#patches.xen/xen-blkback-bimodal-suse backwards compatability
#patches.xen/xen-blkif-protocol-fallback-hack backwards compatability
patches.xen/xen-blkback-cdrom
patches.xen/xen-blktap-write-barriers
patches.xen/xen-scsifront-block-timeout-update
patches.xen/xen-op-packet
patches.xen/xen-blkfront-cdrom
patches.xen/xen-sections
#patches.xen/xen-swiotlb-heuristics caused problems on dell optiplex system, not essential
patches.xen/xen-kconfig-compat
patches.xen/xen-cpufreq-report
patches.xen/xen-staging-build
patches.xen/xen-sysdev-suspend
patches.xen/xen-ipi-per-cpu-irq
patches.xen/xen-virq-per-cpu-irq
patches.xen/xen-configurable-guest-devices
patches.xen/xen-netback-nr-irqs
patches.xen/xen-netback-notify-multi
patches.xen/xen-x86-panic-no-reboot
patches.xen/xen-x86-dcr-fallback
patches.xen/xen-x86-consistent-nmi
patches.xen/xen-x86-no-lapic
patches.xen/xen-x86-pmd-handling
patches.xen/xen-x86-bigmem
patches.xen/xen-x86-machphys-prediction
patches.xen/xen-x86-exit-mmap
patches.xen/xen-x86_64-pgd-pin
patches.xen/xen-x86_64-pgd-alloc-order
patches.xen/xen-x86_64-dump-user-pgt
patches.xen/xen-x86_64-note-init-p2m

Having made the list of patches I have a script which extracts the vanilla kernel source and attempts to apply the patches, when it fails it stops and drops to bash so that I can fix the problem manually, to give you an idea of the changes here is the diff output between the original and my updated patches:

diff -ur /mnt/fatfiler/suse_kernels/suse-kernel-source-2.6.30-50.1/patches.xen/xen3-auto-common.diff /usr/src/xen-patches/2.6.30/work/patches.xen/xen3-auto-common.diff
--- /mnt/fatfiler/suse_kernels/suse-kernel-source-2.6.30-50.1/patches.xen/xen3-auto-common.diff 2009-06-24 09:57:42.000000000 +0100
+++ /usr/src/xen-patches/2.6.30/work/patches.xen/xen3-auto-common.diff 2009-06-30 14:20:41.000000000 +0100
@@ -19,9 +19,9 @@
obj-$(CONFIG_NUBUS) += nubus/
obj-y += macintosh/
+obj-$(CONFIG_XEN) += xen/
+ obj-$(CONFIG_IDE) += ide/
obj-$(CONFIG_SCSI) += scsi/
obj-$(CONFIG_ATA) += ata/
- obj-$(CONFIG_IDE) += ide/
--- head-2009-06-23.orig/drivers/acpi/Makefile 2009-06-23 12:03:47.000000000 +0200
+++ head-2009-06-23/drivers/acpi/Makefile 2009-06-23 12:28:48.000000000 +0200
@@ -61,3 +61,6 @@ obj-$(CONFIG_ACPI_SBS) += sbs.o
@@ -3411,8 +3411,8 @@
1 << PG_private | 1 << PG_private_2 | \
1 << PG_buddy | 1 << PG_writeback | 1 << PG_reserved | \
1 << PG_slab | 1 << PG_swapcache | 1 << PG_active | \
-- 1 << PG_waiters | __PG_UNEVICTABLE | __PG_MLOCKED)
-+ 1 << PG_waiters | __PG_UNEVICTABLE | __PG_MLOCKED | __PG_XEN)
+- __PG_UNEVICTABLE | __PG_MLOCKED)
++ __PG_UNEVICTABLE | __PG_MLOCKED | __PG_XEN)

/*
* Flags checked when a page is prepped for return by the page allocator.
diff -ur /mnt/fatfiler/suse_kernels/suse-kernel-source-2.6.30-50.1/patches.xen/xen3-fixup-arch-x86 /usr/src/xen-patches/2.6.30/work/patches.xen/xen3-fixup-arch-x86
--- /mnt/fatfiler/suse_kernels/suse-kernel-source-2.6.30-50.1/patches.xen/xen3-fixup-arch-x86 2009-06-24 09:57:42.000000000 +0100
+++ /usr/src/xen-patches/2.6.30/work/patches.xen/xen3-fixup-arch-x86 2009-06-30 14:36:09.000000000 +0100
@@ -2,18 +2,6 @@
From: jbeulich@novell.com
Patch-mainline: obsolete

---- head-2009-04-21.orig/arch/x86/kdb/kdba_bt.c 2009-04-21 10:18:50.000000000 +0200
-+++ head-2009-04-21/arch/x86/kdb/kdba_bt.c 2009-04-21 12:15:27.000000000 +0200
-@@ -3168,6 +3168,9 @@ bb_usage_mov(const struct bb_operand *sr
- bb_is_int_reg(dst->base_rc) &&
- full_register_dst) {
- #ifdef CONFIG_X86_32
-+#ifndef TSS_sysenter_sp0
-+#define TSS_sysenter_sp0 SYSENTER_stack_sp0
-+#endif
- /* mov from TSS_sysenter_sp0+offset to esp to fix up the
- * sysenter stack, it leaves esp well defined. mov
- * TSS_ysenter_sp0+offset(%esp),%esp is followed by up to 5
--- head-2009-04-21.orig/arch/x86/power/Makefile 2009-04-21 10:18:25.000000000 +0200
+++ head-2009-04-21/arch/x86/power/Makefile 2009-04-21 12:15:27.000000000 +0200
@@ -5,3 +5,5 @@ CFLAGS_cpu_$(BITS).o := $(nostackp)
diff -ur /mnt/fatfiler/suse_kernels/suse-kernel-source-2.6.30-50.1/patches.xen/xen3-fixup-common /usr/src/xen-patches/2.6.30/work/patches.xen/xen3-fixup-common
--- /mnt/fatfiler/suse_kernels/suse-kernel-source-2.6.30-50.1/patches.xen/xen3-fixup-common 2009-06-24 09:57:42.000000000 +0100
+++ /usr/src/xen-patches/2.6.30/work/patches.xen/xen3-fixup-common 2009-06-30 14:33:44.000000000 +0100
@@ -310,16 +310,16 @@
--- head-2009-06-09.orig/kernel/kexec.c 2009-06-09 15:22:27.000000000 +0200
+++ head-2009-06-09/kernel/kexec.c 2009-06-09 15:29:19.000000000 +0200
@@ -45,8 +45,10 @@
- #include <linux/kdb.h>
- #endif
+ #include <asm/system.h>
+ #include <asm/sections.h>

+#ifndef CONFIG_XEN
/* Per cpu memory for storing cpu states in case of system crash. */
note_buf_t* crash_notes;
+#endif
- int dump_after_notifier;

/* vmcoreinfo stuff */
+ static unsigned char vmcoreinfo_data[VMCOREINFO_BYTES];
@@ -1168,6 +1170,7 @@ static void final_note(u32 *buf)
memcpy(buf, &note, sizeof(note));
}
@@ -349,9 +349,9 @@
return -ENOMEM;
}
+#endif
- #ifdef CONFIG_SYSCTL
- register_sysctl_table(kexec_sys_table);
- #endif
+ return 0;
+ }
+ module_init(crash_notes_memory_init)
--- head-2009-06-09.orig/mm/memory.c 2009-06-09 15:22:27.000000000 +0200
+++ head-2009-06-09/mm/memory.c 2009-06-09 15:29:19.000000000 +0200
@@ -811,10 +811,12 @@ static unsigned long zap_pte_range(struc
diff -ur /mnt/fatfiler/suse_kernels/suse-kernel-source-2.6.30-50.1/patches.xen/xen3-fixup-kconfig /usr/src/xen-patches/2.6.30/work/patches.xen/xen3-fixup-kconfig
--- /mnt/fatfiler/suse_kernels/suse-kernel-source-2.6.30-50.1/patches.xen/xen3-fixup-kconfig 2009-06-24 09:57:42.000000000 +0100
+++ /usr/src/xen-patches/2.6.30/work/patches.xen/xen3-fixup-kconfig 2009-06-30 14:22:35.000000000 +0100
@@ -12,17 +12,6 @@

config ARCH_SUSPEND_POSSIBLE
def_bool y
---- head-2009-06-09.orig/arch/x86/Kconfig.debug 2009-05-29 11:25:52.000000000 +0200
-+++ head-2009-06-09/arch/x86/Kconfig.debug 2009-06-09 15:29:14.000000000 +0200
-@@ -273,7 +273,7 @@ config OPTIMIZE_INLINING
-
- config KDB
- bool "Built-in Kernel Debugger support"
-- depends on DEBUG_KERNEL
-+ depends on DEBUG_KERNEL && !XEN
- select KALLSYMS
- select KALLSYMS_ALL
- help
--- head-2009-06-09.orig/drivers/xen/Kconfig 2009-06-09 15:01:37.000000000 +0200
+++ head-2009-06-09/drivers/xen/Kconfig 2009-06-09 15:29:14.000000000 +0200
@@ -22,6 +22,9 @@ config XEN_PRIVILEGED_GUEST
diff -ur /mnt/fatfiler/suse_kernels/suse-kernel-source-2.6.30-50.1/patches.xen/xen3-patch-2.6.23 /usr/src/xen-patches/2.6.30/work/patches.xen/xen3-patch-2.6.23
--- /mnt/fatfiler/suse_kernels/suse-kernel-source-2.6.30-50.1/patches.xen/xen3-patch-2.6.23 2009-06-24 09:57:42.000000000 +0100
+++ /usr/src/xen-patches/2.6.30/work/patches.xen/xen3-patch-2.6.23 2009-06-30 14:48:04.000000000 +0100
@@ -2669,13 +2669,12 @@
This driver implements the front-end of the Xen virtual
--- head-2009-06-23.orig/drivers/block/Makefile 2009-06-23 09:56:31.000000000 +0200
+++ head-2009-06-23/drivers/block/Makefile 2009-06-23 12:52:36.000000000 +0200
-@@ -34,7 +34,7 @@ obj-$(CONFIG_BLK_DEV_SX8) += sx8.o
+@@ -34,6 +34,6 @@ obj-$(CONFIG_BLK_DEV_SX8) += sx8.o
obj-$(CONFIG_BLK_DEV_UB) += ub.o
obj-$(CONFIG_BLK_DEV_HD) += hd.o

-obj-$(CONFIG_XEN_BLKDEV_FRONTEND) += xen-blkfront.o
+obj-$(CONFIG_XEN_BLKFRONT) += xen-blkfront.o
- obj-$(CONFIG_CIPHER_TWOFISH) += loop_fish2.o

swim_mod-objs := swim.o swim_asm.o
--- head-2009-06-23.orig/drivers/block/xen-blkfront.c 2009-06-23 09:56:31.000000000 +0200

As you can see the changes are quite small.

Andy
Back to top
View user's profile Send private message
Tuinslak
Tux's lil' helper
Tux's lil' helper


Joined: 26 Nov 2003
Posts: 129
Location: Belgium

PostPosted: Tue Jul 14, 2009 1:55 am    Post subject: Reply with quote

Hi there,

I'm getting this error:

Code:
  CC      drivers/xen/core/evtchn.o
drivers/xen/core/evtchn.c: In function 'unbind_from_irq':
drivers/xen/core/evtchn.c:641: error: 'struct kernel_stat' has no member named 'irqs'
make[3]: *** [drivers/xen/core/evtchn.o] Error 1
make[2]: *** [drivers/xen/core] Error 2
make[1]: *** [drivers/xen] Error 2
make: *** [drivers] Error 2
four linux-2.6.30-xen-r1 #


Any idea?
_________________
Tuinslak
Back to top
View user's profile Send private message
2bbionic
Tux's lil' helper
Tux's lil' helper


Joined: 24 Mar 2005
Posts: 143

PostPosted: Tue Jul 14, 2009 7:00 am    Post subject: Reply with quote

Did you read this thread. A few days ago, this problem was solved... :roll:
Back to top
View user's profile Send private message
Tuinslak
Tux's lil' helper
Tux's lil' helper


Joined: 26 Nov 2003
Posts: 129
Location: Belgium

PostPosted: Tue Jul 14, 2009 2:58 pm    Post subject: Reply with quote

Aight, seems like I missed that.

Kernel compiles fine now, yet I'm getting a Grub error 13 (http://www.flickr.com/photos/tuinslak/3720533708/)

My Gentoo-sources (.29) kernel works fine, so I'm guessing it has something to do with Xen. I am allowed to boot the kernel without the xen.gz kernel, right? Just to see if it boots?

My Grub.conf:

Code:
title tmp (2.6.30)
root (hd0,0)
kernel /boot/kernel-2.6.30 root=/dev/md3

title Xen (2.6.30)
root (hd0,0)
kernel /boot/xen.gz console=vga
module /boot/kernel-2.6.30 root=/dev/md3

title Gentoo (2.6.29)
root (hd0,0)
kernel /boot/kernel-2.6.29 root=/dev/md3


First kernel gives the error 13, the 2nd just reboots the system, without any output I can read, and the 3rd works fine.
_________________
Tuinslak
Back to top
View user's profile Send private message
2bbionic
Tux's lil' helper
Tux's lil' helper


Joined: 24 Mar 2005
Posts: 143

PostPosted: Tue Jul 14, 2009 3:44 pm    Post subject: Reply with quote

Seems, that grub can't read the kernel-file.Do you use a compressed file? Just compare the sizes and try to use an uncompressed kernel (usr/src/linux/vmlinux). And double-check the entries in grub about typos...

Greetings,

2bbionic
Back to top
View user's profile Send private message
Tuinslak
Tux's lil' helper
Tux's lil' helper


Joined: 26 Nov 2003
Posts: 129
Location: Belgium

PostPosted: Tue Jul 14, 2009 5:13 pm    Post subject: Reply with quote

The only compression I seem to have is gzip (so yes, it's vmlinuz file instead of bzImage file). I cannot pick bz2 or something. I can try to disable it, but that won't make a lot of difference I guess, as bz2 works fine for my normal kernel.

For some reason I can now boot using the Xen.gz kernel, but it hangs during boot

You'll have to excuse my blurry images, I've used my cell phone to take them. Basicly, it hangs at async/1

The last message: "async/1 used greatest stack depth"

http://www.flickr.com/photos/tuinslak/3720354353/
http://www.flickr.com/photos/tuinslak/3720353783/

I've left the server on for over an hour, and it hasn't moved a bit.

The kernel without xen.gz still gives me error 13.

kernel sizes:

Code:
four boot # du -sh kern*
2.7M   kernel-2.6.29
3.2M   kernel-2.6.30


one being bz2, other gzip. Seem like normal sizes to me.
_________________
Tuinslak
Back to top
View user's profile Send private message
chair-raver
n00b
n00b


Joined: 13 Jan 2007
Posts: 25
Location: Paderborn, Germany

PostPosted: Wed Jul 15, 2009 7:40 am    Post subject: Reply with quote

About the compilation problem of drivers/xen/core/evtchn.o:

2bbionic wrote:
Did you read this thread. A few days ago, this problem was solved... :roll:


I experienced the same problem and rechecked the problem and find, that SPARSE_IRQ is indeed missing from the .config file. After some greping I find this config option is defaulted in arch/x86/configs/i386_defconfig.

However my general procedure once a new kernel comes out is, to copy the .config from the old kernel into the top level directory of the new kernel and than do a "make oldconfig". So my understanding would be, that this new config option should be picked up from the defconfig file.

I did just that for 2.6.30-xen kernel and find that SPARSE_IRQ isn't picked up from arch/x86/configs/i386_defconfig. Superficially comparing the defconfig with the .config it seems, that there are a couple of more differences.

Am I operating on some false assumptions here?? How do you guys move the old configuration to a new kernel?
Back to top
View user's profile Send private message
stof
n00b
n00b


Joined: 04 Nov 2008
Posts: 15
Location: Germany

PostPosted: Thu Jul 16, 2009 11:57 am    Post subject: Reply with quote

Maybe i'm blind, but i also have the above compilation error for drivers/xen/core/evtchn.o and from the postings above i can't see any information how they fixed it. Could someone please give a hint?

Like chair-raver i copied the old .config from an older kernel. Not sure where i found that information but in some (no longer available) wiki article there was a tipp to create aliases like makeU and make0 that both use configurations in some _dom0 and _domU subdir. I copy both subdirs to the new kernel dir. Not sure if that's still a good idea though.
Back to top
View user's profile Send private message
microcosm
n00b
n00b


Joined: 05 Jul 2009
Posts: 11

PostPosted: Thu Jul 16, 2009 12:00 pm    Post subject: Reply with quote

Tuinslak wrote:
Aight, seems like I missed that.

Kernel compiles fine now, yet I'm getting a Grub error 13 (http://www.flickr.com/photos/tuinslak/3720533708/)

My Gentoo-sources (.29) kernel works fine, so I'm guessing it has something to do with Xen. I am allowed to boot the kernel without the xen.gz kernel, right? Just to see if it boots?



Well not really, I guess the xen kernel is missing something grub expect, and is probably modified so it won't be able to run standalone. (Had the same problem until I did some catch up from the xen howto. :oops: )

This is what xen is all about, it boots first, then loads a linux kernel (dom0) which manage and becomes the layer between the hardware and the domU's.
Back to top
View user's profile Send private message
microcosm
n00b
n00b


Joined: 05 Jul 2009
Posts: 11

PostPosted: Thu Jul 16, 2009 12:10 pm    Post subject: Reply with quote

andylyon wrote:


I will be releasing a updated set of patches soon which will fix this issue and some other problems, please bear with me as I've recently been in hospital so not able to respond as quickly as I usually do.

andy


Recover and get well! And thanks for providing us with up2date xen kernels, it's been so frustrating to see the same xen kernel being in portage for months (even a year?)!

What hardware do you have for testing? If needed, I have access to a decent dell server that can be used for test purposes.
Back to top
View user's profile Send private message
microcosm
n00b
n00b


Joined: 05 Jul 2009
Posts: 11

PostPosted: Thu Jul 16, 2009 12:31 pm    Post subject: Reply with quote

stof wrote:
Maybe i'm blind, but i also have the above compilation error for drivers/xen/core/evtchn.o and from the postings above i can't see any information how they fixed it. Could someone please give a hint?

Like chair-raver i copied the old .config from an older kernel. Not sure where i found that information but in some (no longer available) wiki article there was a tipp to create aliases like makeU and make0 that both use configurations in some _dom0 and _domU subdir. I copy both subdirs to the new kernel dir. Not sure if that's still a good idea though.



Nowadays you don't need to maintain 2 different sets for dom0 and domU, one kernel with the front and backend drivers is all that you need.

For the problem you encounter - I had it too after emerging the xen sources, then using genkernel --menuconfig all. I couldn't get the SPARSE IRQ option to appear when the Xen option was checked, until i did

Code:
make mrproper


and started all over. :cry: All those options to go through....
Back to top
View user's profile Send private message
stof
n00b
n00b


Joined: 04 Nov 2008
Posts: 15
Location: Germany

PostPosted: Thu Jul 16, 2009 12:34 pm    Post subject: Reply with quote

microcosm wrote:

For the problem you encounter - I had it too after emerging the xen sources, then using genkernel --menuconfig all. I couldn't get the SPARSE IRQ option to appear when the Xen option was checked, until i did

Code:
make mrproper


and started all over. :cry: All those options to go through....


Yeah, well that's exactly what i need to avoid. I have a running system and want to keep it up to date. It would be very annyoing if i couldn't reuse the old .config.
Back to top
View user's profile Send private message
sgao
Tux's lil' helper
Tux's lil' helper


Joined: 22 Apr 2006
Posts: 149

PostPosted: Thu Jul 16, 2009 11:25 pm    Post subject: Reply with quote

I am seeing this error with 2.6.30-xen-r2 ebuild:

Quote:
arch/x86/kernel/apic/ipi-xen.c: In function ‘__send_IPI_shortcut’:
arch/x86/kernel/apic/ipi-xen.c:30: error: implicit declaration of function ‘notify_remote_via_ipi’
make[2]: *** [arch/x86/kernel/apic/ipi.o] Error 1
make[1]: *** [arch/x86/kernel/apic] Error 2
make: *** [arch/x86/kernel] Error 2
Back to top
View user's profile Send private message
microcosm
n00b
n00b


Joined: 05 Jul 2009
Posts: 11

PostPosted: Fri Jul 17, 2009 10:06 am    Post subject: Reply with quote

sgao wrote:
I am seeing this error with 2.6.30-xen-r2 ebuild:

Quote:
arch/x86/kernel/apic/ipi-xen.c: In function ‘__send_IPI_shortcut’:
arch/x86/kernel/apic/ipi-xen.c:30: error: implicit declaration of function ‘notify_remote_via_ipi’
make[2]: *** [arch/x86/kernel/apic/ipi.o] Error 1
make[1]: *** [arch/x86/kernel/apic] Error 2
make: *** [arch/x86/kernel] Error 2



Indeed there's a new ebuild, but where did you find a corresponding patch file?
Back to top
View user's profile Send private message
sgao
Tux's lil' helper
Tux's lil' helper


Joined: 22 Apr 2006
Posts: 149

PostPosted: Fri Jul 17, 2009 4:31 pm    Post subject: Reply with quote

http://code.google.com/p/gentoo-xen-kernel/downloads/list.

Actually 2.6.30-r2 ebuild looks for xen-patches-2.6.30-3.tar.bz2, which can't be found. So I edited 2.6.30-r2 ebuild to use xen-patches-2.6.30-2.tar.bz2 instead.

However, I am seeing the same error with 2.6.29-r4 ebuild.
Back to top
View user's profile Send private message
andylyon
n00b
n00b


Joined: 13 Jun 2006
Posts: 74

PostPosted: Fri Jul 17, 2009 6:09 pm    Post subject: Reply with quote

microcosm wrote:
sgao wrote:
I am seeing this error with 2.6.30-xen-r2 ebuild:

Quote:
arch/x86/kernel/apic/ipi-xen.c: In function ‘__send_IPI_shortcut’:
arch/x86/kernel/apic/ipi-xen.c:30: error: implicit declaration of function ‘notify_remote_via_ipi’
make[2]: *** [arch/x86/kernel/apic/ipi.o] Error 1
make[1]: *** [arch/x86/kernel/apic] Error 2
make: *** [arch/x86/kernel] Error 2



Indeed there's a new ebuild, but where did you find a corresponding patch file?


I was about to upload the patches file but I held back because I noticed a problem, I have now uploaded the updated patches tarball so please give it a try if you have had problems with previous 2.6.30 kernels, also if you do have problems please try starting with a blank .config, I know its a pain and I will be looking into why it makes a difference but it seems to fix many problems.

Note that James Harper's gplpv drivers do not work with kernel 2.6.30, James has given me a patch which works around the problem but I feel we still need to find the root cause and fix it as the problem happens regularly and seems to affect network performance.

The patch is:

diff -r 36221c314d54 xennet/xennet_common.c
--- a/xennet/xennet_common.c Wed Jul 15 20:05:36 2009 +1000
+++ b/xennet/xennet_common.c Fri Jul 17 23:53:12 2009 +1000
@@ -181,6 +181,12 @@
return PARSE_TOO_SMALL;
}
}
+
+ if ((ULONG)XN_HDR_SIZE + pi->ip4_length > pi->total_length)
+ {
+ KdPrint((__DRIVER_NAME " XN_HDR_SIZE + ip4_length (%d) > total_length (%d)\n", XN_HDR_SIZE + pi->ip4_length, pi->total_length));
+ return PARSE_UNKNOWN_TYPE;
+ }

pi->tcp_length = pi->ip4_length - pi->ip4_header_length - pi->tcp_header_length;
pi->tcp_remaining = pi->tcp_length;

Andy
Back to top
View user's profile Send private message
microcosm
n00b
n00b


Joined: 05 Jul 2009
Posts: 11

PostPosted: Fri Jul 17, 2009 8:50 pm    Post subject: Latest ebuild Reply with quote

Code:
<M> Export Xen attributes in sysfs


still gives:

Code:
ERROR: "xenbus_xsd_state" [drivers/xen/core/xen_sysfs.ko] undefined!
ERROR: "paddr_vmcoreinfo_xen" [drivers/xen/core/xen_sysfs.ko] undefined!
ERROR: "vmcoreinfo_size_xen" [drivers/xen/core/xen_sysfs.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
Back to top
View user's profile Send private message
andylyon
n00b
n00b


Joined: 13 Jun 2006
Posts: 74

PostPosted: Wed Jul 29, 2009 1:08 pm    Post subject: Reply with quote

andylyon wrote:


Note that James Harper's gplpv drivers do not work with kernel 2.6.30, James has given me a patch which works around the problem but I feel we still need to find the root cause and fix it as the problem happens regularly and seems to affect network performance.


James has added code to his driver to fix the crash and log a error when xennet receives a incorrectly formatted packet from dom0 (http://xenbits.xensource.com/ext/win-pvdrivers.hg?rev/0436238bcda5), and I have found a workaround, on my system toggling receive checksum offload using ethtool -K peth0 rx off ; ethtool -K peth0 rx on , completely fixes the problem.

Please note that the fix is not included in 10.0.86 so if you do not build the drivers yourself from the source then you must run the ethtool workaround before starting a hvm with gplpv drivers, otherwise it will bugcheck in xennet.sys, whereas with the latest drivers a error will be logged like "XenNet XN_HDR_SIZE + ip4_length (2974) > total_length (54)"

It is important to re-enable checksum offloading, if you do not then you will get poor networking performance in domU and a slightly different error will be logged "XenNet Size Mismatch 54 (ip4_length + XN_HDR_SIZE) != 60 (total_length)", provided you disable+enable you should not get any errors, so I would like to hear about it if you do.

The problem also affects linux guests using netfront driver.

Andy
Back to top
View user's profile Send private message
_Razorblade_
n00b
n00b


Joined: 01 Jan 2004
Posts: 22

PostPosted: Sun Aug 02, 2009 2:30 pm    Post subject: Reply with quote

andylyon wrote:

The problem also affects linux guests using netfront driver.


Does this apply to hvm only or also pv?

Regards,
Razor
Back to top
View user's profile Send private message
andylyon
n00b
n00b


Joined: 13 Jun 2006
Posts: 74

PostPosted: Sun Aug 02, 2009 7:11 pm    Post subject: Reply with quote

_Razorblade_ wrote:
andylyon wrote:

The problem also affects linux guests using netfront driver.


Does this apply to hvm only or also pv?

Regards,
Razor


yes it affects pv guests, last week I tested on a system that uses e1000e nic driver and it did not have the problem, all my other systems use igb driver, but I've tried different versions of the igb driver and all had the problem so it looks like a interaction between the kernel and the driver.

Andy
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next
Page 6 of 9

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum