Hi Everyone,
First off thanks to bigbrd + all in the group for all the useful info on the webpal! I was wondering anyone else has tried getting a web browser to work on the webpal?
I have been able to get the debian potato distro running quite nicely off nfs and once I got X working now I'm getting greedy. Thinking dillo might be a good choice since it is fairly compact I first tried to install it along with updated libc6-2.2.4.. Seems like anything above the 2.1.x seems to create troubles with kernel invalid page requests... So I decided to just try and compile dillo using the webpal + native gcc 2.95.2 (in potato). The compile actually worked perfectly (albiet slow), but was esier then sorting all the libs out in the cross, and I was able to link against the 2.1.x libc without complaints. Trying to run it I then get the following kernel dump very consistantly:
Jan 27 22:25:19 webpal kernel: Unable to handle kernel paging request at virtual address 6000004c
Jan 27 22:25:19 webpal kernel: pgd = c466c000
Jan 27 22:25:19 webpal kernel: *pgd = 00000000, *pmd = 00000000
Jan 27 22:25:19 webpal kernel: Internal error: Oops: 0
Jan 27 22:25:19 webpal kernel: CPU: 0
Jan 27 22:25:19 webpal kernel: pc : [baddataabort+112/164] lr : [cpu_arm7_proc_fin+4/20] Not tainted
Jan 27 22:25:19 webpal kernel: sp : c4739f14 ip : 000000b1 fp : c4739fb4
Jan 27 22:25:19 webpal kernel: r10: 400a8324 r9 : 400a62d0 r8 : 00000001
Jan 27 22:25:19 webpal kernel: r7 : e104c09c r6 : 00000000 r5 : 60000010 r4 : c4738000
Jan 27 22:25:19 webpal kernel: r3 : 01000000 r2 : c4738242 r1 : 000000b1 r0 : c0131d2c
Jan 27 22:25:19 webpal kernel: Flags: nzcv IRQs off FIQs on Mode SVC_32 Segment user
Jan 27 22:25:19 webpal kernel: Control: EE133F10 Table: EB002828 DAC: EA00000C
Jan 27 22:25:19 webpal kernel: Process dillo (pid: 177, stackpage=c4739000)
Jan 27 22:25:19 webpal kernel: Stack: (0xc4739f04 to 0xc473a000)
Jan 27 22:25:19 webpal kernel: 9f00: c0023b70 c0020f3c 00000093 ffffffff e104c09c c4788aa0 c4738000
Jan 27 22:25:19 webpal kernel: 9f20: ffffffff 40491354 00000000 c4739f60 c4739f3c c002241c c0036674 c00139bc
Jan 27 22:25:19 webpal kernel: 9f40: c4738000 c01321f4 c00139a0 c4739fb8 40491354 c4739f94 c4739f64 c00225ac
Jan 27 22:25:19 webpal kernel: 9f60: c0130648 00000000 00000000 00000007 40491354 c01321f4 c4739fb8 40492ad4
Jan 27 22:25:19 webpal kernel: 9f80: 4047fe04 00013230 c4739fb4 c4739f98 c00229e4 c002253c e104c09c c4739ff4
Jan 27 22:25:19 webpal kernel: 9fa0: 00000000 0000017f 00000000 c4739fb8 c0023b70 c0020f10 40491358 00000000
Jan 27 22:25:19 webpal kernel: 9fc0: 00000001 4049135c 4049135c 40491358 00000000 00000001 00000001 400a62d0
Jan 27 22:25:19 webpal kernel: 9fe0: 400a8324 bffffb30 00000001 bffffb10 400983b4 40098530 60000010 ffffffff
Jan 27 22:25:19 webpal kernel: Backtrace:
Jan 27 22:25:19 webpal kernel: Function entered at [baddataabort+52/164] from [cpu_arm7_proc_fin+4/20]
Jan 27 22:25:19 webpal kernel: r7 = 0000017F r6 = 00000000 r5 = C4739FF4 r4 = E104C09C
Jan 27 22:25:19 webpal kernel: Code: e59f0064 e3842d09 e3822002 e1a0100c (e595603c)
Any ideas? Funny thing is that I started trying to debug dillo to determine where the fault might be occuring, I ended up commenting out everything except for gtk_init() and it still seg-faulted with the same basic error as above. I then built a small gtk program and it worked fine (with the same gtk_init()). It almost appears that when the dillo executable is linked with all it's other objects with everything commented out but gtk_init (comes out to around 1meg executable), gtk_init always fails with the same segfault. Smaller programs with gtk_init however work fine. Kinda strange.. Anyway the webpal I'm testing is setup as follows:
kernel 2.4.18-rmk4, + brd + nfs swap patch
nfs root dir
swap = 32M on nfs, swap via nfs is working fine (tested it quite a bit and it appears to be stable)
32M RAM installed (with mod)
using gcc 2.95.2 from potato to natively compile dillo, using 2.95.3 cross to compile kernel.
By the way I also went back and checked what was dying when using libc6-2.2.4 and it appeared to be the same segfault with a very similiar error.
Seems that if this could be cleared up it would solve a number of issues..
Oh and mozilla dies also in a different way, no seg-fault just decides to stop loading at one point, probably killed by swapping.. (no big suprise there it's huge). Guess I can always try to get konq-e running!?
Thanks
Zooloo