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 systems. 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 community. Thanks for reading......... -- Seth Bardash Partner Integrated Solutions and Systems LLC seth at integratedsolutions.org Failure cannot survive knowledge and perseverance!