I've the same issue on my guruplug server plus. First i tried my own kernel (by just doing a makeold config run from a configuration which worked on 3.0) then the sheevaplug build from the link here, in both cases it stopped at booting the kernel.

I've the same issue on my guruplug server plus. First i tried my own kernel (by just doing a makeold config run from a configuration which worked on 3.0) then the sheevaplug build from the link here, in both cases it stopped at booting the kernel.

Thanks, that's reassuring. I have fiddled a few likely parameters with no luck, so far.

On my sheeva the uImage partition size is 0x400000.I wonder if you guys maybe have a partition size of 0x300000.If that's the problem, either the kernel image is going to have to shrinkor you're going to have to reconfigure your partition sizes (which would be a pain).We could probably shrink the kernel size by using CONFIG_KERNEL_LZMA rather than CONFIG_KERNEL_GZIP.

On my sheeva the uImage partition size is 0x400000.I wonder if you guys maybe have a partition size of 0x300000.If that's the problem, either the kernel image is going to have to shrinkor you're going to have to reconfigure your partition sizes (which would be a pain).We could probably shrink the kernel size by using CONFIG_KERNEL_LZMA rather than CONFIG_KERNEL_GZIP.

If you boot from SD card none of that should apply. In any case, for plug users it's something to keep in mind. My sheeva boots from SD, so I personally have to worry too much about uImage size.

I have carefully checked bikers (and my) .config. I have built dozens of variations trying to get 3.2 to at least start the boot process. None of them would even twitch. Wait for 3.2.1 methinks.

There is another option...git bisect. It's not necessarily true that the problem will self-resolve as the 3.2 kernel increments. You could get the main kernel git code and bisect between the 3.1 and 3.2 tags to isolate the problem. Since it's a "lockup" problem, the test procedure is quite simple.

I've isolated problems with the kernel with git before, and once you've experience "git bisect" in action, you'll wonder how any decent sized software project could get by without it.

I see that 3.2.1 has just been released. I'll build that up real soon and you can give that a try. If it doesn't fix the problem, git bisect might be the answer.

git bisect is just a basic binary search it can be done with anything which has a concept of revisions including svn or even something as basic as dropbox... actually even cvs can be used for it with the time statement. all this in log(n) (in the worst case) where n is first known not working revision minus last known woking revision So don't wonder how big project can get by without git at all.

git bisect is just a basic binary search it can be done with anything which has a concept of revisions including svn or even something as basic as dropbox... actually even cvs can be used for it with the time statement. all this in log(n) (in the worst case) where n is first known not working revision minus last known woking revision So don't wonder how big project can get by without git at all.

Actually, git's non-linear check-in model makes bisection a bit more complicated than just splitting the difference between versions, which you can do in your head. Anyway, it's very nicely integrated in git. Sounds like Mercurial has bisect as well, although I haven't used it.

yes without the command git would have an extremely big negative point because it's extremely complex for humans to handle it manually with the git system. others can be easily implemented as a command with a 5 lines bash script.Anyway going back to the topic for me it's difficult to do as it would take 4 hours each build (as i build on the plug and i don't have crosscompilers on my main systems) i wonder if spinifex could do it else i could have a try at it. 3.1.5 didn't build for me at all so i'll have to hope 3.1 builds for me (as in linus tree you've just that one).