Bugzilla Bug 238496

Hi,

today I installed another OpenVZ server. We are already having one running for
over a year. Since the hardware is more or less identical I expected no big
issues. Well, I was taught otherwise. The 3ware controller was not detected
upon first boot into the system. The Genoo livecd (2008) detected it (kernel is
more recent there). What drove me completely mad was a CentOS CD, also with
kernel 2.6.18 that detected the controller as well.
Now I started looking into the patches of CentOS and found a patch that solves
the whole issue. It turned out the controller was slightly different, being a
9650SE-4LP compared to a 9550SXU.

I would be glad to see this patch applied and save other users from wasting a
lot of time :)

Created an attachment (id=166197) [edit]
CentOS kernel patch

Patch from the CentOS kernel package to make the kernel detect a newer version
of the 3ware-9xxx controller

OK, let me get this clear - so you built an openvz-sources kernel and it needs
patching, right?

It needs patching to do the thin it is supposed to do on runtime. It compiles
fine without the patch, but does not detect the RAID controller.
I used the stable OpenVZ sources and applied the patch against it with no
problems at all.

There are three flavors of kernels in our tree:
1. 2.6.18.028.053-r2, 2.6.18.028.056.1 - based on 2.6.18 vanilla kernel with
openvz patchset: http://wiki.openvz.org/Download/kernel/2.6.18
2. 2.6.18.028.057.2 - kernel based on RHEL5 patchset:
http://wiki.openvz.org/Download/kernel/rhel5
3. 2.6.24* - development kernel, is maintained because suse uses it:
http://wiki.openvz.org/Download/kernel/2.6.24. This kerenels are hardmasked!

Your patch is already incorporated into RHEL5 patchset and it is suggested by
upstream that we use RHEL5 based kernels. The problem with this kernels are
that it's hard to build them - RHEL developers just incorporate fixes for parts
of code they use and this means that if you used different configuration you'll
obviously fail to build kernel.

That's being said, I suggest you to try 2. 2.6.18.028.057.2. If it fails report
here (or better upstream and CC me there) and attach your .config. Note: you'll
need to enable PTRACE as kernel definitely is not buildable without that and
upstream is aware about this problem.

Also if you still insist on using vanilla based kernels I've added
2.6.18.028.056.1 which includes this patch and I'm going to stabilize it pretty
soon. Enjoy.


P.S. @bug-wranglers: There is no need to CC me if bug is assigned on me... ;)

Hi Peter,

yes, of course I use the stable-marked version of OpenVZ
(openvz-sources-2.6.18.028.053-r2) on a production system. I was absolutely not
aware that we have 3 different patchsets for the different versions. And no, I
see no reason to switch to the RHEL version as I don't want to mess with their
patching and the (probably) resulting problems from this.
Maybe you could change the naming of the versions a bit to make it more obvious
where the differences are. The current long tail of numbers is very confusing.

I thank you for your quick reaction and would be glad to see the new vanilla
version marked stable soon.

(In reply to comment #5)
> Maybe you could change the naming of the versions a bit to make it more obvious
> where the differences are. The current long tail of numbers is very confusing.

Well, having too many different packages is not good, but to clarify situation
a bit may be I'll add elog notice with a link to wiki page which describes
patchset used in the current kernel. That is a mess upstream did for us and I
hope it will be resolved as soon as openvz technology enters Linus tree.

> I thank you for your quick reaction and would be glad to see the new vanilla
> version marked stable soon.

Well, but could you test this kernel before I mark it stable (btw, I've already
tested but more help in this area does not harm). Just do

# ACCEPT_KEYWORDS=~amd64 emerge sys-kernel/openvz-sources:2.6.18.028.056.1

eselect that kernel build, run and report back. Thanks.