I cannot get the linux-2.6.22-xen kernel to compile on an amd64 platform. linux-2.6.20-xen-r6, by comparison, worked fine with a nearly identical .config file (I say nearly because running a make oldconfig on the 2.6.22 kernel presented me with some new options). Here's the error message I get when attempting to run a make:
arch/x86_64/kernel/genapic-xen.c:28: error: 'BAD_APICID' undeclared here (not in a function)
arch/x86_64/kernel/genapic-xen.c: In function 'send_IPI_self':
arch/x86_64/kernel/genapic-xen.c:82: error: 'APIC_DEST_SELF' undeclared (first use in this function)
arch/x86_64/kernel/genapic-xen.c:82: error: (Each undeclared identifier is reported only once
arch/x86_64/kernel/genapic-xen.c:82: error: for each function it appears in.)
make: *** [arch/x86_64/kernel/genapic-xen.o] Error 1
make: *** [arch/x86_64/kernel] Error 2
Interestingly, genapic-xen.c is not even included in the 2.6.20 kernel, so I was unable to look for any differences that may have caused the problem. I checked my .config file for any mention of APIC, and have the following:
# grep -i apic .config
However, as I mentioned this is the same configuration I used for the previous kernel and it worked just fine. I also tried searching through menuconfig for some mention of APIC to try disabling it, but I couldn't find it.
At this point I'm stuck. Would appreciate it if a kernel dev could look into it. This is for a domU environment.
Steps to Reproduce:
1. emerge -pv '=sys-kernel/xen-sources-2.6.22'
2. cd /usr/src/linux-2.6.22-xen
3. (copy && make config)
make fails with the error(s) listed in the description
make should complete successfully
Ok, thanks for the report. I've been trying to shake the bugs out of the i386 version first but I'll get to x86_64 soon.
I'd like to add, that i wasn't able to compile a Dom0 without enabling CONFIG_SMP.
Michael: you have fixed that a few times in the past. Should be easy for you.
After enabling CONFIG_SMP, dom0 compiled fine and also works fine.
On the otehr hand, domU doesn't compile with the exact same error messages as given above. No matter, whether CONFIG_SMP is enabled, or not.
another issue...on i386 with pae under load "Bad page state in process 'events/1' page ... Trying to fix it up, but a reboot is needed" system crashed...i reverted to 2.6.20-xen-r6
same problem on Pentium3 (no smp) when compiling dom0
same .config (without new features) worked with 2.6.21-xen
arch/i386/kernel/apic-xen.c: In function 'apic_set_verbosity':
arch/i386/kernel/apic-xen.c:17: error: 'APIC_DEBUG' undeclared (first use in this function)
arch/i386/kernel/apic-xen.c:17: error: (Each undeclared identifier is reported only once
arch/i386/kernel/apic-xen.c:17: error: for each function it appears in.)
arch/i386/kernel/apic-xen.c:19: error: 'APIC_VERBOSE' undeclared (first use in this function)
arch/i386/kernel/apic-xen.c: In function 'APIC_init_uniprocessor':
arch/i386/kernel/apic-xen.c:48: error: 'smp_found_config' undeclared (first use in this function)
arch/i386/kernel/apic-xen.c:49: error: 'skip_ioapic_setup' undeclared (first use in this function)
arch/i386/kernel/apic-xen.c:49: error: 'nr_ioapics' undeclared (first use in this function)
make: *** [arch/i386/kernel/apic-xen.o] Error 1
make: *** [arch/i386/kernel] Error 2
(In reply to comment #2)
> I'd like to add, that i wasn't able to compile a Dom0 without enabling
Just FYI, in my case I do have CONFIG_SMP enabled (though it's a domU).
Michael - thanks for looking into this.
BTW, on my RAID-1 Xen server I experienced severe disk access input/output errors with this kernel (don't ask me what exactly this error means ;). I had to revert to my previous kernel which is xen-sources-2.6.20-r6 (which works all fine for me).
After a while of heavy disk access within either a domU or dom0, error messages similar to this one would pop-up all of a sudden:
mymachine / # who
-bash: /usr/bin/who: Input/output error
xenon / # shutdown -h now
-bash: /sbin/shutdown: Input/output error
The partitions were read-only suddenly and even fundamental programs weren't usable anymore with all the nasty consequences like not being able to shutdown the box anymore using ctrl-alt-del or /sbin/shutdown. The only way to make the box work properly again was doing a remote power reset and hence reboot. Booting the same kernel, it then worked till the moment of the next heavy disk usage where the same errors would appear. (BTW, after rebooting I usually checked the filesystems for errors but there weren't any)
It's a reproducible error (heavy disk usage e.g. when rsyncing for backup purposes seems to trigger it), but I didn't find out the exact reason. It might have something to do with my RAID controller as to my knowledge, other gentooers haven't reported such an error yet. Could be an issue of this kernel (or one of the patches automagically applied to this kernel) with the aacraid module (or its compiled-in counterpart), as that's the driver I use for the RAID controller (on a Dell PowerEdge Dualcore Intel Xeon 64bit server).
You need to add
wow, what a solution... xen-sources-2.6.22 was removed from the tree in
(In reply to comment #8)
> wow, what a solution... xen-sources-2.6.22 was removed from the tree in
> february. yay!
It was removed because it had a subtle but major bug that caused the kernel to oops when swapping. My time to work on xen has been limited and hunting down that bug is no easy task. How on earth SuSE has been managing to ship their 2.6.22 xen kernel with that bug (xen-sources-2.6.22 was based on their patches) is beyond me. At this point I'm keeping an eye on the RedHat/Fedora folks who are working on a full xen implementation using paravirt_ops, that work is really the only hope for a decent xen kernel at this point.
(In reply to comment #9)
> (In reply to comment #8)
> > wow, what a solution... xen-sources-2.6.22 was removed from the tree in
> > february. yay!
> It was removed because it had a subtle but major bug that caused the kernel to
> oops when swapping. My time to work on xen has been limited and hunting down
> that bug is no easy task. How on earth SuSE has been managing to ship their
> 2.6.22 xen kernel with that bug (xen-sources-2.6.22 was based on their patches)
> is beyond me. At this point I'm keeping an eye on the RedHat/Fedora folks who
> are working on a full xen implementation using paravirt_ops, that work is
> really the only hope for a decent xen kernel at this point.
Thanks for the explanation, Michael!
Never in tree afaict, .29 and .31 now available (masked)
We have newer kernels available? I can't find any in my local portage tree (masked or otherwise), nor is it listed here: