Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161339AbWBUFHp (ORCPT ); Tue, 21 Feb 2006 00:07:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161340AbWBUFHp (ORCPT ); Tue, 21 Feb 2006 00:07:45 -0500 Received: from mail.clusterfs.com ([206.168.112.78]:6878 "EHLO mail.clusterfs.com") by vger.kernel.org with ESMTP id S1161339AbWBUFHo (ORCPT ); Tue, 21 Feb 2006 00:07:44 -0500 Date: Mon, 20 Feb 2006 22:07:40 -0700 From: Andreas Dilger To: Maurice Volaski Cc: ext3-users@redhat.com, linux-kernel@vger.kernel.org Subject: Re: ext3 involved in kernel panic in 2.6.13? Message-ID: <20060221050740.GB13382@schatzie.adilger.int> Mail-Followup-To: Maurice Volaski , ext3-users@redhat.com, linux-kernel@vger.kernel.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2224 Lines: 51 On Feb 19, 2006 14:09 -0500, Maurice Volaski wrote: > A panic occurred, which contains references to ext3 code. > > I'm not sure how others manage to get these typed out, Normally a serial console is best, and if you have at least 2 machines you can cross-connect the serial ports with a NULL-modem cable and run a terminal emulator (e.g. minicom) to log it to disk on the other system. Having netdump is also a good choice, though maybe not quite as reliable as a real serial console. > but I'm manually typing it from what's on the monitor: > > Call Trace: {i8042_interrupt+111} > {commit_timeout+0} > {run_timer_softirq+387} > {__do_softirq+113} > {call_softirq+31} {do_softirq+53} > {apic_timer_interrupt+132} At this point (and above) the process is in an IRQ handler, so it is likely that the problem exists somewhere at that level. However, the critical part of the oops is missing - what actually went wrong? It could be a BUG, which is a kernel assertion, or it could be a bad pointer dereference, or anything really. There is nothing here which indicates what the problem is. > {do_get_write_access+118} > {do_get_write_access+94} {__getblk+47} > {filldir+0} > {journal_get_write_access+41} > {ext3_reserve_inode+write+76} > {filldir+0} > {ext3_mark_inode_dirty+56} > {journal_start_229} > {ext3_dirty_inode+113} > {__mark_inode_dirty+52} > {update_atime+123} {vfs_readdir+166} > {syst_getdents+130} {sys_fcntl+830} > {system_call+126} Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/