gprovost

Members
  • Content Count

    162
  • Joined

  • Last visited

1 Follower

About gprovost

  • Rank
    Elite member

Contact Methods

  • Website URL
    http://kobol.io

Profile Information

  • Gender
    Male
  • Location
    Singapore

Recent Profile Visitors

989 profile views
  1. @lanefu Good suggestion because I think everyone is a bit lost on what the roadmap is. We did the required work for Helios4 bsp package and were expecting everyone would have done so for their respective board... but doesn't seem it happened. Can you explain the 'move kernel patch our form main script' ? Because I'm really not sure what you mean.
  2. Can we have an update status on this RFC. What's the plan / roadmap ?
  3. @helios4noob Your issue is unrelated to Helios4 hardware. It's a software setup issue, could be on your computer / laptop trying to access the share drives on Helios4. You will find better help effectively on the OMV forum for that. Have you tried to disable the firewall on you computer / laptop just to test if you can access the share drives without ? I assume you are using windows machine. As for the Helios4 froze that happened once, next occurrence check status of LED8 and LED1 and let us know. (ref to this wiki page to identify LED : https://wiki.kobol.io/led/)
  4. Hi @Igor Is the SFTP upload available ?
  5. Yes we are working on it, we just wanted to ask the question first of the intention for Default if we move the pointer for Next branch ;-)
  6. @Igor If we move Next branch to kernel 4.19, then should we move Default branch to kernel 4.14 ? I don't really see the point of letting Default branch pointing to a supposedly 'vendor provided' kernel stuck at 4.4.
  7. I also wanted to post a little update regarding the issue reported by @uzair which ended up being a conflict between OMV standby mode and watchdog service. It is an issue unrelated to Helios4, however we committed a change to OMV official repo to finally address the issue that was actually impacting any user of any platform. https://github.com/openmediavault/openmediavault/issues/343
  8. @djurny Well at least you narrow down the issue as being the board. Running out of clue of what it could be. Anyhow, let's proceed to a board replacement then since we can't figure out the root cause. Please PM me.
  9. We need some times to look, it won't be straight forward... some patched would need to be rework most probably, some patched would also need to be remove since some of our stuff made it upstream but not all. With @aprayoga we will start to look and report in this thread or new one. Igor is not talking about the -20c tweak which was anyway just a cosmetic thingy for all mvebu platform. There is a lot of kernel patches for mvebu and we need to insure all apply well on 4.19... for Helios4 one or two might be a bit tricky. Anyway we will work on it.
  10. Thanks for the info and pointer. Now I understand where this -20°C tweak we asked about here comes from It means it wasn't so smart to remove already the tweak... well at least it will already be aligned when armbian mvebu next jump to 4.19 or 5.x The kernel change you mention are from this commit and effectively it didn't made it to v4.14 https://github.com/torvalds/linux/commit/8c0b888f6610d0ebbc4bdfb52d2fef9f4a11adfc I'm also not 100% sure how this bitwise tweak works :/ FYI The Marvell errata (#132698) mentioned in the commit is an internal errata, it wasn't even made public.
  11. @uzair Ahhh we found the issue OMV install watchdog service by default. When the system is put in standby / suspend mode the watchdog is not stopped, therefore since nothing will be kicking the watchdog in that state, the watchdog will reset the system after 60sec. You will need to disable watchdog service. $> sudo systemctl disable watchdog Note: you will need to reboot after you disable the watchdog in order to ensure the watchdog is stopped. It's quite odd that systemctl doesn't try to stop the watchdog before doing the suspend... and then restart the watchdog when waking-up. But well at the same time some would say it's odd to have a watchdog on a system that is meant to be put in suspend mode. Also it seems there is a hardware limitation on Armada SoC watchdog (orion_wdt) that doesn't allow the watchdog to be stop during runtime for security reason... so will need to investigate more.
  12. @djurny Ok thanks, keep us updated. @uzair Even though it's most probably unrelated to the standby issue on which Aditya will help you. What's the hardware time and the system time before you put your system in standby ? Do the following command : System time $> date Hardware Clock time (RTC) $> hwclock -r @seawolfssn Ok understood, well it looks like your PSU is faulty unable to provide 12V while still providing enough voltage for the different buck converters (5V and 3.3V rails) to operate. Please PM me and will arrange to send you a new PSU.
  13. @djurny We not sure what it could be. BTW is it a system from batch1 or batch2 ? We are asking because if it's batch2 and as you said the fan still spin after system has hanged, then it means PWM it is running, so the system is not completely hang. In order to narrow down the issue, could you swap the PSUs between your 2 Helios4 systems, to see if it could be a faulty PSU ? In any case, if we can't figure out the root cause, then we will proceed to a replacement of the board. @seawolfssn Sounds like power budget issue, the overall peripherals current consumption exceed the max power budget of Helios4. I'm a bit lost at some point in your explanation, what combination you tried with which HDD and in which order. Maybe a table would help that also show the exact HDD brand + model you are testing. Please note there are 2 power rails for the SATA HDDs, the 5V and the 12V. While the 12V rail is directly coming from the AC/DC PSU, the 5V rail is generated by a buck converter (step-down converter). This buck converter has several protection (over current, over voltage, temperature, etc..) that will switch off the buck converter if something wrong and latch it in this state until a full power cycle. So if by plugging in and out devices you triggered the buck converter protection, plugging/swapping devices might not work because the buck is latching in off state... you need to do a full power cycle (unplug / plug PSU). The same things apply for USB devices, there is a dedicated 5V rails for the USB ports with the same kind of protection and behavior described above.
  14. Sure, no rush... on my side I don't have any package to push. BTW what will be the sftp address ?
  15. Great ! Just sent you my pub key by PM ;-)