Steve Lord <lord@xxxxxxx> wrote:
>> Thomas Graichen <graichen@xxxxxxxxxxxxx> wrote:
> In theory this should be true - it is always possible there is a glitch
> lurking out there somewhere. One issue might be how a specific architecture
> lays out a structure in memory. We reply on the compiler to generate the
> correct layout for on disk structures. For example, if you run
> # gdb modules/xfs.o
> you can do things like
> (gdb) print sizeof(xfs_sb_t)
> $1 = 200
> This and other on disk structures need to come out the same size on
> the ppc for things to work.
this one is the same for x86 and ppc - can you just write down the
names of some other structures of interest - so that i may compare
their sizes ?
>> ok - now tried the fix for the ppc >32 shift bug and it now shifts
>> correctly and thus it now also mounts fine with the original xlatesb
>> with the shifts > 32 in it - so this problem is fixed now ... but
>> if i try to write to the filesystem it crashes with
>>
>> XFS assertion failed: indlen > 0, file: xfs_bmap.c, line:4904
> I do not think pagebuf tracing is going to help here (but thanks for
> capturing them).
> This assert is coming out of a very specific function.
> indlen = (xfs_extlen_t)
> xfs_bmap_worst_indlen(ip, alen);
> ASSERT(indlen > 0);
> Instead of just calling ASSERT here, put in an explicit check for
> indlen being less than zero, if it is then print out indlen and
> alen, they are both unsigned 32 bit quantities (which makes the
> assert somewhat bogus). However, indlen should not be huge, it is
> supposed to be the worst case calculation of the amount of disk
> space to hold alen of data (worst case metadata overhead).
i think you meant "greater than zero" ? - if so it's indlen 5 and
alen 16 all time ... what exactly does the ASSERT do and where is
it defined ? (will install lxr as the next step to be able to
navigate through the code better - do you know it - if not it's
really worth a look: http://lxr.linux.no/)
> Adding printk calls to xfs_bmap_worst_indlen would be the next step - it
> is in xfs_bmap.c. Something in this function is probably the cause,
> maybe mp->m_bmap_dmxr[0] or [1] is incorrectly initialized. Printing
> out XFS_BM_MAXLEVELS(mp, XFS_DATA_FORK) would be useful too.
will do that as the next step - btw. i just updated to the current
cvs code and while recompiling it i noticed the following:
gcc -D__KERNEL__ -I/usr/src/xfs/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -D__powerpc__ -fsigned-char -msoft-float -pipe -ffixed-r2
-Wno-uninitialized -mmultiple -mstring -fno-strict-aliasing -DMODULE -g3
-Wno-unused
-Wno-parentheses -Wno-uninitialized -I./linux -I./pseudo-inc -I. -D_KERNEL
-funsigned-char -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG -c -o xfs_vnodeops.o
xfs_vnodeops.c
xfs_vnodeops.c: In function `xfs_allocstore':
xfs_vnodeops.c:5056: warning: comparison is always true due to limited range of
data type
gcc -D__KERNEL__ -I/usr/src/xfs/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -D__powerpc__ -fsigned-char -msoft-float -pipe -ffixed-r2
-Wno-uninitialized -mmultiple -mstring -fno-strict-aliasing -DMODULE -g3
-Wno-unused
-Wno-parentheses -Wno-uninitialized -I./linux -I./pseudo-inc -I. -D_KERNEL
-funsigned-char -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG -c -o xfs_rw.o
xfs_rw.c
xfs_rw.c: In function `xfs_build_gap_list':
xfs_rw.c:662: warning: comparison is always true due to limited range of data
type
which i do not see on the x86 from the same source - both times its
an
ASSERT(count_fsb >= 0LL);
any idea ?
t
--
thomas.graichen@xxxxxxxxxxxxx
technical director innominate AG
clustering & security networking people
tel: +49.30.308806-13 fax: -77 http://innominate.de
|