Kernel Panic while building IP or TCP hash tables

Kernel Panic while building IP or TCP hash tables

[Gérard Guével]

Hi,

After many days of tests, I can say that the system does not crash anymore
with the patch installed.

The most difficult thing is to determine the frames which generate the
kernel panic.
I can exclude arp broadcast frames and ip unicast frames.
It seems that the multicast frames are the origin of the system crash but I
can't say
if it is the only case.

The system runs in any case with the patch. Use it !!!

Thanks to Jean-Denis Boyer

Gérard Guével


-----Message d'origine-----
De : Jean-Denis Boyer [mailto:jdboyer@m5t.com]
Envoyé : jeu. 5 juin 2003 14:09
À : Gérard Guével
Cc : linuxppc-embedded@lists.linuxppc.org
Objet : RE: Kernel Panic while building IP or TCP hash tables



I experienced a similar problem with my system, I was not sure if it was
specific to my implementation. Can you try the following patch and tell us
if it helps?

It registers the IPv4 handling functions AFTER initializing the IP routing
stuff. Early packets could enter the stack and crash the system.

--- Kernel.old/net/ipv4/ip_output.c     Thu Jun  5 09:00:39 2003
+++ Kernel/net/ipv4/ip_output.c Thu Jun  5 09:00:28 2003
@@ -1087,11 +1087,11 @@

 void __init ip_init(void)
 {
-       dev_add_pack(&ip_packet_type);
-
        ip_rt_init();
        inet_initpeers();

+       dev_add_pack(&ip_packet_type);
+
 #ifdef CONFIG_IP_MULTICAST
        proc_net_create("igmp", 0, ip_mc_procinfo);
 #endif


Salutations,

--------------------------------------------
 Jean-Denis Boyer, Software Designer
 M5T Centre d'Excellence en Télécom Inc.
 4283 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA
 (819)829-3972 x241
--------------------------------------------


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Kernel Panic while building IP or TCP hash tables

[Gérard Guével]

Hi,

After many days of tests, I can say that the system does not crash
anymore with the patch installed.

The most difficult thing is to determine the frames which generate the
kernel panic. I can exclude arp broadcast frames and ip unicast frames.
It seems that the multicast frames are the origin of the system crash
but I can't say if it is the only case.

The system runs in any case with the patch. Use it !!!

Thanks to Jean-Denis Boyer

Gérard Guével

-----Message d'origine-----
De : Jean-Denis Boyer [mailto:jdboyer@m5t.com]
Envoyé : jeu. 5 juin 2003 14:09
Objet : RE: Kernel Panic while building IP or TCP hash tables

I experienced a similar problem with my system, I was not sure if it was
specific to my implementation. Can you try the following patch and tell
us if it helps?

It registers the IPv4 handling functions AFTER initializing the IP
routing stuff. Early packets could enter the stack and crash the system.

--- Kernel.old/net/ipv4/ip_output.c     Thu Jun  5 09:00:39 2003
+++ Kernel/net/ipv4/ip_output.c Thu Jun  5 09:00:28 2003
@@ -1087,11 +1087,11 @@

 void __init ip_init(void)
 {
-       dev_add_pack(&ip_packet_type);
-
        ip_rt_init();
        inet_initpeers();

+       dev_add_pack(&ip_packet_type);
+
 #ifdef CONFIG_IP_MULTICAST
        proc_net_create("igmp", 0, ip_mc_procinfo);
 #endif

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Kernel Panic while building IP or TCP hash tables

[Jean-Denis Boyer]

I experienced a similar problem with my system, I was not sure if it was specific to my implementation. Can you try the following patch and tell us if it helps?

It registers the IPv4 handling functions AFTER initializing the IP routing stuff. Early packets could enter the stack and crash the system.

--- Kernel.old/net/ipv4/ip_output.c     Thu Jun  5 09:00:39 2003
+++ Kernel/net/ipv4/ip_output.c Thu Jun  5 09:00:28 2003
@@ -1087,11 +1087,11 @@

 void __init ip_init(void)
 {
-       dev_add_pack(&ip_packet_type);
-
        ip_rt_init();
        inet_initpeers();

+       dev_add_pack(&ip_packet_type);
+
 #ifdef CONFIG_IP_MULTICAST
        proc_net_create("igmp", 0, ip_mc_procinfo);
 #endif


Salutations,

--------------------------------------------
 Jean-Denis Boyer, Software Designer
 M5T Centre d'Excellence en Télécom Inc.
 4283 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA
 (819)829-3972 x241
--------------------------------------------

> -----Original Message-----
> From: Gérard Guével [mailto:gguevl@interfaceconcept.com]
> Sent: 5 juin, 2003 08:49
> To: linuxppc-embedded@lists.linuxppc.org
> Subject: Kernel Panic while building IP or TCP hash tables
>
>
>
> Hello,
>
> I'm running the Elinos 2.4.18 linux kernel on a custom 8260 board.
>
> I have the following kernel panic only if I receive a broadcast or
> unicast frame while the system is building the IP routing cache hash
> table or the TCP hash tables.
>
> Since I can see the start of the "IP: routing ..." string, I think
> the kernel panic occurs before the TCP phase if the printk is,
> as I suppose, a blocking (synchronized ?) write function.
>
> ...
> eth0: FCC ENET Version 0.3, 00:10:cd:31:18:20
> eth1: FCC ENET Version 0.3, 00:10:cd:31:18:21
> eth2: FCC ENET Version 0.3, 00:10:cd:31:18:22
> loop: loaded (max 8 devices)
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMP
> IP: routing <4>Oops: kernel access of bad area, sig: 11
> NIP: C0090A9C XER: 00000000 LR: C0093528 SP: C0599CA0 REGS:
> c0599bf0 TRAP:
> 0300d
> MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> DAR: 75DCDC7A, DSISR: 20000000
> TASK = c0598000[1] 'swapper' Last syscall: 120
> last math 00000000 last altivec 00000000
> GPR00: 00222298 C0599CA0 C0598000 C05B4080 A8020B0D A8020A0D 00000000
> 00000003
> GPR08: C0120000 C0100000 75DCDBFE C0100000 0000000D 0006B270 AAA96041
> FF010000
> GPR16: 00008149 0A114000 FF010000 41DA5241 00001032 000000BD 0000012B
> C00F5040
> GPR24: 0000012C C05B8400 C05B84DC C05B8400 A8020A0D 00000000 C05B4080
> A8020B0D
> Call backtrace:
> 00000000 C0093528 C0084C20 C00181E0 C00070D8 C0005F2C 73747576
> 000081A4 C0012DA4 C0012E3C C0012F5C C00132A0 C0013194 C00FEAF0
> C00FED54 C00FF5DC C00F67A0 C00F739C C0005B00 C000848C
> Kernel panic: Aiee, killing interrupt handler!
>
> For information the right start is like :
> ...
> eth0: FCC ENET Version 0.3, 00:10:cd:31:17:a0
> eth1: FCC ENET Version 0.3, 00:10:cd:31:17:a1
> eth2: FCC ENET Version 0.3, 00:10:cd:31:17:a2
> loop: loaded (max 8 devices)
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMP
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 2048 bind 2048)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> VFS: Mounted root (ramfs filesystem).
> UNTAR: Extracting root archive: do..
> init started:  BusyBox v0.60.5 (2003î2.20-13:09+0000) multi-call
>
>
> Thanks in advance
> Gérard
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Problem with FCC under 2.4.18 kernel

[Gérard Guével]

Hello,

I'm running the 2.4.18 linux kernel on a custom 8260 board.

Sometimes I have the following problem with the ethernet 0 device while
using a NFS.
	Sending BOOTP requests . OK
	IP-Config: Got BOOTP answer from 192.168.1.65, my address is 192.168.1.145
	IP-Config: Complete:
      	device=eth0, addr=192.168.1.145, mask=255.255.255.0,
gw=255.255.255.255,
     	host=192.168.1.145, domain=, nis-domain=(none),
     	bootserver=192.168.1.65, rootserver=192.168.1.65,
rootpath=/home/targetnfs/ver_cour
	NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
	Looking up port of RPC 100003/2 on 192.168.1.65
	Looking up port of RPC 100005/1 on 192.168.1.65
	VFS: Mounted root (nfs filesystemÿ
	Oops: kernel access of bad area, sig: 11
	NIP: C002AF58 XER: 00000000 LR: C002AEF8 SP: C010B1F0 REGS: c010b140 TRAP:
0300    Not tainted
	MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
	DAR: 401F66D4, DSISR: 20000000
	TASK = c0109430[0] 'swapper' Last syscall: 120
	last math c1f9e000 last altivec 00000000
	GPR00: DFFFFFFF C010B1F0 C0109430 00000001 00009032 C010B300 00000004
C01F66C0
	GPR08: C1F84000 401F66BC 00000800 00000003 42000022 1005D7A0 34068873
FF010000
	GPR16: 8AC410E4 CA800C11 FF010000 78E4841E 00001032 0010B2F0 00000000
C0003F8C
	GPR24: C000506C 00000400 00000000 C0150000 00000020 C01565E8 C010B1F8
C01565E0
	Call backtrace:
	C00C34CC C008E648 C008A5D0 C008A224 C0004F90 C00050C0 C0003F8C
	C00203F0 C00055F8 C0005620 C0003910 C0119718 0000372C
	Kernel panic: Aiee, killing interrupt handler!
	In interrupt handler - not syncing

The last function calls are fcc_enet_rx and alloc_skb.

The problem happens while I mount the NFS or later while the init phase is
running.
If I can enter under the busybox application, I have no more problem with
the fcc device.

I can increase the problem frequency if I ping on the target while the boot
phase.
It seems the problem happens if I receive frames during this boot phase.
With an embedded ramdisk, it works fine.

Does anyone already meet this situation ?

Thanks in advance.
Gérard


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Kernel Panic while building IP or TCP hash tables

[Gérard Guével]

Hello,

I'm running the Elinos 2.4.18 linux kernel on a custom 8260 board.

I have the following kernel panic only if I receive a broadcast or
unicast frame while the system is building the IP routing cache hash
table or the TCP hash tables.

Since I can see the start of the "IP: routing ..." string, I think
the kernel panic occurs before the TCP phase if the printk is,
as I suppose, a blocking (synchronized ?) write function.

...
eth0: FCC ENET Version 0.3, 00:10:cd:31:18:20
eth1: FCC ENET Version 0.3, 00:10:cd:31:18:21
eth2: FCC ENET Version 0.3, 00:10:cd:31:18:22
loop: loaded (max 8 devices)
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing <4>Oops: kernel access of bad area, sig: 11
NIP: C0090A9C XER: 00000000 LR: C0093528 SP: C0599CA0 REGS: c0599bf0 TRAP:
0300d
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 75DCDC7A, DSISR: 20000000
TASK = c0598000[1] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: 00222298 C0599CA0 C0598000 C05B4080 A8020B0D A8020A0D 00000000
00000003
GPR08: C0120000 C0100000 75DCDBFE C0100000 0000000D 0006B270 AAA96041
FF010000
GPR16: 00008149 0A114000 FF010000 41DA5241 00001032 000000BD 0000012B
C00F5040
GPR24: 0000012C C05B8400 C05B84DC C05B8400 A8020A0D 00000000 C05B4080
A8020B0D
Call backtrace:
00000000 C0093528 C0084C20 C00181E0 C00070D8 C0005F2C 73747576
000081A4 C0012DA4 C0012E3C C0012F5C C00132A0 C0013194 C00FEAF0
C00FED54 C00FF5DC C00F67A0 C00F739C C0005B00 C000848C
Kernel panic: Aiee, killing interrupt handler!

For information the right start is like :
...
eth0: FCC ENET Version 0.3, 00:10:cd:31:17:a0
eth1: FCC ENET Version 0.3, 00:10:cd:31:17:a1
eth2: FCC ENET Version 0.3, 00:10:cd:31:17:a2
loop: loaded (max 8 devices)
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 2048)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ramfs filesystem).
UNTAR: Extracting root archive: do..
init started:  BusyBox v0.60.5 (2003î2.20-13:09+0000) multi-call


Thanks in advance
Gérard


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/