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
|