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. 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 [...] 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.
Attachment:
signature.asc
Description: This is a digitally signed message part.