SPEC Tried to track down what was going on with lbm; it doesn't seem to be repeatable on canis1; I'd previously seen it fail at O1 and work at O0 and tried to chop down the flags between the two; but after adding all the flags back in on top of -O0 it still worked and then I tried -O1 again and it worked. Going to try on another machine, but it might be uninitialised data somewhere.
Panda Our panda arrived; it's now happily nestling near our Beagles and running the 0126 headless snapshot (with 0127 hwpack). It seems fine except for rather slow USB and SD IO. Tip: Panda's do absolutely nothing (no LEDs, no serial console activity) unless you put an SD card in with the firmware on.
Libffi Wrote the changes for armhf. Tested on arm, armhf, i386, ppc and s390x - all happy. (Not too unsuspectingly variadic calls just work on everything other than armhf without the api change) Mailed Python CType list asking how much of a pain the API change will be and any hints on what might be affected. Awaiting sign off for submission of code.
Optimised library routines Looked at benchmarking 'git'; I'd seen previous discussions where it had been pointed out that it spends a lot of time in library routines; and indeed it does spend useful amounts in memchr, memcpy and friends on a simple git diff v2.6.36 v.2.6.37 > /dev/null of the current kernel tree produces a useful ~25second run. One interesting observation is that the variation in the times reported by 'time' - i.e. user, system and real, the variation in user+system is much less than either user or system individually and is quite stable (within ~0.7% over 10 runs). I've just tried preloading my memchr routine in and it does get a consistent 1-1.2% improvement which does look above the nice. Also asked on libc-help list for suggestions as to other benchmarks people actually trust to reflect useful performance increases in core routines as opposed to totally artificial ones.
Dave