Jump to content

Search the Community

Showing results for tags 'helios4'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Community
    • Announcements
    • Feature Requests
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Upcoming Hardware (WIP)
    • News
    • Odroid M1
    • ROCK 5B
    • Orange Pi 5
  • Maintained Hardware
    • Board does not start
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Unmaintained (CSC/EOL/TVB) / Other
    • TV boxes
    • Off-topic
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP/Jabber


Skype


Github


Discord


Location


Interests

  1. After upgrading to the 5.15 kernel, I noticed that the fan control is only able to control one of the fans, while the other spins at full speed. Experimentally I found out that the PWM control for the second fan is ineffective: helios4# uname -r 5.15.86-mvebu helios4# echo 0 > /dev/fan-j10/pwm1 # works, fan is off helios4# echo 255 > /dev/fan-j10/pwm1 # works, fan at full speed helios4# echo 0 > /dev/fan-j17/pwm1 # does nothing, full speed helios4# echo 255 > /dev/fan-j17/pwm1 # does nothing, full speed Some digging around I found that 92-mvebu-gpio-remove-hardcoded-timer-assignment.patch has been ported to 5.15, but it doesn't seem to work for me.
  2. Hello everyone! After my Helios4 had been laying in a cardboard box for a long time after moving houses, I decided it was time to once again set it up as an NAS. I was previously running Open Media Vault (OMV) with 4 disks in xfs and using MergerFS for unionizing three of them at a single mount point and then using Snapraid for the fourth disk. OMV worked pretty well for me but I go somewhat irritated from time to times because how it decides to thing in it's own way. But now I when I re-installed it (after getting a new PSU) I went with Armbian instead to keep it closer to "standard" linux. I think I will still go with MerverFS and Snapraid this time also but I also wonder what you guys and gals are using! For example: - What filesystem are you using? xfs, btrfs or maybe zfs? - Are you running raid, mergerfs or something else? - How are making the storage avalible to other hosts? NFS, SSHFS? - Are you running some kind of admin UI to manage your Helios?
  3. I've been having issues with my Helios4 becoming unresponsive when it's been up for a while. I decided to do some more thorough investigating and found that it was having problems writing to the sdcard. That led to the following entries in syslog: Dec 20 21:36:43 helios-backup kernel: [318645.034243] mmc0: Timeout waiting for hardware interrupt. Dec 20 21:36:43 helios-backup kernel: [318645.034254] mmc0: sdhci: ============ SDHCI REGISTER DUMP =========== Dec 20 21:36:43 helios-backup kernel: [318645.034258] mmc0: sdhci: Sys addr: 0x00000008 | Version: 0x00000202 Dec 20 21:36:43 helios-backup kernel: [318645.034263] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000001 Dec 20 21:36:43 helios-backup kernel: [318645.034267] mmc0: sdhci: Argument: 0x0084a0d0 | Trn mode: 0x0000002b Dec 20 21:36:43 helios-backup kernel: [318645.034271] mmc0: sdhci: Present: 0x01e60006 | Host ctl: 0x00000017 Dec 20 21:36:43 helios-backup kernel: [318645.034274] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000000 Dec 20 21:36:43 helios-backup kernel: [318645.034278] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00000207 Dec 20 21:36:43 helios-backup kernel: [318645.034282] mmc0: sdhci: Timeout: 0x0000000e | Int stat: 0x00000000 Dec 20 21:36:43 helios-backup kernel: [318645.034285] mmc0: sdhci: Int enab: 0x03ff000b | Sig enab: 0x03ff000b Dec 20 21:36:43 helios-backup kernel: [318645.034289] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 Dec 20 21:36:43 helios-backup kernel: [318645.034292] mmc0: sdhci: Caps: 0x25fcc8b2 | Caps_1: 0x00002f77 Dec 20 21:36:43 helios-backup kernel: [318645.034296] mmc0: sdhci: Cmd: 0x0000193a | Max curr: 0x00000000 Dec 20 21:36:43 helios-backup kernel: [318645.034299] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0x00000000 Dec 20 21:36:43 helios-backup kernel: [318645.034303] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000900 Dec 20 21:36:43 helios-backup kernel: [318645.034306] mmc0: sdhci: Host ctl2: 0x00000000 Dec 20 21:36:43 helios-backup kernel: [318645.034309] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x78275208 Dec 20 21:36:43 helios-backup kernel: [318645.034313] mmc0: sdhci: ============================================ Dec 20 21:36:46 helios-backup kernel: [318648.042018] mmc0: Card stuck being busy! __mmc_poll_for_busy Dec 20 21:36:48 helios-backup kernel: [318649.277911] mmc0: card never left busy state Dec 20 21:36:48 helios-backup kernel: [318649.277918] mmc0: tried to HW reset card, got error -110 Dec 20 21:36:48 helios-backup kernel: [318649.277923] mmcblk0: recovery failed! Dec 20 21:36:48 helios-backup kernel: [318649.277947] blk_update_request: I/O error, dev mmcblk0, sector 8691920 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 Dec 20 21:36:48 helios-backup kernel: [318649.277958] EXT4-fs warning (device mmcblk0p1): ext4_end_bio:348: I/O error 10 writing to inode 382819 starting block 1086491) Is it possible this is due to the power supply starting to go bad? I haven't yet tried using different sdcards, but that would be my next step. Has anyone else seen this?
  4. Helios4 can boot directly from the sata disk nr 1, without the need to switch from the SD or the eMMC. I personally tried setting SW1 to 11100 and using u-boot-sata for Clearfog, which shares the same uSOM and the system booted regularly, obviously the system didn't recognize many devices being u-boot for another board. I tried to compile a version of u-boot for sata trying to integrate the changes present in https://solidrun.atlassian.net/wiki/spaces/developer/pages/287212134/A38X+U-Boot in the U-boot build instruction and sources for Helios4 present in the Kobol Wiki but my skills are not sufficient for such a job. In the binaries available for Helios4 at https://imola.armbian.com/beta/pool/main/l/linux-u-boot-helios4-current/ there are only u-boots for uart, flash and mmc. Would it be possible to have the sata version in future releases? Thanks in advance and for all the work done.
  5. Straightforward! See signature. Thanks to the team.
  6. After upgrade to version 5.15.72, fancontrol service fails to start, due to missing /dev/fan-j17 There is some information in dmesg: pwm-fan j17-pwm: error -EBUSY: Could not get PWM
  7. For marvell-mvebu build DRBD is not supported, the module is missing in either current and edge config a grep of CONFIG_BLK_DEV_DRBD in build/config/kernel from the git build repo shows that most boards have DRBD compiled as module except some few exceptions. One of these few exception is mvebu (ClearFog Base/Pro, ESPRESSObin, Helios 4). I don't understand why. DRBD is a very nice and secure block device which provides network block replication (raid over network), and it is widely used. DRDB compile and work flawlessly on helios4 with the mvebu kernel. But we are obliged to compile the kernel or only the module, which is somewhat painful. As I have an helios4 which provides a DRBD node, I first compiles three years ago the module using the current kernel headers,. Then I refrained from updating since I was needing this DRDB node. But now I need to update to buster, so I updated to the current branch. Of course I lost my DRBD device, and so I compiled a home made kernel. This is now technically very easy with the new build environment and docker. compile.sh and the associated set of bash scripts are very handy and well conceived. Thank you for the developers who did this work. But with my servers t has been nevertheless very long and painful. I have only low power servers, and my gateway upper download rate is 300KB. So when I tried the script it could not download anything, I found that it gives to aria2c a lowest speed limit of 500K, so no hope to download something on my network. I tried to change this limit. I tried many value, usually I could down load at 220K, but it seems that the speed can slow down during short period of time, so my downloads aborted. I had to reduce this minimal speed to 70KB to be able to download the software. Then I compiled the kernel 14h of compilation on my machine! Next time I will try either to launch a temporary instance on a VPS with better bandwidth, and/or install DISTCC, but I have never tried discc in docker, and I have to learn. Now running current-mvebu_22.11.0-trunk with kernel 5.15.76, drbd works flawlessly on helios4. But for next release I strongly wish that it would be incorporated in the distribution. I think it could be useful for people looking fr a server to support a drbd node. But how to request it, posting in the github issues? doing a PR seems quite overkill to just replace 'n' by 'm' in CONFIG_BLK_DEV_DRBD.
  8. Hi All, I'm a happy user of a Helios4, and have been for several years now. However, at some point it will be challenging to continue to support it, and I'd rather be proactive about maintaining access to my data than scrambling around. Do people here have recommendations on current hardware that can replace the Helios4? It would need to meet the baseline hardware requirements of the existing hardware. Bonus points if one can re-use the laser-cut case Thanks!
  9. System successfully upgraded. No problems detected (so far). Thanks to the team.
  10. Hey, the last time my Helios4's PSU blew I suspect was due to a power overload, with the PSU not being able to deal with all 4 HDDs doing active work (this also killed one of the HDDs in my array). Based on the system log, it looked like the system was doing a regular integrity checks on all 4 HDDs at once (!). I would like to either disable the integrity check altogether, or more ideally, spread it out. I have two RAID-1 arrays, and there is no reason for all four drives to be checked simultaneously. For example, I can check one of the arrays (two HDDs) and then once that is done, the second array (the other two HDDs) after. Does anyone know where the code/script for the integrity check lives? The closest I found was /etc/cron.daily/mdadm which runs mdadm --monitor --scan --oneshot but from the manpage description it is unclear to me whether that is superficial check or that may actually invoke a deep and lengthy integrity check.
  11. Hi, after some time on storage i tried to reativate my batch 2 helios4 only to be greeted with a seemingly broken device. Tried the following: 1. Flashed a new good SD Card with Armbian (golden sundisk one) 2. unplugged all harddisks in my helios 4 3. inserted SD-Card and plugged in in. Result: Orange blinking on the Network Port Green blinking next to the Power slow USB-TTY does not show up Tt does not boot I hear a slight chirping noise synchronous with the green LED. It comes directly from the board not the fans, harddisks or PSU. Sounds like a fan briefly rubbing against something but it's comming 100% certain from the board. Is my Helios4 broken? That would be absolutely saddening because theres no ECC Memory Replacement available. Any Ideas?
  12. Hello all, This seems to be an issue related to the python script to start the program, any help will be appreciated for those with python programming understanding: $ sudo systemctl status sys-oled.service * sys-oled.service - System Starting on OLED Display Loaded: loaded (/etc/systemd/system/sys-oled.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2021-09-17 02:22:42 JST; 10s ago Process: 4425 ExecStart=/usr/bin/python3 /usr/local/bin/sys-oled --display ${display_model} (code=exited, status=1/FAILURE) Main PID: 4425 (code=exited, status=1/FAILURE) Sep 17 02:22:42 nas python3[4425]: main() Sep 17 02:22:42 nas python3[4425]: File "/usr/local/bin/sys-oled", line 132, in main Sep 17 02:22:42 nas python3[4425]: display_info(device) Sep 17 02:22:42 nas python3[4425]: File "/usr/local/bin/sys-oled", line 105, in display_info Sep 17 02:22:42 nas python3[4425]: draw.text((0, 0), cpu_usage(), font=font, fill="white") Sep 17 02:22:42 nas python3[4425]: File "/usr/local/bin/sys-oled", line 78, in cpu_usage Sep 17 02:22:42 nas python3[4425]: temp = psutil.sensors_temperatures()['f10e4078.thermal'] Sep 17 02:22:42 nas python3[4425]: KeyError: 'f10e4078.thermal' Sep 17 02:22:42 nas systemd[1]: sys-oled.service: Main process exited, code=exited, status=1/FAILURE Sep 17 02:22:42 nas systemd[1]: sys-oled.service: Failed with result 'exit-code'. Thank you in advance for any hints or recommendations about how to solve this. Sincerely,
  13. This is with armbian 22.02 bullseye. phross@helios4:~$ uname -a Linux helios4 5.15.26-mvebu #trunk.0002 SMP Thu Mar 3 10:15:53 UTC 2022 armv7l GNU/Linux phross@helios4:~$ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 0.00 ms. analyzing CPU 1: no or unknown cpufreq driver is active on this CPU maximum transition latency: 0.00 ms. I remember reading discussions about issues with cpufreq patches causing issues on armada-38x socs. Is the cpufreq driver for armada-388 still not working?
  14. Hi, I have a Armbian 22.02.1 with Linux 5.10.60-mvebu with buster debian packages. Its possible to update bullseye a not lost my storage raids?
  15. Hello, I know that Kobol is out of Business.. But I am thinking...what if my helios4 motherboard die...? To mitigate that, I want to acquire new motherboard. Does any one knows how I could get one? Thanks in Advance
  16. Hi all, I got my helios4 sometimes in 2019 and it was one of the best purchases I ever made. It has served and was solid as a rock. Unfortunately all that ended couple of days ago when I noticed the Helios was not powering up properly, think it was the power supply not connected well (because I just recently changed the location) I removed and fitted the PSU a couple of times, I could see the led light come on but still it would not boot properly. By the time I found out what the real problem is things had gone worse, the reason for the incomplete boot was the SD card has been removed. Unfortunately, it seems my constant removing and refitting the PSU to the board most have done some damage because right now the board has refused to come on. I used a multi-meter to check the reading from the PSU and it is constantly at 12.5v but the molex for the sata is are all completely 0v. Same for the fan ground and 12v pin for the Fan male header. Curious enough, the control and sense pin out for the FAN reads about 4v. This is pretty much the only thing I was able to get reading from. Rest of the board just seem dead, no LED, no indication whatsoever that PSU is connected to the board. I am aware that the PSU was one of the weak side of the Helios4, But like I said, the pin out of the PSU reads 12.5v so I am thinking maybe this is an issue with a blown mosfet? I am a total newb when it comes to computer hardware. There are no device out there (arm based and DIY) That comes close to the Helios so I am pretty much stuck. Any advise on how to troubleshoot this would be very much welcome.
  17. The board was up and running when suddenly I could not access the share anymore. I went near it and I was hearing some HDD clicking. I rebooted it from the console and when it came on, no storage was available. I could see some /dev/sd* but one HDD was missing from it and the lvm was not available anymore. Also all the HDDs where clicking and I was hearing a loud buzzing sound from the board. I rebooted it again, measured the PSU and even load tested it and it is fine, the same for the moled connectors, it was measuring 12V and 5V, but the truth was, the HDDs this time were not even detected. Took it all apart and booted it without any HDD connected and surprise, it no longer boots. It's missing now the 5V from the molex. What is the reference for the small IC responsible for creating the 5V for the HDDs? does it has any impact in the board booting? or was the CPU board killed somehow in the process? I measured the two coils near the CPU module and i see there 5V and 3.3V I tested all the HDDs in a pc bbefore measuring voltages, and all of them are fine. Thank you. .
  18. 4 2.5" HDDs. [ 1242.509097] BTRFS info (device sda): scrub: started on devid 1 [ 1242.560838] BTRFS info (device sda): scrub: started on devid 4 [ 1242.615578] BTRFS info (device sda): scrub: started on devid 3 [ 1242.703587] BTRFS info (device sda): scrub: started on devid 2 [ 3731.573257] ata2.00: exception Emask 0x0 SAct 0xffffffff SErr 0x0 action 0x0 [ 3731.573272] ata2.00: irq_stat 0x40000001 [ 3731.573279] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573283] ata2.00: cmd 60/80:00:00:2f:2b/00:00:03:00:00/40 tag 0 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573300] ata2.00: status: { DRDY ERR } [ 3731.573306] ata2.00: error: { UNC } [ 3731.573311] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573315] ata2.00: cmd 60/80:08:00:3b:2b/00:00:03:00:00/40 tag 1 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573331] ata2.00: status: { DRDY ERR } [ 3731.573336] ata2.00: error: { UNC } [ 3731.573342] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573346] ata2.00: cmd 60/80:10:00:3d:2b/00:00:03:00:00/40 tag 2 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573361] ata2.00: status: { DRDY ERR } [ 3731.573365] ata2.00: error: { UNC } [ 3731.573371] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573375] ata2.00: cmd 60/80:18:00:3f:2b/00:00:03:00:00/40 tag 3 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573390] ata2.00: status: { DRDY ERR } [ 3731.573395] ata2.00: error: { UNC } [ 3731.573400] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573404] ata2.00: cmd 60/80:20:00:5f:2b/00:00:03:00:00/40 tag 4 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573419] ata2.00: status: { DRDY ERR } [ 3731.573423] ata2.00: error: { UNC } [ 3731.573429] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573433] ata2.00: cmd 60/80:28:00:63:2b/00:00:03:00:00/40 tag 5 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573448] ata2.00: status: { DRDY ERR } [ 3731.573452] ata2.00: error: { UNC } [ 3731.573458] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573461] ata2.00: cmd 60/80:30:00:6d:2b/00:00:03:00:00/40 tag 6 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573477] ata2.00: status: { DRDY ERR } [ 3731.573481] ata2.00: error: { UNC } [ 3731.573486] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573490] ata2.00: cmd 60/80:38:80:76:27/00:00:02:00:00/40 tag 7 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573505] ata2.00: status: { DRDY ERR } [ 3731.573510] ata2.00: error: { UNC } [ 3731.573515] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573519] ata2.00: cmd 60/80:40:80:78:27/00:00:02:00:00/40 tag 8 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573534] ata2.00: status: { DRDY ERR } [ 3731.573538] ata2.00: error: { UNC } [ 3731.573543] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573547] ata2.00: cmd 60/80:48:80:7a:27/00:00:02:00:00/40 tag 9 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573562] ata2.00: status: { DRDY ERR } [ 3731.573567] ata2.00: error: { UNC } [ 3731.573572] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573576] ata2.00: cmd 60/80:50:80:7c:27/00:00:02:00:00/40 tag 10 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573591] ata2.00: status: { DRDY ERR } [ 3731.573595] ata2.00: error: { UNC } [ 3731.573601] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573604] ata2.00: cmd 60/80:58:80:7e:27/00:00:02:00:00/40 tag 11 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573620] ata2.00: status: { DRDY ERR } [ 3731.573624] ata2.00: error: { UNC } [ 3731.573629] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573633] ata2.00: cmd 60/80:60:80:80:27/00:00:02:00:00/40 tag 12 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573648] ata2.00: status: { DRDY ERR } [ 3731.573653] ata2.00: error: { UNC } [ 3731.573658] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573662] ata2.00: cmd 60/80:68:80:82:27/00:00:02:00:00/40 tag 13 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573678] ata2.00: status: { DRDY ERR } [ 3731.573682] ata2.00: error: { UNC } [ 3731.573687] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573691] ata2.00: cmd 60/80:70:80:84:27/00:00:02:00:00/40 tag 14 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573706] ata2.00: status: { DRDY ERR } [ 3731.573711] ata2.00: error: { UNC } [ 3731.573716] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573720] ata2.00: cmd 60/80:78:80:86:27/00:00:02:00:00/40 tag 15 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573735] ata2.00: status: { DRDY ERR } [ 3731.573740] ata2.00: error: { UNC } [ 3731.573745] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573748] ata2.00: cmd 60/80:80:80:88:27/00:00:02:00:00/40 tag 16 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573764] ata2.00: status: { DRDY ERR } [ 3731.573768] ata2.00: error: { UNC } [ 3731.573773] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573777] ata2.00: cmd 60/80:88:80:8a:27/00:00:02:00:00/40 tag 17 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573792] ata2.00: status: { DRDY ERR } [ 3731.573797] ata2.00: error: { UNC } [ 3731.573802] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573806] ata2.00: cmd 60/80:90:80:8c:27/00:00:02:00:00/40 tag 18 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573821] ata2.00: status: { DRDY ERR } [ 3731.573825] ata2.00: error: { UNC } [ 3731.573830] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573834] ata2.00: cmd 60/80:98:80:8e:27/00:00:02:00:00/40 tag 19 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573849] ata2.00: status: { DRDY ERR } [ 3731.573854] ata2.00: error: { UNC } [ 3731.573859] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573863] ata2.00: cmd 60/80:a0:80:90:27/00:00:02:00:00/40 tag 20 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573878] ata2.00: status: { DRDY ERR } [ 3731.573883] ata2.00: error: { UNC } [ 3731.573888] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573891] ata2.00: cmd 60/80:a8:80:92:27/00:00:02:00:00/40 tag 21 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573906] ata2.00: status: { DRDY ERR } [ 3731.573911] ata2.00: error: { UNC } [ 3731.573916] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573920] ata2.00: cmd 60/80:b0:80:94:27/00:00:02:00:00/40 tag 22 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573935] ata2.00: status: { DRDY ERR } [ 3731.573939] ata2.00: error: { UNC } [ 3731.573944] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573948] ata2.00: cmd 60/80:b8:80:96:27/00:00:02:00:00/40 tag 23 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573963] ata2.00: status: { DRDY ERR } [ 3731.573968] ata2.00: error: { UNC } [ 3731.573973] ata2.00: failed command: READ FPDMA QUEUED [ 3731.573977] ata2.00: cmd 60/80:c0:80:9a:27/00:00:02:00:00/40 tag 24 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.573992] ata2.00: status: { DRDY ERR } [ 3731.573996] ata2.00: error: { UNC } [ 3731.574001] ata2.00: failed command: READ FPDMA QUEUED [ 3731.574005] ata2.00: cmd 60/80:c8:80:9c:27/00:00:02:00:00/40 tag 25 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.574020] ata2.00: status: { DRDY ERR } [ 3731.574025] ata2.00: error: { UNC } [ 3731.574030] ata2.00: failed command: READ FPDMA QUEUED [ 3731.574034] ata2.00: cmd 60/80:d0:00:e2:f6/00:00:05:00:00/40 tag 26 ncq dma 65536 in res 41/40:80:30:e2:f6/00:00:05:00:00/40 Emask 0x409 (media error) <F> [ 3731.574049] ata2.00: status: { DRDY ERR } [ 3731.574054] ata2.00: error: { UNC } [ 3731.574059] ata2.00: failed command: READ FPDMA QUEUED [ 3731.574063] ata2.00: cmd 60/80:d8:80:2a:27/00:00:02:00:00/40 tag 27 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.574078] ata2.00: status: { DRDY ERR } [ 3731.574082] ata2.00: error: { UNC } [ 3731.574087] ata2.00: failed command: READ FPDMA QUEUED [ 3731.574091] ata2.00: cmd 60/80:e0:80:66:27/00:00:02:00:00/40 tag 28 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.574107] ata2.00: status: { DRDY ERR } [ 3731.574111] ata2.00: error: { UNC } [ 3731.574116] ata2.00: failed command: READ FPDMA QUEUED [ 3731.574120] ata2.00: cmd 60/80:e8:80:72:27/00:00:02:00:00/40 tag 29 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.574135] ata2.00: status: { DRDY ERR } [ 3731.574140] ata2.00: error: { UNC } [ 3731.574145] ata2.00: failed command: READ FPDMA QUEUED [ 3731.574149] ata2.00: cmd 60/80:f0:00:21:2b/00:00:03:00:00/40 tag 30 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.574164] ata2.00: status: { DRDY ERR } [ 3731.574168] ata2.00: error: { UNC } [ 3731.574173] ata2.00: failed command: READ FPDMA QUEUED [ 3731.574177] ata2.00: cmd 60/80:f8:80:98:27/00:00:02:00:00/40 tag 31 ncq dma 65536 in res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error) [ 3731.574192] ata2.00: status: { DRDY ERR } [ 3731.574196] ata2.00: error: { UNC } [ 3731.576554] ata2.00: configured for UDMA/100 [ 3731.576609] sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s [ 3731.576617] sd 1:0:0:0: [sdb] tag#0 Sense Key : 0x3 [current] [ 3731.576622] sd 1:0:0:0: [sdb] tag#0 ASC=0x11 ASCQ=0x4 [ 3731.576629] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 03 2b 2f 00 00 00 80 00 [ 3731.576633] blk_update_request: I/O error, dev sdb, sector 53161728 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0 [ 3731.576689] sd 1:0:0:0: [sdb] tag#1 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s [ 3731.576696] sd 1:0:0:0: [sdb] tag#1 Sense Key : 0x3 [current] [ 3731.576701] sd 1:0:0:0: [sdb] tag#1 ASC=0x11 ASCQ=0x4 [ 3731.576707] sd 1:0:0:0: [sdb] tag#1 CDB: opcode=0x28 28 00 03 2b 3b 00 00 00 80 00 [ 3731.576711] blk_update_request: I/O error, dev sdb, sector 53164800 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0 [ 3731.576741] sd 1:0:0:0: [sdb] tag#2 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s [ 3731.576747] sd 1:0:0:0: [sdb] tag#2 Sense Key : 0x3 [current] [ 3731.576752] sd 1:0:0:0: [sdb] tag#2 ASC=0x11 ASCQ=0x4 [ 3731.576758] sd 1:0:0:0: [sdb] tag#2 CDB: opcode=0x28 28 00 03 2b 3d 00 00 00 80 00 [ 3731.576761] blk_update_request: I/O error, dev sdb, sector 53165312 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0 [ 3731.576791] sd 1:0:0:0: [sdb] tag#3 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s [ 3731.576797] sd 1:0:0:0: [sdb] tag#3 Sense Key : 0x3 [current] [ 3731.576803] sd 1:0:0:0: [sdb] tag#3 ASC=0x11 ASCQ=0x4 [ 3731.576808] sd 1:0:0:0: [sdb] tag#3 CDB: opcode=0x28 28 00 03 2b 3f 00 00 00 80 00 [ 3731.576811] blk_update_request: I/O error, dev sdb, sector 53165824 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0 [ 3731.576842] sd 1:0:0:0: [sdb] tag#4 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s [ 3731.576849] sd 1:0:0:0: [sdb] tag#4 Sense Key : 0x3 [current] [ 3731.576854] sd 1:0:0:0: [sdb] tag#4 ASC=0x11 ASCQ=0x4 [ 3731.576860] sd 1:0:0:0: [sdb] tag#4 CDB: opcode=0x28 28 00 03 2b 5f 00 00 00 80 00 [ 3731.576863] blk_update_request: I/O error, dev sdb, sector 53174016 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0 [ 3731.576891] sd 1:0:0:0: [sdb] tag#5 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s [ 3731.576898] sd 1:0:0:0: [sdb] tag#5 Sense Key : 0x3 [current] [ 3731.576903] sd 1:0:0:0: [sdb] tag#5 ASC=0x11 ASCQ=0x4 [ 3731.576908] sd 1:0:0:0: [sdb] tag#5 CDB: opcode=0x28 28 00 03 2b 63 00 00 00 80 00 [ 3731.576912] blk_update_request: I/O error, dev sdb, sector 53175040 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0 [ 3731.576947] sd 1:0:0:0: [sdb] tag#6 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s [ 3731.576954] sd 1:0:0:0: [sdb] tag#6 Sense Key : 0x3 [current] [ 3731.576959] sd 1:0:0:0: [sdb] tag#6 ASC=0x11 ASCQ=0x4 [ 3731.576965] sd 1:0:0:0: [sdb] tag#6 CDB: opcode=0x28 28 00 03 2b 6d 00 00 00 80 00 [ 3731.576968] blk_update_request: I/O error, dev sdb, sector 53177600 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0 [ 3731.576997] sd 1:0:0:0: [sdb] tag#7 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s [ 3731.577003] sd 1:0:0:0: [sdb] tag#7 Sense Key : 0x3 [current] [ 3731.577008] sd 1:0:0:0: [sdb] tag#7 ASC=0x11 ASCQ=0x4 [ 3731.577014] sd 1:0:0:0: [sdb] tag#7 CDB: opcode=0x28 28 00 02 27 76 80 00 00 80 00 [ 3731.577017] blk_update_request: I/O error, dev sdb, sector 36140672 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0 [ 3731.577043] sd 1:0:0:0: [sdb] tag#8 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s [ 3731.577050] sd 1:0:0:0: [sdb] tag#8 Sense Key : 0x3 [current] [ 3731.577055] sd 1:0:0:0: [sdb] tag#8 ASC=0x11 ASCQ=0x4 [ 3731.577060] sd 1:0:0:0: [sdb] tag#8 CDB: opcode=0x28 28 00 02 27 78 80 00 00 80 00 [ 3731.577064] blk_update_request: I/O error, dev sdb, sector 36141184 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0 [ 3731.577086] sd 1:0:0:0: [sdb] tag#9 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s [ 3731.577092] sd 1:0:0:0: [sdb] tag#9 Sense Key : 0x3 [current] [ 3731.577097] sd 1:0:0:0: [sdb] tag#9 ASC=0x11 ASCQ=0x4 [ 3731.577103] sd 1:0:0:0: [sdb] tag#9 CDB: opcode=0x28 28 00 02 27 7a 80 00 00 80 00 [ 3731.577106] blk_update_request: I/O error, dev sdb, sector 36141696 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0 [ 3731.577293] ata2: EH complete [ 5747.007408] BTRFS warning (device sda): checksum error at logical 145793888256 on dev /dev/sdb, physical 49304711168, root 1094, inode 157635, offset 150896640, length 4096, links 1 (path: volumes/quassel-config/_data/quassel-storage.sqlite) [ 5747.007434] BTRFS error (device sda): bdev /dev/sdb errs: wr 12, rd 83, flush 0, corrupt 7, gen 0 [ 5747.117543] BTRFS error (device sda): unable to fixup (regular) error at logical 145793888256 on dev /dev/sdb [ 7435.261454] BTRFS info (device sda): scrub: not finished on devid 3 with status: -125 [ 7435.261491] BTRFS info (device sda): scrub: not finished on devid 1 with status: -125 [ 7435.261512] BTRFS info (device sda): scrub: not finished on devid 2 with status: -125 [ 7435.261734] BTRFS info (device sda): scrub: not finished on devid 4 with status: -125 The end is me stopping the scrub. Is this an indication that the power supply needs replacing? edit: Maybe the hard drive instead...
  19. I'm using Armbian 21.08.8 (Bullseye). I want to upgrade to Armbian 22.02.1 but "apt-get update" doesn't offer anything. Reason seems to be that <mirror>/apt/dists is from Feb 1st 2022. OTOH <mirror>/dl contains the new release but "starting from scratch" (download image, write SDcard) implies that I have to rebuild my OMV6 on top of Armbian. Question: When can I expect that <mirror>/apt/dists will be refreshed? Or is there any other way to upgrade my installation?
  20. I was trying get sys-oled running on a new installation (upgrade, really) of bullseye. If go with the original Kobol github version, https://github.com/kobol-io/sys-oled, it fails to build RPI.GPIO and something else. I also found an alternate at https://github.com/rpardini/sys-oled-hc4, that builds, but when I run it, it complains about a thermal call in python: # sys-oled --display sh1106 Traceback (most recent call last): File "/usr/local/bin/sys-oled", line 142, in <module> main() File "/usr/local/bin/sys-oled", line 132, in main display_info(device) File "/usr/local/bin/sys-oled", line 105, in display_info draw.text((0, 0), cpu_usage(), font=font, fill="white") File "/usr/local/bin/sys-oled", line 78, in cpu_usage temp = psutil.sensors_temperatures()['cpu_thermal'] KeyError: 'cpu_thermal' I opened an issue with the Kobol github, but I don't anticipate much in the way of results there. `rpardini` doesn't appear to be able to accept issues. Has anyone had any success with getting this running in bullseye?
  21. Hello! I have connected the WD 10TB RED HDD via external USB 3.0 enclosure to one of the USB 3.0 Ports on the HELIOS4. Unfortunately the speeds don't exceed 45 MB/s. when running RSYNC jobs. On the PC I can completely use the speed of the GBit Port.. When connected to the USB Ports of HELIOS4 the speeds are low. Can somebody help? The external enclosure is from UGREEN. HDD is NTFS formatted. Any advice will be gratefully appreciated.
  22. Wanted to share my unfortunate experience today of trying to do a fresh install of a newer armbian version in order to accommodate OMV 5 on my Helios4. Was doing everything as usual and after the first boot from the new SD card tried to run armbian-config while still attached to the serial console. That proved to be a mistake as it started some auto install script type of thing and wiped one of my hard drives. Also the GUI wasn't showing properly. The exact same thing happened when I tried to reproduce the same steps. Should have been wiser and connected via SSH after inital boot to go from there. No such thing happened when running armbian-config via SSH for the first time. I am running Mac OS Big Sur and have the 1.4.7 FTDI VCP beta driver installed. The command I was running to connect was screen /dev/tty.usbserial-X 115200 -L. Fortunately the drive that was wiped was a redundancy drive.
  23. It's been a while I have on my TODO list : write a guide on how to activate and use the Marvell Cryptographic Engines And Security Accelerator (CESA) on Helios4. Previously I already shared some numbers related to the CESA engine while using @tkaiser sbc-bench tool. I also shared some findings on the openssl support for the kernel modules (cryptodev and af_alg) that interact with the cesa engine. My conclusion was : 1. performance wise : effectively cryptodev performs slightly better than af_alg. 2. openssl / libssl support : very messy and broken, it all depends which version of openssl you use. Since many Debian Stretch apps depend on "old" libssl (1.0.2), I felt taking the cryptodev approach was the best way since it could expose all encryption and authentication algorithms supported by the cesa engine... even though it requires some patching in openssl. Plus cryptodev implementation in new LTS openssl version 1.1.1 has been completely reworked, so long term it should be the right way. Anyhow I'm not going to describe here the step by step setup, I'm already writing a page on our wiki for that, once it's ready I will post the link here. Also I won't risk myself talking about the relevance of some of ciphers, it deserves a topic on its own. I'm just going to share benchmark number on a concrete use case which is HTTPS file download : So I setup on my Helios4 Apache2 to serve a 1GB file hosted on a SSD drive. Then I did 3 batch of download tests, for each batch I configured Apache2 to use a specific cipher that I know is supported by the cesa engine. AES_128_CBC_SHA AES_128_CBC_SHA256 AES_256_CBC_SHA256 For each batch, I do the following 3 tests : 1. download without cryptodev module loaded (100% software encryption) 2. download with cryptodev loaded and libssl (openssl) compiled with -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS 3. download with cryptodev loaded and libssl (openssl) compile only with -DHAVE_CRYPTODEV, which means hashing operation will still be done 100% by software. Here are the results : Note: CPU utilization is for both cores. Obviously each test is just a single process running on a single core therefore when you see CPU utilization around 50% (User% + Sys%) it means the core used for the test is fully loaded. Maybe i should have reported the number just for the core used, which would be more or less doing x2 of the value you see in the table. For reference: Using AES_128_GCM_SHA256 (Default Apache 2.4 TLS cipher. GCM mode is not something that can be accelerated by CESA.) CPU Utilization : User %42.9, Sys %7.2 Throughput : 30.6MB/s No HTTPS CPU Utilization : User %1.0, Sys %29.8 Throughput : 112MB/s CONCLUSION 1. Hashing operation are slower on the CESA engine than the CPU itself, therefore making HW encryption with hashing is less performant than 100% software encryption. 2. HW encryption without hashing provides 30 to 50% of throughput increase while decreasing the load on the CPU by 20 to 30%. 3. Still pondering if it's worth the effort to encourage people to do the move... but i think it's still cool improvement.
  24. Hi there, I have a little problem with my i2c-screen on the Helios4. It was setup according to the Kobol-Wiki and was working right from the start. However after running for some time (in this example it took around 6 hours) the screen is black and empty. Once I SSH back into the helios and restart the systemd sys-oled.service, it works again for some time... "journalctl -u sys-oled.service" gives the following: Sep 13 10:18:38 helios4 systemd[1]: Started System Starting on OLED Display. Sep 13 16:46:01 helios4 python3[23009]: Traceback (most recent call last): Sep 13 16:46:01 helios4 python3[23009]: File "/usr/local/bin/sys-oled", line 158, in <module> Sep 13 16:46:01 helios4 python3[23009]: main() Sep 13 16:46:01 helios4 python3[23009]: File "/usr/local/bin/sys-oled", line 148, in main Sep 13 16:46:01 helios4 python3[23009]: display_info(device) Sep 13 16:46:01 helios4 python3[23009]: File "/usr/local/bin/sys-oled", line 130, in display_info Sep 13 16:46:01 helios4 python3[23009]: draw.text((0, 27), network(net_name), font=font, fill="white") Sep 13 16:46:01 helios4 python3[23009]: File "/usr/local/lib/python3.7/dist-packages/luma/core/render.py", line 43, in __exit__ Sep 13 16:46:01 helios4 python3[23009]: self.device.display(self.image) Sep 13 16:46:01 helios4 python3[23009]: File "/usr/local/lib/python3.7/dist-packages/luma/oled/device/__init__.py", line 114, in display Sep 13 16:46:01 helios4 python3[23009]: self.command(set_page_address, 0x02, 0x10) Sep 13 16:46:01 helios4 python3[23009]: File "/usr/local/lib/python3.7/dist-packages/luma/core/device.py", line 48, in command Sep 13 16:46:01 helios4 python3[23009]: self._serial_interface.command(*cmd) Sep 13 16:46:01 helios4 python3[23009]: File "/usr/local/lib/python3.7/dist-packages/luma/core/interface/serial.py", line 91, in command Sep 13 16:46:01 helios4 python3[23009]: list(cmd)) Sep 13 16:46:01 helios4 python3[23009]: File "/usr/local/lib/python3.7/dist-packages/smbus2/smbus2.py", line 643, in write_i2c_block_data Sep 13 16:46:01 helios4 python3[23009]: ioctl(self.fd, I2C_SMBUS, msg) Sep 13 16:46:01 helios4 python3[23009]: TimeoutError: [Errno 110] Connection timed out Sep 13 16:46:01 helios4 systemd[1]: sys-oled.service: Main process exited, code=exited, status=1/FAILURE Sep 13 16:46:01 helios4 systemd[1]: sys-oled.service: Failed with result 'exit-code'. Any hint / idea is highly appreciated.
  25. Anyone know why it's not supported out of the box? The wiki provides a patch but does not mention why it's not upstream or in Armbian. The bus-width being 4 is also quite suspect. All the other Armada 38x devices have it at 8. Armada 37x ones have it at 4.
×
×
  • Create New...