I have had the problem before (and so has several other people)
This is a reply I got on the old Linux PPC mailinglist last year
(from Gerard Guevel [gguevel at interfaceconcept.com])
---- Original message -----
RE: FCC ethernets not stable
I received the right solution from Jean-Denis Boyer (thanks to him...)
>>
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
>>
I never saw this problem after installing this patch.
Regards
Gerard Guevel
> -----Original Message-----
> From: linuxppc-embedded-bounces at ozlabs.org
> [mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of
> Steffen Rumler
> Sent: Wednesday, January 12, 2005 02:38
> To: linuxppc
> Subject: Kernel boot hangs by parallel flood pings
>
> I'm using a 2.4.20 kernel (PPC).
>
> When I run multiple 'ping -f' directed to my board
> during the kernel boots, sometimes it hangs with
> the following messages:
>
>
> Memory BAT mapping: BAT2=64Mb, BAT3=32Mb, residual: 84Mb
> Linux version 2.4.20-rthal5 (ru at styx) (gcc version 2.95.3
> 20010111 (prerelease/franzo/20010111))
> #9 Tue Jan 11 17:09:22 CET 2005
> On node 0 totalpages: 29859
> zone(0): 29859 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: bootdev=aps0
> ip=218.1.36.70:218.1.36.47:218.1.36.254:255.255.255.0::eth0:off
> panic=1 mem=119436k
> Calibrating delay loop... 194.15 BogoMIPS
> ...
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> IP: routing cache ha
> ^^^^^^^
> the kernel boot hangs here
>
>
> I have checked this with the BDI2000 and found that the
> kernel loops anywhere inside ip_route_input().
>
> I think this is because the ethernet driver (fcc_enet.c)
> enables the hardware too already inside it's init routine
> (fec_enet_init()).
>
> In this way, frames may be received and forwarded to the upper
> layers with netif_rx(), before the TCP/IP was initialized.
>
> I suggest to delay the lines
>
> /* Enable transmit/receive */
> fccp->fcc_gfmr |= FCC_GFMR_ENR | FCC_GFMR_ENT;
>
> to the open entry point (fcc_enet_open()), which is
> triggered by 'ifconfig up' in the following way:
>
>
> if(!((fccp->fcc_gfmr) & FCC_GFMR_ENR))
> fccp->fcc_gfmr |= (FCC_GFMR_ENR | FCC_GFMR_ENT);
>
> By the way, fcc_enet_close() does _NOT_ stop the hardware.
> Hopefully, this is not a real problem.
>
>
> Steffen
>
> --
>
>
> --------------------------------------------------------------
>
> Steffen Rumler
> ICN CP D NT SW 3
> Siemens AG
> Hofmannstr. 51 Email: Steffen.Rumler at siemens.com
> D-81359 Munich Phone: +49 89 722-44061
> Germany Fax : +49 89 722-36703
>
> --------------------------------------------------------------
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
