Jump to content

Kernel bug (Large file transfers)

Chris Bognar

By Chris Bognar
in Rockchip

 Share

Recommended Posts

Chris Bognar

Chris Bognar

Posted
Posted (edited)

Getting system crashes and instability, including a loss of HD I/O, during very large file transfers.  This happens over the network, whether using SCP, FTP, or SMB.  I'm a hobbyist, and am no coder or developer, so other than Googling, I have no practical knowledge to pull on.  When the problem started occuring, I opened two PuTTY SSH interfaces as root - one with htop, and another with "dmesg --follow" to see what was going on with the system, and this is what happened:

 

dmesg readout at file transfer crash (using SMB this time):

 

  Reveal hidden contents

 

Terminal lost connectivity at this time.

 

On the PuTTY htop session:

CPU frozen, a few cores max,  temp in the high 50's (58 on crash).

Terminal lost connectivity at this time also.

 

When this happens, if the system is able to continue, no more HD activity is able to occur.  If the KOBOL softlocks, I have to hard powerdown (hold the power button until it turns off).

 

I'm running 4 HD's in a RAID5, through OpenMediaVault, and one manually mounted HD as a spare drive.  The RAID5 is XFS, the spare drive is EXT4.  The RAID5 drives are NAS drives, not all the same though, and the spare drive is an old desktop drive.

 

Any ideas or help would be appreciated . . . Google's results are varied and inconclusive so far.

Edited by TRS-80
put long output inside spoiler
barnumbirr

barnumbirr

Posted
Posted

I'm also running kernel 5.8.17-rockchip64 and haven't encountered any such issues. Did you start out on 5.8.17 or did you upgrade from previous versions?
Earlier versions of the kernel has severe stability issues and in such cases (had this happen to me as well) a clean install of the system helped.

Chris Bognar

Chris Bognar

Posted
  • Author
Posted

I figured out my issue.  I set up a 4GB swap partition on the spare drive, and the system was choking on it.  To fix my problem, all I had to do was turn off the swap and remove the swap partition mount from fstab and all was good.

 

As I said, I'm just a hobbyist, and I set up the swap drive out of habit with linux.  The system works fine without it, but I'd be interested in learning why it was Oops-ing on a swap partition.  If I find the answer, I'll post it here for others to learn from.

TRS-80

TRS-80

Posted
Posted

@Chris Bognar,

 

Thanks for reporting back.

 

There are quite a number of optimizations that Armbian / Kobol do to these boards, as hardware wise they are not exactly like the "normal" x86 you may be used to.  I would recommend leaving them as is for the most part, unless you really know what you are doing.

 

Of course, the whole point of GNU/Linux is to tinker though, so...  :D  Maybe get another cheap board for such tinkering / learning, instead of your (home?) "production" NAS.  Just a thought!  Cheers!  :beer:

ShadowDance

ShadowDance

Posted
Posted

If you created a separate partition for swap on the raw disk (not on top of RAID), I see only one reason that it would lead to a kernel panic, and that's a bad disk. A bad disk would lead to memory corruption. Have you run a S.M.A.R.T. self-test (both short and long) on the disk that had the swap?

 

That said, I would expect swap to work on top of RAID as well, but it's an extra layer that might get congested during high memory pressure. ZFS, for instance, doesn't deal well with swap on top of it, there's at least one long-standing open issue about it.

1
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept