Intel's i7-5960X + X99 Motherboard On CentOS 7.0 Has Some Pains

[phoronix]

Phoronix: Intel's i7-5960X + X99 Motherboard On CentOS 7.0 Has Some Pains

For those that may have picked up the incredibly-fast, $1000+ Intel Core i7 5960X CPU with a new required motherboard bearing the X99 chipset, be prepared for potential troubles if you're planning to install CentOS 7.0...

http://www.phoronix.com/vr.php?view=MTgwMzY

[Grogan]

That's what happens when they insist on using old kernels (patching the Hell out of them) for "stability"

I got a server with RHEL 4 (the current redhat distro at the time), it was nothing exotic, just an athlon64 based system. It was a significant hardware upgrade from what we had and I was expecting it to solve the problem of search engine spiders simultaneously hitting our database (php/mysql) and crippling us.

It seemed OK at first, until the bots came that night. During the wave of liquishit, while the web server had practically stopped responding to requests, I was watching with top (which itself was laggy despite a good route to the datacenter) and noticed kernel threads like kswapd in D states (uninterruptible sleep, usually because of waiting for disk i/o). I didn't understand that, there wasn't even any swap in use (and it wasn't the only process), we had 2G of RAM, plenty for everything we were trying to do, plus disk caching. I tried this, and tried that for a few days (compensating a little) playing with apache limits, setting robots.txt directives, the new in Linux 2.6 "swappiness" kernel parameter. Then it dawned on me, the kernel had to go. Now, I was well versed at configuring kernels, optimally for hardware, but I hated to do that on redhat systems remotely (e.g. if mkinitrd gets your mandatory initrd wrong it's an embarrassing phone call to the datacenter) but I built a 2.6.16.x kernel, which was being maintained longterm by Adrian Bunk, and I could tell almost immediately that the problem was solved. Not only didn't we get the crippling iowait, but the forums and stuff "snapped" to attention when accessed. That server ran for years (when 2.6.16 maintenance stopped, I still kept using the last one, scared to go too modern on such old userspace on RHEL4) without a hickup.

One day, the webhost started messing with servers to check if people were up to date and they insisted that I go back to the distro kernel revisions, still patched 2.6.9. I explained the problem and said I'd do some testing, and the current patch levels of RHEL 2.6.9 no longer had the specific iowait problem on our hardware, but the system wasn't as snappy, and still didn't handle load as well. So I decided it was time to upgrade servers... but moving to another datacenter where they were just going to mind their own business unless a support request was submitted. (cheaper hosting at that, with no Big Brotherly "support").

Why in the Hell would they have stuck with 2.6.9 of all kernels for RHEL 4? You don't have to stick with the same kernel series for the life of the product, just do adequate testing like you'd still have to do with your umpteen thousand silly patches anyway. That was an awful release. Patching in new hardware support is just trying to sew more arms onto the octopus. That turned me right off RHEL.

Pretty hard to get an installation off the ground like that though, especially with a complex installer. Slackware it ain't.

[calc]

That server ran for years (when 2.6.16 maintenance stopped, I still kept using the last one, scared to go too modern on such old userspace on RHEL4) without a hickup.

Why in the Hell would they have stuck with 2.6.9 of all kernels for RHEL 4? You don't have to stick with the same kernel series for the life of the product, just do adequate testing like you'd still have to do with your umpteen thousand silly patches anyway. That was an awful release. Patching in new hardware support is just trying to sew more arms onto the octopus. That turned me right off RHEL.

Answered your own question it appears. You could always have just upgraded to RHEL5 (2.6.18), 6 (2.6.32), or 7 (3.10).

[birdie]

Why in the Hell would they have stuck with 2.6.9 of all kernels for RHEL 4? You don't have to stick with the same kernel series for the life of the product, just do adequate testing like you'd still have to do with your umpteen thousand silly patches anyway. That was an awful release. Patching in new hardware support is just trying to sew more arms onto the octopus. That turned me right off RHEL.

QA/QC plus binary drivers from OEMs.

You might have heard of this.

And there's no way to solve this issue, unless you abandon a mess called Linux.

[birdie]

Answered your own question it appears. You could always have just upgraded to RHEL5 (2.6.18), 6 (2.6.32), or 7 (3.10).

Bullocks. Are you sure new kernel releases are compatible with the old userspace? Are you sure new kernels haven't thrown out some working hardware drivers? (RHEL6/7 both did that).

[wazoo42]

I used the Asus X99-Deluxe and 5960X, and installed Centos 7 on a Samsung EVO 840 750 GB. I had to turn off Secureboot in the bios, but that was the only issue I ran into while installing or using Centos 7.

[calc]

Bullocks. Are you sure new kernel releases are compatible with the old userspace? Are you sure new kernels haven't thrown out some working hardware drivers? (RHEL6/7 both did that).

I must be confused as your argument is one major reason why upgrading the kernel during the same release cycle is a very bad idea, and is similar to the point that Grogan made before asking why Red Hat didn't just do it anyway. There is no way for a vendor to test all the invariably broken hardware out there to make sure there are no regressions when upgrading between kernel releases, which is a big reason why they don't upgrade them and instead only backport selective patches that they test thoroughly. I'm currently tracking a regression on one of my systems, not running rhel/centos, with usb 3 no longer working on newer kernels.