Random system reboots


Mangix
 Share

4 4

Recommended Posts

vor 30 Minuten schrieb Mangix:

2 days uptime without DFS patches. No issues to report. Marked as solved.

 

I assume new kernels will be out if they're not already.

OTOH After the upgrade to 5.8.18, containing the DFS patches, my installation is up and running for 4 days now.

Are there any negative implications to be expected after the release of the new kernels without DFS management?

Link to post
Share on other sites

Donate and support the project!

15 hours ago, FredK said:

OTOH After the upgrade to 5.8.18, containing the DFS patches, my installation is up and running for 4 days now.

Are there any negative implications to be expected after the release of the new kernels without DFS management?

2 degrees higher CPU temperatures were reported on a WRT3200ACM.

 

That's a router with no fans. In other words, no difference.

Link to post
Share on other sites

vor einer Stunde schrieb Heisath:

@FredKout of curiosity, did you just replace the PSU? And you're doing the same high I/O tasks as before?

 

The updates are underway, PR need to be approved, merged and debs rebuild. Probably today.

@Heisath The reboots took place with 5.8.16-mvebu. After replacement of the PSU I had a reboot after one day, so I excluded the PSU as the root cause, but I left the new one in operation. Next step was the upgrade to 5.8.18-mvebu, five days ago. Since then uninterrupted operation.

The usage profile is always the same, a RAID5 serving as media server plus a nextcloud docker installation.

Link to post
Share on other sites

Is that btrfs raid5?

 

edit: I just had a thought. Since the Helios 4 is underclocked, I wonder if placing it back to the stock clocks would make the DFS patches work.

 

Then again, I do remember my Turris Omnia freezing as well.

 

Never mind.

Link to post
Share on other sites

@gprovost I went the upgrade path where i went from debian 9 to debian 10 so i could upgrade from omv4 to 5 using the omv upgrade script. After having random reboots after the upgrade, I did a clean install of debian 10 buster with omv5. I had no issues with reboots for about 20 days until i updated and reboot since then I am having random reboot after about 3 days.

 

If the watchdog service is off, i will get hard lockups with a powercycle reboot so i kept the watchdog service on.  It points to the orion watchdog service.

 

Since omv5 has changed a couple things are different now: kernel, urbackup service is now a docker, cockpit, and portainer.

 

i stopped the urbackup docker.. still had random reboots ~3 days.

 

i decided to switch to the older 4.19.159 kernel now.

 

I will see how it works.

 

Other notes about armbian 20.11

@gprovost

I have not had issues with going to the kernel 4.19.159 or greater

 

@Igor

 

The armbian-apt-updates located here: /usr/lib/armbian this bash script does not work on a clean build(it will not create the temp file needed for updates). I switched to the python script version from debian 9 so it will download updates. (Not sure why it switched) 

Also, the file in /etc/update-motd.d 30-armbian-sysinfo always gets changes when armbian is updated and i have to switch the STORAGE= variable to the correct storage i am using.

 

Thanks

 

Patrick

 

 

Link to post
Share on other sites

2 hours ago, PEW said:

The armbian-apt-updates located here: /usr/lib/armbian this bash script does not work on a clean build(it will not create the temp file needed for updates). I switched to the python script version from debian 9 so it will download updates. (Not sure why it switched) 

Also, the file in /etc/update-motd.d 30-armbian-sysinfo always gets changes when armbian is updated and i have to switch the STORAGE= variable to the correct storage i am using.


Review is welcomed:
https://github.com/armbian/build/pull/2402

Link to post
Share on other sites

Unrelated but one of the patches that I removed seems to actually be useful.

 

I just talked to Felix Fietkau and according to him, it seems the mvneta driver does not do any hardware queue configuration, leading to a nasty performance problem. Testable with iperf -P 4. Not iperf3.

 

Although the equipment he tested on did have a switch. The Helios4 does not.

 

I don't think the way I'm using mine it matters a whole lot though.

Link to post
Share on other sites

Ah but that might matter for the clearfog. Remember armbian supports more than only the helios4. The mvebu patches we've removed also affect clearfogbase & pro. 

 

So if I understand correctly we need this patch again? https://github.com/armbian/build/commit/15cb0f6e3f688d60a4565079468d9c7fd6b2f7a3#diff-0e2d5f1c7cffdc7dfa0c8bb8730d65ee262430d835a454ba5b0046dcb907800a

Link to post
Share on other sites

It should probably be tested beforehand.

 

Again, he tested "iperf -P 4" with swconfig on an armada device. He doesn't remember if it was the armada 37x or 38x. Clearfog devices are only the latter I believe.

 

edit: ehm I'm getting full speeds when I tested this. I think he tested this on the older 37x platform.

 

edit2: second posibility: iperf from one device connected to the switch to another connected to the switch. I tested from the helios device itself to a router (mvebu 385 platform running OpenWrt).

Link to post
Share on other sites

 Share

4 4