[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:
> No, in the sense that the latest CPU on that list is a K7, which is quite
> old.

I see. Also from the fact that it supports memory testing up to a whopping 

I ran some of the tests on my dual-core x86_64 box, and with just 1 process 
running it did not even break out a sweat. With 2 running it did get some 
workout, although I've heard the fans screaming harder when I run the 
Hercules s390 emulator over both cores.

One last thing to consider is that in D-I you have no way of monitoring the 
system temperature. This is at least one (at least visual) safety catch 
less than you might have when running it from other environments (e.g. a 
live CD).

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

Seems fine. Even if it's not portable, it's at least save in that it will 
just return 0 and thus noting will get started. You should probably break 
out in that case though (with a message to syslog).

I'd also change the grep to '^processor[[:space:]]*:' to be totally safe.

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

OK. I agree that CPU detection does makes sense, as also discussed elsewhere 
in the thread.
Only thing that's left then is the cache/memory testing. Seems useful to 
just do that by default, so I suppose you could grep for mmx support and 
then use MMX or else BX for Intel processors.
You could then possibly even not include all test programs in the udeb.

What do you plan to do for real 486 processors (and anything else that 
cannot be accurately derived)?

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

You'd have to select it manually and could do so at any point, so basically 
you don't know what the status of mounts is.
But that you _also_ do not know that when using the lower menu number as a 
user could go back and select it manually at any time. Note also that the 
hd-media installation method will _already_ have a file system mounted at 
that point (on /hd-media).

With the additional info _and_ given the warning in cpuburn's README about 
running without any file systems mounted, I think your original menu number 
is probably best (with added benefit of preseeding option). You could even 
add a test for mounted filesystems and display an additional warning if 
there _are_ file systems mounted.

I think testing for mounts on /target, /hd-media and /mnt should be 
sufficient in practice, though a more general test would be better (if you 
can think of one that also catches all the really weird device names in 
existence for some block devices).

Suggest you move the "Use at your own risk" to a separate para in the 

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

Looks good.

> > I'd also like to test the udeb before final approval.
> How would I help you do this? :)

Simple: provide either the final patch (or even better a udeb built for 
i386) so I can include the final version on a custom image and test using 


P.S. While you're working on the package anyway...
The original README and your summaries in the mails here provide much better 
documentation than the current manpage. Feel like extending that a bit?
IMO at least the various warnings and disclaimers should be added.

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

Reply to: