Jump to content

5kft

Members
  • Posts

    264
  • Joined

  • Last visited

Posts posted by 5kft

  1. 14 hours ago, Igor said:

    I don't understand what you mean by that? Can you elaborate better? I know there were some changes in the packaging, perhaps @5kft can shed some light. He was making last adjustments in this section.

     

    @going - are you asking why the kernel packages don't include the specific kernel version in them, like as is the case with a native Debian kernel build?  I'm not sure why this isn't the case with Armbian, but I suppose that support could be added - although I'm not sure of the dependencies elsewhere in the build tools (or if there are any).

     

     

  2. 5 hours ago, Ford_Prefect said:

    Hi,

    Thanks for your work,

    I tested your kernel packages yesterday and everything works flawlessly now. I get about 40 to 50 MBps throughput with Ipsec now without stalling and "breaking" the Interface.

     

    I am happy, thanks alot!

     

    Cheers

     

    Ford Prefect

     

     

    Wonderful - this is great to hear! :)  It is a new patch, so keep an eye on the pull requests for the kernels regarding this change, I'm sure it will get pulled into v5.10 soon (and hopefully backported to v5.9 as well).

  3. I'm not an expert in this area whatsoever, but this problem looks like an upstream kernel issue, and perhaps is related to this fallback deadlock fix?  https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=a2715fbdc6fc387e85211df917a4778761ec693d

     

    The posted fix patch is only applicable to kernel v5.10; just in case you want to give it a try, I've uploaded a ToT test build of v5.10-rc3 with this kernel patch applied:  https://drive.google.com/file/d/1Eg_cn3bEYsRFZ3vrP9Mc0fxJjPREczcW/view.  Again, I'm not sure if this will fix the problem, but there are a number of changes in cryptodev here compared to kernel v5.9, so it might be worth a try.

  4. I think that more research is needed here, as the problem is non-obvious.  Unfortunately I can't reproduce any issues on my OrangePi R1 with either 5.8.5 or 5.9.5.  @Igor this doesn't appear to be DVFS related; the DTs are correct and the board is correctly maxed at 1GHz (but it can support 1.3GHz via the overclocking overlay).  I can successfully run all of "openssl speed -multi 4", throttling is fine, etc.

     

    Using iperf3 testing, I can't reproduce any issues on my board with the Ethernet interfaces either; both eth0 and enxc0742bfffa39 work properly for me...  I'm seeing 94Mbps on both eth0 and enxc0742bfffa39 (for testing, I purged network-manager and statically set the IPs in /etc/network/interfaces.d/) - here is the iperf3 server output for the two runs from the R1:

     

    Spoiler

    -----------------------------------------------------------
    Server listening on 5201
    -----------------------------------------------------------
    Accepted connection from 192.168.3.8, port 47388
    [  5] local 192.168.3.2 port 5201 connected to 192.168.3.8 port 47390
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-10.00  sec   112 MBytes  94.1 Mbits/sec
    [  5]  10.00-20.00  sec   112 MBytes  94.1 Mbits/sec
    [  5]  20.00-30.00  sec   112 MBytes  94.1 Mbits/sec
    [  5]  30.00-30.01  sec  93.3 KBytes  90.7 Mbits/sec
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-30.01  sec   337 MBytes  94.1 Mbits/sec                  receiver
    -----------------------------------------------------------
    Server listening on 5201
    -----------------------------------------------------------
    Accepted connection from 192.168.3.7, port 34552
    [  5] local 192.168.3.2 port 5201 connected to 192.168.3.7 port 34554
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-10.00  sec   112 MBytes  93.8 Mbits/sec
    [  5]  10.00-20.00  sec   112 MBytes  94.2 Mbits/sec
    [  5]  20.00-30.00  sec   112 MBytes  94.2 Mbits/sec
    [  5]  30.00-30.01  sec  89.1 KBytes  93.6 Mbits/sec
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-30.01  sec   337 MBytes  94.1 Mbits/sec                  receiver
    -----------------------------------------------------------
    Server listening on 5201
    -----------------------------------------------------------

     

    Of course this is not to say that there isn't a problem, but with this simple/quick iperf3 testing I can't reproduce anything on my board.  @Ford_Prefect I think it would be interesting to see what your serial console shows.  @guidol would it be possible to get serial console output for your situation as well?

     

  5. A lot has changed in the thermal drivers since 4.19, it's possible that the "better temperatures" you are seeing in the older kernel are actually incorrect.  E.g., see https://github.com/megous/linux/commits/orange-pi-5.3/drivers/thermal/sun8i_thermal.c (in particular https://github.com/megous/linux/commit/eac37f0ec6f33e8f3edb8dbdb9d11b4cb8e218e5#diff-e5ac7e093b36d92344ed52a2747602d5e46d366ca34b4abb46cc005f92ee679f).  There are numerous posts in the forums about this and there have been a number of changes in the upstream drivers in this area over the past couple of years...

     

    New (post-4.19) thermal driver history here:  https://lore.kernel.org/linux-arm-kernel/20191226202607.GA9524@Red/T/#mfffc26980cb13605429156c3833464fe3cbdb661 

     

  6. 1 hour ago, guidol said:

    is your "cleaner" NEO2 under ubuntu or debian?

     

    I actually tried both - Debian works fine (as you noted), but Focal crashes just like I was seeing yesterday:

     

    Spoiler

    [2020/11/08 18:27:40.947991,  0] ../../lib/util/fault.c:79(fault_report)
      ===============================================================
    [2020/11/08 18:27:40.948421,  0] ../../lib/util/fault.c:80(fault_report)
      INTERNAL ERROR: Signal 11 in pid 3682 (4.11.6-Ubuntu)
      If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting
    [2020/11/08 18:27:40.948559,  0] ../../lib/util/fault.c:86(fault_report)
      ===============================================================
    [2020/11/08 18:27:40.948649,  0] ../../source3/lib/util.c:823(smb_panic_s3)
      PANIC (pid 3682): internal error
    [2020/11/08 18:27:40.956215,  0] ../../lib/util/fault.c:264(log_stack_trace)
      BACKTRACE: 38 stack frames:
       #0 /lib/aarch64-linux-gnu/libsamba-util.so.0(log_stack_trace+0x38) [0xffffb10427b8]
       #1 /lib/aarch64-linux-gnu/libsmbconf.so.0(smb_panic_s3+0x20) [0xffffb0fe4be8]
       #2 /lib/aarch64-linux-gnu/libsamba-util.so.0(smb_panic+0x34) [0xffffb10428d4]
       #3 /lib/aarch64-linux-gnu/libsamba-util.so.0(+0x10b54) [0xffffb1042b54]
       #4 linux-vdso.so.1(__kernel_rt_sigreturn+0) [0xffffb14617bc]
       #5 /lib/aarch64-linux-gnu/libpthread.so.0(+0xc26c) [0xffffb073026c]
       #6 /lib/aarch64-linux-gnu/libtdb.so.1(+0xf76c) [0xffffafb5b76c]
       #7 /lib/aarch64-linux-gnu/libtdb.so.1(+0x723c) [0xffffafb5323c]
       #8 /lib/aarch64-linux-gnu/libtdb.so.1(+0x79bc) [0xffffafb539bc]
       #9 /lib/aarch64-linux-gnu/libtdb.so.1(+0x9434) [0xffffafb55434]
       #10 /lib/aarch64-linux-gnu/libtdb.so.1(+0x54e0) [0xffffafb514e0]
       #11 /lib/aarch64-linux-gnu/libtdb.so.1(tdb_storev+0x88) [0xffffafb51a80]
       #12 /usr/lib/aarch64-linux-gnu/samba/libdbwrap.so.0(+0x62cc) [0xffffb04202cc]
       #13 /usr/lib/aarch64-linux-gnu/samba/libdbwrap.so.0(dbwrap_record_storev+0x10) [0xffffb041d300]
       #14 /usr/lib/aarch64-linux-gnu/samba/libdbwrap.so.0(dbwrap_record_store+0x18) [0xffffb041d320]
       #15 /usr/lib/aarch64-linux-gnu/samba/libsmbd-base.so.0(+0x16dfcc) [0xffffb1225fcc]
       #16 /usr/lib/aarch64-linux-gnu/samba/libsmbd-base.so.0(+0x16e968) [0xffffb1226968]
       #17 /usr/lib/aarch64-linux-gnu/samba/libsmbd-base.so.0(smb2srv_tcon_create+0x68) [0xffffb1227a18]
       #18 /usr/lib/aarch64-linux-gnu/samba/libsmbd-base.so.0(smbd_smb2_request_process_tcon+0x40c) [0xffffb120fb94]
       #19 /usr/lib/aarch64-linux-gnu/samba/libsmbd-base.so.0(smbd_smb2_request_dispatch+0xc80) [0xffffb1209f50]
       #20 /usr/lib/aarch64-linux-gnu/samba/libsmbd-base.so.0(+0x152a70) [0xffffb120aa70]
       #21 /lib/aarch64-linux-gnu/libtevent.so.0(tevent_common_invoke_fd_handler+0x88) [0xffffb075c390]
       #22 /lib/aarch64-linux-gnu/libtevent.so.0(+0xc668) [0xffffb0762668]
       #23 /lib/aarch64-linux-gnu/libtevent.so.0(+0xa72c) [0xffffb076072c]
       #24 /lib/aarch64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x94) [0xffffb075ba4c]
       #25 /lib/aarch64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x20) [0xffffb075bcc8]
       #26 /lib/aarch64-linux-gnu/libtevent.so.0(+0xa6a4) [0xffffb07606a4]
       #27 /usr/lib/aarch64-linux-gnu/samba/libsmbd-base.so.0(smbd_process+0x6d4) [0xffffb11fa94c]
       #28 /usr/sbin/smbd(+0xb51c) [0xaaaaabc4b51c]
       #29 /lib/aarch64-linux-gnu/libtevent.so.0(tevent_common_invoke_fd_handler+0x88) [0xffffb075c390]
       #30 /lib/aarch64-linux-gnu/libtevent.so.0(+0xc668) [0xffffb0762668]
       #31 /lib/aarch64-linux-gnu/libtevent.so.0(+0xa72c) [0xffffb076072c]
       #32 /lib/aarch64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x94) [0xffffb075ba4c]
       #33 /lib/aarch64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x20) [0xffffb075bcc8]
       #34 /lib/aarch64-linux-gnu/libtevent.so.0(+0xa6a4) [0xffffb07606a4]
       #35 /usr/sbin/smbd(main+0x1970) [0xaaaaabc482f0]
       #36 /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe8) [0xffffb05d7090]
       #37 /usr/sbin/smbd(+0x85ec) [0xaaaaabc485ec]
    [2020/11/08 18:27:40.957516,  0] ../../source3/lib/util.c:836(smb_panic_s3)
      smb_panic(): calling panic action [/usr/share/samba/panic-action 3682]
    [2020/11/08 18:27:40.967186,  0] ../../source3/lib/util.c:843(smb_panic_s3)
      smb_panic(): action returned status 0
    [2020/11/08 18:27:40.967539,  0] ../../source3/lib/dumpcore.c:315(dump_core)
      dumping core in /var/log/samba/cores/smbd

     

     

  7. 9 hours ago, guidol said:

    its interesting - for me - that the newer version 4.11.6 does crash with kernel 5.10.0-rc2 on ubuntu focal but the older 4.9.5 has no problems using kernel 5.10.0-rc2 under debain buster...

     

    Glad it is working for you, but very curious indeed!

     

    Edit:  I tried on another NEO2, and indeed 4.9.5 works fine :blink:.  Perhaps my first test was odd because I just upgraded the kernel on a much older platform rootfs.  But I can confirm the platform-provided v4.9.5 is working under v5.10-rc2 on my "cleaner" NEO2.  I'm also glad to see that the latest v4.13.2 also works!

  8. Hi @guidol, I'm actually seeing similar issues with Debian (!).  The default Debian Buster v4.9.5 Samba server works fine with kernel v5.9.5, but for me with kernel v5.10-rc2 it consistently crashes with "INTERNAL ERROR" faults when a client would access it.  Samba has had issues like this in the past where a particular version would start crashing on newer kernels, so I installed the latest version of Samba (v4.13.2) and it works fine with kernel v5.10 - no crashes, and everything works well.  It looks like there have been a number of changes made for Samba in the new kernel (e.g., see https://wiki.samba.org/index.php/LinuxCIFSKernel#Changes_by_release), so perhaps the older server versions provided by the distributions are simply too old and incompatible for the new v5.10 kernel.

     

    Here are some quick screen captures showing Samba working on my NEO2; I first make a directory "testing", and then copy some files to it, and then I map and access the NEO2 share via Windows:

     

    image.png.604b2e17737e3e100099b0766357af94.png

     

    image.thumb.png.8f67fa2b9d81a965f9ecd2ec0a3dfd03.png

     

    I copied a number of files across the share as well and it worked fine.  I don't use Ubuntu, so I'm not sure what version of Samba is provided with Focal, but perhaps you're encountering the same issue?  You might try installing a newer Samba version and see how it works for you.  Note that I did this all as a test and simply built Samba v4.13.2 from source on the NEO2 (I used https://download.samba.org/pub/samba/samba-latest.tar.gz to download the source).  I hope this helps!

     

     

  9. I'm seeing the same problem, exactly as @guidol described.  I cleared the cache directory and then cleared the output directory, then building 5.9 for nanopi-r1 I ended up with (correct) .debs for sunxi, but (incorrect?) .debs for sunxi64 as well :blink:

     

    Note:  I'm using docker to build; I performed a full build again after removing all "linux-*" files from "/var/lib/docker/volumes/armbian-cache/_data/sources/linux-mainline/" first, and then the output .debs were correct.  So this is consistent with the workarounds above - just need to clear the right "cache" directory.

  10. If you're feeling adventurous and like living life on the edge, I have provided a buildable 5.10 tree here for sunxi:

     

    git clone -b v5.10-dev-test https://github.com/5kft/build

     

    Build as normal using "./compile.sh" using "BRANCH=dev" from this git branch and it'll build 5.10.0-rc1 targets.  Both sunxi and sunxi64 builds are enabled.  Note that I only tested on a few H3 and H5 boards (both Nano Pi and Orange Pi), but it seems to work pretty well.  But no guarantees, support, etc. - this is just a side project atm :)

  11. Understood.  A lot has changed since 4.19...it could be any number of things.  I checked the passive polling rate and 5.x actually polls more often than 4.x, so that's interesting...   A couple of questions:

    • In terms of your older 4.19 kernel, what was the maximum clock rate of the CPU?
    • If you don't overclock to 1.3GHz with 5.x, does it work okay (i.e., doesn't overheat)?

     

  12. With just a few local test hacks, I was able to bring up kernel 5.10-rc1 on sunxi this morning (based on the new megous branch):

     

    root@air's password:
     _   _ ____  _      _    _
    | \ | |  _ \(_)    / \  (_)_ __
    |  \| | |_) | |   / _ \ | | '__|
    | |\  |  __/| |  / ___ \| | |
    |_| \_|_|   |_| /_/   \_\_|_|
    
    Welcome to Armbian 20.08.14 Buster with Linux 5.10.0-rc1-sunxi
    
    System load:   2%               Up time:       11 min
    Memory usage:  14% of 491M      IP:            172.24.18.151
    CPU temp:      34°C             Usage of /:    24% of 7.2G
    
    Last login: Tue Oct 27 07:20:02 2020 from 172.24.18.20
    root@air:~# cat /proc/version
    Linux version 5.10.0-rc1-sunxi (root@355045fc2473) (arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #trunk SMP Tue Oct 27 14:13:23 UTC 2020
    root@air:~#
    root@air:~# cpufreq-info -c 0
    cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
    Report errors and bugs to cpufreq@vger.kernel.org, please.
    analyzing CPU 0:
      driver: cpufreq-dt
      CPUs which run at the same hardware frequency: 0 1 2 3
      CPUs which need to have their frequency coordinated by software: 0 1 2 3
      maximum transition latency: 5.44 ms.
      hardware limits: 480 MHz - 1.20 GHz
      available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.10 GHz, 1.20 GHz
      available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
      current policy: frequency should be within 480 MHz and 1.20 GHz.
                      The governor "ondemand" may decide which speed to use
                      within this range.
      current CPU frequency is 816 MHz (asserted by call to hardware).
      cpufreq stats: 480 MHz:97.72%, 648 MHz:0.22%, 816 MHz:0.20%, 960 MHz:0.23%, 1.01 GHz:0.15%, 1.10 GHz:0.19%, 1.20 GHz:1.29%  (679)
    root@air:~#

     

    I tested this on a spare NanoPi NEO Air board I had; I haven't tried an arm64 build yet.  dmesg is clean; cpufreq works,  overclocking works, wireless works, etc.  Our 5.9 kernel patchset applied almost completely without error (there are a few other changes needed such as the builddeb patches and fbcon reversion patch we did).

     

    In any case I just wanted to let people know.  Given that 5.10 is confirmed to be the new LTS and 5.9 is the new primary -stable,  I'm wondering if 5.8's days are numbered (like what happened to 5.7).  I'm happy to put some work into bringing 5.10 into build if there is interest.

     

  13. 16 hours ago, linuxjosef said:

    As you can see, still not working correctly.

     

    Thanks @linuxjosef, these videos are very helpful!  From what I can see, it is working just fine in the default configuration, and overheating in this instance when overclocking to the maximum speed possible.  Clearly you have insufficient cooling present on this board, especially when overclocking (e.g., too small a heatsink, no fan).  I've had the same problem on my Orange Pi Zero Plus2 H5s, because the heatsink is so small - unfortunately the board isn't designed well for supporting a large heatsink.  However, on my Nano Pis for example I can overclock to the maximum 1.3GHz without an issue, because the heatsink options are significantly larger, e.g., see https://www.friendlyarm.com/image/catalog/description/neo-heat-sink_en_03.jpg and https://www.friendlyarm.com/image/catalog/description/NEO2newcase_en_02.jpg - with these heatsink configurations the CPUs barely get hot.

     

    To avoid this problem I would suggest that you use a larger heatsink regardless, and/or add a cooling fan.  When using a larger heatsink, if overclocking, try overclocking to 1.2GHz instead of 1.3GHz, or simply don't overclock at all (since nothing is guaranteed when overclocking anyway). 

     

    I took a look at tweaking the maps to downclock more aggressively at the higher temperatures (testing on an OPi Zero Plus2), but it became quite obvious that there is only so much that can be done with purely passive cooling and a small heatsink.  Even clocking down significantly at over 90C would still spike with the "openssl" test and hit critical shutdown.  Then, as a test I simply sat a bigger heatsink on top of the existing small heatsink, and then I couldn't get it to overheat - the openssl test successfully ran to completion when overclocked to 1.3GHz:

     

    Spoiler

    root@orangepizeroplus2-h5:~# armbianmonitor -m
    Stop monitoring using [ctrl]-[c]
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

    15:51:58: 1296MHz  0.76  28%  13%  10%   0%   3%   0% 35.2°C  0/11
    15:52:03:  480MHz  0.70   0%   0%   0%   0%   0%   0% 34.8°C  0/11
    15:52:08:  480MHz  0.64   0%   0%   0%   0%   0%   0% 34.3°C  0/11
    15:52:14:  648MHz  0.59   2%   0%   1%   0%   0%   0% 34.0°C  0/11
    15:52:20: 1296MHz  0.54  40%   2%  38%   0%   0%   0% 58.4°C  0/11
    15:52:27: 1296MHz  0.82  99%   0%  99%   0%   0%   0% 60.2°C  0/11
    15:52:34: 1296MHz  1.38  99%   0%  99%   0%   0%   0% 60.9°C  0/11
    15:52:42: 1296MHz  1.59 100%   0%  99%   0%   0%   0% 64.2°C  0/11
    15:52:50: 1296MHz  2.04 100%   0%  99%   0%   0%   0% 64.0°C  0/11
    15:52:57: 1296MHz  2.19  99%   0%  99%   0%   0%   0% 70.1°C  0/11
    15:53:03: 1296MHz  2.55  99%   0%  99%   0%   0%   0% 67.9°C  0/11
    15:53:10: 1296MHz  2.66  99%   0%  99%   0%   0%   0% 66.7°C  0/11
    15:53:17: 1248MHz  2.77 100%   0%  99%   0%   0%   0% 79.8°C  1/11
    15:53:25: 1200MHz  3.03 100%   0%  99%   0%   0%   0% 82.3°C  3/11
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    15:53:33: 1104MHz  3.11  99%   0%  99%   0%   0%   0% 84.8°C  5/11
    15:53:41: 1104MHz  3.32 100%   0%  99%   0%   0%   0% 87.7°C  5/11
    15:53:49: 1104MHz  3.50 100%   0%  99%   0%   0%   0% 90.6°C  5/11
    15:53:57: 1008MHz  3.54  99%   0%  99%   0%   0%   0% 89.7°C  7/11
    15:54:04: 1008MHz  3.69 100%   0%  99%   0%   0%   0% 91.4°C  7/11
    15:54:11: 1008MHz  3.71  99%   0%  99%   0%   0%   0% 93.9°C  7/11
    15:54:18: 1008MHz  3.73 100%   0%  99%   0%   0%   0% 95.1°C  3/11
    15:54:26: 1104MHz  3.85 100%   0%  99%   0%   0%   0% 88.4°C  5/11
    15:54:33: 1104MHz  3.86  99%   0%  99%   0%   0%   0% 87.8°C  5/11
    15:54:41: 1104MHz  3.96 100%   0% 100%   0%   0%   0% 88.1°C  5/11
    15:54:49: 1200MHz  4.04 100%   0%  99%   0%   0%   0% 84.9°C  3/11
    15:54:57: 1200MHz  4.03 100%   0%  99%   0%   0%   0% 84.2°C  3/11
    15:55:04: 1104MHz  4.10 100%   0%  99%   0%   0%   0% 87.2°C  5/11
    15:55:09: 1104MHz  4.09 100%   0%  99%   0%   0%   0% 87.8°C  5/11
    15:55:15: 1104MHz  4.09 100%   0%  99%   0%   0%   0% 88.1°C  5/11
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    15:55:22: 1104MHz  4.08  99%   0%  99%   0%   0%   0% 88.4°C  5/11
    15:55:29: 1104MHz  4.14 100%   0%  99%   0%   0%   0% 87.5°C  5/11
    15:55:36: 1008MHz  4.13 100%   0%  99%   0%   0%   0% 91.0°C  7/11
    15:55:42: 1008MHz  4.12  99%   0%  99%   0%   0%   0% 90.6°C  7/11
    15:55:49: 1008MHz  4.17 100%   0%  99%   0%   0%   0% 91.7°C  7/11
    15:55:58: 1008MHz  4.16 100%   0%  99%   0%   0%   0% 92.2°C  7/11
    15:56:06: 1008MHz  4.21 100%   0%  99%   0%   0%   0% 93.0°C  7/11
    15:56:14: 1008MHz  4.25 100%   0%  99%   0%   0%   0% 92.9°C  7/11
    15:56:22: 1008MHz  4.23 100%   0%  99%   0%   0%   0% 94.2°C  7/11
    15:56:29: 1200MHz  4.27 100%   0%  99%   0%   0%   0% 94.2°C  7/11
    15:56:38: 1008MHz  4.25 100%   0%  99%   0%   0%   0% 94.3°C  7/11
    15:56:46:  816MHz  4.28 100%   0%  99%   0%   0%   0% 82.9°C  7/11
    15:56:55: 1008MHz  4.31 100%   0%  99%   0%   0%   0% 93.5°C  7/11
    15:57:02: 1200MHz  4.29 100%   0%  99%   0%   0%   0% 93.8°C  7/11
    15:57:08: 1008MHz  4.32 100%   0%  99%   0%   0%   0% 94.6°C  7/11
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    15:57:15: 1008MHz  4.30  99%   0%  99%   0%   0%   0% 95.4°C  3/11
    15:57:23: 1008MHz  4.27 100%   0%  99%   0%   0%   0% 83.2°C  7/11
    15:57:31: 1104MHz  4.30  99%   0%  99%   0%   0%   0% 95.7°C  5/11
    15:57:40: 1104MHz  4.33 100%   0%  99%   0%   0%   0% 88.2°C  5/11
    15:57:49: 1008MHz  4.30 100%   0%  99%   0%   0%   0% 83.2°C  7/11
    15:57:57: 1200MHz  4.33 100%   0%  99%   0%   0%   0% 94.3°C  7/11
    15:58:04: 1008MHz  4.35 100%   0%  99%   0%   0%   0% 94.2°C  7/11
    15:58:11: 1008MHz  4.33  99%   0%  99%   0%   0%   0% 93.5°C  7/11
    15:58:18: 1008MHz  4.30  99%   0%  99%   0%   0%   0% 93.3°C  7/11
    15:58:27: 1008MHz  4.33 100%   0%  99%   0%   0%   0% 94.2°C  7/11
    15:58:35: 1008MHz  4.35  99%   0%  99%   0%   0%   0% 93.8°C  7/11
    15:58:42: 1008MHz  4.32  99%   0%  99%   0%   0%   0% 91.7°C  7/11
    15:58:51: 1104MHz  4.35 100%   0%  99%   0%   0%   0% 90.4°C  7/11
    15:58:59: 1104MHz  4.37 100%   0%  99%   0%   0%   0% 88.8°C  5/11
    15:59:05: 1104MHz  4.34 100%   0%  99%   0%   0%   0% 88.1°C  5/11
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    15:59:13: 1008MHz  4.31 100%   0%  99%   0%   0%   0% 92.3°C  7/11
    15:59:22: 1008MHz  4.34 100%   0%  99%   0%   0%   0% 93.2°C  7/11
    15:59:29: 1008MHz  4.36  99%   0%  99%   0%   0%   0% 94.2°C  7/11
    15:59:38: 1008MHz  4.33 100%   0%  99%   0%   0%   0% 93.5°C  7/11
    15:59:46: 1008MHz  4.35 100%   0%  99%   0%   0%   0% 94.5°C  7/11
    15:59:53: 1008MHz  4.32  99%   2%  97%   0%   0%   0% 94.9°C  3/11
    16:00:02:  816MHz  4.35 100%   2%  97%   0%   0%   0% 94.9°C  7/11
    16:00:10: 1008MHz  4.37 100%   0%  99%   0%   0%   0% 90.1°C  5/11
    16:00:19: 1008MHz  4.34 100%   0%  99%   0%   0%   0% 91.3°C  7/11
    16:00:27: 1008MHz  4.36 100%   0%  99%   0%   0%   0% 90.0°C  5/11
    16:00:36: 1104MHz  4.38 100%   0%  99%   0%   0%   0% 88.7°C  5/11
    16:00:44: 1104MHz  4.35  99%   0%  99%   0%   0%   0% 88.8°C  5/11
    16:00:52: 1104MHz  4.37 100%   0%  99%   0%   0%   0% 87.5°C  5/11
    16:00:58: 1104MHz  4.34 100%   0%  99%   0%   0%   0% 86.6°C  5/11
    16:01:06: 1104MHz  4.36 100%   0%  99%   0%   0%   0% 86.5°C  5/11
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    16:01:14: 1104MHz  4.38 100%   0%  99%   0%   0%   0% 85.9°C  5/11
    16:01:22: 1104MHz  4.35 100%   0%  99%   0%   0%   0% 85.8°C  5/11
    16:01:29: 1104MHz  4.37 100%   0%  99%   0%   0%   0% 85.1°C  3/11
    16:01:37: 1104MHz  4.34 100%   0%  99%   0%   0%   0% 85.6°C  5/11
    16:01:44: 1200MHz  4.36  99%   0%  99%   0%   0%   0% 85.2°C  5/11
    16:01:53: 1200MHz  4.33 100%   0%  99%   0%   0%   0% 84.8°C  5/11
    16:02:01: 1104MHz  4.36 100%   0%  99%   0%   0%   0% 84.6°C  5/11
    16:02:09: 1200MHz  4.45 100%   0%  99%   0%   0%   0% 84.6°C  5/11
    16:02:16: 1200MHz  4.41 100%   0%  99%   0%   0%   0% 84.6°C  3/11
    16:02:23: 1200MHz  4.38 100%   0%  99%   0%   0%   0% 85.1°C  3/11
    16:02:31: 1200MHz  4.40 100%   0%  99%   0%   0%   0% 88.2°C  5/11
    16:02:40: 1008MHz  4.41 100%   0%  99%   0%   0%   0% 90.4°C  5/11
    16:02:48: 1008MHz  4.38 100%   0%  99%   0%   0%   0% 88.8°C  5/11
    16:02:57: 1104MHz  4.39 100%   0%  99%   0%   0%   0% 89.1°C  5/11
    16:03:04: 1104MHz  4.40 100%   0%  99%   0%   0%   0% 86.6°C  5/11
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    16:03:11: 1104MHz  4.37 100%   0%  99%   0%   0%   0% 87.1°C  5/11
    16:03:20: 1104MHz  4.39 100%   0%  99%   0%   0%   0% 86.1°C  5/11
    16:03:28: 1104MHz  4.36 100%   0%  99%   0%   0%   0% 85.6°C  5/11
    16:03:37: 1008MHz  4.38 100%   0%  99%   0%   0%   0% 92.5°C  7/11
    16:03:44: 1008MHz  4.35  99%   0%  99%   0%   0%   0% 93.6°C  7/11
    16:03:52: 1008MHz  4.37 100%   0%  99%   0%   0%   0% 94.6°C  7/11
    16:04:00: 1200MHz  4.38  99%   0%  99%   0%   0%   0% 93.6°C  7/11
    16:04:08: 1008MHz  4.35 100%   0%  99%   0%   0%   0% 83.5°C  7/11
    16:04:16: 1008MHz  4.37 100%   0%  99%   0%   0%   0% 93.0°C  7/11
    16:04:23: 1008MHz  4.34 100%   0%  99%   0%   0%   0% 92.9°C  7/11
    16:04:32: 1008MHz  4.36 100%   0%  99%   0%   0%   0% 92.9°C  7/11
    16:04:41: 1008MHz  4.38 100%   0%  99%   0%   0%   0% 93.9°C  5/11
    16:04:50: 1104MHz  4.40 100%   0%  99%   0%   0%   0% 91.1°C  5/11
    16:04:58: 1008MHz  4.36 100%   0%  99%   0%   0%   0% 93.8°C  7/11
    16:05:07: 1008MHz  4.38 100%   0%  99%   0%   0%   0% 93.9°C  7/11
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    16:05:14: 1008MHz  4.40  99%   0%  99%   0%   0%   0% 82.7°C  3/11
    16:05:21: 1008MHz  4.36 100%   0%  99%   0%   0%   0% 95.2°C  3/11
    16:05:30: 1008MHz  4.38 100%   0%  99%   0%   0%   0% 95.2°C  3/11
    16:05:37: 1008MHz  4.35 100%   0%  99%   0%   0%   0% 94.9°C  7/11
    16:05:44: 1008MHz  4.32 100%   0%  99%   0%   0%   0% 94.8°C  3/11
    16:05:52: 1008MHz  4.35 100%   0%  99%   0%   0%   0% 95.1°C  3/11
    16:06:01: 1008MHz  4.37 100%   0%  99%   0%   0%   0% 83.7°C  7/11
    16:06:09:  816MHz  4.34 100%   0%  99%   0%   0%   0% 94.9°C  9/11
    16:06:18:  816MHz  4.36 100%   0%  99%   0%   0%   0% 94.1°C  7/11
    16:06:26: 1200MHz  4.38 100%   0%  99%   0%   0%   0% 83.5°C  7/11
    16:06:35: 1008MHz  4.39 100%   0%  99%   0%   0%   0% 84.3°C  7/11
    16:06:44:  816MHz  4.36 100%   0%  99%   0%   0%   0% 95.9°C  7/11
    16:06:52: 1008MHz  4.38  99%   0%  99%   0%   0%   0% 83.7°C  7/11
    16:07:01: 1008MHz  4.39 100%   0%  99%   0%   0%   0% 84.2°C  3/11
    16:07:09: 1200MHz  4.36 100%   0%  99%   0%   0%   0% 94.3°C  3/11
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    16:07:18: 1008MHz  4.38 100%   0%  99%   0%   0%   0% 94.5°C  9/11
    16:07:27: 1008MHz  4.40 100%   0%  99%   0%   0%   0% 96.1°C  3/11
    16:07:35:  816MHz  4.41 100%   0%  99%   0%   0%   0% 95.4°C  3/11
    16:07:44:  816MHz  4.38 100%   0%  99%   0%   0%   0% 84.5°C  7/11
    16:07:53: 1200MHz  4.39 100%   0%  99%   0%   0%   0% 84.2°C  7/11
    16:08:01: 1200MHz  4.41 100%   0%  99%   0%   0%   0% 84.0°C  7/11
    16:08:10: 1008MHz  4.45 100%   0%  99%   0%   0%   0% 94.9°C  5/11
    16:08:18:  816MHz  4.46 100%   0%  99%   0%   0%   0% 84.2°C  3/11
    16:08:27: 1200MHz  4.46 100%   0%  99%   0%   0%   0% 94.6°C  9/11
    16:08:35: 1200MHz  4.46 100%   0%  99%   0%   0%   0% 96.4°C  3/11
    16:08:44: 1200MHz  4.43 100%   0%  99%   0%   0%   0% 94.5°C  3/11
    16:08:53:  816MHz  4.43 100%   0%  99%   0%   0%   0% 84.0°C  7/11
    16:09:01: 1008MHz  4.44 100%   0%  99%   0%   0%   0% 92.0°C  7/11
    16:09:09: 1008MHz  4.41  99%   0%  99%   0%   0%   0% 93.2°C  7/11
    16:09:16: 1008MHz  4.42 100%   0%  99%   0%   0%   0% 93.0°C  7/11
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    16:09:23: 1008MHz  4.38 100%   0%  99%   0%   0%   0% 93.6°C  7/11
    16:09:32: 1008MHz  4.40 100%   0%  99%   0%   0%   0% 93.5°C  7/11
    16:09:40: 1200MHz  4.41 100%   0%  99%   0%   0%   0% 95.1°C  3/11
    16:09:48: 1200MHz  4.38 100%   0%  99%   0%   0%   0% 94.3°C  7/11
    16:09:55: 1008MHz  4.39  99%   0%  99%   0%   0%   0% 94.8°C  7/11
    16:10:04: 1200MHz  4.36 100%   0%  99%   0%   0%   0% 94.2°C  7/11
    16:10:11:  816MHz  4.38  99%   0%  99%   0%   0%   0% 83.2°C  7/11
    16:10:19: 1008MHz  4.35 100%   0%  99%   0%   0%   0% 90.7°C  7/11
    16:10:28: 1008MHz  4.37 100%   0%  99%   0%   0%   0% 90.9°C  7/11
    16:10:34: 1008MHz  4.39  99%   0%  99%   0%   0%   0% 90.6°C  7/11
    16:10:41: 1008MHz  4.35 100%   0%  99%   0%   0%   0% 91.1°C  7/11
    16:10:50: 1008MHz  4.37 100%   0%  99%   0%   0%   0% 90.4°C  7/11
    16:10:57:  816MHz  4.34  99%   0%  99%   0%   0%   0% 94.9°C  3/11
    16:11:06: 1008MHz  4.36 100%   0%  99%   0%   0%   0% 84.2°C  7/11
    16:11:14: 1200MHz  4.33 100%   0%  99%   0%   0%   0% 92.7°C  7/11
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    16:11:21: 1008MHz  4.36 100%   0%  99%   0%   0%   0% 93.2°C  7/11
    16:11:30: 1104MHz  4.38 100%   0%  99%   0%   0%   0% 89.6°C  7/11
    16:11:38: 1200MHz  4.35 100%   0%  99%   0%   0%   0% 93.6°C  7/11
    16:11:45: 1008MHz  4.37  99%   0%  99%   0%   0%   0% 94.2°C  9/11
    16:11:54: 1008MHz  4.34 100%   0%  99%   0%   0%   0% 84.6°C  7/11
    16:12:01: 1008MHz  4.36 100%   0%  99%   0%   0%   0% 94.2°C  7/11
    16:12:08: 1200MHz  4.33 100%   0%  99%   0%   0%   0% 95.7°C  3/11
    16:12:17: 1008MHz  4.35 100%   0%  99%   0%   0%   0% 94.5°C  3/11
    16:12:25: 1200MHz  4.45 100%   0%  99%   0%   0%   0% 95.4°C  3/11
    16:12:33: 1200MHz  4.41 100%   0%  99%   0%   0%   0% 95.5°C  3/11
    16:12:42:  816MHz  4.42 100%   0%  99%   0%   0%   0% 94.6°C  3/11
    16:12:50:  816MHz  4.43 100%   0%  99%   0%   0%   0% 94.1°C  3/11
    16:12:59: 1008MHz  4.39 100%   0%  99%   0%   0%   0% 94.6°C  3/11
    16:13:07:  816MHz  4.41 100%   0%  99%   0%   0%   0% 95.5°C  3/11
    16:13:16: 1200MHz  4.42 100%   0%  99%   0%   0%   0% 94.9°C  7/11
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    16:13:23:  816MHz  4.39  99%   0%  99%   0%   0%   0% 85.1°C  7/11
    16:13:32: 1200MHz  4.40 100%   0%  99%   0%   0%   0% 84.5°C  3/11
    16:13:39: 1008MHz  4.41 100%   0%  99%   0%   0%   0% 92.5°C  7/11
    16:13:46: 1008MHz  4.38 100%   0%  99%   0%   0%   0% 94.1°C  7/11
    16:13:55: 1008MHz  4.35 100%   0%  99%   0%   0%   0% 84.3°C  7/11
    16:14:04: 1200MHz  4.37 100%   0%  99%   0%   0%   0% 83.3°C  7/11
    16:14:10: 1008MHz  4.39 100%   0%  99%   0%   0%   0% 94.8°C  7/11
    16:14:17: 1008MHz  4.35 100%   0%  99%   0%   0%   0% 91.4°C  7/11
    16:14:24: 1008MHz  4.33  99%   0%  99%   0%   0%   0% 90.7°C  5/11
    16:14:33: 1008MHz  4.35 100%   0%  99%   0%   0%   0% 91.1°C  5/11
    16:14:40: 1104MHz  4.37 100%   0%  99%   0%   0%   0% 89.6°C  5/11
    16:14:47: 1200MHz  4.34 100%   0%  99%   0%   0%   0% 84.2°C  9/11
    16:14:54: 1200MHz  4.36 100%   0%  99%   0%   0%   0% 83.9°C  3/11
    16:15:01: 1008MHz  4.33 100%   0%  99%   0%   0%   0% 94.2°C  7/11
    16:15:10: 1008MHz  4.30 100%   0%  99%   0%   0%   0% 84.6°C  3/11
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    16:15:18: 1008MHz  4.33 100%   0%  99%   0%   0%   0% 84.3°C  7/11
    16:15:25: 1200MHz  4.35 100%   0%  99%   0%   0%   0% 84.9°C  3/11
    16:15:32: 1200MHz  4.33 100%   0%  99%   0%   0%   0% 95.7°C  7/11
    16:15:39:  480MHz  4.03  37%   0%  37%   0%   0%   0% 61.1°C  0/11
    16:15:44:  480MHz  3.71   0%   0%   0%   0%   0%   0% 57.9°C  0/11
    16:15:49:  480MHz  3.41   0%   0%   0%   0%   0%   0% 56.4°C  0/11
    16:15:54:  480MHz  3.14   0%   0%   0%   0%   0%   0% 54.7°C  0/11
     

     

    I hope this helps!

  14. 1 hour ago, Igor said:

    I would say we remove revert and go with a mainline. Also possible to just wait since most of them are already changed https://groups.google.com/g/linux-sunxi and remove our patch once they reaches maineline?

     

    Yes, I agree - especially if this patch from @Icenowy makes it into the mainline: https://groups.google.com/g/linux-sunxi/c/QzBM7nciPLo.  We should wait for the dust to settle then can remove our revert patch and adapt the other DTs appropriately.  Thanks!

  15. @Igor I'd like to get your thoughts regarding this...:  The Realtek kernel change that caused this issue is indeed correct and good (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=bbc4d71d63549bcd003a430de18a72a742d8c91e), as it fixes the earlier invalid implementation in the kernel.  The failure problems with the RTL8812E occur with this change because "phy-mode" in the DT now matters and must be correct, whereas previously it did not.  By changing the "phy-mode" to "rgmii-id" correctly for sunxi boards that have the TXDLY and RXDLY pull-ups on the PHY, the RTL8812E is properly configured and works.  However this means that all of the relevant DTs need to be updated to correctly reflect their actual hardware configuration.

     

    I started making these changes in the patches in sunxi-dev, confirming the existence of the delay configuration pull-ups with the board schematics to determine the proper phy-mode to set, and removing my reversion patch.  However any boards that are missed will have Ethernet failures until the DTs are properly patched.  Should we just leave the reversion patch in instead (long-term)?

  16. For what it's worth, I'm not seeing any issues on a 256MB OrangePi R1 running 5.8.14-current (I only have a 512MB Pi Zero).  It works without issue - e.g.,

     

    root@orangepi-r1:~# uname -a
    Linux orangepi-r1 5.8.14-sunxi #trunk SMP Sun Oct 11 14:48:02 UTC 2020 armv7l GNU/Linux
    root@orangepi-r1:~# cpufreq-info -c 1
    cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
    Report errors and bugs to cpufreq@vger.kernel.org, please.
    analyzing CPU 1:
      driver: cpufreq-dt
      CPUs which run at the same hardware frequency: 0 1 2 3
      CPUs which need to have their frequency coordinated by software: 0 1 2 3
      maximum transition latency: 5.44 ms.
      hardware limits: 480 MHz - 1.01 GHz
      available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz
      available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
      current policy: frequency should be within 480 MHz and 1.01 GHz.
                      The governor "ondemand" may decide which speed to use
                      within this range.
      current CPU frequency is 480 MHz (asserted by call to hardware).
      cpufreq stats: 480 MHz:86.78%, 648 MHz:0.30%, 816 MHz:0.18%, 960 MHz:0.06%, 1.01 GHz:12.69%  (193)
    root@orangepi-r1:~# free
                  total        used        free      shared  buff/cache   available
    Mem:         243992       78052       79360        1936       86580      155792
    Swap:        121992           0      121992
    root@orangepi-r1:~# echo 0 > /sys/devices/system/cpu/cpu2/online
    root@orangepi-r1:~# apt-get update
    Hit:1 http://deb.debian.org/debian buster InRelease
    Hit:2 http://deb.debian.org/debian buster-updates InRelease
    Hit:3 http://deb.debian.org/debian buster-backports InRelease
    Hit:4 http://security.debian.org buster/updates InRelease
    Hit:5 https://armbian.systemonachip.net/apt buster InRelease
    Reading package lists... Done
    root@orangepi-r1:~# wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.8.14.tar.xz
    --2020-10-11 15:52:46--  https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.8.14.tar.xz
    Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:600::432, 2a04:4e42::432, 2a04:4e42:200::432, ...
    Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:600::432|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 114506716 (109M) [application/x-xz]
    Saving to: ‘linux-5.8.14.tar.xz’
    
    linux-5.8.14.tar.xz 100%[===================>] 109.20M  3.19MB/s    in 30s
    
    2020-10-11 15:53:17 (3.68 MB/s) - ‘linux-5.8.14.tar.xz’ saved [114506716/114506716]
    
    root@orangepi-r1:~# md5sum linux-5.8.14.tar.xz
    b4ed25c9a13f2ac90405b74da26e31d6  linux-5.8.14.tar.xz
    root@orangepi-r1:~# cat /sys/class/thermal/thermal_zone0/temp
    60297
    root@orangepi-r1:~#

     

    @maracuja Might it be possible to hook a serial console to the board, and then capture the output when your board freezes/crashes?  (It might also be interesting to try using Wi-Fi instead of Ethernet to eliminate that vector as a possibility?)

     

  17. 2 minutes ago, dolphs said:

    @5kft  - The image does build,  however the error @Werner mentioned earlier today is there compiling: 

    
    ./compile.sh BRANCH=dev RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no

     

    Please find attached patching.log, note the "wifi-brcmfmac-fix-txctl-credits.patch" that complains with:
    1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c.rej

     

     

     

    Yes, do a pull and try again - I just removed the offending patch as it was merged upstream in -rc6 :thumbup:

     

    (See https://github.com/armbian/build/commit/9637d3d0f94203a8ea18495d61090dbe202aeeaf)

     

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines