On Fri, Apr 08, 2005 at 02:12:04PM +0200, Simon Derr wrote: > I enabled the debug messages in random.c and I think I found the problem > lying in the IA64 version of fls().
Good catch. > It turns out that the generic and IA64 versions of fls() disagree: > > (output from a small test program) > > x ia64_fls(x) generic_fls(x) > > i=-1, t=0, ia64: -65535 et generic:0 > i=0, t=1, ia64: 0 et generic:1 > i=1, t=2, ia64: 1 et generic:2 > i=2, t=4, ia64: 2 et generic:3 > i=3, t=8, ia64: 3 et generic:4 Well PPC at least sez: /* * fls: find last (most-significant) bit set. * Note fls(0) = 0, fls(1) = 1, fls(0x80000000) = 32. */ And that agrees with the generic code (used by x86). So I think IA64 is probably wrong here indeed. It's amazing that the other users of fls don't blow up spectacularly. > I tried to fix it with an ia64 version that would give the same result as > the generic version, but the kernel did not boot, I guess some functions > rely on the ""broken"" ia64_fls() behaviour. > > So I just changed fls() to use generic_fls() instead of ia64_fls(). If the "fixed" version didn't boot, how did the "alternate fixed" version boot? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/