Hosting Provided By

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

From: Frans Pop <elendil(at)planet.nl>
Date: Fri Feb 08 2008 - 21:29:04 EST

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

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.

Do you need help?

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

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

Do you need more help?

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

Cheers,
FJP 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.

-- 
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: This is a digitally signed message part.

Received on Fri Feb 8 21:29:34 2008

This message: [ Message body ]
Next message: Otavio Salvador: "Hints for Debian Installer related packages"
Previous message: Bruno: "Bug#464799: debian-installer: can't use Canadian Keyboard (it use legacy canadian)"
In reply to: Chris Lamb: "Re: [PATCH] Support for "hardware burn-in" stage"
Next in thread: Otavio Salvador: "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:21:57 EDT