X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n36Hfweu181344 for ; Mon, 6 Apr 2009 12:42:13 -0500 X-ASG-Debug-ID: 1239039758-6de903c60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 84CC313FA4FD for ; Mon, 6 Apr 2009 10:42:39 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id JNd6xoQLUliazkMG for ; Mon, 06 Apr 2009 10:42:39 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LqsoB-0005IR-PJ; Mon, 06 Apr 2009 17:40:35 +0000 Date: Mon, 6 Apr 2009 13:40:31 -0400 From: Christoph Hellwig To: Christopher Layne Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_trans_log_inode: OOPS in 2.6.28.7 Subject: Re: xfs_trans_log_inode: OOPS in 2.6.28.7 Message-ID: <20090406174030.GA8943@infradead.org> References: <20090402024744.GB23044@ns1.signalpunk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090402024744.GB23044@ns1.signalpunk.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239039779 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Apr 02, 2009 at 02:47:44AM +0000, Christopher Layne wrote: > While I think I might be able to reproduce this it's not something I > particularly want to reproduce. The precursor was cancelling an > already running xfs_fsr, removing the .fsr_last, and immediately > restarting it (forcing a new cycle). Right after I received an OOPS and > all file system access was blocked necessitating a hard reboot and > xfs_repair. The a5a5a5 in there looks like slab poisoning. I'll try to come up with a testcase based on your above report to try to reproduce it.