On 03/30/2014 12:43 PM, Olliver Schinagl wrote:
On 03/30/2014 12:33 PM, Olliver Schinagl wrote:
On 03/30/2014 12:25 PM, Olliver Schinagl wrote:
Status update:
d2a8c8d Merge tag 'v2014.04-rc2' into sunxi
seems stable and was able to compile u-boot on itself ;)
linux-sunxi kept failing due to remote hung endpoints while fetching the
full git tree, nothing unexpected there.
4362605 Merge remote-tracking branch
'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi
So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz
causes no issues yet. I'll keep using that rev for a few hours then go
onto the next one.
I shouted too early :(
[ 508.891546] Process login (pid: 2265, stack limit = 0xee5f82f0)
[ 508.901743] Stack: (0xee5f9e78 to 0xee5fa000)
[ 508.910451] 9e60:
000001f9 c006bab0
[ 508.923123] 9e80: d1015788 ee825a78 b7caf08b 00000003 ee825a8c
c0782b28 d1015788 ee5f9f10
[ 508.935835] 9ea0: 00000001 c00d5498 ee5f9f10 00000001 ee5f8010
00000000 c051a038 c012bc38
[ 508.948540] 9ec0: ee6398b8 ee639800 ee58cb40 271ae921 00000000
ee639800 ee63989c 00000000
[ 508.961336] 9ee0: 00000001 ee63990c ee58cb40 c0292cbc 00000007
c05442e4 c0292504 c077f97c
[ 508.974074] 9f00: ee5f8000 ee5c72c0 00000001 ee639800 ee5f8000
ee5f8028 ee5f8000 00000000
[ 508.986932] 9f20: 00000005 c02935c0 ee825a40 00000000 00000001
ee5f8000 c000e108 c003d5b8
[ 508.999755] 9f40: b6d3c000 ee5038fc ee4f9884 c0101d18 ffffffff
ee4f9880 ee5038f0 c023b764
[ 509.012692] 9f60: ee4f98b8 eeb9d080 00000000 ee5f8000 000000f8
c000e108 ee5f8000 00000000
[ 509.025742] 9f80: 00000005 c003db38 00000000 0006efae b6f77774
b6f77774 000000f8 c003dbc4
[ 509.038900] 9fa0: 00000000 c000df00 0006efae b6f77774 00000000
0006ef9a b6fbc4c0 00000000
[ 509.052039] 9fc0: 0006efae b6f77774 b6f77774 000000f8 00857898
008513f8 000171d8 00000005
[ 509.065171] 9fe0: 000000f8 be9a7834 b6f0a0f3 b6eaef96 60000030
00000000 00000000 00000000
[ 509.078413] [<c0299810>] (tty_ldisc_hangup+0x3c/0x2a4) from
[<c0292cbc>] (__tty_hangup+0x124/0x378)
[ 509.097651] [<c0292cbc>] (__tty_hangup+0x124/0x378) from [<c02935c0>]
(disassociate_ctty+0x7c/0x240)
[ 509.117536] [<c02935c0>] (disassociate_ctty+0x7c/0x240) from
[<c003d5b8>] (do_exit+0x294/0x784)
[ 509.131797] [<c003d5b8>] (do_exit+0x294/0x784) from [<c003db38>]
(do_group_exit+0x54/0xc8)
[ 509.145622] [<c003db38>] (do_group_exit+0x54/0xc8) from [<c003dbc4>]
(__wake_up_parent+0x0/0x20)
[ 509.159980] Code: e2066002 e2505000 0a000018 e5953000 (e5933018)
[ 509.171733] ---[ end trace 0b4cd254dfcafc0c ]---
[ 509.181906] Fixing recursive fault but reboot is needed!
Going back to the parent rev,
d3686aa sunxi: use a 4MB malloc pool
and report then :)
Right, this one doesn't seem to crash; but I cant extract the .xz either...
linux-sunxi/.git/objects/pack/pack-06962d550c8aab83282655647120ce3552ca5b0e.idx
xz: (stdin): Compressed data is corrupt
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
and that constantly, sometimes it gets to go 1 file further ...
ironically the sha1 calculation worked fine
I'll go back to pre-merge and double check that.
4271202 sunxi: add board hcore hc860
seems to be un-able to extract the tar-ball and causes an oops.
[ 450.179006] [<c02449fc>] (__list_del_entry+0x8/0xb8) from
[<c0244ab8>] (list_del+0xc/0x24)
[ 450.199528] [<c0244ab8>] (list_del+0xc/0x24) from [<c00e48c0>]
(__rmqueue+0x70/0x370)
[ 450.219659] [<c00e48c0>] (__rmqueue+0x70/0x370) from [<c00e563c>]
(get_page_from_freelist+0x324/0x4b8)
[ 450.253607] [<c00e563c>] (get_page_from_freelist+0x324/0x4b8) from
[<c00e6154>] (__alloc_pages_nodemask+0x18c/0x7b4)
[ 450.289644] [<c00e6154>] (__alloc_pages_nodemask+0x18c/0x7b4) from
[<c0115560>] (new_slab+0x84/0x23c)
[ 450.325304] [<c0115560>] (new_slab+0x84/0x23c) from [<c0509ad0>]
(__slab_alloc.constprop.54+0x20c/0x450)
[ 450.362016] [<c0509ad0>] (__slab_alloc.constprop.54+0x20c/0x450) from
[<c0116e84>] (kmem_cache_alloc+0x70/0x18c)
[ 450.400291] [<c0116e84>] (kmem_cache_alloc+0x70/0x18c) from
[<c019cb34>] (ext4_alloc_inode+0x20/0xbc)
[ 450.438405] [<c019cb34>] (ext4_alloc_inode+0x20/0xbc) from
[<c0133230>] (alloc_inode+0x24/0x9c)
[ 450.462253] [<c0133230>] (alloc_inode+0x24/0x9c) from [<c0134c30>]
(new_inode_pseudo+0x10/0x50)
[ 450.486131] [<c0134c30>] (new_inode_pseudo+0x10/0x50) from
[<c0134c80>] (new_inode+0x10/0x24)
[ 450.509985] [<c0134c80>] (new_inode+0x10/0x24) from [<c0184ff8>]
(ext4_new_inode+0x94/0xee0)
[ 450.533711] [<c0184ff8>] (ext4_new_inode+0x94/0xee0) from
[<c0191318>] (ext4_create+0xb0/0x150)
[ 450.557750] [<c0191318>] (ext4_create+0xb0/0x150) from [<c012905c>]
(vfs_create+0x98/0x11c)
[ 450.581516] [<c012905c>] (vfs_create+0x98/0x11c) from [<c01294f8>]
(do_last+0x418/0x7e8)
[ 450.605109] [<c01294f8>] (do_last+0x418/0x7e8) from [<c012a164>]
(path_openat+0xc4/0x39c)
[ 450.628904] [<c012a164>] (path_openat+0xc4/0x39c) from [<c012a530>]
(do_filp_open+0x34/0x80)
[ 450.653058] [<c012a530>] (do_filp_open+0x34/0x80) from [<c011b7e0>]
(do_sys_open+0xf0/0x17c)
[ 450.677183] [<c011b7e0>] (do_sys_open+0xf0/0x17c) from [<c000df00>]
(ret_fast_syscall+0x0/0x30)
[ 450.701580] Code: c065f53a c065f587 e92d4007 e1a03000 (e8900006)
inux-sunxi/arch/um/drivers/pcap_kern.c
linux-sunxi/arch/um/drivers/xterm_kern.c
linux-sunxi/arch/um/drivers/cow_sys.h
linux-sunxi/arch/um/drivers/random.c
l[ 450.736543] ---[ end trace 6f1dba53c1a6e6be ]---
inux-sunxi/arch/um/drivers/mconsole_kern.c
This is on an SSD, with a 2amps charger. I ran tinymembenches before
never exceeding 0.7 amps; could someone confirm this on the cubietruck?
Olliver
olliver
On 03/30/2014 11:05 AM, Olliver Schinagl wrote:
On 03/29/2014 05:37 PM, Ian Campbell wrote:
On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote:
Hey all,
I was using current head on my Cubietruck; and it kept crashing. I first
tried to revert the density/width only, but that made no difference what
so ever.
Oh dear.
Aye!
Using the merge tag seems to be fine however, d2a8c8da1.
So it is one of the newer patches, will slowly progress the line, as
time permits, to find the culprit.
The first crash I had on cloning git during 3.4.79+; i first reverted to
Hans's 3.4 series from fedora 19, but then a big huge oops happened even
during boot. And consistently during boot. It doesn't seem to be power
relate either.
I have since reverted to d9aa5dd3d and that seems to be stable again.
Which branch are you running? u-boot-sunxi/sunxi I guess but you mention
Hans' series so maybe jwrdegoede/sunxi-next?
for u-boot, the linux-sunxi u-boot variant.
for the kernel, hans's 3.4 that comes with fedora 19; but I initially
experienced these problems with one the sunxi nightlies, a 3.4.79+
I will cook dinner now, and keep the board running using the d9 hash and
checkout a few newer revisions then. Stable for 10 minutes now though ;)
The obvious first one to try would be d2a8c8da1c6 "Merge tag
'v2014.04-rc2' into sunxi". Its immediate parent on the sunxi side is
d9aa5dd3d which you've already found to be stable. If you can rule that
out then the rest should be fairly tractable to bisect... Looking at
"gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master" most of them
are supposed to be "no semantic change" type cleanups or things which
don't touch cubietruck...
If it does turn out to be the merge then I think it will be time to take
a fine toothed comb to the merge...
Luckily, this does not seem the case. I will keep you all posted.
Olliver
Ian.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
