[CentOS] OT: ?? Centos Still Broken, Red Hat won't fix ??

Fri Jul 9 14:32:53 UTC 2010
Seth Bardash <seth at integratedsolutions.org>

On 7/8/2010 6:25 PM, John R Pierce wrote:
> On 07/08/10 2:39 PM, Seth Bardash wrote:
>> To the Linux Community at Large:
>> I reported to this list back in January, 2010 that the standard x86_64
>> kernel, when built from the src.rpm and modified for ...
> I don't understand how you think that this is a bug.  you modified
> something and it broke.   the provided redhat binary kernels work fine
> as advertised.
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos

OK, There seems to be some confusion about my motives / objectives / 
point of view. Please let me clear those up and I apologize if my 
approach was askew or this answer is too long winded.

Lets start with why I posted:

I posted my observations ( and reported the bugs) so that anyone else 
running RH AS > 5.3 or Centos that was trying to optimize their kernel 
for AMD CPU's would know there was a problem. A problem that Red Hat 
caused and has chosen not to address. That was the only reason I posted! 
To inform.

Red Hat takes a standard kernel and modifies it, extensively. The 
standard kernel.org kernel works fine and supports this function. What 
is standard and supported in a kernel is decided by kernel.org. What is 
standard and supported in a Red Hat kernel is decided by Red Hat. The 
standard binary is built with the Generic X84_64 option selected. Red 
Hat's source code also includes an AMD Opteron option and an Intel EM64T 
option. Since the changes made to Red Hat's kernel by Red Hat since 
kernel 2.6.18-9 have broken one of these options but not the other two 
options I thought it might be useful to Red Hat and the Centos community 
to know that the AMD option is broken. The Generic x86_64 option and the 
Intel option work and compile fine. I tested these also. This is a bug, 
not something I broke. If I broke it, I would feel an obligation to fix 
it. Red Hat made the changes to the kernel source that broke this option.

Next, I have only posted to this list over the past 5 years when I could 
report a problem I thought might be of interest or add, help fix or 
supply code for a work around, on an issue with RH Linux or Centos. So I 
think the comment about troll bait is out of line. Just my opinion, I 
could be wrong. :)

I don't expect RH to do anything except what is in Red Hat's interests.

This can be influenced (very slightly) by non-paying users, fully 
supported paying users and to some extent Systems Integrators (like my 
company) if they are listening and if, again, it is in Red Hat's interests.

As a business owner, I would want to know about a problem with my 
product, especially if it costs me customers or profit or future sales. 
That is why we supplied some of the early drivers for 3ware cards for 
the Centos 3 OS. Our customers needed them, we supplied them free of 
charge. We have done this many times for many different linux based 

I have received responses off this list that suggest that there are 
other people and organizations that indeed use optimized kernels in 
conjunction with RH AS and Centos. Some use a modified RH kernel, some 
use a newer standard kernel from kernel.org with options changed, some 
use the real-time extensions to the standard kernel. All of them have 
found that it provides better performance for THEIR applications. We 
have done similar work for many customers.

When we changed the kernel and break it, we fix it.

My intent was to inform and hear from people that had similar issues and 
to learn what they might have done to work around them. Not to cause a 
debate on business practices, criticize Red Hat or inflame the  Centos 

Thanks for reading.........

Seth Bardash


Integrated Solutions and Systems LLC

seth at integratedsolutions.org
Failure cannot survive knowledge and perseverance!