On Fri, Sep 18, 2015 at 06:38:38PM +0200, Angelo Dureghello wrote: > Hi all, > > working on arm (32bit arch), kernel 4.1.6. Is this a new platform? Also, we need to know what compiler you are using, because we know that certain versions of gcc miscompile XFS kernel code on arm (4.6, 4.7 and certain versions of 4.8 are suspect) due to a combination of compiler mis-optimisations and kernel bugs in the arm 64 bit division asm implementation. As such, it would be worthwhile trying gcc-4.9 and a 4.3-rc1 kernel to see if the problems still occur. > Looking to find the reason of some bad results on xfstests, > > -tests/generic/009 > ------------------ > i get several "all holes" messages > > generic/009 [ 842.949643] run fstests generic/009 at 2015-09-18 > 15:29:36 > - output mismatch (see > /home/angelo/xfstests/results//generic/009.out.bad) > --- tests/generic/009.out 2015-09-17 10:54:06.689071257 +0000 > +++ /home/angelo/xfstests/results//generic/009.out.bad > 2015-09-18 15:29:41.412784177 +0000 > @@ -1,79 +1,45 @@ > QA output created by 009 > 1. into a hole > -0: [0..7]: hole > -1: [8..23]: unwritten > -2: [24..39]: hole > +0: [0..39]: hole > daa100df6e6711906b61c9ab5aa16032 > > also some other tests are giving the same bad notices. Can you attach the entire /home/angelo/xfstests/results//generic/009.out.bad file? I'm not sure which of the tests this output comes from, so I need to confirm which specific operations are resulting in errors. > -tests/generic/308 > ------------------ > > I have now: CONFIG_LBDAF=y > > In my target device this test creates a 16 Terabytes file 308.tempfile > > -rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 > > While "df" is not complaining about: > > /dev/mmcblk0p5 8378368 45252 8333116 1% /media/p5 > > and next rm -f on it hands the cpu to 95%, forever. > > This issue seems known from a long time, as it has been discussed in > the thread: > > http://oss.sgi.com/archives/xfs/2013-04/msg00273.html > > I was wondering if there was any special reason why the Jeff patch has > never been finally applied. MAX_LFS_FILESIZE on 32 bits is 8TB, whereas xfs supports 16TB file size on 32 bit systems. The specific issue this test fixed was committed in commit 8695d27 ("xfs: fix infinite loop at xfs_vm_writepage on 32bit system") http://oss.sgi.com/archives/xfs/2014-05/msg00447.html And, as you may notice now, generic/308 is the test case for the exact problem the above commit fixed. Can you find out exactly where the CPU is looping? sysrq-l will help, as will running 'perf top -U -g' to show you the hot code paths, and so on. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
