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 attachment 166197 [details, diff] 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.
