"w_tom" <w_tom1@usa.net> wrote in message
news:1188520262.350183.75610@i13g2000prf.googlegro ups.com...
> On Aug 30, 6:41 am, Maurice Batey <maur...@bcs.removethis.org.uk>
> wrote:
>> Will resume battle on return on Sunday.
>> Many thanks for all your efforts to help; much appreciated...
>> Have nice weekends, folks!
>
> You have a long list of wild and wanton suggestions. A new keyboard
> is not relevant to your problem. Either is some mysterious virus that
> exists only in wild speculation.
>
> Kony has provided a responsible list of suspect. This poster was
> doing this stuff multiple generations ago. Kony's list is what you
> should be concentrating on - and ignore so many other posts based only
> in speculation - it could be this or could be that follows by "so
> replace it".
>
> The suspect list is where to begin looking for irrefutable facts -
> where you 'follow the evidence'. Too many are saying "I suspect it
> must be this, therefore it must be this; so replace this". That can
> even make the problem exponentially more complex.
>
> Notice after so much work, your accomplishment is zero. You still
> don't even know what in the computer is good. Swapping also does not
> verify things good.
>
> Get a 3.5 digit multimeter. A tool so simple and so ubiquitous as
> to be sold even to K-mart shoppers. IOW if you fear the meter, then
> you have no business even trying to fix the computer. Get the meter.
> Take some voltage measurements. Where to get those DC voltage numbers
> from is listed in "When your computer dies without warning....."
> starting 6 Feb 2007 in the newsgroup alt.windows-xp at:
> http://tinyurl.com/yvf9vh
>
> In your case, most important numbers are voltages on any one of
> orange, red, purple, and yellow wire from power supply to motherboard
> just after power switch is pressed. Post those numbers here to learn
> even more useful information. Now we have definitive facts - no more
> "it could be ..."
>
> IOW first establish power supply 'system' integrity. Yes the power
> supply is only one part of that 'system'. If you don't establish
> 'system' integrity, then 'try this and try that' will take weeks.
> Above procedure means the few technically informed here can then post
> something useful. Numbers obtained in two minutes.
>
> Another suggested BIOS battery. Only ten second with the meter
> provides that number. We remove nothing (because a better number
> means the battery stays connected to motherboard). We then know if a
> battery is defective OR we know that battery is good. IOW we
> accomplish something. But that means numbers and a meter.
>
> Why so few useful responses? A direct reflection of information
> provided in your posts. Having provided so few useful facts, then one
> is even claiming some nonsense about a virus. Ignore those posters.
> There is nothing wrong with the Eprom, as Kony posted - obviously.
> But then so many who *know* computers don't even understand what he
> posted about BIOS operation. They are the sources of wild speculation
> even about overheating.
>
> Take only two minutes. Get those power supply voltage numbers. Post
> them here. Obtain useful replies. Only then have you accomplished
> something by establishing one subsystem as good. Notice what it takes
> to 'follow the evidence' AND accomplish something.
>
> Currently you have a near zero list of good subsystems - and too
> many useless replies. You want replies that are useful? Start by
> defining what is 'definitively good' and 'definitively bad'. That
> means numbers. Provided is where to look for facts:
>> Cold power up problems tend to be either power supply, flaky
>> motherboard capacitors, a bad mechanical connection or a PCB
>> problem such as bad solder joints or board cracks, though
>> the former two are a lot more common than the latter two.
>
> Since the power supply can make anything or everything look
> defective, then we first establish its integrity - two minutes with a
> multimeter and then post those numbers.
>
> IOW we fix things only by 'following the evidence'. Which item on
> that list is know good after all this time? None. Nothing was
> accomplished. That virus? Show me how he concluded by following the
> evidence. He did not. That post demonstrated how many *computer
> experts* don't even know how a computer works - don't even know how
> electricity works - why they are experts only because they speculate.
>
You again, why don't you an Kony get a room?
No one suggested that a virus was the cause of the OP's
problem. I was the only one to even mention a virus and
that was just as an example of how code/software can
effect the startup process. You talk of your adherence
to the scientific principle/requirement for numeric data, but
you deliberately misinterpreted statements or totally invent
them to try and make your point.
Should the OP follow standard troubleshooting practice;
of course he should. Should the power supply be checked
and established as good, yes that is a given. But a quick
review of our previous encounters suggests that, for you,
the problem is always the power supply or grounding. Just
like for Kony it's always a heat related problem or failing
capacitors.
My posting about a similar situation where the cure turned
out to be replacing the keyboard and its drivers, was offered
because it was one rare case where traditional troubleshooting
didn't provide the answer. It was a "long shot" that I wouldn't
expect to be considered, in the normal troubleshooting process.
(Which is the very reason I felt it needed bringing up.) Because
it fixed a very similar problem I thought it might benefit the OP.
Most of the ammunition for your arguments against the postings
here comes not from statements addressing the OP's problem, but
from my replies to Kony's knee jerk reaction to my posting. I
foolishly thought I could provide some information to show why
it is possible, countering Kony's claims that it wasn't. I should
have known that nothing I could say, would allow Kony (or such
as you) to see that anything but their suggestions could have merit.
I don't actually know if the possible explanations I provided were
the ones at work in the situation I was describing, I do know that
the actions I took and described, fixed the problem. It is certainly
possible that totally different factors were in play, that I did not
detect. I do know that what I did worked, when changing good
MBs, cases, processors, memory, and yes power supplies, did
not isolate or fix the problem.
I certainly hope that the readers don't buy into Kony's or your
position that only postings that meet your approval or that you
originate, are worth considering.
On Thu, 30 Aug 2007 21:37:35 -0500, "Ken Maltby"
<kmaltby@sbcglobal.net> wrote:
> Just
>like for Kony it's always a heat related problem or failing
>capacitors.
I again invite you to look over my past posts and prove your
statement that I frequently claim "it's always a heat
related problem", with the exception of cases where the OP
had already indicated as much, or there was a direct link
like a failing fan.
If you haven't seen much gear with failing capacitors, I
suggest you haven't seen much gear. I can't will a cap to
pop, but once it does there is little speculation needed -
to merely look inside a computer is an obvious enough
suggestion to make when troubleshooting hardware, and while
one is inside, they might as well move an eyeball or two
towards the vicinity of the capacitors. It is quick, easy,
free, and requires no special ability on the part of the
person looking except to recognize that a cap should be flat
on top, stand up straight, and not have crusty residue
leaking out.
If I had ever seen or even heard of one single virus that
flashed any semi-modern motherboard bios and this resulted
in the board posting but then locking up, I might then
consider it worth mentioned from time to time. Instead I
only mention things that have any reasonable chance of
happening without some indication of an unusual
circumstance.
>
> My posting about a similar situation where the cure turned
>out to be replacing the keyboard and its drivers, was offered
>because it was one rare case where traditional troubleshooting
>didn't provide the answer. It was a "long shot" that I wouldn't
>expect to be considered, in the normal troubleshooting process.
>(Which is the very reason I felt it needed bringing up.) Because
>it fixed a very similar problem I thought it might benefit the OP.
There's no need to be defensive, we're all just throwing out
ideas. Nobody is going to guess right immediately, 100% of
the time, but some things are far less likely and/or
contrary to the evidence presented. Group collaboration can
reduce the magnitude of things someone troubleshooting would
need try, and hopefully reduce the time and expense to get
the system working right again.
>
> Most of the ammunition for your arguments against the postings
>here comes not from statements addressing the OP's problem, but
>from my replies to Kony's knee jerk reaction to my posting.
That's an interesting statement, considering I had posted
nothing to this thread yet when you wrote:
"Have you and "Grinder" been replaced by "kony" clones?"
While your suggestion about drivers and bios can help, maybe
even solve some seemingly related problems, in this case
there was a specific reason to believe it could be ruled
out. The only way to narrow the focus and have someone try
a few targeted things, is to also rule out the hundreds if
not thousands of things that don't need to be considered.
When a cold-off system locks up before one can even get into
the bios menu, which is necessarily before it has ever tried
to read anything from the hard drive, when the only thing
running as of yet is the decompressed bios, we know there is
no software issue because there is no software running yet,
nor any chance a volatile register held the wrong values -
because it was a clean boot from cold off, something the
system had to have been doing correctly up until the problem
started.
>I
>foolishly thought I could provide some information to show why
>it is possible, countering Kony's claims that it wasn't. I should
>have known that nothing I could say, would allow Kony (or such
>as you) to see that anything but their suggestions could have merit.
I suppose if I was a virus writer, and knew the specific
board someone had, it would be possible to target them and
write something to NV memory that would allow a system to
POST but be instable, and yet, there'd be a checksum error
and if this was just an inappropriate configuration value
that prevented the board from running stabily, clearing CMOS
should resolve it. I suppose if we wanted to stretch things
even further, it might be possible to redo the entire bios
such that it passed the checksum test and then was instable,
but how many hours of work and motherboards would the hacker
have to have, identical to the target system? Some ideas
are just so "out there" that until there is one single
example, we have to ignore what is theoretically possible.
If we want to talk theory, in theory a snake might have
crawled inside and done some damage. I have actually had a
system someone brought that had a snake in it (they had
removed the snake before bringing it), and I vaguely recall
a web picture of a snake in a PSU. With these two examples
of snakes in systems, I have more reason to suggest looking
for snakes than you would to wonder about a bios flashing
virus that leaves the system posting, and yet you are
welcome to scavenge my posts to see if I've ever mentioned
snakes in systems except for this example - because it's
just not likely enough to mention.
>
> I don't actually know if the possible explanations I provided were
>the ones at work in the situation I was describing, I do know that
>the actions I took and described, fixed the problem. It is certainly
>possible that totally different factors were in play, that I did not
>detect. I do know that what I did worked, when changing good
>MBs, cases, processors, memory, and yes power supplies, did
>not isolate or fix the problem.
>
> I certainly hope that the readers don't buy into Kony's or your
>position that only postings that meet your approval or that you
>originate, are worth considering.
I'm sorry I got you bent into a knot Ken, the goal here is
to solve the OP's problem and if I know based on the
evidence that it can't be software or drivers, shouldn't I
have mentioned that instead of having the OP try things that
won't fix the problem? The OP made no mention of changing
drivers just prior to the onset of the problem, and the
system is now 3 years old. While we can't be guaranteed the
OP has not changed drivers, we can only go on what has been
written, and have to assume if there is no driver change
mentioned, there is no driver change... and if there is no
driver change, it should not now be locking up because of a
driver when it had ran same driver previously, UNLESS there
is some other hardware problem too... and if there is some
other hardware problem, it'll have to be solved at least
enough that the system is not locking up even at entry to
the bios before drivers can even be considered.
We don't know that there isn't a driver problem, but we do
know there is at least one problem not related to drivers,
causing an instability. It is exceedingly difficult to try
to troubleshoot OS or drivers when the hardware isn't even
stable yet before loading any software.
"kony" <spam@spam.com> wrote in message
news:q04fd3980mrvatho7971qes9lql2d75t7r@4ax.com...
> On Thu, 30 Aug 2007 21:37:35 -0500, "Ken Maltby"
> <kmaltby@sbcglobal.net> wrote:
>
>
> If I had ever seen or even heard of one single virus that
> flashed any semi-modern motherboard bios and this resulted
> in the board posting but then locking up, I might then
> consider it worth mentioned from time to time. Instead I
> only mention things that have any reasonable chance of
> happening without some indication of an unusual
> circumstance.
>
>
>>
>> My posting about a similar situation where the cure turned
>>out to be replacing the keyboard and its drivers, was offered
>>because it was one rare case where traditional troubleshooting
>>didn't provide the answer. It was a "long shot" that I wouldn't
>>expect to be considered, in the normal troubleshooting process.
>>(Which is the very reason I felt it needed bringing up.) Because
>>it fixed a very similar problem I thought it might benefit the OP.
>
> There's no need to be defensive, we're all just throwing out
> ideas. Nobody is going to guess right immediately, 100% of
> the time, but some things are far less likely and/or
> contrary to the evidence presented. Group collaboration can
> reduce the magnitude of things someone troubleshooting would
> need try, and hopefully reduce the time and expense to get
> the system working right again.
>
>>
>> Most of the ammunition for your arguments against the postings
>>here comes not from statements addressing the OP's problem, but
>>from my replies to Kony's knee jerk reaction to my posting.
>
> That's an interesting statement, considering I had posted
> nothing to this thread yet when you wrote:
>
> "Have you and "Grinder" been replaced by "kony" clones?"
>
Your "Sock Puppet" didn't use that in his argument, just
my responses to your later posts.
> While your suggestion about drivers and bios can help, maybe
> even solve some seemingly related problems, in this case
> there was a specific reason to believe it could be ruled
> out. The only way to narrow the focus and have someone try
> a few targeted things, is to also rule out the hundreds if
> not thousands of things that don't need to be considered.
>
> When a cold-off system locks up before one can even get into
> the bios menu, which is necessarily before it has ever tried
> to read anything from the hard drive, when the only thing
> running as of yet is the decompressed bios, we know there is
> no software issue because there is no software running yet,
> nor any chance a volatile register held the wrong values -
> because it was a clean boot from cold off, something the
> system had to have been doing correctly up until the problem
> started.
>
>
>
>>I
>>foolishly thought I could provide some information to show why
>>it is possible, countering Kony's claims that it wasn't. I should
>>have known that nothing I could say, would allow Kony (or such
>>as you) to see that anything but their suggestions could have merit.
>
> I suppose if I was a virus writer, and knew the specific
> board someone had, it would be possible to target them and
> write something to NV memory that would allow a system to
> POST but be instable, and yet, there'd be a checksum error
> and if this was just an inappropriate configuration value
> that prevented the board from running stabily, clearing CMOS
> should resolve it. I suppose if we wanted to stretch things
> even further, it might be possible to redo the entire bios
> such that it passed the checksum test and then was instable,
> but how many hours of work and motherboards would the hacker
> have to have, identical to the target system? Some ideas
> are just so "out there" that until there is one single
> example, we have to ignore what is theoretically possible.
Now lets add back in a portion of my post that you felt
shouldn't be quoted here:
" No one suggested that a virus was the cause of the OP's
problem. I was the only one to even mention a virus and
that was just as an example of how code/software can
effect the startup process. You talk of your adherence
to the scientific principle/requirement for numeric data, but
you deliberately misinterpreted statements or totally invent
them to try and make your point."
Then you just ignore what was posted, so you can put
words in my mouth. There was no virus involved in the
startup problem that was cured by replacing the keyboard
and drivers. The point was that some errant or corrupted
code could effect the startup process, and that it could
explain the events I observed, in fixing a startup problem
by replacing the keyboard and its drivers.
> If we want to talk theory, in theory a snake might have
> crawled inside and done some damage. I have actually had a
> system someone brought that had a snake in it (they had
> removed the snake before bringing it), and I vaguely recall
> a web picture of a snake in a PSU. With these two examples
> of snakes in systems, I have more reason to suggest looking
> for snakes than you would to wonder about a bios flashing
> virus that leaves the system posting, and yet you are
> welcome to scavenge my posts to see if I've ever mentioned
> snakes in systems except for this example - because it's
> just not likely enough to mention.
>
>
>
>>
>> I don't actually know if the possible explanations I provided were
>>the ones at work in the situation I was describing, I do know that
>>the actions I took and described, fixed the problem. It is certainly
>>possible that totally different factors were in play, that I did not
>>detect. I do know that what I did worked, when changing good
>>MBs, cases, processors, memory, and yes power supplies, did
>>not isolate or fix the problem.
>>
>> I certainly hope that the readers don't buy into Kony's or your
>>position that only postings that meet your approval or that you
>>originate, are worth considering.
>
> I'm sorry I got you bent into a knot Ken, the goal here is
> to solve the OP's problem and if I know based on the
> evidence that it can't be software or drivers, shouldn't I
> have mentioned that instead of having the OP try things that
> won't fix the problem? The OP made no mention of changing
> drivers just prior to the onset of the problem, and the
> system is now 3 years old. While we can't be guaranteed the
> OP has not changed drivers, we can only go on what has been
> written, and have to assume if there is no driver change
> mentioned, there is no driver change... and if there is no
> driver change, it should not now be locking up because of a
> driver when it had ran same driver previously, UNLESS there
> is some other hardware problem too... and if there is some
> other hardware problem, it'll have to be solved at least
> enough that the system is not locking up even at entry to
> the bios before drivers can even be considered.
>
> We don't know that there isn't a driver problem, but we do
> know there is at least one problem not related to drivers,
> causing an instability. It is exceedingly difficult to try
> to troubleshoot OS or drivers when the hardware isn't even
> stable yet before loading any software.
On Fri, 31 Aug 2007 01:43:51 -0500, "Ken Maltby"
<kmaltby@sbcglobal.net> wrote:
>>> Most of the ammunition for your arguments against the postings
>>>here comes not from statements addressing the OP's problem, but
>>>from my replies to Kony's knee jerk reaction to my posting.
>>
>> That's an interesting statement, considering I had posted
>> nothing to this thread yet when you wrote:
>>
>> "Have you and "Grinder" been replaced by "kony" clones?"
>>
> Your "Sock Puppet" didn't use that in his argument, just
>my responses to your later posts.
It seems this conversation is degrading pretty fast.
Do we have anything useful to cover now that might help the
OP with this system or are we both just wasting time?
> Now lets add back in a portion of my post that you felt
>shouldn't be quoted here:
>
> " No one suggested that a virus was the cause of the OP's
>problem. I was the only one to even mention a virus and
>that was just as an example of how code/software can
>effect the startup process. You talk of your adherence
>to the scientific principle/requirement for numeric data, but
>you deliberately misinterpreted statements or totally invent
>them to try and make your point."
"Shouldn't" be quoted? It was left out because it is
non-applicable to the OP's primary problem.
Maurice Batey wrote:
>
> Looking for a good newsgroup to help me diagnose a weird hardware problem with
> my 3-year old desktop.
>
> If this is not it, could someone recommend one, please?
>
> (Inconsistent symptoms, but machine always locks up within 4 minutes of cold
> power up, regardless of which operating system is being booted.
Look for heat related problems. ie clogged up cpu fansinks, not enough
case fans, etc.
> > (Inconsistent symptoms, but machine always locks up within 4 minutes of cold
> > power up, regardless of which operating system is being booted.
>
> Look for heat related problems. ie clogged up cpu fansinks, not enough
> case fans, etc.
It's highly logical of you to blame lack of heat for a heat problem
> I unplugged and replugged all the power connections in the PC
> (apart from the big one plugged into the motherboard, which I simply could not
> get out).
>
> After powering up from cold it has been running normally (WinXP, Kubuntu,
> Mandriva) -
No more lockups, but since that day I have been using the
following procedure, just to be on the safer side, after powering
off overnight.
(1) Half hour before wanting to use PC, boot up the PC and let
it sit at the prompt for BIOS password (with everything else
still powered off).T
(2) After half an hour, power on monitor, router, etc, and
boot some system up.
Later on I might just try without the half hour warm up ...
Been OK for sevetral days now. Fingers crossed...
--
Maurice
(Remove 'removethis.' to reply by email)
> I have been using the following procedure, just to be on the
safer side, after powering
> off overnight.
>
> (1) Half hour before wanting to use PC, boot up the PC and let
> it sit at the prompt for BIOS password (with everything else
> still powered off).T
> (2) After half an hour, power on monitor, router, etc, and
> boot some system up.
Gradually reduced the warm-up time to 5 minutes from power up,
and have had no lockups for 2 months now...
--
Maurice
(Remove 'removethis.' to reply by email)
Re: Hardware problem 
Linear Mode
