From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 18 Feb 2003 12:46:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 18 Feb 2003 12:46:29 -0500 Received: from caramon.arm.linux.org.uk ([212.18.232.186]:3851 "EHLO caramon.arm.linux.org.uk") by vger.kernel.org with ESMTP id ; Tue, 18 Feb 2003 12:46:27 -0500 Date: Tue, 18 Feb 2003 17:56:26 +0000 From: Russell King To: linux-kernel@vger.kernel.org Subject: IP/ICMP networking oddity Message-ID: <20030218175626.A9785@flint.arm.linux.org.uk> Mail-Followup-To: linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi, I'm seeing the following weird behaviour in the IP layer. While pinging a 2.5.62 machine with: "ping -s 16000 -f", I get a number of: eth0: Far too big packet error. errors (from the smc9194.c driver.) This message is displayed when the transmit path encounters a packet which is too large for it to send. Displaying the size of these over-sized packets (skb->len), it turns out ot be 16042 bytes, despite ifconfig reporting a MTU of 1500 bytes for the interface. I added a BUG() in the complaint path and got the backtrace below. In addition, I don't see the outgoing ICMP echo replies in tcpdump, although I do see incoming ICMP echo requests, along with TCP, ARP and UDP traffic in both directions. Also, the ethernet interface has RX, TX, link and CPU access activity indicators - despite the RX and CPU activity LEDs being permanently lit during the flood ping, but the TX LED is mostly off. It seems that ICMP echo replies are somehow missing the IP fragmentation process (despite it appearing in the backtrace.) Please note that while this flood ping is in effect, NFS appears to be happy on 2.5.62 accessing other machines on the network with very little latency. [] (smc_wait_to_send_packet+0x0/0x32c) from [] (qdisc_restart+0x9c/0x198) [] (qdisc_restart+0x0/0x198) from [] (dev_queue_xmit+0x108/0x3d4) [] (dev_queue_xmit+0x0/0x3d4) from [] (ip_finish_output+0x210/0x294) [] (ip_finish_output+0x0/0x294) from [] (ip_fragment+0x76c/0x870) [] (ip_fragment+0x0/0x870) from [] (ip_output+0x78/0x300) [] (ip_output+0x0/0x300) from [] (ip_push_pending_frames+0x36c/0x458) [] (ip_push_pending_frames+0x0/0x458) from [] (icmp_push_reply+0xec/0xf8) [] (icmp_push_reply+0x0/0xf8) from [] (icmp_reply+0x180/0x1e4) [] (icmp_reply+0x0/0x1e4) from [] (icmp_echo+0x5c/0x64) [] (icmp_echo+0x0/0x64) from [] (icmp_rcv+0x17c/0x1e0) [] (icmp_rcv+0x0/0x1e0) from [] (ip_local_deliver+0x154/0x260) [] (ip_local_deliver+0x0/0x260) from [] (ip_rcv+0x460/0x504) [] (ip_rcv+0x0/0x504) from [] (netif_receive_skb+0x1c0/0x210) [] (netif_receive_skb+0x0/0x210) from [] (process_backlog+0xa4/0x17c) [] (process_backlog+0x0/0x17c) from [] (net_rx_action+0x98/0x1b0) [] (net_rx_action+0x0/0x1b0) from [] (do_softirq+0x84/0xec) [] (do_softirq+0x0/0xec) from [] (__do_softirq+0x8/0x20) [] (asm_do_IRQ+0x0/0xd8) from [] (__irq_svc+0x34/0xac) -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html