Jump to content

sundbry

Members
  • Posts

    6
  • Joined

  • Last visited

Everything posted by sundbry

  1. @markolonius I haven't seen this issue in production for over a month on my 7x units I have deployed, after reverting to the method used in the "legacy" kernel branch. Here is the patch. The original patch which is in upstream Linux was a little "too clever", and although I believe it must have worked well for the person who submitted it, the errata in the hardware make it an unreliable fix. The previous technique of just reading the register in a loop until it gets a stable reading works much better. https://github.com/arctype-co/linux/commit/5fcb4e57eeaa4d670ef4acf5818c6fe16aa0d3d0
  2. @windysea as I was pondering this further yesterday, I realized I had never observed this issue for over a year when running on the 3.xx ayufan kernels. I think that what you said may have something to do with it. I wonder what other differences are hiding and implemented in that kernel?
  3. The heat sink adhesive melted off? Yikes @Petee Thanks for the info @windysea. I wonder what the hell the ALLWINNER CORPORATION has to say about this. You would think that maybe knowing the internals of the CPU they could provide some guidance. Why would I ever want to rely on another Allwinner CPU if they can't communicate. Maybe the Pine64 guys are the only ones with enough leverage to get them to speak up.
  4. test timer results Host with clock already drifted to 2114: ./root@host-131:~# ./test_timer TAP version 13 # number of cores: 4 ok 1 same timer frequency on all cores # timer frequency is 24000000 Hz (24 MHz) ok 2 native counter reads are monotonic # 0 errors # min: 6, avg: 6, max: 3795 ok 3 Linux counter reads are monotonic # 0 errors # min: 458, avg: 504, max: 39000 # core 0: counter value: 2610635813617 => 108776 sec # core 0: offsets: back-to-back: 7, b-t-b synced: 10, b-t-b w/ delay: 9 # core 1: counter value: 2610635816527 => 108776 sec # core 1: offsets: back-to-back: 9, b-t-b synced: 7, b-t-b w/ delay: 9 # core 2: counter value: 2610635818363 => 108776 sec # core 2: offsets: back-to-back: 9, b-t-b synced: 7, b-t-b w/ delay: 8 # core 3: counter value: 2610635821240 => 108776 sec # core 3: offsets: back-to-back: 8, b-t-b synced: 7, b-t-b w/ delay: 8 1..3 root@host-131:~# date Fri Jun 22 19:59:10 UTC 2114 Host with clock still at the present time: root@host-125:~# ./test_timer TAP version 13 # number of cores: 4 ok 1 same timer frequency on all cores # timer frequency is 24000000 Hz (24 MHz) ok 2 native counter reads are monotonic # 0 errors # min: 6, avg: 6, max: 174096 ok 3 Linux counter reads are monotonic # 0 errors # min: 458, avg: 500, max: 25958 # core 0: counter value: 2612467490982 => 108852 sec # core 0: offsets: back-to-back: 8, b-t-b synced: 11, b-t-b w/ delay: 9 # core 1: counter value: 2612467492975 => 108852 sec # core 1: offsets: back-to-back: 8, b-t-b synced: 6, b-t-b w/ delay: 8 # core 2: counter value: 2612467494726 => 108852 sec # core 2: offsets: back-to-back: 8, b-t-b synced: 6, b-t-b w/ delay: 8 # core 3: counter value: 2612467497033 => 108852 sec # core 3: offsets: back-to-back: 8, b-t-b synced: 6, b-t-b w/ delay: 8 1..3 root@host-125:~# date Tue Apr 30 23:27:54 UTC 2019
  5. @Petee you can get all the board schematic pdfs (and the CPU manual) at http://wiki.pine64.org/index.php/PINE_A64_Main_Page
  6. Unfortunately, the current mainline fix seems to be unreliable. I am running a fleet of these things (with a kernel built from source). The UNKOWN1 patch is enabled and loaded, but this is the second time I have seen this happen on this kernel. It happens on different devices too - the second time was a different one than the first time I saw it. I don't know if the patch was just a statistical cross-your-fingers patch, I'm going to review it now, but that's what it seems like. root@host-131:~# uname -a Linux host-131 5.1.0-rc2-sunxi64 #5.77.66 SMP Sun Apr 28 16:02:54 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux root@host-131:~# date Fri Jun 22 19:45:31 UTC 2114 root@host-131:~# zcat /proc/config.gz | grep ERRAT CONFIG_ARM64_ERRATUM_826319=y CONFIG_ARM64_ERRATUM_827319=y CONFIG_ARM64_ERRATUM_824069=y CONFIG_ARM64_ERRATUM_819472=y # CONFIG_ARM64_ERRATUM_832075 is not set CONFIG_ARM64_ERRATUM_845719=y CONFIG_ARM64_ERRATUM_843419=y CONFIG_ARM64_ERRATUM_1024718=y CONFIG_ARM64_ERRATUM_1188873=y CONFIG_ARM64_ERRATUM_1165522=y CONFIG_ARM64_ERRATUM_1286807=y # CONFIG_CAVIUM_ERRATUM_22375 is not set CONFIG_CAVIUM_ERRATUM_23144=y # CONFIG_CAVIUM_ERRATUM_23154 is not set # CONFIG_CAVIUM_ERRATUM_27456 is not set # CONFIG_CAVIUM_ERRATUM_30115 is not set # CONFIG_QCOM_FALKOR_ERRATUM_1003 is not set # CONFIG_QCOM_FALKOR_ERRATUM_1009 is not set # CONFIG_QCOM_QDF2400_ERRATUM_0065 is not set CONFIG_HISILICON_ERRATUM_161600802=y CONFIG_QCOM_FALKOR_ERRATUM_E1041=y CONFIG_FUJITSU_ERRATUM_010001=y CONFIG_FSL_ERRATUM_A008585=y # CONFIG_HISILICON_ERRATUM_161010101 is not set # CONFIG_ARM64_ERRATUM_858921 is not set CONFIG_SUN50I_ERRATUM_UNKNOWN1=y root@host-131:~# cat /proc/device device-tree/ devices root@host-131:~# cat /proc/device device-tree/ devices root@host-131:~# cat /proc/device-tree/timer/ allwinner,erratum-unknown1 compatible interrupts name root@host-131:~# cat /proc/device-tree/timer/allwinner,erratum-unknown1 root@host-131:~# dmesg | grep errat [ 0.000000] CPU features: detected: ARM erratum 845719 [ 0.000000] CPU features: detected: ARM erratum 843419 [ 0.000000] arch_timer: Enabling global workaround for Allwinner erratum UNKNOWN1
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines