Hi Stephen,
Thanks for your analisys!
2015-04-02 7:33 GMT+09:00 Stephen Warren swarren@wwwdotorg.org:
On 03/31/2015 06:02 AM, Masahiro Yamada wrote:
Since the Kconfig conversion, some developers have reported that Kbuild sometimes fails completely at random. According to the error reports, it seems to occur for any target board, but only on very fast computers.
The log message for the fail case is like this:
make[1]: *** No rule to make target `../arch//cpu/u-boot.lds', needed by `u-boot.lds'. Stop.
It looks like the top config.mk has not been included for *some* reason, and $(ARCH) has been left blank.
I suspect "autoconf_is_current" is not working in some situation.
That's certainly true. The following code doesn't end up including config.mk in the bad case:
# We want to include arch/$(ARCH)/config.mk only when include/config/auto.conf # is up-to-date. When we switch to a different board configuration, old CONFIG # macros are still remaining in include/config/auto.conf. Without the following # gimmick, wrong config.mk would be included leading nasty warnings/errors. autoconf_is_current := $(if $(wildcard $(KCONFIG_CONFIG)),$(shell find . \ -path ./include/config/auto.conf -newer $(KCONFIG_CONFIG))) ifneq ($(autoconf_is_current),) include $(srctree)/config.mk include $(srctree)/arch/$(ARCH)/Makefile endif
That's because:
[swarren@swarren-lx1 tegra-uboot-flasher]$ ls -l --full-time u-boot-*/{.config,include/config/auto.conf}|cat -rw-rw-r-- 1 swarren swarren 9219 2015-04-01 15:50:08.000000000 -0600 u-boot-bad/.config -rw-rw-r-- 1 swarren swarren 928 2015-04-01 15:50:08.000000000 -0600 u-boot-bad/include/config/auto.conf -rw-rw-r-- 1 swarren swarren 9219 2015-04-01 15:51:25.000000000 -0600 u-boot-ok/.config -rw-rw-r-- 1 swarren swarren 928 2015-04-01 15:51:26.000000000 -0600 u-boot-ok/include/config/auto.conf
In the bad case, the timestamps are equal (and hence the -newer check fails), whereas in the good case they're different. Recall ext* filesystems have a 1s timestamp resolution.
It makes sense that this problem happens more frequently on faster computers.
Note that this is state left over from "make xxx_defconfig"; If I just manually run "make all" in a tree in this state, it'll stay in this state forever, and vice-versa for a working tree.
I expect that simulating this condition with some judicious manually executed touch commands would be extremely easy.
Possible solutions are:
Is there a -newer-or-equal that could be used in the find command rather than -newer?
I checked the "man find", but I could only find a -newer option, but it works enough for our purpose.
Please check if this patch solves the problem: http://patchwork.ozlabs.org/patch/457838/
When running "make xxx_defconfig", can the code there compare the timestamp of those two files, and keep looping and touching the auto.conf file until the timestamps differ.
Something else entirely? I couldn't see anything relating to autoconf_is_current in the kernel's makefiles.
Right. The kernel does not need this hack.
When we build the kernel, ARCH= is given from the command line, i.e. the correct arch/${ARCH}/Makefile is always included. (In other words, it is users who are responsible for passing the correct ARCH from the command line.)
For U-boot, on the other hand, ARCH is decided by the board configuration. (It was done by mkconfig+boards.cfg, and it is by Kconfig now.)
If we build ARM board after PowerPC board, for example, the .config points to ARM, but include/config/auto.conf to PowerPC, it causes a wrong arch/${ARCH}/{config.mk,Makefile} to be included at the first run.
I know the autoconf_is_current is an ugly hack, but it requires more changes to the build system to rip it off.