Frans Pop wrote:
Hi, thanks for your comments.
> I have the following questions that I'd like to see answered to so we
> can form a more informed opinion on this.
>
> Are all x86 processor types supported?
So, this question really has two answers. As the answer filters down into
some of your other questions, I will attempt to be somewhat detailed.
No, in the sense that the latest CPU on that list is a K7, which is quite
old..
But yes in the sense that most of the burnFOO flavours are simply an
attempt to use some specific properties of the CPU to generate a lot of
heat, such as ruining cache lines and (ab)using floating point and integer
math.
In my experience, however, if a machine is tending to lock-up, then any of
the flavours will reproduce it. Even a "while true; do done" shell loop
will do it. Hardware failures seem to be too non-deterministic to be
able to claim that a particular variant causes lock-ups quicker, however.
On the other hand, judging by the upstream's documentation, some trial and
effort is required to really "push" a CPU. I'm not sure burnP6 is really
pushing my modern, 4-core CPU, but it does to a better job at heating my
room than parallel squashfs, kernel compiles or an empty C loop.
On balance, I think the answer here is "no, but it doesn't really matter".
> Are multiprocessor systems supported?
Not natively by cpuburn. However, my patch spawns n instances where n is
determined by $(grep -c "^processor" /proc/cpuinfo). (Is this method
portable?) This causes 100% CPU on all 4 of my cores.
> Will cpuburn work in emulators or virtual machines?
Yes. I have tested under Qemu (0.9.1, 32- and 64-bit) and VirtualBox
(1.5.4)
> Is the program safe in the sense that if an incorrect processor type is
> selected, it will error out? How are such errors handled?
> If not, can processors be damaged if an incorrect CPU type is selected?
It's safe by this definition, yes. See above for more.
> It could be safer to have it listed after Finish install and thus only
> executable if selected from the menu (i.e. have a menu number greater
> than 90000 (see [1]).
I agree, yes. Is the target filesystems still mounted then?
> What are its dependencies? Please show the output of debc (of dpkg -I)
> for the udeb.
% dpkg -I cpuburn-udeb_1.4-27_amd64.udeb
new debian package, version2.0.
size 3384 bytes: control archive=1973 bytes.
271 bytes, 11 lines control
2703 bytes, 141 lines * postinst #!/bin/sh
1311 bytes, 42 lines templates
Package: cpuburn-udeb
Source: cpuburn
Version: 1.4-27
Architecture: amd64
Installer-Menu-Item: 95000
Maintainer: Aurelien Jarno <aurel32@debian.org>
Installed-Size: 15
Depends: cdebconf-udeb
Section: debian-installer
Priority: optional
Description: perform CPU stress test (burn in) - expert use only
> - I wonder if the CPU type could not be determined based on /proc/cpuinfo
> and options/defaults adjusted accordingly (with an "unrecognized" error
> dialog for unknown types); see for example [2]
That would be possible.. However, do you still think it is necessary after
my above comments? (If so, can I call on code you linked, or should I roll
my own?)
I agree with and have applied your
* Package description
* "Priority: optional" request
* Initial dialog manual reference suggestion
* XB-Installer-Menu-Item > 90000 suggestion
* Coding style suggestions
..locally. I'll only repost the patch when it contains something
interesting, however.
> I'd also like to test the udeb before final approval.
How would I help you do this? :)
Regards,
--
Chris Lamb, UK chris@chris-lamb.co.uk
GPG: 0x634F9A20
Attachment:
signature.asc
Description: PGP signature