If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
"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 |
#12
|
|||
|
|||
"TLB parity error in virtual array; TLB error 'instruction"?
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 |
#13
|
|||
|
|||
"TLB parity error in virtual array; TLB error 'instruction"?
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 |
#14
|
|||
|
|||
"TLB parity error in virtual array; TLB error 'instruction"?
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. ( ) |
#15
|
|||
|
|||
"TLB parity error in virtual array; TLB error 'instruction"?
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. ( ) |
#16
|
|||
|
|||
"TLB parity error in virtual array; TLB error 'instruction"?
|
#18
|
|||
|
|||
"TLB parity error in virtual array; TLB error 'instruction"?
|
#19
|
|||
|
|||
"TLB parity error in virtual array; TLB error 'instruction"?
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. |
#20
|
|||
|
|||
"TLB parity error in virtual array; TLB error 'instruction"?
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. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
"TLB parity error in virtual array; TLB error 'instruction"? | Ant[_3_] | AMD x86-64 Processors | 8 | March 13th 10 04:32 PM |
"Parity Error Detected" message when running Intel Storage Console. | Brcobrem | Storage (alternative) | 1 | November 18th 09 08:49 PM |
"paper is jammed" "at the transport" error message-Canon Mp830 (false error) | markm75 | Printers | 2 | August 19th 07 02:04 AM |
Samsung ML-2150 (2152W) (1) suddenly prints all pages "almost" blank and (2) error message "HSync Engine Error" , not in user manual | Lady Margaret Thatcher | Printers | 5 | May 4th 06 04:51 AM |
ASUS A8V & ATI AIW 9600 "inf" "thunk.exe" error message? | ByTor | AMD x86-64 Processors | 5 | January 13th 06 06:50 PM |