On Do, 2018-09-20 at 09:29 -0700, Tony Lindgren wrote:
Hi Tony,
well, that change seems to have an effect - but it seems to WORSEN things.
None of the three Pyras survived longer than 3 minutes now.
And it's definitely not the temperature: Sat Jan 1 00:02:41 UTC 2000 35�° 35�° 37�° 22�° 3564mV 1000MHz 00:02:41 up 2 min, 1 user, load average: 1.96, 0.96, 0.38
(this was the last entry one of the Pyras spit out).
mtest from U-Boot, however, was working fine (I had it running for over 100 iterations).
None of the units have ever crashed running U-Boot - but then again, a lot less is going on there.
How did you run your memtest? From a loaded kernel or from U-Boot as well?
BTW: One unit spit out the following when it froze:
[ 236.148138] Unable to handle kernel NULL pointer dereference at virtual address 0000022b [ 236.148283] Unable to handle kernel paging request at virtual address a0100101 [ 236.148418] Unable to handle kernel paging request at virtual address a0100101 [ 236.148553] Unable to handle kernel paging request at virtual address a0100101 [ 236.148687] Unable to handle kernel paging request at virtual address a0100101 [ 236.148821] Unable to handle kernel paging request at virtual address a0100101 [ 236.148955] Unable to handle kernel paging request at virtual address a0100101 [ 236.149089] Unable to handle kernel paging request at virtual address a0100101 [ 236.149221] Unable to handle kernel paging request at virtual address a0100101 [ 236.149354] Unable to handle kernel paging request at virtual address a0100101 [ 236.149486] Unable to handle kernel paging request at virtual address a0100101 [ 236.149618] Unable to handle kernel paging request at virtual address a0100101 [ 236.149751] Unable to handle kernel paging request at virtual address a0100101 [ 236.149883] Unable to handle kernel paging request at virtual address a0100101 [ 236.150016] Unable to handle kernel paging request at virtual address a0100101 [ 236.150148] Unable to handle kernel paging request at virtual address a0100101 [ 236.150282] Unable to handle kernel paging request at virtual address a0100101 [ 236.150415] Unable to handle kernel paging request at virtual address a0100101 [ 236.150548] Unable to handle kernel paging request at virtual address a0100101 [ 236.150682] Unable to handle kernel paging request at virtual address a0100101 [ 236.150814] Unable to handle kernel paging request at virtual address a0100101 [ 236.150947] Unable to handle kernel paging request at virtual address a0100101 [ 236.151079] Unable to handle kernel paging request at virtual address a0100101 [ 236.151212] Unable to handle kernel paging request at virtual address a0100101 [ 236.358133] Unable to handle kernel NULL pointer dereference at virtual address 0000026b
Does that help?
@Tony: We do have an adaptor for JTAG access available for the Pyra, but we have no one who know is very knowledgable with that. Have you ever used the JTAG and would that help you debugging the memory issue? Then Nikolaus could send that adaptor to you.
- H. Nikolaus Schaller hns@goldelico.com [180920 14:13]:
Am 20.09.2018 um 15:57 schrieb Michael Mrozek < EvilDragon@openpandora.org>:
They are in a big array of magic hex numbers...
http://git.goldelico.com/?p=letux-uboot.git;a=blob;f=board/goldelico/letux-c...
The datasheet usually has minimum and maximum listed, so I should be able to safely change them.
I'd change one value at a time between max and min to see if it improves things (or worsens them).
Also, simply comparing the values to the datasheet might help as well.
Yes please do check again :)
Can you please try maxing out .sdram_tim3 T_RFC value from 0x027f8be8 to 0x027f8ff8, see commit 2b143578a07afe0e50567f8327f4f62e0703cb20.
Regards,
Tony