Hi Greg, I've also posted on this list cause Russell pointed that the problem could be related to uClinux so I've just tried to get some more advice, I'm not an advanced programmer... Yes, I know there are better tools and newer kernels. In fact, I've installed arm-linux-gcc-3.4.6, built using buildroot. But my problem is that my company decided to buy a commercial board (from an Asian manufacturer) which came with Linux-2.6.14 already running with some interesting drivers linked into. Kernel was compiled using 3.3.2 so as far as I know modules must be compiled using the same toolchain (also provided with the board), so I cannot just use a newer one... unless I decide to miss some drivers, which obviously I could also write later but extending project deadline. I think code is right because it runs on my desktop computer...
Regards On 7/19/07, Greg Ungerer <[EMAIL PROTECTED]> wrote:
Hi Jesus, You don't like the answers you got on the arm.linux.kernel mainling list for this same question :-) Jesus Lopez wrote: > I must write some code for a custom ethernet-like stuff. I'm using snull > code from LDD3 to do some prior testing. I'm working on an AT91rm9200 > running linux-2.6.14-uc0, arm-linux-gcc-3.3.2. I can compile the module > with no trouble, insmod it and bring both interfaces up but when I ping > any address kernel crashes: > > # ifconfig sn0 192.168.1.67 <http://192.168.1.67/> > # ping 192.168.1.15 <http://192.168.1.15/> > PING 192.168.1Unable to handle kernel paging request at virtual address > ffffffff > .pgd = c1a10000 > 1[ffffffff] *pgd=200020315, *pte=00000000 , *ppte=00000000( > 1Internal error: Oops: 817 [#1] > Modules linked in: snull > CPU: 0 > PC is at snull_header+0x5c/0xac [snull] > LR is at neigh_connected_output+0xa4 > /0x11c > pc : [<bf000778>] lr : [<c01c47e4>] Not tainted > sp : c1c7bbfc ip : c1c7bc2c fp : c1c7bc28 > r10: c03978c4 r9 : 00000040 r8 : 00000000 > r7 : c039fc00 r6 : 00000800 r5 : c03d7a20 r4 : fffffff3 > r3 : c03978c4 r2 : 00000800 r1 : 00000000 r0 : 00000008 > Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user > Control: C000717F Table: 21A10000 DAC: 00000015 > Process ping (pid: 761, stack limit = 0xc1c7a194) > Stack: (0xc1c7bbfc to 0xc1c7c000) > bbe0: > c1c7bc4c > bc00: c1c7bc0c c03d7a20 00000000 c03978a0 c1bc8040 c038be80 00000000 > c1c7bc4c > bc20: c1c7bc2c c01c47e4 bf00072c 00000000 00000054 c03d7a20 00000000 > c038be80 > bc40: c1c7bc84 c1c7bc50 c01d85f0 c01c4750 c039fc00 c01dadc0 80000000 > c03d7a20 > bc60: c1bc8040 00000040 c03d7a20 c1bc8040 00000040 c1bc8040 c1c7bcc0 > c1c7bc88 > bc80: c01da84c c01d8358 c039fc00 c01dad8c 80000000 c03d7a20 00000000 > c1c7beac > bca0: 0f01a8c0 c1bc8040 c1bc8040 00000000 00000040 c1c7bda0 c1c7bcc4 > c01f64c8 > bcc0: c01da414 00000000 c1c7bd6c c038be80 00000000 00000000 c038be80 > 00000000 > bce0: 00000000 0f01a8c0 00000000 00000000 00000000 00000000 00000000 > 00000000 > bd00: 00000000 00000000 00000001 00000000 00000000 00000000 00000000 > 00000000 > bd20: 00000000 00000000 00000000 0f01a8c0 4301a8c0 00000000 00000000 > 00000000 > bd40: 00000000 00000000 00000000 00000000 00000001 00000008 00000000 > 00000000 > bd60: 00000000 00000000 00000000 0f01a8c0 00000000 00000000 c1bc8040 > c1c7be0c > bd80: c1c7beac 00000040 0004ec08 c1c7a000 00000010 c1c7bdc0 c1c7bda4 > c01ffad8 > bda0: c01f61b4 c1c7beac 00000000 00000000 00000040 c1c7be9c c1c7bdc4 > c01b2bd4 > bdc0: c01ffa8c c0042b4c c0042ec4 c1c7be10 00000040 c1c6f080 0000002b > 00000000 > bde0: c1c7beac c0042d0c c0042afc c1c7be0c c1c7bdfc c0023db0 c0042ccc > ffffffff > be00: c1c7be98 c1c7be10 c0022984 c0023d50 4007cc60 00000000 00000001 > ffffffff > be20: 00000000 c001e1a8 00000000 0000002b 00000000 00000000 4007c000 > c1c97d60 > be40: 00000000 00000000 c00294b4 c002b5b0 80000013 ffffffff c001c1fc > 00000100 > be60: 00000000 c1c97d60 c00537e0 c1c7be6c c1c7be6c 00000010 00000010 > c1c7bec8 > be80: c1c7bdc4 c1c6f080 c1c7bec8 00000000 c1c7bf6c c1c7bea0 c01b4160 > c01b2b2c > bea0: bed58c90 00000040 00000000 c1c7bec8 00000010 c1c7bea0 00000001 > 00000000 > bec0: 00000000 00000000 00000002 0f01a8c0 00000000 00000000 c1a11000 > c0fef1d4 > bee0: 00000000 0004ecbc 60000013 c02ed240 c02eed9c 0000000a 00000001 > c1c7a000 > bf00: 4001bd18 c1c7bf28 c1c7bf14 c003a310 c003a27c 00000000 c0fe2000 > c1c7bf40 > bf20: c1c7bf2c c00fe4c0 c003a2f8 00000000 c02ed240 c1c7bf50 c1c7bf44 > c0112668 > bf40: c00fe470 c1c7bf68 00000000 0000000b 00000040 00000066 c0022e64 > bed58cc8 > bf60: c1c7bfa4 c1c7bf70 c01b4990 c01b40bc 0004ec08 00000010 00000003 > bed58c90 > bf80: 00000040 00000000 0004ec08 00000010 bed58c90 00000000 00000000 > c1c7bfa8 > bfa0: c0022ce0 c01b483c bed58c90 c0023d50 0000000b bed58c78 00000040 > 00000000 > bfc0: bed58c90 00000000 00000040 0004ec1c 00000001 0004ecbc bed58cc8 > bed58cf8 > bfe0: 4010f8f0 bed58c78 000275f4 4010f900 60000010 0000000b de312472 > 0ef2bccf > Backtrace: > [<bf00071c>] (snull_header+0x0/0xac [snull]) from [<c01c47e4>] > (neigh_connected_output+0xa4/0x11c) > [<c01c4740>] (neigh_connected_output+0x0/0x11c) from [<c01d85f0>] > (ip_output+0x2a8/0x31c) > r6 = C038BE80 r5 = 00000000 r4 = C03D7A20 > [<c01d8348>] (ip_output+0x0/0x31c) from [<c01da84c>] > (ip_push_pending_frames+0x448/0x574) > r7 = C1BC8040 r6 = 00000040 r5 = C1BC8040 r4 = C03D7A20 > [<c01da404>] (ip_push_pending_frames+0x0/0x574) from [<c01f64c8>] > (raw_sendmsg+0x324/0x410) > [<c01f61a4>] (raw_sendmsg+0x0/0x410) from [<c01ffad8>] > (inet_sendmsg+0x5c/0x64) > [<c01ffa7c>] (inet_sendmsg+0x0/0x64) from [<c01b2bd4>] > (sock_sendmsg+0xb8/0xd4) > r7 = 00000040 r6 = 00000000 r5 = 00000000 r4 = C1C7BEAC > [<c01b2b1c>] (sock_sendmsg+0x0/0xd4) from [<c01b4160>] > (sys_sendto+0xb4/0xc8) > r6 = 00000000 r5 = C1C7BEC8 r4 = C1C6F080 > [<c01b40ac>] (sys_sendto+0x0/0xc8) from [<c01b4990>] > (sys_socketcall+0x164/0x1f4) > [<c01b482c>] (sys_socketcall+0x0/0x1f4) from [<c0022ce0>] > (ret_fast_syscall+0x0/0x2c) > r5 = 00000000 r4 = BED58C90 > Code: 3a000012 e5954080 e1a00426 e2581000 (e5c4000c) > 92<0>Kernel panic - not syncing: Aiee, killing interrupt handler! > . 168.1.15): 56 data bytes > > Any idea what's wrong? Source code is obviously right. Why is it obviously right? > Whose the fault? > Any pending patch to be applies to kernel tree? Lots, it then becomes 2.6.22 (or pick any version in between :-) > Compiler? Yes, there are newer versions of the toolchain, as pointed out on the arm list, 3.3.2 is known old and buggy. Why not use the newer binary tool chain package for uClinux-dist, at http://ftp.snapgear.org/pub/snapgear/tools/arm-linux/arm-linux-tools-20061213.tar.gz Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
