I/O in Linux crashes otherwise-stable overclock

[MrFigs]

I’m working on my 9900k overclock, currently targeting a safe and comfortable 4.9 GHz. I’m using the Scythe Fuma 2; it has great acoustic efficiency, but not a high enough TDP ceiling to handle 5 GHz all-core. I’ve been stress-testing with Prime95 (AVX disabled) and the x264 test (AVX enabled); P95 draws a little more power but their stress level is pretty close. But both of these pale in comparison to the ultimate stability test…

The Fedora LiveCD.

I’ve reproduced this at two different frequencies. First, I was trying a borderline-unsafe 5 GHz overclock. It passed some 60-odd loops of x264, so I figured it was stable and ran a distro update on my dual-booted OpenSUSE install. That…didn’t go too well (of course it failed while installing the kernel update). I could have recovered it, but decided to distro-hop again. But no matter what distro I hopped to, the step that scans the available hard drives would always crash. Dragging the windows around too quickly also halted the system.

Since I was already past the point of thermal limiting, I dropped the multiplier a step and lowered the voltage a fair bit. Once again, I was x264/P95 stable in Windows, so I rebooted into Linux Mint (reinstalled on stock settings). But opening GParted revealed in mere seconds that I needed about 15 mV more Vcore.

So maybe I should be using CrystalDiskMark as a CPU test? I’m not sure what to make of this—why Linux is so much more sensitive, why I/O needs more voltage than the AVX units, or why Windows can’t push the hardware the same way. But now that I know what crashes my CPU first…does anybody know exactly what GParted is doing during its initial “scanning partitions” state, and how I can loop it? Otherwise, the best stress test is just queuing up a bunch of disk operations at once—rescan my music library, compress this huge folder, etc.—which isn’t exactly 100% load, nor reproducible.

[FurryJackman]

I literally had the exact same issues with x264 and FFmpeg. Yes, you will always be stable 100mhz lower than what your Windows stability tests tell you.

This could mean you need MORE idle voltage and your LLC needs to be tweaked to favor lower voltage during load. You also need more on your System Agent since it looks like that’s at it’s limit too.

Weak IMC performance is likely the cause of freezing simply dragging around Windows. Some of that can also be attributed to graphics drivers crashing, so try all this again with nomodeset.

[MrFigs]

Interesting, how does idle Vcore make a difference? I always took it as given that, if a chip is stable at a lower voltage (e.g. loaded with Vdroop), it must be stable at higher voltages as well. But maybe you’re right; raising Vcore seems to have stabilized things, and these crashes happen at low load. Good tip on LLC also, I wouldn’t have thought of that. I’ll try rolling back the Vcore bump and adding some uncore, see if that makes a difference.

Thanks!

Edit: I just tried increasing System Agent/uncore but didn’t notice any improvement. Eventually stability decreased so I put it back to default. But since idle Vcore does seem to be the key, I’m just going to stability-test like normal with LLC down a notch. Hopefully, I can get the same 100% load voltage/temps, but with higher idle Vcore (enough for stability) and better LLC stability to boot. Thanks again for the pointers.

[MrFigs]

One more update. I was still getting intermittent crashes after using a lower LLC setting, and bumping Vcore didn’t help. But increasing System Agent and VCCIO both to 1.1V seems to have fixed this; I’ve been clear for a couple days now with zero problems. I don’t know if VCCIO was really necessary, and I didn’t fine-tune either voltage since I can’t really stress-test them, but…whatever. Both voltages are way safe and aren’t going to add any significant heat afaik. I’ll have to work on stepping Vcore back down once I’m sure it’s stable.

So basically, you were right on all counts. Thanks again!