xfs
[Top] [All Lists]

Re: 3.9-rc2 xfs panic

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: 3.9-rc2 xfs panic
From: CAI Qian <caiqian@xxxxxxxxxx>
Date: Tue, 12 Mar 2013 04:04:11 -0400 (EDT)
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130312074608.GL21651@dastard>

----- Original Message -----
> From: "Dave Chinner" <david@xxxxxxxxxxxxx>
> To: "CAI Qian" <caiqian@xxxxxxxxxx>
> Cc: xfs@xxxxxxxxxxx
> Sent: Tuesday, March 12, 2013 3:46:08 PM
> Subject: Re: 3.9-rc2 xfs panic
> 
> On Tue, Mar 12, 2013 at 02:34:07AM -0400, CAI Qian wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Dave Chinner" <david@xxxxxxxxxxxxx>
> > > To: "CAI Qian" <caiqian@xxxxxxxxxx>
> > > Cc: xfs@xxxxxxxxxxx
> > > Sent: Tuesday, March 12, 2013 2:07:01 PM
> > > Subject: Re: 3.9-rc2 xfs panic
> > > 
> > > On Tue, Mar 12, 2013 at 12:32:28AM -0400, CAI Qian wrote:
> > > > Just came across when running xfstests using 3.9-rc2 kernel on
> > > > a
> > > > power7
> > > > box with addition of this patch which fixed a known issue,
> > > > http://people.redhat.com/qcai/stable/01-fix-double-fetch-hlist.patch
> > > > 
> > > > The log shows it was happened around test case 370 with
> > > > TEST_PARAM_BLKSIZE = 2048
> > > 
> > > That doesn't sound like xfstests. it only has 305 tests, and no
> > > parameters like TEST_PARAM_BLKSIZE....
> > Sorry, it is a typo, test case 270 not 370. TEST_PARAM_BLKSIZE was
> > from an internal wrapper to be used to create new filessytem not
> > from the
> > original xfstests.
> 
> OK, so that means you're testing 2k filesystem block size on a 64k
> page size machine?
Looks like so. Would that be a problem?

TEST_PARAM_TEST_DEV not specified; using loopback file
TEST_PARAM_SCRATCH_DEV not specified; using loopback file
meta-data=/dev/loop0             isize=256    agcount=4, agsize=655360 blks
         =                       sectsz=512   attr=2, projid32bit=0
data     =                       bsize=2048   blocks=2621440, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=2048   blocks=5120, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
TEST_DEV=/dev/loop0                             # device containing TEST 
PARTITION
TEST_DIR=/mnt/testarea/test                             # mount point of TEST 
PARTITION
SCRATCH_DEV=/dev/loop1                  # device containing SCRATCH PARTITION
SCRATCH_MNT=/mnt/testarea/scratch                       # mount point for 
SCRATCH PARTITION
SCRATCH_LOGDEV=                 # optional external log for SCRATCH PARTITION
SCRATCH_RTDEV=                  # optional realtime device for SCRATCH PARTITION
TMPFS_MOUNT_OPTIONS=""  # scratch mount options for tmpfs
TEST_FS_MOUNT_OPTS=""   # test mount options for tmpfs
> Are you running with CONFIG_XFS_DEBUG=y?
# CONFIG_XFS_DEBUG is not set
I can enable this if I can reproduce it.
> 
> > > So, looks like memory corruption - a corrupted slab, perhaps? Can
> > > you turn on memory poisoning, debugging, etc?
> 
> Does this turn anything up?
It is still running. Unsure if it is reproducible at this point.
CAI Qian
> 
> Cheers,
> 
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
> 

<Prev in Thread] Current Thread [Next in Thread>