CPUstress 2.5.2 (7 September 2014)
https://dl.dropboxusercontent.com/u/701 ... s-2.5.2.7z
Size: 4715741 bytes
MD5: ca845305abcfff1dea544134e326e8e7
SHA1: 72639b2584f7ad210f4cb9b9ddf477c7f8e5b3e7

• Updated Intel LINPACK to v11.2.0 (from v11.1.3)
• Updated kernel to 3.16.2. Enabled CONFIG_RELOCATABLE due to recent change in the kernel code. See the Linux changelog for details.

CPUstress 2.5.3 (18 September 2014)
https://dl.dropboxusercontent.com/u/701 ... s-2.5.3.7z
Size: 4714489 bytes
MD5: 747728e5651eb5e032499aadf7780372
SHA1: 071f99a24c72a70688117f281e338309a84d5f99

• Updated kernel to 3.16.3. Disabled CONFIG_INTEL_IDLE as there are problems reported with the driver. (See viewtopic.php?p=25464#p25464)
• Added "consoleblank=0" to boot parameters.
• Minor fixes in scripts and documentation.

The "consoleblank=0" boot option disables the console blanking (like a screensaver) in Linux kernel. It is good to make it the default in CPUstress as the user often puts the computer in stress and monitors without hitting any keys. And programs like cpuburn (burn) and CPU burn-in (cpuburn-in), with wrapper scripts, accidentally terminate when user tries to simply get out of the screensaver. Setting "consoleblank=0" avoids the problem.

@Victor: Please update the 2 documents cpustress/help/syslinux/cpustrs{1,2}.txt
And add "consoleblank=0" into APPEND lines of syslinux menu entries that start CPUstress.
From this:

to this:

Noted. Thanks!

@Explorer09: Is it sufficient to update cpustress/help/syslinux/cpustrs{1,2}.txt with the ones in "cpustress-2.5.3.7z", or is there anything additional that I need ot do?

Yes, I would like the (isolinux/grub4dos) menu entries to be updated with the additional kernel parameter, "consoleblank=0".
The reason for adding this is explained in the above post.

You can look at how I have done to "ubcd/menus/syslinux/cpu.cfg" in this git commit and you will get the idea.

Yes, just to confirm, "consoleblank=0" has been done. I wanted to also make sure nothing extra needs to be done in "cpustress/help/syslinux/cpustrs{1,2}.txt" because I always update them with each of your new release.

No, that's all.

CPUstress 2.5.4 (2 November 2014)
https://dl.dropboxusercontent.com/u/701 ... s-2.5.4.7z
Size: 4737406 bytes
MD5: 7f1c50d7f7f68180a5642efa67a493fe
SHA1: 6bfb0642862539880c87eb064ddace04b304dcb1

• Rebuilt BusyBox. Changes in this build:
  
  1. Applied temporary patches from upstream Git master to fix important bugs.
  2. Removed 'cut' and 'expr'. (Unused in scripts and "$(())" is better.)
  3. Removed unnecessary features in 'ash' and 'mount', but enable 'help' builtin and fancy prompts.
  4. Disable some useless config options to reduce size.
• Updated kernel to 3.17.2.
• All scripts that invoke 'less' command now invoke with '-M' option.
• Minor bug fixes in shell scripts.

@Victor:
A few descriptions of Syslinux boot entries have been slightly modified. See this commit for what's changed:
https://github.com/Explorer09/cpustress ... 645310b104
Let me know if you wish to understand the reasons behind.

If you have the time, some short notes about the reasoning behind the changes will be appreciated.

Cos the info may be useful later for people who contribute to the project.

Thanks!

I thought the reasons are easily understood to anyone who maintains the project:
1. I didn't include hard disk stressing option in the 'stress' program, and I don't want to confuse new users into thinking they can do hard disk stress. The CPUstress image is never intended to have hard disk support.
2. Clean up the "TM" thing in cpuburn's description text. People knew they are trademarks and having "TM" in description text just looks ugly.
3. Systester's entry change should be self-explanatory.

Hello, is the CPU stresstest in latest version supposed to be a trojan of type Artemis?

Br, Victor

It's a false positive. Better report it to your antivirus software vendor.

Seriously, the file you are referring to is just a compressed, custom Linux kernel image. It's impossible to have a trojan horse built inside, let alone letting it run.

My quick Google search also shows that antivirus such as McAfee has already false Artemis reported.

(By the way, according to the MD5 hash included in your screenshot, the kernel file you have is the same as the one in my release and not altered.)