I am looking at a Linux-Intel-Xeon board which has a PCIe Switch (config Space shown below). On the the other side of the LinuxSwitch, via a CABLE there is a different OtherBoard running my software (non-Intel CPU, non-Linux-OS and BSP, which I understand quite well), and it has another switch and an endpoint/s (EP). From the OtherBoard I want to write to shared memory (e.g. on Linux addres 0xB000 0000), and inform LinuxBoardCpu via MSI.
Focusing on MSI (not general interrupts and not general enumeration). I have two main separate questions:
Q1 How does the SW on the OtherBoard cause an MSI to the LinuxBoard, does the OtherBoard perform a write to Linux 0xFEEE_0D38 (e.g. with data=0x0 or data=0x1)? Or does the OtherBoard write 0x1 to a register on the LinuxBoard's-Switch. I should be able to test this from the Linux side only by writing to 0xFEEE_0D38. How do I get a ptr to that address?
Q2 Just focusing on the LinuxBoard Switch-CPU-Memory: how do I effect the write to LinuxBoard's DRAM/DDR/memory address 0xB000_0000? It seems I need a translation of some some sort at the LinuxCPU. The LinuxSwitch will forward the write-address-data to the LinuxSwitch which forwards to the LinuxCPU, but do I need to setup the LinuxCpu to accept the access, or how does the memory-write access the 0xB000_0000?
I wrote a quick program to explore and dump the Linux PCIeBoard Switch's Config Space
04 10 BAR0 : 0x90800000
05 14 BAR1 : 0x00000000
08 20 MemLim, MemBase : 0x90509050 <<<<\b
09 24 PrefetchMems LnB : 0x90219001
10 28 PrefetchUpBaseAdd : 0x00000000
11 2C PrefecthLimAdd : 0x00000000
12 30 IoLimU16 IoBaseU16: 0x00000000
13 34 ......Cap : 0x00000040
14 38 reserved : 0x00000000
15 3C ....InLine : 0x001001ff
16 40 .... MSICapPtr : 0xc8034801
17 44 : 0x00000008
18 48 MSIintCtrl Nxt ID : 0x01876805
19 4C LowerMsgAddr : 0xfee003d8 <<<<
20 50 UpperMsgAddr : 0x00000000
21 54 .... MsgData : 0x00000000
26 68 Cap, Nxt ID : 0x0052a410
27 6C DevCap : 0x012c8003
28 70 DevStat DevCtrl : 0x00090830
29 74 LnkCap : 0x00416883
30 78 LnkStat ..LnkCtr : 0x10830040
31 7C : 0x00000000
32 80 : 0x00000000
Related
Hi i'm using sigar very usefully,
but some critical problem was occurred.
in Windows 10 & jdk11 sigar lib makes JVM crash(append logs below) at all method
but, It works fine when using jdk8 under same environment.
It seems to my sigar-amd64-winnt.dll isn't compatible with jdk11 on windows 10.
so i update my sigar binary to 1.6.4 download from https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/magelan/hyperic-sigar-1.6.4.zip
Unfortunately problem isn't resolved.
is any resolution about this problem?
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000010014ed4, pid=28016, tid=5076
#
# JRE version: Java(TM) SE Runtime Environment (11.0.6+8) (build 11.0.6+8-LTS)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0.6+8-LTS, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [sigar-amd64-winnt.dll+0x14ed4]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--------------- S U M M A R Y ------------
Command Line: org.ngrinder.NGrinderAgentStarter --mode=agent --command=run -o
Host: Intel(R) Core(TM) i7-7700 CPU # 3.60GHz, 8 cores, 15G, Windows 10 , 64 bit Build 17134 (10.0.17134.753)
Time: Thu Feb 13 18:15:10 2020 ¢¥eCN©öI¡¾©ö C¡ÍA¨ª¨öA elapsed time: 0 seconds (0d 0h 0m 0s)
--------------- T H R E A D ---------------
Current thread (0x00000219633f8800): JavaThread "main" [_thread_in_native, id=5076, stack(0x000000256b800000,0x000000256b900000)]
Stack: [0x000000256b800000,0x000000256b900000], sp=0x000000256b8fee50, free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [sigar-amd64-winnt.dll+0x14ed4]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.hyperic.sigar.ProcState.gather(Lorg/hyperic/sigar/Sigar;J)V+0
j org.hyperic.sigar.ProcState.fetch(Lorg/hyperic/sigar/Sigar;J)Lorg/hyperic/sigar/ProcState;+11
j org.hyperic.sigar.Sigar.getProcState(J)Lorg/hyperic/sigar/ProcState;+2
j org.hyperic.sigar.Sigar.getProcState(Ljava/lang/String;)Lorg/hyperic/sigar/ProcState;+6
j org.ngrinder.NGrinderAgentStarter.checkDuplicatedRun(Ljava/lang/String;)V+26
j org.ngrinder.NGrinderAgentStarter.main([Ljava/lang/String;)V+227
v ~StubRoutines::call_stub
siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000009811d78
Register to memory mapping:
RIP=0x0000000010014ed4 sigar-amd64-winnt.dll
RAX=0x0000000009811c40 is an unknown value
RBX={method} {0x000002197fe1ab58} 'gather' '(Lorg/hyperic/sigar/Sigar;J)V' in 'org/hyperic/sigar/ProcState'
RCX=0x00000219633f8b40 points into unknown readable memory: 90 5d 23 16 ff 7f 00 00
RDX=0x000000256b8ff0b0 is pointing into the stack for thread: 0x00000219633f8800
RSP=0x000000256b8fee50 is pointing into the stack for thread: 0x00000219633f8800
RBP=0x000000256b8ff080 is pointing into the stack for thread: 0x00000219633f8800
RSI=0x0000000000200021 is an unknown value
RDI=0x0000000000000268 is an unknown value
R8 =0x0000000000000032 is an unknown value
R9 =0x00000007107f73c0 is an oop: org.hyperic.sigar.Sigar
{0x00000007107f73c0} - klass: 'org/hyperic/sigar/Sigar'
R10=0x0000000000000010 is an unknown value
R11=0x00007fff162b0188 jvm.dll
R12=0x0 is NULL
R13=0x000002197fe1ab48 is pointing into metadata
R14=0x000000256b8ff0b8 is pointing into the stack for thread: 0x00000219633f8800
R15=0x00000219633f8800 is a thread
Registers:
RAX=0x0000000009811c40, RBX=0x000002197fe1ab50, RCX=0x00000219633f8b40, RDX=0x000000256b8ff0b0
RSP=0x000000256b8fee50, RBP=0x000000256b8ff080, RSI=0x0000000000200021, RDI=0x0000000000000268
R8 =0x0000000000000032, R9 =0x00000007107f73c0, R10=0x0000000000000010, R11=0x00007fff162b0188
R12=0x0000000000000000, R13=0x000002197fe1ab48, R14=0x000000256b8ff0b8, R15=0x00000219633f8800
RIP=0x0000000010014ed4, EFLAGS=0x0000000000010202
Top of Stack: (sp=0x000000256b8fee50)
0x000000256b8fee50: 00000219633f8b40 000000256b8ff0b0
0x000000256b8fee60: 00000219633f8800 0000000000000000
0x000000256b8fee70: 0000000009811c40 0000000000000000
0x000000256b8fee80: 000000256b8ff0b8 000000001002113b
0x000000256b8fee90: 00000219633f8b40 000000256b8ff0b0
0x000000256b8feea0: 0000000000200021 0000000000000268
0x000000256b8feeb0: 0000000000000000 0000000000000000
0x000000256b8feec0: 0000000000000000 0000000000000000
0x000000256b8feed0: 0000000000000000 000002190875c9b0
0x000000256b8feee0: 00007fff160ce510 000002190860a550
0x000000256b8feef0: 000000037f73c000 00007fff15f009e5
0x000000256b8fef00: 000002197fe1ab50 00000219633f8800
0x000000256b8fef10: 0000000100000004 00007fff00000003
0x000000256b8fef20: 00000219633f9160 0000002800000003
0x000000256b8fef30: 00000219633f8800 000000256b8ff0b8
0x000000256b8fef40: 000002197fe1ab48 00007fff159c880f
Instructions: (pc=0x0000000010014ed4)
0x0000000010014eb4: 7c 24 20 00 75 15 48 8d 15 df 58 04 00 48 8b 4c
0x0000000010014ec4: 24 40 e8 45 00 00 00 33 c0 eb 32 48 8b 44 24 20
0x0000000010014ed4: 83 b8 38 01 00 00 00 74 1f 48 8b 44 24 20 44 8b
0x0000000010014ee4: 80 38 01 00 00 48 8b 54 24 20 48 8b 4c 24 40 e8
.
.
. (skip)
.
.
Stack slot to memory mapping:
stack at sp + 0 slots: 0x00000219633f8b40 points into unknown readable memory: 90 5d 23 16 ff 7f 00 00
stack at sp + 1 slots: 0x000000256b8ff0b0 is pointing into the stack for thread: 0x00000219633f8800
stack at sp + 2 slots: 0x00000219633f8800 is a thread
stack at sp + 3 slots: 0x0 is NULL
stack at sp + 4 slots: 0x0000000009811c40 is an unknown value
stack at sp + 5 slots: 0x0 is NULL
stack at sp + 6 slots: 0x000000256b8ff0b8 is pointing into the stack for thread: 0x00000219633f8800
stack at sp + 7 slots: 0x000000001002113b sigar-amd64-winnt.dll
--------------- S Y S T E M ---------------
OS: Windows 10 , 64 bit Build 17134 (10.0.17134.753)
CPU:total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 6 model 158 stepping 9, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, avx2, aes, clmul, erms, rtm, 3dnowpref, lzcnt, ht, tsc, tscinvbit, bmi1, bmi2, adx, fma
Memory: 4k page, system-wide physical 16287M (6175M free)
TotalPageFile size 23455M (AvailPageFile size 6527M)
current process WorkingSet (physical memory assigned to process): 74M, peak: 74M
current process commit charge ("private bytes"): 355M, peak: 355M
vm_info: Java HotSpot(TM) 64-Bit Server VM (11.0.6+8-LTS) for windows-amd64 JRE (11.0.6+8-LTS), built on Dec 11 2019 09:17:57 by "mach5one" with MS VC++ 15.5 (VS2017)
END.
I am trying to decrypt wm-bus telegram from Kamstrup Multical21 in C1 mode with Extended Link Layer.
The payload together with ELL info is following:
23 44 2D 2C 45 45 71 63 1B 16 8D 20 6A 31 FB 7C 20 39 A3 79 60 4B 90 BD FC BE 8D D8 CB 18 CE 77 DC 41 CE 8C
Analysing CI = 8D I found that there is a ELL with following data:
CI (1 byte) CC(1 byte) ACC(1 byte) SN(4 bytes) CRC(2 bytes)
8D 20 6A 31 FB 7C 20 39 A3
The documentation says that the buffer which should be decrypted shall contain CRC from ELL, i.e:
39 A3 79 60 4B 90 BD FC BE 8D D8 CB 18 CE 77 DC 41 CE 8C
I have got the AES key from the Manufacturer:
B9 7A 6D 4E C2 74 A4 6D 87 0E 31 27 D9 A0 AF 63
Initialization vector for ELL shall be:
M-field A-field CC-field SN-field FN BC
2D 2C 45 45 71 63 1B 16 20 31 FB 7C 20 00 00 00
After decrypting, I get the following result:
08 3a 5f ce b2 8d 51 97 94 a2 5b fb 61 ab 2e c0
e4 20 c8 2a 43 ff 3a 75 6f 93 d0 ac 8c 79 b7 a1
Since there is no 2F 2F in the beginning, something is wrong!
Can somebody help me and tell what I have done wrong?
Thanks in advance.
I had a look in the latest Kamstrup docs ("Wireless M-Bus Communication Kamstrup Water Meters - MULTICAL® 21 and flowIQ® water meters Mode C1 according to EN 13757-4:2013")
When I decrypt your packet I find:
25877968217E8E01000000000000000000
Firstly, it seems the Kamstrup decrypted packets does not start with 2F 2F.
The first 2 bytes of the decrypted packet is supposedly the PLCRC (I can't confirm that right now - don't have immediate access to the standard that defines the crc polynomial algorithm), and then the next byte is 79, which means it is a Compact Frame, then the next 4 bytes are 2 more CRCs, and then the next 2 bytes 0100 is probably the Info, which is manufacturer specific and I don't know how to interpret that yet.
This meter is probably R type 1, right? (on the face place, the "Con.:" parameter's 3rd last digit should be a 1) So its format would be [Info][Volume][Target Volume] - 2 bytes, 4 bytes, 4 bytes - I kind of assume that, since this packet is a compact packet, so I don't get the actual format the long packet would have, e.g. number of decimals - which normally you'd need - but your values are zeroes? so decimals doesn't matter. (the 'long' packet of course is every 6th packet or so?)
The IV I get is:
2D2C454571631B162031FB7C20000000
which is exactly the same as yours.
The encrypted packet I use is:
39A379604B90BDFCBE8DD8CB18CE77DC41
so I exclude the CE and 8C you had on yours?
When I put them in, the decrypted packet becomes:
25877968217E8E01000000000000000000BB49
which is pretty much the same packet with some more crc stuff at the back, I suspect, so I really do not get what you do to decrypt, since your result is completely different?
Ok, maybe you use AES/CBC/NoPadding, as in OpenMUC.
Kamstrup uses AES/CTR/NoPadding. That is how they don't have to decrypt multiples of 16 byte blocks? The way that looks in my Java code is as follows:
Cipher cipher = Cipher.getInstance("AES/CTR/NoPadding");
the hints here are very helpfull. There's one obstacle I stumbled across with the given message. The Length-Field is wrong and there are 2 bytes of garbage at the end.
I guess the original message was encoded in frame format B. That means the length field includes the frame CRCs and should be corrected after the CRCs are removed. After correcting the length to 0x21 (33 bytes + L-Field), I get the correct message and also can verify that the first 2 bytes of the decoded message contain the CRC16 of the remaining message.
As I am running out of licenses I am using both Matlab and Octave and as long as I keep things simple I haven't had any trouble.
I recently started using .mat files to decrease my amount of single files.
When I do everything in Matlab it works just fine but when I use 'save' in Octave it saves the file as ASCII and it looks somewhat like this at the beginning and has multiple matrixes in it and so multiple headers.
# Created by Octave 3.6.4, Mon Feb 24 21:34:39 2014 CET <***#****>
# name: C
# type: matrix
# rows: 10000
# columns: 10
79 79 79 79 79 79 79 79 79 79
74 115 87 55 101 46 83 92 113 61
69 142 128 48 160 45 87 113 114 71
84 107 145 62 245 78 69 88 149 78
120 73 148 32 299 114 57 79 137 76
This is fine but Matlab refuses to read the file. Neither with 'load' and '-ASCII' nor with importdata.
(Warning: File contains uninterpretable
data....)
Is there anything I can do? Octave loads the files just fine with 'load'.
Thanks!!
In Octave save as "-ascii" or as matlab binary format v4, v6, v7
octave:1> a = rand(3, 3)
a =
0.086093 0.541999 0.889222
0.029643 0.633532 0.762954
0.544787 0.150573 0.927285
octave:2> save ("-ascii", "yourfile.asc")
octave:3> save ("-v7", "yourfile.mat")
back in matlab do
>> b = load ('yourfile.asc')
b =
0.0861 0.5420 0.8892
0.0296 0.6335 0.7630
0.5448 0.1506 0.9273
or
>> load ('yourfile.mat')
>> a
a =
0.0861 0.5420 0.8892
0.0296 0.6335 0.7630
0.5448 0.1506 0.9273
So, I'm using AT Commands with Matlab to return the Caller ID. It DOES work, but I have to manually ask for it. I what it to return Caller ID automatically whenever I ring on the phone.
Here is what I write before I ring:
>> s = serial('COM8');
>> fopen(s)
And I type this when my phone rings:
>> fwrite(s, [65 84 43 67 82 67 61 49 13])
Then I ask for the returned value(the caller phone number):
>> s
Serial Port Object : Serial-COM8
Communication Settings
Port: COM8
BaudRate: 9600
Terminator: 'LF'
Communication State
Status: open
RecordStatus: off
Read/Write State
TransferStatus: idle
BytesAvailable: 47
ValuesReceived: 0
ValuesSent: 18
>> fread(s, 47)
and it returns me 47 ASCII numbers like this(note that I have deleted most of the returned code):
ans =
65
84
43
67
82
67
61
49
13
Which translates to the following(changed the number for safety reasons):
+CRING:VOICE +CLIP: "+359888888888",145AT+CRC=1OK
What I want to happen is when the phone rings to immediately send the computer the output of
>> fwrite(s, [65 84 43 67 82 67 61 49 13])
>> fread(s, 47)
Ran into this JVM error after running an process for an extended period of time that reads records from a csv file, validates the data, and stores in in a database. Using Hibernate and PostgreSQL. The JVM dump mentions some psql classes. Can anyone help with this?
Additional noteworthy infomation:
The process slows down over time but keeps a consistent CPU and memorry usage (about 150% CPU and 11.5% memory)
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x000000073f4027bb, pid=977, tid=1111066944
#
# JRE version: 6.0_26-b03
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C 0x000000073f4027bb
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
--------------- T H R E A D ---------------
Current thread (0x00000000537bd000): GCTaskThread [stack: 0x0000000042298000,0x0000000042399000] [id=985]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000000
Registers:
RAX=0x0000000000000000, RBX=0x0000000000000000, RCX=0x0000000000000003, RDX=0x0000000740c37298
RSP=0x0000000042397b38, RBP=0x0000000042397bb0, RSI=0x00000007f65092b8, RDI=0x0000000740c372a8
R8 =0x0000000000000012, R9 =0x0000000000000012, R10=0x00000007f6fdafb9, R11=0x00002aaaaf38bf10
R12=0x00000007f65092b8, R13=0x0000000000000005, R14=0x0000000000000000, R15=0x0000000740c30ac0
RIP=0x000000073f4027bb, EFLAGS=0x0000000000010286, CSGSFS=0x0000000000000033, ERR=0x0000000000000006
TRAPNO=0x000000000000000e
Top of Stack: (sp=0x0000000042397b38)
0x0000000042397b38: 00002b776b7c8dea 168cf3000000aacb
0x0000000042397b48: 00002b776baf73d0 168cf3000000aacc
0x0000000042397b58: 0000000053802720 0000000053802720
0x0000000042397b68: 0000000000000009 168cf3000000aacc
0x0000000042397b78: 00000007f6fdb02d 0000000042397ba0
0x0000000042397b88: 00000007f6fdafb8 00002b776bb09ee0
0x0000000042397b98: 00000000538027a0 0000000000000000
0x0000000042397ba8: 0000000000000001 0000000042397bd0
0x0000000042397bb8: 00002b776b7c914d 0000000053802720
0x0000000042397bc8: 0000000053802788 0000000042397c10
0x0000000042397bd8: 00002b776b7c85bf 00000007f6fdafb9
0x0000000042397be8: 0000000053802720 0000000000000006
0x0000000042397bf8: 00002aaab4cfe410 00002b776bb04f20
0x0000000042397c08: 0000000042397c2c 0000000042397c60
0x0000000042397c18: 00002b776b7cb948 0000000042397c30
0x0000000042397c28: 2ec7c4dd6b4cdc27 00000007f60b61ba
0x0000000042397c38: 00002b776baedc24 00002aaab4cfe410
0x0000000042397c48: 00000000537bd000 00002b776b937aa6
0x0000000042397c58: 0000000000000000 0000000042397d60
0x0000000042397c68: 00002b776b4ceefa 0000000042397cb0
0x0000000042397c78: 0000000042397c88 00002b776bb08ac0
0x0000000042397c88: 0000000000000000 00000000537bd4d0
0x0000000042397c98: 00000000537bd500 00000000537bd510
0x0000000042397ca8: 00000000537bd8e8 00000000537bd000
0x0000000042397cb8: 00000000537bd8f0 00000000537bd920
0x0000000042397cc8: 00000000537bd930 00000000537bdd08
0x0000000042397cd8: 0000000042397d00 00000000537bd4d0
0x0000000042397ce8: 00000000537bd500 00000000537bd510
0x0000000042397cf8: 00000000537bd8e8 00000000537bd000
0x0000000042397d08: 00000000537bd8f0 00000000537bd920
0x0000000042397d18: 00000000537bd930 00000000537bdd08
0x0000000042397d28: 00000000537bdd10 00000000537be630
Instructions: (pc=0x000000073f4027bb)
0x000000073f40279b: e7 00 00 00 00 14 00 6a 61 76 61 2f 75 74 69 6c
0x000000073f4027ab: 2f 50 72 6f 70 65 72 74 69 65 73 00 00 01 72 99
0x000000073f4027bb: 4a 0f 00 00 00 78 00 e8 e7 00 00 00 00 10 00 6a
0x000000073f4027cb: 61 76 61 2f 75 74 69 6c 2f 56 65 63 74 6f 72 00
Register to memory mapping:
RAX=0x0000000000000000 is an unknown value
RBX=0x0000000000000000 is an unknown value
RCX=0x0000000000000003 is an unknown value
RDX=0x0000000740c37298 is an oop
{method}
- klass: {other class}
RSP=0x0000000042397b38 is an unknown value
RBP=0x0000000042397bb0 is an unknown value
RSI=0x00000007f65092b8 is an unknown value
RDI=0x0000000740c372a8 is an oop
{method}
- klass: {other class}
R8 =0x0000000000000012 is an unknown value
R9 =0x0000000000000012 is an unknown value
R10=0x00000007f6fdafb9 is an unknown value
R11=0x00002aaaaf38bf10 is an unknown value
R12=0x00000007f65092b8 is an unknown value
R13=0x0000000000000005 is an unknown value
R14=0x0000000000000000 is an unknown value
R15=0x0000000740c30ac0 is an oop
{constant pool}
- klass: {other class}
- cache: 0x0000000740c4f550
- 1 : : klass_index=110 name_and_type_index=300
- 2 : : klass_index=109 name_and_type_index=301
- 3 : : klass_index=110 name_and_type_index=302
- 4 : : klass_index=109 name_and_type_index=303
- 5 : : klass_index=304 name_and_type_index=305
- 6 : : klass_index=306 name_and_type_index=307
- 7 : : klass_index=304 name_and_type_index=308
- 8 : : klass_index=109 name_and_type_index=309
- 9 : : klass_index=109 name_and_type_index=310
- 10 : : klass_index=109 name_and_type_index=311
- 11 : : 'org/postgresql/core/Field'
- 12 : : 'java/util/Vector'
- 13 : : klass_index=12 name_and_type_index=314
- 14 : : klass_index=109 name_and_type_index=315
- 15 : : klass_index=109 name_and_type_index=316
- 16 : : klass_index=109 name_and_type_index=317
- 17 : : 'java/lang/String'
- 18 : : "*" {0x73f6b2b18}
- 19 : : klass_index=109 name_and_type_index=320
- 20 : : klass_index=109 name_and_type_index=321
- 21 : : "8.2" {0x740a78928}
- 22 : : klass_index=323 name_and_type_index=324
- 23 : : 'org/postgresql/util/PSQLException'
- 24 : :
The last time something like that happened to me, I found that the main memory on my computer was damaged, I know, I know, most likely everything's ok, but if I were you, i will check it out with memtest86+