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@xxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
Failure cannot survive knowledge and perseverance!
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
