* Paul E. McKenney <paul...@linux.vnet.ibm.com> wrote: > On Mon, Feb 18, 2013 at 09:41:30AM +0100, Ingo Molnar wrote: > > > > * H. Peter Anvin <h...@zytor.com> wrote: > > > > > On 02/16/2013 11:46 AM, Linus Torvalds wrote: > > > >Adding Peter Anvin to the people, just in case he sees what's wrong > > > >with the system call stub generation that keeps excessively old object > > > >files around. If it's easy to fix, it might be worth trying to make it > > > >ok to switch from i386 to x86-64 and back in the same tree. > > > > > > I have not been able to reproduce this; it seems to Just > > > Work[TM]. > > > > > > The syscall header stuff is definitely not to blame: it > > > doesn't even *see* the CONFIG_ settings; instead they are only > > > used to determine which subset of files to create, but the > > > files themselves are configuration-independent. This is by > > > design. > > > > > > As such, without an actual known to fail test case there isn't > > > much I can do. > > > > I tried (based on the versions given by Paul): > > > > git checkout v3.7-rc7 > > make ARCH=i386 defconfig > > make -j64 bzImage > > > > git checkout v3.8-rc7 > > make ARCH=x86_64 olddefconfig > > make -j64 bzImage > > > > but it built just fine. The build bug might depend on the > > specific config file, or might depend on tooling details? > > The problem is that the git tree I used is one that I build out of > very infrequently, and so all I really know about the previous > build was that it was done a long time ago. :-(
Unless you recreated the Git repo from scratch, you could find clues about past versions used in .git/logs/HEAD. Except if you used it to pull bits frequently - but built rarely out of it. In that case the information is probably lost. (Don't worry about it too much - someone will eventually hit it again during bisection or so.) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/