Jump to content

5kft

Members
  • Posts

    264
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Unfortunately I'm not an expert in RCU stalls (https://www.kernel.org/doc/Documentation/RCU/stallwarn.txt). Do you have other processes running on the device that could be impacting the system? E.g., what does "top" show while you try to use networking?
  2. It might be worth trying to reinstall the original posted -rc3 version again (esp. the dtb and image debs), just to see if that helps? (Just force an install via dpkg -i *.deb)
  3. This problem sounds like this issue: https://github.com/armbian/build/issues/2315
  4. @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).
  5. 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).
  6. 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.
  7. 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: 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?
  8. 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
  9. I actually tried both - Debian works fine (as you noted), but Focal crashes just like I was seeing yesterday:
  10. Glad it is working for you, but very curious indeed! Edit: I tried on another NEO2, and indeed 4.9.5 works fine . 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!
  11. 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: 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!
  12. Yes, added appropriate pre-merge tags for both -current and -dev. (Interestingly, at least at present, the delta between 5.9.x and 5.10.x is tiny.)
  13. @Igor, kernel 5.8 has gone EOL with 5.8.18...should we look at moving 5.9 to -current? It's easy enough to move sunxi-dev to 5.10 (and it works quite well). Interested in your thoughts.
  14. 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 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.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines