"TLB parity error in virtual array; TLB error 'instruction"?

Ant wrote:
On 3/8/2010 8:49 PM PT, Robert Redelmeier typed:

As Yousef has mentioned, any PSU failure serious enough to
damage RAM could easily damage the CPU. Especially AMD with
the RAM controller and busses inside the CPU.

Damn. Intel CPUs does better with this?

The old ones might, because they had separated memory controllers on the
chipset rather than inside the processor. But the new ones, Core
i-series, are exactly like AMD ones, they have integrated memory
controllers too.

However, I don't see this as an issue in your case, whether it was
separated or integrated memory controllers. The TLB is part of the
processor's cache system, which is much higher up in the food chain than
the memory controllers. They don't have any direct connection to the
system RAM.

Yousuf Khan

Ant wrote:
On 3/8/2010 7:01 PM PT, Yousuf Khan typed:

If that PSU failure took out so much other hardware, then it's likely it
took out your processor too, and it took longer for it to finally fail.
CPU chips tend to be more robust than memory chips and GPU chips, a lot
more redundancy, so they may show the signs of the failure much later.

Ah, that could be it. So far, a 512 MB of RAM and video card went bust
with the PSU. Too bad my friend and I did not see physical evidences of
busted caps, discolorations, etc.

Those may yet come, after much time. But in reality, caps can be much
more robust than any of the electronic components. The CPU and RAM may
run anywhere between 1.0 to 2.0 Volts, so a spike of even 0.1V is
significant to them. A capacitor is just a very simple electrical
component, and a small spike won't kill it. A damaged capacitor might
still continue to work in diminished capacity for a long time.

In actual fact, the motherboard capacitors are there to protect against
voltage spikes to some extent. So the fact that it didn't really protect
these components, might be an indication that they may already be
damaged and just working in diminished capacity right now.

Your original PSU problem, what caused it? Lightening? Or did it just go
on its own for some unknown reason? If it went on its own, then it's
likely it caused this level of damage to your entire system. The PSU
also has capacitors in it, designed to protect against voltage spikes. A
surge suppressing power bar also helps protect along the way, with
capacitors. Each one acts like a flood dike. A lightening strike may
overwhelm the surge suppressor, and then it will overwhelm the PSU, but
the PSU has fuses that will sacrifice themselves and thus protect the
motherboard and internal components. If the PSU didn't do that fast
enough, then it may have let over-voltage through.

Or possibly, the PSU itself was the cause of the overvoltage. Was it an
old PSU that failed? Certain PSU size calculator sites make a provision
for systems that are left on for 24 hours for years on end. They reduce
its capacity rating by upto 40% for such a situation!

Yousuf Khan

Ant wrote in part:
40 times?! Is there an easy way to run it in one command
or something? I had to run two of them manually earlier.

Type once, repeat many times:
$ time nice -19 ./burnMMX P &

then just [up-arrow] [enter] to repeat.


OK, I am fine to 40 but I don't want to manually copy
and paste 40 times.


Why not? That's even easier -- just highlight the whole line
(including the return) then click the middle button 40 times.

-- Robert

Your original PSU problem, what caused it? Lightening? Or did it just go
on its own for some unknown reason? If it went on its own, then it's
likely it caused this level of damage to your entire system. The PSU
also has capacitors in it, designed to protect against voltage spikes. A
surge suppressing power bar also helps protect along the way, with
capacitors. Each one acts like a flood dike. A lightening strike may
overwhelm the surge suppressor, and then it will overwhelm the PSU, but
the PSU has fuses that will sacrifice themselves and thus protect the
motherboard and internal components. If the PSU didn't do that fast
enough, then it may have let over-voltage through.

Here is what I remember before the PSU went dead.

1. A few days before it, I smelled something burning but couldn't figure
out what.

2. A few laters, computer went dead. Computer didn't want to boot up.
Drive light blink like crazy when computer is on.

3. My friend and I investigated and narrowed down to dead PSU. However,
computer still wouldn't boot up. We tried another SAME motherboard
model. Same thing. We tried an older motherboard with an Athlon 754
single core CPU. No problems!

4. After more testings, we found that EVGA GeForce 8800 GT was the
problem to prevent motherboard to boot up. That explains why motherboard
beeped a few times without it. With it, nothing. :/ We RMA'ed it and got
a fixed one.

5. Got everything back. Then, kernel panics one in a while (usually
takes 5-8 days to reproduce and usually during idle times from what I
noticed)! Note that I never had them before getting things back
together. I assume it was the PSU incident that started it.

6. We ran memtest86+ v4.00 and it found errors. My friend and I narrowed
down to a 512 MB piece and removed it. Tested all of them and no errors
again.

7. We assumed things were fine now after finding out the bad RAM. NOPE
after a week or so, more kernel panics! Reran memtest86 overnight twice
and no errors. Great, something else is wrong then.


Or possibly, the PSU itself was the cause of the overvoltage. Was it an
old PSU that failed? Certain PSU size calculator sites make a provision
for systems that are left on for 24 hours for years on end. They reduce
its capacity rating by upto 40% for such a situation!

The new Antec PSU? How can I check for that? I think I already shared my
machine specifications:
http://alpha.zimage.com/~ant/antfarm.../computers.txt (secondary). If
not, then see that link.

Also note that I have an UPS behind the computer (and another desktop).
--
"We are anthill men upon an anthill world." --Ray Bradbury
/\___/\
/ /\ /\ \ Phillip (Ant) @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
\ _ / Please remove ANT if replying by e-mail.
( )

40 times?! Is there an easy way to run it in one command
or something? I had to run two of them manually earlier.

Type once, repeat many times:
$ time nice -19 ./burnMMX P &

then just [up-arrow] [enter] to repeat.

Wow, that's going to be crazy to count them :P. I assume killall burnMMX
command will kill them all. Does it have to be 40 of them? I might run
them all night tonight or so.


OK, I am fine to 40 but I don't want to manually copy
and paste 40 times.


Why not? That's even easier -- just highlight the whole line
(including the return) then click the middle button 40 times.

Still a lot. I will do that.
--
"We are anthill men upon an anthill world." --Ray Bradbury
/\___/\
/ /\ /\ \ Phillip (Ant) @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
\ _ / Please remove ANT if replying by e-mail.
( )

wrote in part:
Wow, that's going to be crazy to count them :P. I assume
killall burnMMX command will kill them all. Does it have
to be 40 of them? I might run them all night tonight or so.

Something around that, to use up available RAM without
going into swap. You can count them, or run them under
`time` so it marks when/if they abend. killall works.

-- Robert

wrote:
Or possibly, the PSU itself was the cause of the overvoltage. Was it an
old PSU that failed? Certain PSU size calculator sites make a provision
for systems that are left on for 24 hours for years on end. They reduce
its capacity rating by upto 40% for such a situation!

The new Antec PSU? How can I check for that? I think I already shared my
machine specifications:
http://alpha.zimage.com/~ant/antfarm.../computers.txt (secondary). If
not, then see that link.


No, not the new PSU, the old one that created all of the commotion in
the first place. Just wondering what the cause of that original failure
was. Since you got a new PSU, it's not likely the cause of any of the
current problems. The current CPU problem is probably a leftover from
that original failure.

Yousuf Khan

wrote:
40 times?! Is there an easy way to run it in one command
or something? I had to run two of them manually earlier.
Type once, repeat many times:
$ time nice -19 ./burnMMX P &

then just [up-arrow] [enter] to repeat.

Wow, that's going to be crazy to count them :P. I assume killall burnMMX
command will kill them all. Does it have to be 40 of them? I might run
them all night tonight or so.


Or just create a script. Simplest thing you can do is copy paste into
the text editor 40 times. Or if you want to be pretty about it, try
writing a loop for it:

#!/bin/bash
x=1
while (x -lt 40)
do
time nice -19 ./burnMMX P &
x=x+1
done

That's just off the top of my head, I haven't tested the syntax.

Yousuf Khan

On 3/9/2010 11:18 PM PT, Yousuf Khan typed:

wrote:
Or possibly, the PSU itself was the cause of the overvoltage. Was it
an old PSU that failed? Certain PSU size calculator sites make a
provision for systems that are left on for 24 hours for years on end.
They reduce its capacity rating by upto 40% for such a situation!

The new Antec PSU? How can I check for that? I think I already shared
my machine specifications:
http://alpha.zimage.com/~ant/antfarm.../computers.txt (secondary).
If not, then see that link.

No, not the new PSU, the old one that created all of the commotion in
the first place. Just wondering what the cause of that original failure
was. Since you got a new PSU, it's not likely the cause of any of the
current problems. The current CPU problem is probably a leftover from
that original failure.

I assume the old PSU died by itself and damaged my hardwares? A few days
before it, I smelled something burning that I couldn't narrow down.
Probably the PSU since we couldn't find any obvious oddness on
motherboard, etc. We never bothered to look inside the PSU (too late
now). I don't remember PSU smelling either.
--
"I got worms! That's what we're going to call it. We're going to
specialize in selling worm farms. You know like ant farms. What's the
matter, a little tense about the flight?" --Lloyd Christmas (Dumb and
Dumber movie)
/\___/\
/ /\ /\ \ Phil./Ant @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links: http://aqfl.net
\ _ / Nuke ANT from e-mail address: NT
( ) or
Ant is currently not listening to any songs on his home computer.

On 3/9/2010 8:13 PM PT, Robert Redelmeier typed:

Wow, that's going to be crazy to count them :P. I assume
killall burnMMX command will kill them all. Does it have
to be 40 of them? I might run them all night tonight or so.

Something around that, to use up available RAM without
going into swap. You can count them, or run them under
`time` so it marks when/if they abend. killall works.

I ran it for about 15 minutes.

$ sensors -f
acpitz-virtual-0
Adapter: Virtual device
temp1: +71.2°F (crit = +206.2°F)

k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp: +127.4°F
Core1 Temp: +100.4°F

$ top
top - 07:35:06 up 1 day, 23:52, 1 user, load average: 42.33, 37.41, 20.82
Tasks: 188 total, 37 running, 151 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0%us, 0.0%sy, 75.3%ni, 24.7%id, 0.0%wa, 0.0%hi, 0.0%si,
0.0%st
Cpu1 : 3.3%us, 6.2%sy, 88.9%ni, 0.0%id, 0.0%wa, 1.6%hi, 0.0%si,
0.0%st
Mem: 2595064k total, 2527612k used, 67452k free, 376k buffers
Swap: 2361512k total, 361084k used, 2000428k free, 4756k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1857 ant 39 19 65632 64m 4 R 28 2.5 0:48.63 burnMMX

1844 ant 39 19 65632 64m 4 R 16 2.5 0:08.30 burnMMX

1876 ant 39 19 65632 64m 4 R 14 2.5 0:49.97 burnMMX

1838 ant 39 19 65632 64m 4 R 11 2.5 0:48.66 burnMMX

1827 ant 39 19 65632 64m 4 R 11 2.5 0:53.44 burnMMX

1879 ant 39 19 65632 64m 4 R 9 2.5 0:43.21 burnMMX

1881 ant 39 19 65632 64m 4 R 7 2.5 0:43.91 burnMMX

1837 ant 39 19 65632 64m 4 R 6 2.5 0:45.62 burnMMX

1872 ant 39 19 65632 64m 4 R 6 2.5 0:24.34 burnMMX

1861 ant 39 19 65632 64m 4 R 5 2.5 0:15.91 burnMMX

1812 ant 39 19 65632 64m 4 R 5 2.5 0:42.38 burnMMX

1823 ant 39 19 65632 64m 4 R 5 2.5 0:16.68 burnMMX

1820 ant 39 19 65632 64m 4 R 3 2.5 0:46.17 burnMMX

1822 ant 39 19 65632 64m 4 R 3 2.5 0:44.40 burnMMX

1845 ant 39 19 65632 64m 4 R 3 2.5 0:21.89 burnMMX

1871 ant 39 19 65632 64m 4 R 3 2.5 0:28.55 burnMMX

1873 ant 39 19 65632 64m 4 R 3 2.5 0:19.51 burnMMX

1883 ant 39 19 65632 64m 4 R 3 2.5 0:49.04 burnMMX

14720 root 40 0 10412 2972 728 S 3 0.1 0:09.04 python

1806 ant 39 19 65632 64m 4 R 3 2.5 0:49.38 burnMMX

1821 ant 39 19 65632 64m 4 R 3 2.5 0:45.35 burnMMX

1824 ant 39 19 65632 64m 4 R 3 2.5 0:47.17 burnMMX

1825 ant 39 19 65632 64m 4 R 3 2.5 0:44.06 burnMMX

1826 ant 39 19 65632 64m 4 R 3 2.5 0:45.99 burnMMX

1836 ant 39 19 65632 64m 4 R 3 2.5 0:33.37 burnMMX

1841 ant 39 19 65632 64m 4 R 3 2.5 0:26.37 burnMMX

1856 ant 39 19 65632 64m 4 R 3 2.5 0:12.81 burnMMX

1858 ant 39 19 65632 64m 4 R 3 2.5 0:27.78 burnMMX

1877 ant 39 19 65632 64m 4 R 3 2.5 0:27.71 burnMMX

1878 ant 39 19 65632 64m 4 R 3 2.5 0:15.96 burnMMX

1882 ant 39 19 65632 64m 4 R 3 2.5 0:31.35 burnMMX

1839 ant 39 19 65632 64m 4 R 3 2.5 0:44.30 burnMMX

1842 ant 39 19 65632 64m 4 R 3 2.5 0:44.33 burnMMX

1843 ant 39 19 65632 64m 4 R 3 2.5 0:19.46 burnMMX

1855 ant 39 19 65632 64m 4 R 3 2.5 0:26.53 burnMMX

1874 ant 39 19 65632 52m 4 D 2 2.1 0:03.33 burnMMX

31 root 20 0 0 0 0 D 1 0.0 0:03.75 kswapd0

1465 ant 40 0 56428 6520 320 S 1 0.3 0:19.93
launch_here.rb
1840 ant 39 19 65632 38m 4 D 1 1.5 0:02.47 burnMMX

1860 ant 39 19 65632 33m 4 R 1 1.3 0:02.54 burnMMX

1880 ant 39 19 65632 36m 4 D 1 1.4 0:02.60 burnMMX

21 root 20 0 0 0 0 R 0 0.0 0:14.38 kblockd/1

1859 ant 39 19 65632 36m 4 D 0 1.5 0:02.49 burnMMX

1875 ant 39 19 65632 34m 4 D 0 1.4 0:02.55 burnMMX

1939 ant 40 0 2464 1212 888 R 0 0.0 0:00.09 top

2657 root 40 0 3392 344 284 S 0 0.0 0:04.12
hald-addon-stor
1 root 40 0 2036 212 188 S 0 0.0 0:01.50 init

2 root 40 0 0 0 0 S 0 0.0 0:00.00 kthreadd

3 root RT 0 0 0 0 S 0 0.0 0:00.03
migration/0
4 root 20 0 0 0 0 S 0 0.0 0:00.90
ksoftirqd/0
5 root RT 0 0 0 0 S 0 0.0 0:00.00 watchdog/0

6 root RT 0 0 0 0 S 0 0.0 0:00.01
migration/1
7 root 20 0 0 0 0 S 0 0.0 0:04.74
ksoftirqd/1
8 root RT 0 0 0 0 S 0 0.0 0:00.00 watchdog/1

9 root 20 0 0 0 0 S 0 0.0 0:00.04 events/0

10 root 20 0 0 0 0 S 0 0.0 0:00.19 events/1

11 root 20 0 0 0 0 S 0 0.0 0:00.00 cpuset

12 root 20 0 0 0 0 S 0 0.0 0:00.00 khelper...

So far, nothing interesting in my logs or any crashes. Just a very slow
Debian/Linux! Also, the HDD light was very busy. And top shows swap
usage. I checked iotop and saw:

$ iotop

Total DISK READ: 3.02 M/s | Total DISK WRITE: 1259.75 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND

31 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [kswapd0]
1045 be/4 root 0.00 B/s 38.17 K/s 0.00 % 46.36 % [kjournald]
1465 be/4 ant 690.95 K/s 76.35 K/s 50.71 % 4.72 % ruby
../launch_here.rb -b
1844 be/7 ant 580.25 K/s 0.00 B/s 99.99 % 0.00 % ./burnMMX P
1859 be/7 ant 255.77 K/s 0.00 B/s 92.82 % 0.00 % ./burnMMX P
1860 be/7 ant 209.96 K/s 0.00 B/s 99.99 % 0.00 % ./burnMMX P
1874 be/7 ant 427.55 K/s 0.00 B/s 63.77 % 0.00 % ./burnMMX P
1875 be/7 ant 244.31 K/s 0.00 B/s 99.99 % 0.00 % ./burnMMX P
1880 be/7 ant 454.27 K/s 0.00 B/s 99.99 % 0.00 % ./burnMMX P
1840 be/7 ant 263.40 K/s 0.00 B/s 99.99 % 0.00 % ./burnMMX P
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % init [2]
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
3 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/0]
4 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
5 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/0]
6 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/1]
7 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/1]
8 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/1]
....

Are you sure it is not supposed to use swap? I am not even running X.

Do I need to run this overnight or something?
--
"Ants are so much like human beings as to be an embarrassment. They farm
fungi, raise aphids as livestock, launch armies into wars, use chemical
sprays to alarm and confuse enemies, capture slaves. The families of
weaver ants engage in child labor, holding their larvae like shuttles to
spin out the thread that sews the leaves together for their fungus
gardens. They exchange information ceaselessly. They do everything but
watch television." --Lewis Thomas
/\___/\
/ /\ /\ \ Phil./Ant @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links: http://aqfl.net
\ _ / Nuke ANT from e-mail address: NT
( ) or
Ant is currently not listening to any songs on his home computer.