Thomas Graichen wrote:
This may be an off question, but what version of gcc are you using?
We've seen shift problems with the 2.95.x versions.
> Steve Lord <lord@xxxxxxx> wrote:
>
> > So I am officially stumped, one comment on your earlier email though,
> > %ll does not work for long long in the kernel as you pointed out, but
> > %L does.
>
> %L does not too - %l does but this is the wrong one for long long ...
>
> > We know that the code:
>
> > fields &= ~(1LL << f);
>
> > should do the right thing, which tends to imply xfs_lowbit64 is messing
> > up somehow - or the casting being used around the call to it is
> > messing up.
>
> i am so far now that i am shure that there is a bug somewhere in
> the ppc code for doing shifts for 64bit ints - i nailed it down
> to the following test:
>
> unsigned int myint;
>
> for (myint = 0; myint < 64; myint++) {
> printf("Mask %d is ",myint);
> printf("0x%8x", (int)((1LL << myint) >> 32));
> printf("%8x - ", (int)(1LL << myint));
> printf("0x%8x", (int)(~(1LL << myint) >> 32));
> printf("%8x\n", (int)(~(1LL << myint)));
> }
>
> which is used to run around the missing %llx (i hope all the shifting
> stuff is doing the right here to put together the full 64bit number
> from it's two 32bit parts which i can printk fine)
>
> this code results in
>
> ...
> Mask 29 is 0x 020000000 - 0xffffffffdfffffff
> Mask 30 is 0x 040000000 - 0xffffffffbfffffff
> Mask 31 is 0x 080000000 - 0xffffffff7fffffff
> Mask 32 is 0x 1 0 - 0xfffffffeffffffff
> Mask 33 is 0x 2 0 - 0xfffffffdffffffff
> Mask 34 is 0x 4 0 - 0xfffffffbffffffff
> ...
>
> in userland on i386 and ppc and also in the kernel on i386 but only
> in the kernel on ppc it gives
>
> ...
> Mask 29 is 0x 020000000 - 0xffffffffdfffffff
> Mask 30 is 0x 040000000 - 0xffffffffbfffffff
> Mask 31 is 0x 080000000 - 0xffffffff7fffffff
> Mask 32 is 0x 1 0 - 0xfffffffeffffffff
> Mask 33 is 0x 0 0 - 0xffffffffffffffff
> Mask 34 is 0x 0 0 - 0xffffffffffffffff
> ...
>
> which is definitely wrong - i'll ask about this on the ppc-dev list
> - hopefully they have an answer for it (or at least an idea)
>
> > It might be worth the pain of pulling this into a user space program
> > and stepping though it in a debugger.
>
> i think this is not nessesary because it looks like it's definitely
> a result of the above shift problem
>
> > So instead of trying to understand what is wrong with that code, try
> > this code instead, it is a bit more simplistic in its approach - it
> > works on ia32, let me know how the ppc does.
> > ...
> > void
> > xfs_xlatesb(void *data, xfs_sb_t *sb, int dir, xfs_arch_t arch,
> > __int64_t fields)
> > {
> > ...
> > }
>
> ok - i tried this and it works - which completely fits into the
> theory - because you now only shift by one - which seems to work
> (shifts up to 32 work fine) ... and also it crashes later with
> the same error we had when not using the xlate code at all in
> the normal operation (the inodelen thing i think) ... also this
> fits perfect into the picture: somewhere else in the code are
> most probably other shifts > 32 resulting in garbage and thus
> the crash
>
> i think this is more a ppc problem than an xfs problem now and
> i will come back here as soon as this is somehow fixed
>
> so far a real big "thanks" for all your quick and very good help
> - this way it is really fun to try to help on this
>
> till later ... i will come back if there are any news ...
>
> t
>
> --
> thomas.graichen@xxxxxxxxxxxxx
> Technical Director innominate AG
> Clustering & Security networking people
> tel: +49.30.308806-13 fax: -77 web: http://innominate.de
--
Russell Cattelan
cattelan@xxxxxxxxxxx
|