Cubieboard 2 stopped working after update

This forum is for supported devices using an ARMv7 Allwinner SoC.

Re: Cubieboard 2 stopped working after update

Postby PLyttle » Thu Jun 12, 2014 10:33 am

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
PLyttle
 
Posts: 120
Joined: Mon Jun 10, 2013 6:52 am

Re: Cubieboard 2 stopped working after update

Postby maggu2810 » Thu Jun 12, 2014 1:00 pm

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.
maggu2810
 
Posts: 35
Joined: Thu May 29, 2014 12:52 pm

Re: Cubieboard 2 stopped working after update

Postby PLyttle » Thu Jun 12, 2014 3:26 pm

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
PLyttle
 
Posts: 120
Joined: Mon Jun 10, 2013 6:52 am

Re: Cubieboard 2 stopped working after update

Postby maggu2810 » Thu Jun 12, 2014 3:56 pm

I could reproduce it, too.

Perhaps we should do a git bisect.
Do you know which version do not fail?
maggu2810
 
Posts: 35
Joined: Thu May 29, 2014 12:52 pm

Re: Cubieboard 2 stopped working after update

Postby PLyttle » Thu Jun 12, 2014 4:23 pm

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
PLyttle
 
Posts: 120
Joined: Mon Jun 10, 2013 6:52 am

Re: Cubieboard 2 stopped working after update

Postby maggu2810 » Thu Jun 12, 2014 5:01 pm

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.
maggu2810
 
Posts: 35
Joined: Thu May 29, 2014 12:52 pm

Re: Cubieboard 2 stopped working after update

Postby PLyttle » Thu Jun 12, 2014 5:56 pm

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.
PLyttle
 
Posts: 120
Joined: Mon Jun 10, 2013 6:52 am

Re: Cubieboard 2 stopped working after update

Postby maggu2810 » Thu Jun 12, 2014 5:59 pm

I will have a look at it tomorrow.
maggu2810
 
Posts: 35
Joined: Thu May 29, 2014 12:52 pm

Re: Cubieboard 2 stopped working after update

Postby WarheadsSE » Thu Jun 12, 2014 7:43 pm

PLyttle, can you be more specific? .. Might be handy to get this fixed. Perhaps a PR with an update to the patch.
Core Developer
Remember: Arch Linux ARM is entirely community donation supported!
WarheadsSE
Developer
 
Posts: 6807
Joined: Mon Oct 18, 2010 2:12 pm

Re: Cubieboard 2 stopped working after update

Postby PLyttle » Thu Jun 12, 2014 9:48 pm

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
PLyttle
 
Posts: 120
Joined: Mon Jun 10, 2013 6:52 am

PreviousNext

Return to Allwinner

Who is online

Users browsing this forum: No registered users and 4 guests