• Content count

  • Joined

  • Last visited

  1. That sounds gerat - and thanks for all the hard work!
  2. Hi Da Xue, thanks for pointing this out. Indeed LibreELEC for LePotato is currently on 3.14.29, and I really look forward to when mainline kernel is ready - or at least ready enough to support LibeELEC. Mainly the video hardware acceleration is the key in my eyes, since for a media center that's the key part. My biggest fear is, that Le Potato will share the fate of many SBC's and never reach maturity.
  3. OK, thanks for clarifying. So I'll go deeper and start debugging. Furtunately, I've got crash data output on the debug UART, this should make it possible to locate the code that actually causes the problem. Have never done this kind of debugging before, but since noone from the few LePotato-LibreELEC-developers currently is working on this bug, I think I need to learn myself :-)
  4. Hi TonyMac32, may I ask your assistance again? I've read myself into compiling LibeELEC myself, and was able to identify the corresponding code parts in the old kernel drivers. The patches you pointed me at could go in nearly unaltered, but unfortunately it does not solve the issue. As afar as I understand, the first patch you mention addresses problems with the EEE feature, while the second addresses unsuccessful auto negotiation. I switched off both features on my network switch, and also forced the adapter into a fixed state using ethtool, but all the time things fail. This is why I suspect that the patches are not the complete solution. Still, the current Armbian kernel is free of this problem, so a solution must exist. Do you have any idea where I might look for other modifications? Thanks!
  5. Hi TonyMac32, I can confirm that the problem is gone with the current kernel - thanks a lot and sorry again for bothering you with an old issue. For me that helps a lot, since I now know it's not my board but a known issue I can ask the LibreELEC team to have a look at.
  6. Did a manual paste from "armbianmonitor -U": https://pastebin.com/ty5ePBg3 Please note, I started 'armbianmonitor -c "$HOME"' (as suggested here: https://docs.armbian.com/User-Guide_Fine-Tuning/) but stopped that when I realized it will fill up my SD - so there's no output for taht in the paste. EDIT: Just note that maybe I used an older image... had quite some problems with monitor setup, and tried a few images... Sorry if I caused uneccessary work. Still, since LibreELEC builds suffer from this problem: Could you point me ant some details the LibeELEC developers could profit from? Thanks!
  7. Does not work: root@lepotato:~# armbianmonitor -u System diagnosis information will now be uploaded to <html> <head> <title>500 Internal Server Error</title> </head> <body> <h1>500 Internal Server Error</h1> The server has either erred or is incapable of performing the requested operation.<br /><br /> </body> </html>Please post the URL in the forum where you've been asked for. Will try again later...
  8. Dear all, first, as being new here: Many thanks to all the work that went into this! Now, here's my problem on Le Potato, which I have with armbian and LibreELEC: As soon as I copy anything large to any media, some services (SSH, Samba, Kodi, tvheadend - all of them network dependent) crash after writing something between 200 and 700 MB - not always at the same point. So anything like cp /some/huge/file /home/me crashes the services. Something like this: cp /some/huge/file /dev/null is no problem. I tried writing to SD as well as to USB, and I tried via network (scp from another machine into Le Potato) and locally (copying fom USB to SD, but still using ssh to run the command). Always crash. To make sure it's not an issue of LibreELEC, I now picked armbian (Ubuntu from here: https://www.armbian.com/lepotato/). And I did this instead of copy: #!/bin/bash LARGEFILE="/home/potato/largefile.txt" # Clean up any old file rm $LARGEFILE # Create a string of 4096 bytes MAKE4K="" for i in `seq 1 4096`; do MAKE4K="${MAKE4K}A" done # Write the 4096 byte string a million times --> 4G file for j in `seq 1 1000000`; do echo $MAKE4K >> $LARGEFILE done I SSH'd into the machine, started the script, and *boom* SSH down and out at about 250 MB written - all three sessions I had open. BUT: Script seems to keep running: Local console login survived, and file keeps growing, until it finally reached the target 4 GB. Closer inspection showed: ping --> destination unreachable ifdown eth0 ifup eth0 ping --> Success And ssh is possible again. So my conclusion would be: network stack somehow gets corrupted. /var/log/syslog does not show anything helpful. Any idea? Is this reproducible by others? Cheers