Cubieboard 2 stopped working after update

[PLyttle]

I tried this one too:

$this->bbcode_second_pass_code('', 'dd if=/dev/zero of=bigfile bs=1M count=1500
')

Here the kernel OOPSes too, but the sytem recovers and from a remote terminal you notice nothing of the event. the created file is even completely written.

Serial debug cable tells all

LP

[maggu2810]

Do you write to NAND or SD?

Perhaps it is no RAM problem, but a file system, block I/O driver one.

I am not using the NAND ATM.

[PLyttle]

I use SD at the moment, you mean you can't replicate the issue?

I get the same problem with 3.4.93-ARCH+ by the way

You might be right, this is what I observed

I tried writing to SATA, same problem
I tried cubietruck - (2 Gbyte RAM) file grows to about 850 Mbyte
I tried Phioenix A20 (almost cubieboard-2 - 1GByte RAM) - file grows to about 400 Mbyte

When monitoring /proc/meminfo, the problem occurs when HighFree approaches 1000 KByte, after the crash it is about half that. On a stable system HighFree never drops under the minimum limit.

When you write a big file and interrupt before the crash, and after that make a second file the same thing happens, but because HighFree starts at a lower level, the crash happens sooner, leaving the second file so much smaller. The total is more than when you write only one file.

I think that somehow filebuffers are not released quickly enough, or something like that.

Bummer...

LP

[maggu2810]

I could reproduce it, too.

Perhaps we should do a git bisect.
Do you know which version do not fail?

[PLyttle]

Oh, good, I started to feel lonely out on that branch

The last working version would be 3.4.79-8
which is the last one used in ARCH before the systemd shenannigans.

LP

[maggu2810]

We could test some combinations:

• 3.4.79 with xattr for cgroups
• 3.4.79 bumped to 3.4.93 without xattr for cgroups

If the problem exists in the backportet cgroup xattr support, we could run the test after every cherry-picked commit.

[PLyttle]

the patchfile "0001-cgroup-add-xattr-support.patch" contained the error. there are about 32 commits in there.
revert the last 16 and check for error, revert 8 more or 8 less depending on outcome. In about 5 steps the culprit should be clear.

[maggu2810]

I will have a look at it tomorrow.

[WarheadsSE]

PLyttle, can you be more specific? .. Might be handy to get this fixed. Perhaps a PR with an update to the patch.

[PLyttle]

He WarheadSE you are talking to the wrong guy, the credit goes to maggu2810. He has been backporting all this stuff into the sunxi kernel. He compiled the patch currently implemented in the ARCH repository. I only found a bug in it.

Now the patch is limited, and maybe it is possible to find the part where the bug originates, The plan was to find which commit caused the issue and work from there. But we're nowhere near a fix at the moment.

A second way of attack is to locate a bugfix in the mainline kernel, assuming the problem was occurring there too. I don't have high hopes for that. maggu's backport is now up to 3.4.93 and the error still presents itself. (the patch is based on 3.4.90)

A third way is to find a real kernelhacker who is willing to look into it. But that is outside my scope.

I'm afraid for the moment users will have to live with either a kernel that cannot handle big files, or cannot update systemd. I do however think it is a bit of a lapse not to inform the users that the current kernel is broken.

Be well, LP