From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2o3mR548Bao for ; Sat, 23 Nov 2013 14:29:42 +0100 (CET) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Sat, 23 Nov 2013 14:29:42 +0100 (CET) Received: by mail-ea0-f176.google.com with SMTP id h14so1111298eaj.7 for ; Sat, 23 Nov 2013 05:29:41 -0800 (PST) Received: from [192.168.2.24] (56.157.broadband5.iol.cz. [88.100.157.56]) by mx.google.com with ESMTPSA id 8sm84936538eem.15.2013.11.23.05.29.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 05:29:40 -0800 (PST) Message-ID: <5290ADAD.2020207@gmail.com> Date: Sat, 23 Nov 2013 14:29:17 +0100 From: Milan Broz MIME-Version: 1.0 References: <942152294.28287.1385136420109.JavaMail.root@medent.com> <1083384064.30141.1385137797930.JavaMail.root@medent.com> <20131122225355.GA18157@tansi.org> <529062E0.8070203@gmail.com> <20131123115803.GA28775@tansi.org> In-Reply-To: <20131123115803.GA28775@tansi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] dm-crypt + mdadm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 23.11.2013 12:58, Arno Wagner wrote: > I had 3 immediate issues with older, reliable hardware that > never gave me any trouble with any other kernels: > > 1. Kernel panic due to missing radeon firmware image. > Newer kernels do not panic on this. Older ones do not > even detect the integrated graphis as anything special, > just as VGA, and hence do not panic either. > I finally had to switch off the inegrated graphics to get > it to boot at all. I think we are off topic here, but do not forget I was paid for several years to work on kernel parts in RHEL :) Once you install new hw, you have to also install fw packages and ebuild initramfs. For VGA you can quite safely boot in text mode and fix it later, it is just special know-how about some kernel options... And yes, it is **** > 2. A perfectly fine RTL8139 card was not even recognized. First, this Realtek is really cheap hw, but it works. There are many revisions and I guess you had some new which was not yet recognised - there are also some workarounds but you just cannot expect installation will detect hw which was not available when image was built. (There are new installation images in RHN available for minor updates.) > 3. A perfectly fine RTL8168 card caused the driver to spam > the syslog and text-console with warnings and made it unusable. > (No X11 on this installation....) > > Sorry, but that is not what I would call a stable kernel. Feels > more like something hacked together... Well, this is exactly what support should solve. But usually short search on RH bugzilla works as well. (And yes, I was sometimes desperate how it works but that's another story :) Enterprise Linux is always trade-off - you cannot have stable ABI for ~10years, expect 5 years old installation images to work on new motherboards. Usually next update works though. So in general, this kind of distro is not the best option for you. I think Debian or something similar will work much better. > The only possible explantion I have is that this very standard > hardware is not "enterpriese" enough (being cheap) and did not > make it on the hardware compatibility list and hence does not > get tested well or at all. Obviously not everything is tested but I am sure these are. (I had many such cheap cards myself - and working :) >> (And my experience is that RHEL/CentOS kernel are pretty stable >> in comparison with manual upstream builds. I would not >> suggest any customer to build own kernel for these enterprise >> distributions > > The suggestion was for tests, not to create a stable installation > this way. If there is still a performance-hit with a current > kernel, then it is likely not a kernel issue. If not, then > it is and moving away from CentOS may be a viable solution... Regarding performance hit - it CAN be userspace as well. For storage, if you need to handle multipath, lvm2 etc you know what I am talking about. (E.g. RAID misalignment because of using old userspace tool is very common.) ... Anyway, sorry for spam :) Milan