Hosting Provided By

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

From: Chris Lamb <chris(at)chris-lamb.co.uk>
Date: Fri Feb 08 2008 - 12:46:17 EST

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.

Do you need help?

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]).

Do you need more help?

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 
     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.

Can we help you?

How would I help you do this? :)

Regards,

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

-- To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

application/pgp-signature attachment: signature.asc

Received on Fri Feb 8 12:46:49 2008

This message: [ Message body ]
Next message: Chris Lamb: "Re: [PATCH] Support for "hardware burn-in" stage"
Previous message: Frans Pop: "Re: [PATCH] Support for "hardware burn-in" stage"
In reply to: Frans Pop: "Re: [PATCH] Support for "hardware burn-in" stage"
Next in thread: Otavio Salvador: "Re: [PATCH] Support for "hardware burn-in" stage"
Reply: Otavio Salvador: "Re: [PATCH] Support for "hardware burn-in" stage"
Reply: Frans Pop: "Re: [PATCH] Support for "hardware burn-in" stage"

Contemporary messages sorted: [ By Date ] [ By Thread ] [ By Subject ] [ By Author ] [ By messages with attachments ]

This archive was generated by hypermail 2.1.8 : Wed Mar 19 2008 - 05:17:36 EDT