[Cooker] Isolinux broken
In current cooker (and for several days now), booting isolinux to do a hard drive install fails on my notebook. You go through specifying the drive location, get second stage and probing serial ports, several lines of stuff that flies by too fast to read, and the a dead black screen. A hard drive install using hd.img from the same cooker tree doesn't have this problem.
Re: [Cooker] isolinux
guillaume == Guillaume Cottenceau [EMAIL PROTECTED] writes: guillaume Paolo Pedroni [EMAIL PROTECTED] writes: Il 12:43, martedì 30 ottobre 2001, hai scritto: Do you use it often? Did it allow you to detect memory problems in the real world? I detected memory problems at least three times, using memtest. It just works! Now, everytime some friend of mine asks me to check their malfunctioning computer, first thing I do is stick a memtest floppy disk in their drive and check their memory. guillaume Personally, I use for a long time the simple following thing: I recompile guillaume 100 times a kernel, storing the logs, and I then verify all the logs are guillaume the same ; when memory or chipset or processor are malfunctioning, guillaume sometimes GCC receives signal-11 because of failing hardware. guillaume I'm wondering if memtest would not miss some of the errors; also it guillaume doesn't use the harddisk so it can miss chipset problems related to disk guillaume probably. guillaume Of course, memtest is really more easy to use than recompiling a kernel. memtest is better for testing memory. But recompiling the kernel is perhaps better for finding that you have overclocking/bad CPU fan similars. There is another program, cpuburn, that help to found that kind of problems, it executes secuences of instructions that are known to heat the CPU. I don't remind the URL, but goople should help you. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy
RE: [Cooker] isolinux
There is another program, cpuburn, that help to found that kind of problems, it executes secuences of instructions that are known to heat the CPU. I don't remind the URL, but goople should help you. Google?! [root@cooker root]# urpmq -r cpuburn cpuburn-1.4-1mdk -andrej
Re: [Cooker] isolinux
Borsenkow Andrej wrote: There is another program, cpuburn, that help to found that kind of problems, it executes secuences of instructions that are known to heat the CPU. I don't remind the URL, but goople should help you. Google?! [root@cooker root]# urpmq -r cpuburn cpuburn-1.4-1mdk -andrej ctcs includes this and more, good for crashing a system in conjunction with more precise memtesters.
Re: [Cooker] isolinux
Il 12:43, martedì 30 ottobre 2001, hai scritto: Do you use it often? Did it allow you to detect memory problems in the real world? I detected memory problems at least three times, using memtest. It just works! Now, everytime some friend of mine asks me to check their malfunctioning computer, first thing I do is stick a memtest floppy disk in their drive and check their memory. I higly recommend a memtest option in Mandrake boot CD. Bye. -- Paolo Pedroni paolo.pedroniatiol.it
Re: [Cooker] isolinux
On Tuesday 30 October 2001 11:11 am, Guillaume Cottenceau wrote: Paolo Pedroni [EMAIL PROTECTED] writes: I detected memory problems at least three times, using memtest. It just works! Now, everytime some friend of mine asks me to check their malfunctioning computer, first thing I do is stick a memtest floppy disk in their drive and check their memory. Personally, I use for a long time the simple following thing: I recompile 100 times a kernel, storing the logs, and I then verify all the logs are the same ; when memory or chipset or processor are malfunctioning, sometimes GCC receives signal-11 because of failing hardware. I'm wondering if memtest would not miss some of the errors; also it doesn't use the harddisk so it can miss chipset problems related to disk probably. Of course, memtest is really more easy to use than recompiling a kernel. cpuburn http://users.ev1.net/~redelm/severely tests cpu/cache/ram. As a long time overclocker, I can say if your system can run cpuburn for at least 30 mins, it's stable as can be. Quicker and easier to use than memtest86 or settin up a kernel compile loop. I'd strongly suggest havin continuous cpu temp monitoring setup before runnin any of cpuburn's modules. 'burnK7' will get my 1.4 at 1.55 ghz Tbird up to 52°C. BTW, thanks Guillaume for your Penguin Liberation rpms ;) -- Tom Brinkman Galveston Bay, USA chmod +x /bin/Laden.al-Qaeda.Taliban
Re: [Cooker] isolinux
Tom Brinkman wrote: On Tuesday 30 October 2001 11:11 am, Guillaume Cottenceau wrote: Paolo Pedroni [EMAIL PROTECTED] writes: I detected memory problems at least three times, using memtest. It just works! Now, everytime some friend of mine asks me to check their malfunctioning computer, first thing I do is stick a memtest floppy disk in their drive and check their memory. Personally, I use for a long time the simple following thing: I recompile 100 times a kernel, storing the logs, and I then verify all the logs are the same ; when memory or chipset or processor are malfunctioning, sometimes GCC receives signal-11 because of failing hardware. I'm wondering if memtest would not miss some of the errors; also it doesn't use the harddisk so it can miss chipset problems related to disk probably. Of course, memtest is really more easy to use than recompiling a kernel. cpuburn http://users.ev1.net/~redelm/severely tests cpu/cache/ram. As a long time overclocker, I can say if your system can run cpuburn for at least 30 mins, it's stable as can be. Quicker and easier to use than memtest86 or settin up a kernel compile loop. I'd strongly suggest havin continuous cpu temp monitoring setup before runnin any of cpuburn's modules. 'burnK7' will get my 1.4 at 1.55 ghz Tbird up to 52°C. BTW, thanks Guillaume for your Penguin Liberation rpms ;) Or the entire ctcs suite. And btw, wrong Guillaume. We call this one 'gc', you are thinking of Guillaume Rousse I believe.
Re: [Cooker] isolinux
Ainsi parlait Guillaume Cottenceau : BTW, thanks Guillaume for your Penguin Liberation rpms ;) As Blue told it, you're mixing the Guillaume's :-). I'm the only real one, gc is a vile usurpator :-) -- Guillaume Rousse [EMAIL PROTECTED] GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
Re: [Cooker] isolinux
On Tue, 30 Oct 2001, Tom Brinkman wrote: cpuburn http://users.ev1.net/~redelm/severely tests cpu/cache/ram. As a long time overclocker, I can say if your system can run cpuburn for at least 30 mins, it's stable as can be. Quicker You know the risk of overclocing but you can't predict memory problems :( -- 5:17pm up 14 days, 6:13, 3 users, load average: 0.03, 0.03, 0.00 __ | / \ |Iouri Goussev// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Foo-Bar / // \\ \ jgs\\ // http://foobar.irc-unix.net| \__/ | I am not 31337. But I can use the Vi editor... ;-0
Re: [Cooker] isolinux
On Tuesday 30 October 2001 05:18 pm, Yura Gusev wrote: On Tue, 30 Oct 2001, Tom Brinkman wrote: cpuburn http://users.ev1.net/~redelm/severely tests cpu/cache/ram. As a long time overclocker, I can say if your system can run cpuburn for at least 30 mins, it's stable as can be. Quicker You know the risk of overclocing but you can't predict memory problems :( OC'ing is never a risk if it's done properly, YMMV. I'm using very old pc100 (8ns, Mosel Vitelic) at cas2 135mhz as I type, mixed in with 2 other sticks of Micron 7.5ns ram (512 total). The old pc100 is runnin 35% higher than sold as, -o- errors, has for years. Mobo has more to do with ram performance and stabiltiy, as long as it's good quality ram to start with. Most memory problems are solved by re-seating the ram, tryin different slots, changing the order of the sticks, or all the above. 'Course this assumes decent ram and motherboard. For instance, the pc100 I mentioned above won't run memtest86 overnite at 100mhz cas3 (less than it's rated) on a PCCHIPS, or Dell spec board mobo, but will run memtest86 with no errors at 155mhz cas3 on a Soyo with a good power supply. On a Aopen board it's good for 133mhz cas3 with the same quality PS. BTW, the only memory problems I have Yura, are between my ears ; -- Tom Brinkman Galveston Bay, USA chmod +x /bin/Laden.al-Qaeda.Taliban
Re: [Cooker] isolinux
On Tuesday 30 October 2001 03:10 pm, Guillaume Cottenceau wrote: Tom Brinkman [EMAIL PROTECTED] writes: cpuburn http://users.ev1.net/~redelm/severely tests This looks interesting; I'm thinking of puting that in the rescue; what would you advice? What's the procedure? Fork, launch the burn* program and monitor the process? It seems that burnBX would terminate on error but burnP5 would not, is it right? It's sad because it seems that burnP6 would terminate on error? Which burn* would be the best for a general-purpose test, burnP5 for processor and burnBX for memory, right? My experience is that any of the various burn?? modules will run. For instance, I've used 'burnP6' with my Tbird. I believe these questions would be much better answered by the author tho. Robert Redelmeier, HOUSTON USA [EMAIL PROTECTED] He's always been very helpful on the newsgroups... and Texas friendly ;) cpu/cache/ram. As a long time overclocker, I can say if your system can run cpuburn for at least 30 mins, it's stable as can be. Quicker and easier to use than memtest86 or settin up a kernel compile loop. I'd strongly suggest havin continuous cpu temp monitoring setup before runnin any of cpuburn's modules. 'burnK7' will get my 1.4 at Why so? Physical damage only occurs when the processor is _really_ hot, and the motherboard would prevent from that, isn't it? With an Intel proceesor yes. The internal diode protects it. With AMD's ... maybe. Only the new XP Palimino's have a internal temp diode, but currently no motherboards that support (i2c) checking it and shutting down. Also, i2c reporting has been direct (internal core temp) from the earliest Pentiums. With AMD cpu's, temp is reported from a mobo probe (thermistor). Overclockers have always added at least 10°C to probe temps in order to guess at the actual core temp. Recently AMD said to add as much as 20°C (they said 10 to 20). 1.55 ghz Tbird up to 52°C. So my 52°C max could actually be a core temp of 70+° Since Tbirds fry at 90° and generally start spitin errors in the 70's, you wouldn't want to see 55°C from a Tbird probe temp under extreme load, or more'n 50C during normal heavy operation (like a kernel compile). My advice would be to abort burnK7 if the probe temp from a Tbird got near to over 55°C. I'd abort an Intel processor at 50°C (most Intels fry at 65, spit errors at 45). With either, going over what I'm advising probly means you need better HS/fan and case ventilation. BTW, thanks Guillaume for your Penguin Liberation rpms ;) As Blue told it, you're mixing the Guillaume's :-). Mea Culpa, but thanks anyhow to the _real_ Guillaume ;) -- Tom Brinkman Galveston Bay, USA chmod +x /bin/Laden.al-Qaeda.Taliban
Re: [Cooker] isolinux
Paolo Pedroni [EMAIL PROTECTED] writes: Il 12:43, martedì 30 ottobre 2001, hai scritto: Do you use it often? Did it allow you to detect memory problems in the real world? I detected memory problems at least three times, using memtest. It just works! Now, everytime some friend of mine asks me to check their malfunctioning computer, first thing I do is stick a memtest floppy disk in their drive and check their memory. Personally, I use for a long time the simple following thing: I recompile 100 times a kernel, storing the logs, and I then verify all the logs are the same ; when memory or chipset or processor are malfunctioning, sometimes GCC receives signal-11 because of failing hardware. I'm wondering if memtest would not miss some of the errors; also it doesn't use the harddisk so it can miss chipset problems related to disk probably. Of course, memtest is really more easy to use than recompiling a kernel. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] isolinux
Tom Brinkman [EMAIL PROTECTED] writes: cpuburn http://users.ev1.net/~redelm/severely tests This looks interesting; I'm thinking of puting that in the rescue; what would you advice? What's the procedure? Fork, launch the burn* program and monitor the process? It seems that burnBX would terminate on error but burnP5 would not, is it right? It's sad because it seems that burnP6 would terminate on error? Which burn* would be the best for a general-purpose test, burnP5 for processor and burnBX for memory, right? cpu/cache/ram. As a long time overclocker, I can say if your system can run cpuburn for at least 30 mins, it's stable as can be. Quicker and easier to use than memtest86 or settin up a kernel compile loop. I'd strongly suggest havin continuous cpu temp monitoring setup before runnin any of cpuburn's modules. 'burnK7' will get my 1.4 at Why so? Physical damage only occurs when the processor is _really_ hot, and the motherboard would prevent from that, isn't it? 1.55 ghz Tbird up to 52°C. BTW, thanks Guillaume for your Penguin Liberation rpms ;) As Blue told it, you're mixing the Guillaume's :-). -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] isolinux
On 30 Oct 2001, Guillaume Cottenceau wrote: Todd Lyons [EMAIL PROTECTED] writes: I think this would be a VERY good thing (provided there's not a major technical showstopper with memtest-x86, which is what I'm afraid of). Do you use it often? Did it allow you to detect memory problems in the real world? Yes i helped me with strange mem problem on my motherboard. System was totaly unstable after i added more memory(Micron). I exchanged DIMM but i did't helped. Then i used this programm and i give me nothing but after i tryed intensive memory test(it is not default one) after 4 or 5 hours i got a lot of error. Anyway it hepled me to find where to plug this dimm on the motherboard to make system stable. 2 month uptime now. -- 5:05pm up 14 days, 6:02, 3 users, load average: 0.01, 0.01, 0.00 __ | / \ |Iouri Goussev// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Foo-Bar / // \\ \ jgs\\ // http://foobar.irc-unix.net| \__/ | I am not 31337. But I can use the Vi editor... ;-0
[Cooker] isolinux
If isolinux is kept for 8.2, what's keeping you from also allowing it to boot memtest-x86? It would be an awesome thing to be able to tell users it sounds like you've got hardware problems, boot CD 2 and select memtest. Compare that to go to /images on CD1, find memtest-x86.bin, make a boot floppy with the instructions at http://www.linux-mandrake.com/...; I think this would be a VERY good thing (provided there's not a major technical showstopper with memtest-x86, which is what I'm afraid of). Blue skies... Todd -- tlyons at mandrakesoft dot com http://www.linux-mandrake.com/en PGP signature
Re: [Cooker] isolinux
On Mon Oct 29, 2001 at 08:47:20PM -0800, Todd Lyons wrote: If isolinux is kept for 8.2, what's keeping you from also allowing it to boot memtest-x86? It would be an awesome thing to be able to tell users it sounds like you've got hardware problems, boot CD 2 and select memtest. Compare that to go to /images on CD1, find memtest-x86.bin, make a boot floppy with the instructions at http://www.linux-mandrake.com/...; I think this would be a VERY good thing (provided there's not a major technical showstopper with memtest-x86, which is what I'm afraid of). SuSE 7.2 has a lilo entry that boots directly to run memtest86. Not sure about earlier versions or 7.3, but I know this is a feature in 7.2. There is a binary in /boot (memtest.bin) that is executed, and a lilo.conf entry: image = /boot/memtest.bin label = memtest86 I'm not sure if memtest is built in a special way to allow it to be run in this way or not, but it might be more handy than using a CD to do this. The filesize on memtest.bin is 67580 so it's pretty small. -- [EMAIL PROTECTED], OpenPGP key available on www.keyserver.net 1024D/FE6F2AFD 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD - Danen Consulting Serviceswww.danen.net, www.freezer-burn.org - MandrakeSoft, Inc. Security www.linux-mandrake.com Current Linux kernel 2.4.8-31.1mdk uptime: 8 hours 19 minutes. PGP signature
