[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH] Support for "hardware burn-in" stage

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

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

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

> 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? :)


Chris Lamb, UK                                       chris@chris-lamb.co.uk
                                                            GPG: 0x634F9A20

Attachment: signature.asc
Description: PGP signature

Reply to: