Code: Select all
< > Export Xen attributes in sysfsCode: Select all
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
Code: Select all
CONFIG_SYSFS=yI 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.microcosm wrote:I get same warning as you, but that's it. I have an amd64 arch on the other hand.
However compiling with
checked, then it halts with following message:Code: Select all
< > Export Xen attributes in sysfs
Although sysfs never shows up in menuconfig, it's in the .config:Code: Select all
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
So it shouldn't be the lack of sysfs, right?Code: Select all
CONFIG_SYSFS=y
Not sure if anyone gets any wiser from this... but might be of use for the kernel people.
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.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
nice, but how do you figure out what the right patch-order is? thats the point where i usually mess everything upOf 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/repositori ... ctory/src/
http://download.opensuse.org/factory/re ... /suse/src/
http://download.opensuse.org/repositori ... ndard/src/
ftp://ftp.suse.com/pub/projects/kernel/ ... AD/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
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 +.trikolon wrote:nice, but how do you figure out what the right patch-order is? thats the point where i usually mess everything upOf 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/repositori ... ctory/src/
http://download.opensuse.org/factory/re ... /suse/src/
http://download.opensuse.org/repositori ... ndard/src/
ftp://ftp.suse.com/pub/projects/kernel/ ... AD/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
ben
Code: Select all
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 #Code: Select all
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/md3Code: Select all
four boot # du -sh kern*
2.7M kernel-2.6.29
3.2M kernel-2.6.30
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.2bbionic wrote:Did you read this thread. A few days ago, this problem was solved...
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.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?
)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?)!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
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.
Code: Select all
make mrproper
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.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
and started all over.Code: Select all
make mrproper
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
sgao wrote:I am seeing this error with 2.6.30-xen-r2 ebuild:
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
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.microcosm wrote:sgao wrote:I am seeing this error with 2.6.30-xen-r2 ebuild:
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?
Code: Select all
<M> Export Xen attributes in sysfsCode: Select all
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 2James 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-pv ... 36238bcda5), 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.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.
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._Razorblade_ wrote:Does this apply to hvm only or also pv?andylyon wrote: The problem also affects linux guests using netfront driver.
Regards,
Razor