I'm not sure, but hopefully it is one of those two scratchbox-toolchain-arm-gcc3.4.cs-uclibc-* in http://scratchbox.org/download/files...0.9.8/tarball/ . EDIT: it is the non-sf one.

In scratchbox when installed it appears in /scratchbox/compilers/arm-linux-gcc3.4.cs-uclibc0.9.27 and in scratchbox target info I also see name arm-linux-gcc3.4.cs-uclibc0.9.27. I have extracted the tar.gz version into my regular 1.0.x scratchbox, created new scratchbox target with this compiler via sb-menu and it works.

It could be interesting to check System.map vmlinux etc. from both compilers and see where in the code is the difference. Could be compiler bug but in theory it could be also faulty RAM in your device. You may be just lucky to have kernel with specific 'correct' bits in specific location.

I don't think I have the patience to disassemble both kernels and check differences; this would be the starting point to hunt a gcc bug.

Very good point ! How do I test that ? Did you find anything in the initfs that would allow RAM testing in factory tests ?

I'm thinking compiling a kernel with just enough features to boot the device, run the FB and modify the initfs to run as init a modified memtest to output to framebuffer should yield some results. If I can find some spare hours tonight I'll try it, but otherwise it will have to wait until next week.

It is quite unlikely so maybe first lets change something harmless like patching with just rotation patch or slightly change kernel configuration (like disabling Magic SysRq key in Kernel hacking section) and see if the stability is gone. if not then add various combinations of other patches. Either it remains stable (compiler bug or faulty ram in not changed code) or specific patch breaks it (code bug) it or it will be random (faulty RAM somewhere in changed code?).
[/QUOTE]
No. Some memtester that could be run from userspace is mentioned in the wifi memory corruption bug page. However if faulty bit(s) is only in the place where kernel code resides one would need to boot custom code to test it or maybe hack the kernel to uncompress itself into different RAM space and then test it from userspace.

Hi,

I just build the gcc 4.4.1 targeted to ARM, and the vanilla kernel using the gcc 4.4.1.

I got it out at
1262256 Sep 18 20:06 arch/arm/boot/zImage

I'll test it later tonight, and if stable I'll throw in the MMC patches for 48, 24, 12 MHz.

If those are stable as well, I'll release new kernel images.

Can you share gcc 4.4.1 packages for armel?