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. 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]). 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 <aurel32@debian.org> 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. How would I help you do this? :) Regards, -- Chris Lamb, UK chris@chris-lamb.co.uk GPG: 0x634F9A20
Attachment:
signature.asc
Description: PGP signature