-----BEGIN PGP SIGNED MESSAGE-----
I wasn't planning on releasing it separately, since it is might cause
problems along the way (use at your own risk), but here is a patch I
created for IPCop Experimental: http://www.solaris-net.org/ipcop-xen/
31-ipcop-xen-patches.patch . It (hopefully) contains all the
necessary patches for a vanilla kernel 184.108.40.206. They were taken from
the Ubuntu linux-image-2.6.24-18-xen source package and altered to
prevent rejects and stuff. I mostly got rid of incompatible .orig
and .rej files that already exist after applying the 220.127.116.11 patch,
not the best way to go, but it shouldn't create a problem. It also
contains a patch to fix a build error, when building a DomU-only
kernel. However, the resulting kernel might not be stable.
I've had random crashes of my IPCop DomU which might be the result of
me ripping these out. I also noticed, that a resulting DomU-only
kernel locks up when started as the first VM after booting the Dom0
(BUG() in pci_dma_xen-32.c i think) and a few other minor problems
and kernel BUG()s that might or might not cause the crashes. I'm
currently trying to debug this, however, it could also be a problem
specific to my NICs and the sundance driver (for my D-Link DFE-580TX)
not appreciating the PCI passthrough, so if someone tests these,
please let me know if you experience the same problems.
To get the patches, you will need to do the following:
$ wget http://www.solaris-net.org/ipcop-xen/31-ipcop-xen-
patches.patch -O - | patch -p3
Now you need a vanilla linux-18.104.22.168 tree, either from the full
package or linux-2.6.24 and patch-22.214.171.124. I have only tested the
later, since I am building it in the IPCop build environment together
with the other stuff. Here is the order in which the patches should
0) patch-126.96.36.199 (if necessary)
I trust you know what to do from here.
Oh and I checked the Debian patches earlier. Tim was right, the
Debian kernel 2.6.25 uses PVOPS instead of a forward-port of the
original kernel 2.6.18 Xen patches. Too bad, guess I will have to
look for another set of patches against a more recent kernel too, if
I can't fix this one. As he said, the git archive might be the way to
go there, I'll let you know if I find something there.
Public Key: http://solaris-net.dyndns.org/keys/key_avlex.asc
"Making mistakes is human,
but to really fuck things up you need Computers"
Am 18.07.2008 um 06:08 schrieb Tim Post:
On Fri, 2008-07-18 at 00:08 +0200, Paul Schulze wrote:
You can try, but it isn't all that easy to isolate the necessary
patches from the Debian source and I am not quiet sure if the patches
in Debian are even forward-ported. As I said, I haven't tried yet (I
probably will in the next week, because my IPCop DomU is acting up),
but I think I saw something that looked like Xenbus and PCIFront last
time I grepped through the patches. You better check before you put
some serious work in there.
What he might have to do is check out a specific kernel revision by
tag from kernel.ubuntu.com , then install the debhelper packages to
the Debian build system
For instance , git-clone [url] 2.6.25.x (the version being a tag)
The kernel he wants will be in custom-source-xen which can be copied
anywhere else, or he could build it in the sparse tree custom-buld-xen
That may be the best way to go, since it would be relatively easy to
re-generate .deb packages for that kernel so that it can be re-used.
I'm pretty sure 2.6.25.x (or later, up to .26-rc series) can be
the intrepid git tree.
The people on the Ubuntu kernel mailing list are very helpful and
tolerant, I'm sure they could give better help.
This will get him a newer kernel that can be used for dom-0 and dom-u,
with the device pass through that he needs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
-----END PGP SIGNATURE-----
Xen-users mailing list