At 11:26 13/11/2006, you wrote:
The smartctl test also went well.
As Dave mentioned, I will also give it a blast. Hope it will do well. Also I am thinking of re-seating RAM and CPU this evening.
If you take out the CPU then you will also need to apply fresh heat sink compound. I found that a little white spirit (or whatever the solvent for cleaning oil based paint out of brushes is called in your locality) from the DIY shop on a kitchen wipe is very effective for cleaning off the old compound.
But I cannot afford to run memtest for several days as it was required in Mogen's case.
I decided that if a machine hangs during memtest especially when it's already been running for several hours then it most probably isn't the memory that's causing the problem. Does this seem reasonable?
Thanks for the replies guys.
Vijay
BTW Just another thought - Are you powering the machine with a UPS?
BTW Just another thought - Are you powering the machine with a UPS?
Hi Dave,
No there is no UPS.
Just another thought. Do I need noapic and nolapic etc as kernel params during boot? Currently I do not have those but I still remember using those long time ago to install Mandrake (before it became Mandriva) Linux.
Vijay
Vijay Gill wrote:
Just another thought. Do I need noapic and nolapic etc as kernel params during boot? Currently I do not have those but I still remember using those long time ago to install Mandrake (before it became Mandriva) Linux.
These things should just work, and if they don't, you'd know about it. Since you've got as far as you have, they're unlikely to be a problem.
If you want to play with kernel parameters, try noacpi. A dodgy ACPI implementation on your motherboard could cause problems.
Hope this helps,
James.
On 13/11/06, James Wilkinson fedora@aprilcottage.co.uk wrote:
Vijay Gill wrote:
Just another thought. Do I need noapic and nolapic etc as kernel params during boot? Currently I do not have those but I still remember using those long time ago to install Mandrake (before it became Mandriva) Linux.
These things should just work, and if they don't, you'd know about it. Since you've got as far as you have, they're unlikely to be a problem.
If you want to play with kernel parameters, try noacpi. A dodgy ACPI implementation on your motherboard could cause problems.
Hope this helps,
James.
noapic and nolapic did not work anyway. I tried and had segfault. I use mencoder to encode some stuff and surely it crashes after some time. I tried mencoder (along with the needed libs) which was working 100% stable under FC5. Giving noacpi a shot and will report back soon. Vijay
On Mon, 2006-11-13 at 13:14 +0000, Vijay Gill wrote:
On 13/11/06, James Wilkinson fedora@aprilcottage.co.uk wrote:
Vijay Gill wrote:
Just another thought. Do I need noapic and nolapic etc as kernel params during boot? Currently I do not have those but I still remember using those long time ago to install Mandrake (before it became Mandriva) Linux.
These things should just work, and if they don't, you'd know about it. Since you've got as far as you have, they're unlikely to be a problem.
If you want to play with kernel parameters, try noacpi. A dodgy ACPI implementation on your motherboard could cause problems.
Hope this helps,
James.
noapic and nolapic did not work anyway. I tried and had segfault. I use mencoder to encode some stuff and surely it crashes after some time. I tried mencoder (along with the needed libs) which was working 100% stable under FC5. Giving noacpi a shot and will report back soon.
My machine did the very same things, the first week after I bought it. I took it back to the dealer and asked him to test the power supply. I got it back the next day with a new power supply and it hasn't burped once since. With all the flaky capacitors that hit the market I'd suspect dodgy electronics first. If you have a spare power supply lying around, I'd suggest replacing the one you have as a test. Just to see. Ric
James Wilkinson wrote:
If you want to play with kernel parameters, try noacpi. A dodgy ACPI implementation on your motherboard could cause problems.
Few more ideas:
- you can get information about a kernel panic on your text mode console, eg, Ctrl-Alt-F1. Maybe leave the thing like that and wait for it to blow (perhaps starting a compile before switching will help provoke it).
- Maybe come up in runlevel 3 and see if it still misbehaves, in case it is something to do with your video card / bios / driver. Neat way to do this is press 'a' at the grub prompt, and append the number 3 to the kernel commandline for that one boot
- keep an eye on what
dmesg
outputs, sometimes there can be a clue printed by some driver. Likewise, look through the boot messages in there after boot for warnings or other ugliness
-Andy
Few more ideas:
- you can get information about a kernel panic on your text mode
console, eg, Ctrl-Alt-F1. Maybe leave the thing like that and wait for it to blow (perhaps starting a compile before switching will help provoke it).
- Maybe come up in runlevel 3 and see if it still misbehaves, in case
it is something to do with your video card / bios / driver. Neat way to do this is press 'a' at the grub prompt, and append the number 3 to the kernel commandline for that one boot
- keep an eye on what
dmesg
outputs, sometimes there can be a clue printed by some driver. Likewise, look through the boot messages in there after boot for warnings or other ugliness
-Andy
I do not run GUI, always in text mode only :) There was only one kernel panic and I could attribute that to ivtv driver (I have seen this drive giving kernel panic randomly in my old 'totally stable' system also) because it has not happened again. The applications (mencoder and gcc and for one time firefox) just crash with segment fault/internal compiler error. Nothing appears in dmesg or /var/log/messages
Thanks from Vijay
Vijay Gill wrote:
BTW Just another thought - Are you powering the machine with a UPS?
Hi Dave,
No there is no UPS.
Just another thought. Do I need noapic and nolapic etc as kernel params during boot? Currently I do not have those but I still remember using those long time ago to install Mandrake (before it became Mandriva) Linux.
Vijay
Hi
I just noticed your question - how does a UPS cause issues, and how would you troubleshoot/resolve them?
many thanks
Alex
On Friday 17 November 2006 21:52, Alex wrote:
Vijay Gill wrote:
BTW Just another thought - Are you powering the machine with a UPS?
Hi Dave,
No there is no UPS.
Just another thought. Do I need noapic and nolapic etc as kernel params during boot? Currently I do not have those but I still remember using those long time ago to install Mandrake (before it became Mandriva) Linux.
Vijay
Hi
I just noticed your question - how does a UPS cause issues, and how would you troubleshoot/resolve them?
many thanks
Alex
They're supposed to prevent issues with bad mains supplies. e.g my son was happily tapping and clicking away as I came upstairs with a thunderstorm raging away overhead.
"Dad, my UPS just kicked in"
"That's great - it's working"
Tap tap click click....
I don't know where the OP is located but bad mains power causes problems. I just wondered whether this could be a possibility.
Dave
On Fri, 2006-11-17 at 22:06 +0000, David Fletcher wrote:
On Friday 17 November 2006 21:52, Alex wrote:
Vijay Gill wrote:
BTW Just another thought - Are you powering the machine with a UPS?
Hi Dave,
No there is no UPS.
Just another thought. Do I need noapic and nolapic etc as kernel params during boot? Currently I do not have those but I still remember using those long time ago to install Mandrake (before it became Mandriva) Linux.
Vijay
Hi
I just noticed your question - how does a UPS cause issues, and how would you troubleshoot/resolve them?
many thanks
Alex
They're supposed to prevent issues with bad mains supplies. e.g my son was happily tapping and clicking away as I came upstairs with a thunderstorm raging away overhead.
"Dad, my UPS just kicked in"
"That's great - it's working"
Tap tap click click....
I don't know where the OP is located but bad mains power causes problems. I just wondered whether this could be a possibility.
A UPS should not cause any issues. It's there to supplant the mains power if it gets interrupted. The only way a UPS could cause a segfault is if the monitoring software that watches the UPS (generally via a serial port) has issues.
If one is having tons of segfaults on lots of different applications, the most likely cause is flakey memory. Reboot off the first CD and at the "boot:" prompt, enter "memtest86" and test your RAM.
If RAM tests OK, the next most likely culprit is a power supply that's slowly dying. Get thyself a DMM and check the supplies. If they're OK, then look at the CPU cooling fans.
---------------------------------------------------------------------- - Rick Stevens, Senior Systems Engineer rstevens@vitalstream.com - - VitalStream, Inc. http://www.vitalstream.com - - - - "More hay, Trigger?" "No thanks, Roy, I'm stuffed!" - ----------------------------------------------------------------------
Rick Stevens wrote:
A UPS should not cause any issues. It's there to supplant the mains
A PROPERLY WORKING UPS will not cause problems. One which is itself causing power glitches, or which does not adequately suppress mains glitches, can be a problem.
power if it gets interrupted. The only way a UPS could cause a segfault is if the monitoring software that watches the UPS (generally via a serial port) has issues.
Umm, no.
If one is having tons of segfaults on lots of different applications, the most likely cause is flakey memory. Reboot off the first CD and at the "boot:" prompt, enter "memtest86" and test your RAM.
Well, let's say the #1 cause of problems in all equipment is connectors of various sorts. The first step I take is always to shut down, power down, remove the power cord from the mains, and wiggle/remove/reseat all connectors, like power connectors to floppies, hard drives, CDROMs, control cables to same, all expansion boards get removed and reseated (including memory and CPU), etc. Only after this would I run any software intended to diagnose hardware.
If RAM tests OK, the next most likely culprit is a power supply that's slowly dying. Get thyself a DMM and check the supplies. If they're OK, then look at the CPU cooling fans.
Or overloaded. Overloaded PSs cause problems.
Mike
Back again with more results.
As I mentioned in my old mails in this thread, I was seeing this seg-faulting thing while compile stuff like lame, mplayer, xvid etc. on my ASUS A7N8X VM/400 with Athlon XP 3200+ with PC3200 RAM (using on-board AGP).
I replaced RAM with PC2700 and also replaced the Athlon XP 3200+ with XP2400+ (from the machine I retired) and it seems to be working properly now.
Ran memtest+ for an hour - no problems. Compiled stuff (mplayer, xvid, lame, x264 etc) - no crash. I encoded my mythtv recordings to XviD - no crash.
Let's see how it turns out, but for a moment I was really thinking of bringing my DXR out of retirement.
Vijay
David Fletcher wrote:
<snip> Hi
I just noticed your question - how does a UPS cause issues, and how would you troubleshoot/resolve them?
many thanks
Alex
They're supposed to prevent issues with bad mains supplies. e.g my son was happily tapping and clicking away as I came upstairs with a thunderstorm raging away overhead.
"Dad, my UPS just kicked in"
"That's great - it's working"
Tap tap click click....
I don't know where the OP is located but bad mains power causes problems. I just wondered whether this could be a possibility.
Dave
That's OK then, I thought there may be some software issue associated with running a UPS daemon.
many thanks!
Alex
On Fri, 17 Nov 2006 23:45:56 +0000 Alex alx@satta.co.uk wrote:
That's OK then, I thought there may be some software issue associated with running a UPS daemon.
There is UPS software around, it generally serves three purposes
1. Allow the PC to detect the UPS coming on (or hitting low battery) so the PC can shut down
2. Allowing the PC to monitor/check/config the UPS
3. Allow the PC to turn the UPS off
So it is useful but not vital, and dumber UPS lack such features anyway
Alan