From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261270AbUBWMUI (ORCPT ); Mon, 23 Feb 2004 07:20:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261332AbUBWMUI (ORCPT ); Mon, 23 Feb 2004 07:20:08 -0500 Received: from phoenix.infradead.org ([213.86.99.234]:6925 "EHLO phoenix.infradead.org") by vger.kernel.org with ESMTP id S261270AbUBWMUB (ORCPT ); Mon, 23 Feb 2004 07:20:01 -0500 Date: Mon, 23 Feb 2004 12:19:59 +0000 From: Christoph Hellwig To: Mikael Wahlberg Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Filesystem kernel hangup, 2.6.3 (bad: scheduling while atomic!) Message-ID: <20040223121959.A8354@infradead.org> Mail-Followup-To: Christoph Hellwig , Mikael Wahlberg , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20040222164941.D6046@foo.ardendo.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040222164941.D6046@foo.ardendo.se>; from Mikael.Wahlberg@ardendo.se on Sun, Feb 22, 2004 at 04:49:41PM +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 22, 2004 at 04:49:41PM +0100, Mikael Wahlberg wrote: > Description: > > On heavy FTP Load (About 1Gbit/s) running both reads and writes on two ServeRAID6m Raid5 controllers merged together to one filesystem with Raidtools we see the error below. The filesystem gets totally hanged up. Currently with XFS, but JFS gets the same problem (Actually even more often). What does the JFS oops look like? > Feb 22 15:00:53 mserv1 kernel: [] __wake_up_common+0x3a/0x60 > Feb 22 15:00:53 mserv1 kernel: [] __wake_up+0x3f/0x70 This doesn't make a lot of sense, there's only two mrlocks in XFS, and they're in the inodes that have well-defined and understood lifetime rules. OTOH the previos oops might have messed quite a bit up in your system. did you run memtest86 on the box? do you some strange patches applied or external modules loaded? What's your .config? > Feb 22 15:00:54 mserv1 kernel: [] do_page_fault+0x0/0x523 > Feb 22 15:00:54 mserv1 kernel: [] error_code+0x2d/0x38 > Feb 22 15:00:54 mserv1 kernel: [] __wake_up+0x45/0x70 > Feb 22 15:00:54 mserv1 kernel: [] __wake_up_common+0x3a/0x60 > Feb 22 15:00:55 mserv1 kernel: [] __wake_up+0x3f/0x70 > Feb 22 15:00:55 mserv1 kernel: [] mrunlock+0x82/0xb0 > Feb 22 15:00:55 mserv1 kernel: [] mraccessf+0xc0/0xe0 > Feb 22 15:00:55 mserv1 kernel: [] xfs_iunlock+0x3e/0x80 > Feb 22 15:00:55 mserv1 kernel: [] xfs_iomap+0x3bb/0x540 > Feb 22 15:00:55 mserv1 kernel: [] bio_alloc+0xd7/0x1c0 > Feb 22 15:00:55 mserv1 kernel: [] map_blocks+0x7a/0x170 > Feb 22 15:00:55 mserv1 kernel: [] page_state_convert+0x52b/0x6d0 > Feb 22 15:00:55 mserv1 kernel: [] xfs_imap_to_bmap+0x39/0x240 > Feb 22 15:00:55 mserv1 kernel: [] linvfs_release_page+0xa8/0xb0 > Feb 22 15:00:55 mserv1 kernel: [] linvfs_writepage+0x60/0x120 > Feb 22 15:00:55 mserv1 kernel: [] shrink_list+0x41c/0x710 > Feb 22 15:00:55 mserv1 kernel: [] shrink_cache+0x1f8/0x3d0 > Feb 22 15:00:55 mserv1 kernel: [] journal_stop+0x220/0x330 > Feb 22 15:00:55 mserv1 kernel: [] shrink_zone+0xbc/0xc0 > Feb 22 15:00:55 mserv1 kernel: [] shrink_caches+0xc5/0xe0 > Feb 22 15:00:55 mserv1 kernel: [] try_to_free_pages+0xbc/0x190 > Feb 22 15:00:55 mserv1 kernel: [] __alloc_pages+0x203/0x370 > Feb 22 15:00:55 mserv1 kernel: [] __get_free_pages+0x25/0x40 Hmm, from the trace it looks like ->release_page was called from a context where we can't sleep. XFS defintily doesn't handle that, so the question is whether the kernel should do it.