I posted a few weeks ago about this, but still have the same problem.

Any Fedora 19 or 20 3.13.x kernel crashes in early boot about 95% of the time. The rest of the time, the kernel boots and everything seems to work okay. All other kernels used since 2010 have worked fine.

Hardware: Intel i3 540 cpu, Asus P7H55-M PRO motherboard, 4x4G Corsair XMS3 Classic 1333 ram, NVidia 9800GT video card, Kingston SV300 ssd , Seagate Barracuda 7200.12 hd, Corsair CX430 power supply.

I compiled a 3.13.6 version from Fedora, enabled early printk messages (otherwise there are no messages), and by observing these printk's, tracing them up through the source, putting in more printk's etc., eventually generated my own backtrace of the crash, which seems to happen in essentially the same place each time. Here is the call sequence:

free_all_bootmem, called by
mem_init, called by
mm_init, called by
start_kernel.

As far as I can tell, the kernel at early boot sets up an ad hoc memeory management system, which at this point it is done with and tries to free, in preparation for the more general memory management system that will be used once the system is booted (linux seems to have an unnecessarily large amount of bootstrapping components, what also with the very large temporary init file system too, but I guess I just don't understand the need here).

I have posted about this at redhat bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1082207)
but have not been getting much response (a suggestion that I run memcheck86+ which I have, at great length, to discover nothing).

It was also suggested there could be some race condition timing issue here, which seems a little strange to me since at this early stage, I don't know why there would even have to be more than one processor doing anything, or even more than one thread. However, there are spinlocks in the free_all_bootmem code where the memory is being freed, so perhaps that is possible. But really, why? I don't see what it would get you at this point.

Not that it matters. I am not all that interested in learning details of how the kernel operates, I am mostly just a user. But any ideas anyone can offer than increase my understanding would be good, even if they don't lead to a solution (and perhaps at some point they might) since then I will get *something* out of this affair! It seems that few people are experiencing this problem. But I am pretty sure my own specific hardware is not defective in any way that would cause this problem 95% of the time in the same place, yet once things are booted, they run okay. So I suspect it is some hardware idiosyncrasy that is not dealt with by the software that most people don't have (I recall that my last machine's (2003) motherboard implemented some DMA stuff incorrectly, and I had to talk to Alan Cox to find the software workaround. *He* called it defective hardware, but it was not defective in the sense of faulty memory, it was the failure to correctly implement some specification, something that could be worked around (and he did so) in software). I suspect something like that here).

This is pretty serious, since I won't be able to continue along with Linux if I cannot even regularly boot a kernel. Never seen this before in many years (the DMA stuff was serious, but not like this, and it was immediately understood and worked around).

Boot something else, like SytemRescueCd and see if the problem persists.

I am not sure what you mean. The problem is only with 3.13 kernels (and later). I have only one machine, I have been using Fedora kernels on it for many years, currently all 3.12.x ones boot fine all the time and I am using one right now. Fedora debug 3.13 kernels also boot all the time with no apparent problem (but are too slow to use). The problem does not exist with any of these. But of course on attempting reboot to 3.13's, it has not gone away, hence, it "persists".

No, so far you've ony shown that Fedora 3.13 booting has a problem. Something different (and slower) may offer some evidence. Especially as the debug kernels work.
From the evidence you shown, I'd say a race is right up there as a possibility.
Remember too that Fedora use an initrd, so that may have to be considered. And of course a "Fedora kernel" has been patched, so the issue may not be evident in the upstream source tree. Have you tried compiling one of Linus' kernels ?.

Right, my point in reply to the other poster was that since many many other kernels work just fine, including kernels closely related to the problematic ones, I don't see the point of "Boot[ing] [yet another, and less related] something else, like SytemRescueCd and see if the problem persists", because I know it does not "persist" in many cases already.

Even if this is right at the beginning of the kernel boot? It is in the function "start_kernel", the first function coded in C that is ever called, I believe. Do you know where I can read something about early hardware booting on multi-core multi-threaded architectures that describe what different cores and threads are doing? Anything I have found so far does not seem to describe this (The books "Understanding the Linux Kernel" and "Understanding the Linux Virtual Memory Manager")

In particular, why does there have to be a spinlock at the free page code? What other code might be executing at that time that could be using the data structures being altered at that point?

Do you mean an initramfs? Yes, don't most systems use this (although why it needs to contain so much is something I do not understand). In any case, I believe this crash happens before the initramfs is decompressed and mounted, doesn't it (in mm_init of start_kernel)?

Yes, but I have been focussed on the Fedora one, since it is the only distribution I have used for many years. I compiled a stock 3.13.7 from kernel.org as reported April 2 at the Redhat Bugzilla post mentioned above:

However, I don't really remember the details of this, so didn't report it again this time. But I must have done it!

I think it still could be a problem with any kernel, that is not displayed because it relies on the specific positioning of the code when loaded, which could vary from compile to compile. In fact my insertion of printk's could change it as well.