[Top] [All Lists]

Re: SGI XFS on ppc

To: Thomas Graichen <graichen@xxxxxxxxxxxxx>, thomas.graichen@xxxxxxxxxxxxx
Subject: Re: SGI XFS on ppc
From: Steve Lord <lord@xxxxxxx>
Date: Thu, 03 Aug 2000 08:42:10 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: Message from Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx> of "03 Aug 2000 05:36:11 GMT." <news2mail-8mb0cb$jdp$2@xxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs-announce@xxxxxxxxxxx

This is a bit of a shock in the dark, but here goes.....

there are two things you can try:

1. in xfs_bit.c try undefining _MIPS_SIM after the header file includes.
   (we need to generalize the name of this define - it is a hang over from
    the irix code). Undefining it will cause all the masking code to
   use 32 bit quantities.

   An alternative in this file is to try putting LL at the end of the 64
   bit constants. I do not know how well the ppc compiler copes with
   constants like this - if this turns out to be the problem then we will
   need to look all over XFS for constants which are not explicitly typed
   to be 64 bit.

   The body of this function is identical to the code on Irix - where XFS is
   on a big endian cpu, so the function itself does not have problems.

2. in xfs_xlatesb try changing this statement at the end of the function:

   fields &= ~(1LL << f);

   to be

   fields &= ~(1LL << (long long)f);

   Here a 64 bit mask value is being generated - it may also be something
   the compiler has issues with. A simple user space test would be this

   unsigned int i;

   for (i = 0; i < 64; i++) {
        printf("Mask %d is 0x%llx", ~(1LL << i));

   If the compiler was truncating the mask to be 32 bits the behavior you
   are seeing could be explained.

news-innominate.list.sgi.xfs@xxxxxxxxxxxxx said:
>> but here it crashed with
>> pb 0xc3272380 [unlock] (hold 1 lock 1) misc 0x00000000
>>     address 0xc5870e64
>>     offset 0x400 size 0x200 task 0xc108c000
>> MEM_ALLOCATED XFS assertation failed: indlen > 0, file: xfs_bmap.c,
>> line: 4904 kernel BUG at xfs_debug.c:50! 

Go to this location in the file and change the assert to read:

        ASSERT(indlen > 0LL);

again this could be a 64 bit issue (since indlen is 64 bit).


> > You'll need xfs_lowbit64 to be correct for everything to work, so it
> > would be worth checking it out...
> > Let me know how you get on.
> ok - i now switched back to use xlatesb again and added a printk for
> f and the result is: it runs from 0 to 33 and then loops at 33 - looks
> a bit like some 64bit issue ... what to look for next ?
> t
> -- 
> thomas.graichen@xxxxxxxxxxxxx
> technical director                                       innominate AG
> clustering & security                                networking people
> tel: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr

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