From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [Bugme-new] [Bug 10767] New: Seg Fault Instead of Swapping Date: Wed, 21 May 2008 11:53:46 -0700 Message-ID: <20080521115346.21bf74f3.akpm@linux-foundation.org> References: <20080521105747.215be17d.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, bugme-daemon@bugzilla.kernel.org, =?ISO-8859-1?Q? "Ilpo_J=E4rvinen" ?= To: "Brian Vowell" Return-path: Received: from smtp1.linux-foundation.org ([140.211.169.13]:39061 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936602AbYEUSx4 (ORCPT ); Wed, 21 May 2008 14:53:56 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 21 May 2008 11:40:43 -0700 "Brian Vowell" wrote: > Please forgive my lack of technical skills-- I am not a developer. Thank you for reporting this kernel bug! > The bug report referenced below recently occurred on a pretty busy file > server of mine running Fedora 8 with a custom 2.6.25.4 kernel. The attached > hardware RAID controller presents 12 LUNs, which were striped using the > Linux mdadm tools, and then the Linux LVM was used to create a single > logical volume. The filesystem used is XFS. > > Since upgrading from 2.6.25.3 to 2.6.25.4, my log has shown a large number > of errors that I don't possess the skills to diagnose which component is > actually causing the errors. I can verify however, that the hardware is > good. I have run memtest86 and the vendor's diagnostic tools and verified > that everything is running well. > > The errors in /var/log/messages look like this: > May 19 06:30:30 ishtar kernel: Call Trace: > May 19 06:30:30 ishtar kernel: [] > __alloc_pages+0x33f/0x35a > May 19 06:30:30 ishtar kernel: [] do_IRQ+0x13e/0x15f > May 19 06:30:30 ishtar kernel: [] new_slab+0x3f/0x242 > May 19 06:30:30 ishtar kernel: [] > __slab_alloc+0x212/0x43b > May 19 06:30:30 ishtar kernel: [] > __netdev_alloc_skb+0x29/0x43 > May 19 06:30:30 ishtar kernel: [] > __netdev_alloc_skb+0x29/0x43 > May 19 06:30:30 ishtar kernel: [] > __kmalloc_node_track_caller+0x75/0xab > May 19 06:30:30 ishtar kernel: [] __alloc_skb+0x6a/0x133 > May 19 06:30:30 ishtar kernel: [] > __netdev_alloc_skb+0x29/0x43 > May 19 06:30:30 ishtar kernel: [] > tg3_alloc_rx_skb+0xc4/0x153 > May 19 06:30:30 ishtar kernel: [] tg3_poll+0x3be/0x7df > May 19 06:30:30 ishtar kernel: [] > net_rx_action+0xb6/0x1bf > May 19 06:30:30 ishtar kernel: [] __do_softirq+0x65/0xce > May 19 06:30:30 ishtar kernel: [] call_softirq+0x1c/0x28 > May 19 06:30:30 ishtar kernel: [] do_softirq+0x2c/0x68 > May 19 06:30:30 ishtar kernel: [] irq_exit+0x3f/0x83 > May 19 06:30:30 ishtar kernel: [] do_IRQ+0x13e/0x15f > May 19 06:30:30 ishtar kernel: [] ret_from_intr+0x0/0xa > May 19 06:30:30 ishtar kernel: [] > default_idle+0x0/0x55 > May 19 06:30:30 ishtar kernel: [] > lapic_next_event+0x0/0xa > May 19 06:30:30 ishtar kernel: [] default_idle+0x0/0x55 > May 19 06:30:30 ishtar kernel: [] default_idle+0x31/0x55 > May 19 06:30:30 ishtar kernel: [] default_idle+0x2c/0x55 > May 19 06:30:30 ishtar kernel: [] default_idle+0x0/0x55 > May 19 06:30:30 ishtar kernel: [] cpu_idle+0x77/0x9a > > The hardware is an HP Proliant DL145G2, Dual Core Opteron 275 processor, 4GB > of RAM, dual Broadcom GigE NICs bonded with Linux bonding driver, dual > software RAID SATA disks for boot and swap. > > The call trace included with the bug report is the only one that appears in > the log with the "cut here" lines. > OK, that is the TCP code performing self-checks and finding an unexpected state. I was just a bit concerned about the "segfault" part of the description. Because often when the kernel crashes this appears to the operator as a userspace segfault. But the above trace isn't a kernel crash - it's just a warning and the kernel does attept to fix things up in this case. If however you were really seeing unexpected segfaults then it could be the case that the kernel is crashing. But I assume this is not the case, and that the text "Oops" does not appear in the logs.