Cubieboard 2 stopped working after update

[maggu2810]

You could also try to use my modified sunxi-3.4 branch.
It contains my cgroup-xattr backport, should contain a working bcmdhd wlan driver and the latest 3.4.91 patches.

[PLyttle]

I will try that. My current configuration crashes regularly, I probably was not careful enough...
Any reason why you prefer a monolithic kernel over a modular one?

PL

[maggu2810]

What configuration did you mean?
Normally i prefer a modular one.

[PLyttle]

brainfart...

I was'nt paying attention and forgot to configure properly, so it looked like modules were switched off
Doing too many things at a time

LP

[PLyttle]

I'm having issues with the Maggu 3.4.91 kernel branch. Upon intensive file access (for instance tarring a large file (i ise the kernel tree for that)) the kernel OOPSes, like this:

$this->bbcode_second_pass_code('', '<1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
Unable to handle kernel NULL pointer dereference at virtual address 00000000
<1>pgd = c0004000
pgd = c0004000
<1>[00000000] *pgd=00000000[00000000] *pgd=00000000

<0>Internal error: Oops: 817 [#1] PREEMPT SMP ARM
Internal error: Oops: 817 [#1] PREEMPT SMP ARM
<d>Modules linked in:Modules linked in: sunxi_cedar_mod sunxi_cedar_mod g_ether g_ether disp_ump disp_ump ump ump lcd lcd bcmdhd bcmdhd cfg80211 cfg80211 wifi_gpio wifi_gpio rfkill rfkill

CPU: 1 Not tainted (3.4.91 #1)
CPU: 1 Not tainted (3.4.91 #1)
PC is at __mutex_lock_slowpath+0xc4/0x1dc
PC is at __mutex_lock_slowpath+0xc4/0x1dc
LR is at __raw_spin_lock+0x28/0x9c
LR is at __raw_spin_lock+0x28/0x9c
pc : [<c0552b6c>] lr : [<c0555170>] psr: 600f0113
sp : ef1afe10 ip : ef1afde0 fp : ef1afe4c
pc : [<c0552b6c>] lr : [<c0555170>] psr: 600f0113
sp : ef1afe10 ip : ef1afde0 fp : ef1afe4c
r10: ef00466c r9 : 00000000 r8 : ef1ae010
r10: ef00466c r9 : 00000000 r8 : ef1ae010
r7 : ef1ae000 r6 : ef06f9c0 r5 : ef004664 r4 : ef004660
r7 : ef1ae000 r6 : ef06f9c0 r5 : ef004664 r4 : ef004660
r3 : 00000000 r2 : ef1afe14 r1 : ef1afdd0 r0 : 00000001
r3 : 00000000 r2 : ef1afe14 r1 : ef1afdd0 r0 : 00000001
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 6ea3806a DAC: 00000015
.
.
Backtrace:
[<c0552aa8>] (__mutex_lock_slowpath+0x0/0x1dc) from [<c0552cf8>] (mutex_lock+0x74/0x78)
[<c0552c84>] (mutex_lock+0x0/0x78) from [<c00f35ac>] (vmpressure+0x40/0x7c)
r4:ef004658 r3:c07b6668
[<c00f356c>] (vmpressure+0x0/0x7c) from [<c00c2804>] (shrink_zone+0xa8/0xb0)
r7:c0807340 r6:00000000 r5:ef1aff58 r4:00000000
[<c00c275c>] (shrink_zone+0x0/0xb0) from [<c00c3610>] (kswapd+0x634/0xb04)
[<c00c2fdc>] (kswapd+0x0/0xb04) from [<c005426c>] (kthread+0x98/0x9c)
[<c00541d4>] (kthread+0x0/0x9c) from [<c003bfa4>] (do_exit+0x0/0x7d0)
r6:c003bfa4 r5:c00541d4 r4:ef03bed4
<0>Code: e24b2038 e50ba038 e5842010 e50b3034 (e5832000)
<4>---[ end trace c07f92e7ccc3dba1 ]---
<6>note: kswapd0[23] exited with preempt_count 2
')

Aside from that I can't get bluetooth to load the firmware, but that is not important right now.

I tried this on both my A20 platforms, a cubietruck and a Phoenix A20.
On the Phoenix the u-boot also gets corrupted. On the cubietruck it remains intact.

To stay with cubietruck, I just used cubietruck_defconfig, no extra patches
Anything I can try?

LP

[WarheadsSE]

We've backported those to the sunxi family in our PKGBUILDs

[Ninolein1988]

Thanks for the advice. I think that was the problem and the solution was an update over chroot because meanwhile in the repo the corrected packages are available.

Nino

[PLyttle]

My, you guys have been busy, Thanks for that.

The 3.4.90-1-ARCH kernel from PKGBUILD solves my bluetooth issue, however I get the same kernel OOPS

$this->bbcode_second_pass_code('', '<1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 262.945493] Unable to handle kernel NULL pointer dereference at virtual address 00000000
<1>pgd = c0004000
[ 262.963829] pgd = c0004000
<1>[00000000] *pgd=00000000[ 262.977396] [00000000] *pgd=00000000

<0>Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 262.993979] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
<d>Modules linked in:[ 263.009506] Modules linked in: bnep bnep hci_uart hci_uart bluetooth bluetooth sunxi_cedar_mod sunxi_cedar_mod g_ether g_ether disp_ump disp_ump ump ump hdmi hdmi lcd lcd disp disp cfbfillrect cfbfillrect cfbimgblt cfbimgblt cfbcopyarea cfbcopyarea bcmdhd bcmdhd cfg80211 cfg80211

CPU: 0 Not tainted (3.4.90-1-ARCH #1)
[ 263.047306] CPU: 0 Not tainted (3.4.90-1-ARCH #1)
PC is at __list_add+0x34/0x7c
[ 263.063711] PC is at __list_add+0x34/0x7c
LR is at __mutex_lock_slowpath+0x10c/0x1c4
[ 263.080194] LR is at __mutex_lock_slowpath+0x10c/0x1c4
.
.
.
')

The problem seems memory related, On a board with 1GB installed RAM, the kernel crashes when my TAR-file grows to about 350 MB, on a board with double that RAM, it happens at about 800 MB

On my 2GB board:
/proc/meminfo - HighFree starts at 778520 kB
gradually reduces to 1908 kB and after the crash reads 420 kB and stays there until my debug interface shuts down.

Kind of suggestive when you see the created tar-file reach a similar size as the memory lost.
(836024 KB, in this case)

I tried "Disabling memory control group subsystem" with the cgroup_disable=memory option.
Disabling worked, but the kernel crashes like before.

Anything else I can try?

LP

[maggu2810]

Could you give me a script, so I can reproduce this on my board?

If I use ramfs for tmp and fill it with 1400M, the kernel did not crash.

$this->bbcode_second_pass_code('', 'mount -t ramfs none /tmp
dd if=/dev/zero of=/tmp/fill-ram bs=1M count=1400')

ATM I am using a kernel that merged with the 3.4.93 changes.

[PLyttle]

$this->bbcode_second_pass_code('', 'tar -cf bigfile "a_large_tree"')

"a-large-tree" should be something like a linux-kernel tree (linux-kernel). The resulting bigfile should reach 1Gbyte. The crash occurs when this file reaches something like 850 Mbyte on a cubietruck. about 400 Mbyte on a cubieboard-2

Please have a debug cable attached, otherwise it is less than obvoius.

LP