| kernel: EDAC k8 MC0: GART TLB errorr: transaction type(generic), cache level(generic) [message #16438] |
Thu, 06 September 2007 14:42  |
sspt
Messages: 100
Registered: August 2006
Location: Portugal
|
Senior Member |
|
|
Hi,
I'm getting the following error, usually one a day, at the same time:
Sep 6 09:15:55 xxx kernel: VZ QUOTA: disk softlimit exceeded for id=22218
Sep 6 09:21:49 xxx kernel: EDAC k8 MC0: GART TLB errorr: transaction type(generic), cache level(generic)
Sep 6 09:21:49 xxx kernel: EDAC k8 MC0: extended error code: GART error
Sep 6 09:22:15 xxx kernel: EDAC k8 MC0: GART TLB errorr: transaction type(generic), cache level(generic)
Sep 6 09:22:15 xxx kernel: EDAC k8 MC0: extended error code: GART error
Sep 6 14:25:49 xxx kernel: Fatal resource shortage: privvmpages, UB 22210.
And
Sep 4 09:14:30 xxx kernel: EDAC k8 MC0: GART TLB errorr: transaction type(generic), cache level(generic)
Sep 4 09:14:30 xxx kernel: EDAC k8 MC0: extended error code: GART error
Sep 4 09:19:07 xxx kernel: VZ QUOTA: disk softlimit exceeded for id=22218
Linux xxx.myvpz.biz 2.6.18-8.1.8.el5.028stab039.1 #1 SMP Mon Jul 23 18:02:32 MSD 2007 x86_64 x86_64 x86_64 GNU/Linux
MC0 refers to a DRAM controller but all the memory has been tested for about 16 hours without any error.
Since there's usually a quota issue i guess there's some I/O at the moment, is it possible that's related with the HDD and not the RAM controller?
[Updated on: Thu, 06 September 2007 14:43] Report message to a moderator |
|
|
|
| Re: kernel: EDAC k8 MC0: GART TLB errorr: transaction type(generic), cache level(generic) [message #16443 is a reply to message #16438] |
Thu, 06 September 2007 15:40  |
khorenko
Messages: 533
Registered: January 2006
Location: Moscow, Russia
|
Senior Member |
|
|
| sspt wrote on Thu, 06 September 2007 18:42 |
MC0 refers to a DRAM controller but all the memory has been tested for about 16 hours without any error.
Since there's usually a quota issue i guess there's some I/O at the moment, is it possible that's related with the HDD and not the RAM controller?
|
Hi,
well, i personally would not suspect the HDD in this situation: 5 minutes passed between EDAC report and VZQUOTA exceed issue, too long to suspect their direct dependence. At the same time i suppose both these messages mean that node's load raised at that time.
i suggest you to test again the memory or just replace it if possible (may be temporarily - just to test.) What tool do you use? If you used a userspace memory test, then it certain makes sense to retest with memtest86+ (yes, it requires the long node downtime, but it's much more reliable than userspace memory tests).
If it won't show the problem again, then may be cpu or even motherboard is guilty. It's harder to check but makes sense to run several 'cpuburn's along with userspace memory tests - they will give a pretty heavy load. (BTW, is there a new BIOS firmware available for the MB?)
One more possible thing is a power abnormals - if somebody comes to the work and switch on some powerful device somewhere near - this might give such a result...
Hope this helps.
If your problem is solved - please, report it!
It's even more important than reporting the problem itself...
|
|
|
|
|
|
| Re: kernel: EDAC k8 MC0: GART TLB errorr: transaction type(generic), cache level(generic) [message #20144 is a reply to message #20057] |
Wed, 12 September 2007 13:15 |
khorenko
Messages: 533
Registered: January 2006
Location: Moscow, Russia
|
Senior Member |
|
|
| sspt wrote on Tue, 11 September 2007 20:15 |
Sep 11 15:49:14 awknet01 kernel: ioctl32(perl:452): Unknown cmd fd(3) cmd(40067408){00} arg(08986f30) on /dev/tty
|
Most probably you are running a 32bit VE on a 64 bit node (or at least run 32 bit perl under 64 bit kernel). Some perl script (you have its PID - 452) made an ioctl which is unknown to the kernel - 0x40067408.
This is a correct TIOCGETP ioctl (getting the terminal parameters) but it is used only on sparc(64)/alpha/mips/powerpc architectures, and the script is written not in a very sane way and still tries to call this ioctl on your node. Often such things are done to make script more portable and i suppose the script handles the error correctly and works normally further.
I suppose this is not a thing to worry about, it is normal message. The only disadvantage is this message in the logs.
P.S. if you run the same script on a i386 system you won't get those warnings as they exist only in compat ioctl kernel code - i.e. if a 32bit application makes ioctl running under the 64 kernel.
If your problem is solved - please, report it!
It's even more important than reporting the problem itself...
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
