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

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

On Friday 08 February 2008, Chris Lamb wrote:
> These sorts of tests are useful when you have built a new machine and you
> wish to test the stability of the system, or you are experimenting with
> "overclocking" and/or esoteric cooling solutions.
> The basic idea is that shortcomings in the cooling, installation and the
> hardware itself are forced to appear at a predetermined stage, instead of
> arising at some inconvenient time in the future.
> Many system builders perform tests such as these after Debian has been
> installed, but it may be advantageous to perform it in the installer in
> order to prevent against filesystem corruption. It would also be
> significantly more convenient and allow integration with preseeding, etc.

As you indicate yourself, cpuburn can be dangerous. I do understand why it 
would be attractive for experienced sysadmins responsible for commercial 
installations to have this available, but we should be very careful with 
this. Especially since users will not have manpages available.

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?
Are multiprocessor systems supported?
Will cpuburn work in emulators or virtual machines?
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?

> Obviously, this should not be part of the main install process (!), but
> as an optional component.

Agreed. The udeb should not be loaded by default, but only when specifically 
requested during the "load installer components" phase. It can then also be 
loaded at boot time by passing "modules=cpuburn".

This means that its priority should be "optional".

Even then I'm not sure if this option should be in the normal flow of the 
installation. 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 guess my opinion on that depends on answers to the questions I currently 

> My patch is in three parts:
>  3. Adds the cpuburn-udeb package (the interesting bit)
> The resulting udeb is approximately 3KiB. I have put some screenshots
> online here [0].

What are its dependencies? Please show the output of debc (of dpkg -I) for 
the udeb.

Some comments on the patch.
- As the description will be shown in anna, I would suggest to change the
  description to:
     perform CPU stress test (burn in) - expert use only
- For the initial dialog I would suggest to add that users should carefully
  read the cpuburn documentation before using it.
- 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]
- Some coding style comments (though not blocking):
  - we prefer to have 'then' and 'do' on the same line as if/while as
    it saves a few bytes
    example: if true; then
  - for case statements we use 4 spaces for the conditions as that saves
    one level in the indentation of the conditional code and in most cases
    also saves some bytes (spaces versus extra tab for each conditional

> (Frans asked me to post the patch here instead of filing a wishlist bug
> against cpuburn. I believe Aurelien--the maintainer of cpuburn--reads
> this list anyway.)

Well, not _instead_, but rather _before_. Additions of new udebs need to be 
approved by the D-I team before they will be accepted by FTP masters, so 
discussing it here before filing the BR and maybe having the package 
rejected makes sense.

I'd also like to test the udeb before final approval.



Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: