> By broken kernel I mean you see the numbers in square brackets and then it
> immediately reboots without a single kernel message appearing.

Right, this is what happens when the kernel faults before it's built
enough of an environment to run the trap handler..

> I'm trying to narrow it down a bit and be more consistent, but it
> takes a long time... Any thoughts on narrowing it down more to pop a
> pr in?

Well, you have enough here to file a PR already, but if you want to
see it fixed sooner rather than later..

 - rumor has it that someone's going to switch us over to gcc 2.95.3
in the not-too-distant future, but that hasn't happened yet.  making
extreme efforts to locate this bug may not be worthwhile as it is more
likely than not fixed in 2.95.x ..

 - that said, if you want to track it down, i'd take the following
steps:

 - the obvious conclusion from the above is that gcc built with
-march=686 is busted.  I'll call this "bad gcc".  You also have a good
gcc, which you can use to build a working kernel.

Now, do two full kernel builds, without any -march options, and
save the intermediate .o files, and see which ones are different.
(this is complicated by the placement of timestamps in the ELF .o
format; see the gcc makefiles to see what bytes to skip when doing the
compare.  objdump also helps here).

Find the smallest object file which is different, do various objdumps
on them, and diff the output, to see how the "bad gcc" is generating
bad results.

now, start with a working gcc, and start building pieces of it with
-m686 (try a binary search) until it starts generating the same thing
as the "bad gcc"; then see what's different between the last module
you changed..

						- Bill