2005-09-11 06:07:23

by Tony Luck

[permalink] [raw]
Subject: new asm-offsets.h patch problems

I'm sometimes ending up with just "#define IA64_TASK_SIZE 0"
in include/asm-ia64/asm-offsets.h ... but only sometimes.

My build script does "make prepare; make -j8" ... so I guess
there are some races in the parallel build? The "make prepare"
part used to do the full of build offsets.h, but now it just does
the ia64 hack.

-Tony


2005-09-11 07:44:17

by Sam Ravnborg

[permalink] [raw]
Subject: Re: new asm-offsets.h patch problems

iHi Tony

> I'm sometimes ending up with just "#define IA64_TASK_SIZE 0"
> in include/asm-ia64/asm-offsets.h ... but only sometimes.
>
> My build script does "make prepare; make -j8" ... so I guess
> there are some races in the parallel build? The "make prepare"
> part used to do the full of build offsets.h, but now it just does
> the ia64 hack.
First an explanation why it doess less today.
The dependency chain looks like this now:

prepare-all
|
+---> prepare0
|
+--> prepare
|
+--> prepare1
|
+---> prepare2
|
+--> prepare3

So executing `make prepare` will only do a subset of what is needed to do
the full build.
But make -j8 should not fail - and I have tried to find what dependency
is missing since you see this odd behaviour. So far with no luck.
Testing on my UP with an ia64 toolchain did not reveal the problem.

Do you recall why you have this make prepare step. It smells like a
workaround for a missing dependency somewhere.


But you put my attention on another matter. I recall several
cross-compile scripts that uses the 'make prepare' target,
and it will no longer behave as expected. So the only correct
solution for that issue is to move up the prepare target in the
dependency chain. But prepare0 needs stuff to be done in arch makefiles
so we cannot have a nameclash there. The solution I made was to rename
the remaining prepare targets in arch Makefile to archprepare.

Tony - can you test below patch and tell it this solve the problem you
see?

Changes outside top-level Makefile and ia64 Makefile is irellevant for
you.

Sam

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -776,15 +776,16 @@ $(sort $(vmlinux-init) $(vmlinux-main))
# Error messages still appears in the original language

.PHONY: $(vmlinux-dirs)
-$(vmlinux-dirs): prepare-all scripts
+$(vmlinux-dirs): prepare scripts
$(Q)$(MAKE) $(build)=$@

# Things we need to do before we recursively start building the kernel
-# or the modules are listed in "prepare-all".
+# or the modules are listed in "prepare".
# A multi level approach is used. prepare1 is updated first, then prepare0.
-# prepare-all is the collection point for the prepare targets.
+# prepare is the collection point for the prepare targets.
+# prepare-all is old style and kept for compatibility with users build scripts

-.PHONY: prepare-all prepare prepare0 prepare1 prepare2 prepare3
+.PHONY: prepare-all prepare archprepare prepare0 prepare1 prepare2 prepare3

# prepare3 is used to check if we are building in a separate output directory,
# and if so do:
@@ -813,11 +814,11 @@ ifneq ($(KBUILD_MODULES),)
$(Q)mkdir -p $(MODVERDIR)
endif

-prepare0: prepare prepare1 FORCE
+prepare0: archprepare prepare1 FORCE
$(Q)$(MAKE) $(build)=.

# All the preparing..
-prepare-all: prepare0
+prepare prepare-all: prepare0

# Leave this as default for preprocessing vmlinux.lds.S, which is now
# done in arch/$(ARCH)/kernel/Makefile
@@ -908,7 +909,7 @@ modules: $(vmlinux-dirs) $(if $(KBUILD_B

# Target to prepare building external modules
.PHONY: modules_prepare
-modules_prepare: prepare-all scripts
+modules_prepare: prepare scripts

# Target to install modules
.PHONY: modules_install
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -175,7 +175,7 @@ else
endif
@touch $@

-prepare: maketools include/asm-arm/.arch
+archprepare: maketools include/asm-arm/.arch

.PHONY: maketools FORCE
maketools: include/linux/version.h FORCE
diff --git a/arch/cris/Makefile b/arch/cris/Makefile
--- a/arch/cris/Makefile
+++ b/arch/cris/Makefile
@@ -107,7 +107,7 @@ archclean:
rm -f timage vmlinux.bin decompress.bin rescue.bin cramfs.img
rm -rf $(LD_SCRIPT).tmp

-prepare: $(SRC_ARCH)/.links $(srctree)/include/asm-$(ARCH)/.arch
+archprepare: $(SRC_ARCH)/.links $(srctree)/include/asm-$(ARCH)/.arch

# Create some links to make all tools happy
$(SRC_ARCH)/.links:
diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
--- a/arch/ia64/Makefile
+++ b/arch/ia64/Makefile
@@ -82,7 +82,7 @@ unwcheck: vmlinux
archclean:
$(Q)$(MAKE) $(clean)=$(boot)

-prepare: include/asm-ia64/.offsets.h.stamp
+archprepare: include/asm-ia64/.offsets.h.stamp

include/asm-ia64/.offsets.h.stamp:
mkdir -p include/asm-ia64
diff --git a/arch/ppc/Makefile b/arch/ppc/Makefile
--- a/arch/ppc/Makefile
+++ b/arch/ppc/Makefile
@@ -105,7 +105,7 @@ archclean:
$(Q)$(MAKE) $(clean)=arch/ppc/boot
$(Q)rm -rf include3

-prepare: checkbin
+archprepare: checkbin

# Temporary hack until we have migrated to asm-powerpc
include/asm: include3/asm
diff --git a/arch/sh/Makefile b/arch/sh/Makefile
--- a/arch/sh/Makefile
+++ b/arch/sh/Makefile
@@ -152,7 +152,7 @@ endif
@touch $@


-prepare: maketools include/asm-sh/.cpu include/asm-sh/.mach
+archprepare: maketools include/asm-sh/.cpu include/asm-sh/.mach

.PHONY: maketools FORCE
maketools: include/linux/version.h FORCE
diff --git a/arch/sh64/Makefile b/arch/sh64/Makefile
--- a/arch/sh64/Makefile
+++ b/arch/sh64/Makefile
@@ -73,7 +73,7 @@ compressed: zImage
archclean:
$(Q)$(MAKE) $(clean)=$(boot)

-prepare: arch/$(ARCH)/lib/syscalltab.h
+archprepare: arch/$(ARCH)/lib/syscalltab.h

define filechk_gen-syscalltab
(set -e; \
diff --git a/arch/um/Makefile b/arch/um/Makefile
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -108,7 +108,7 @@ else
$(shell cd $(ARCH_DIR) && ln -sf Kconfig.$(SUBARCH) Kconfig.arch)
endif

-prepare: $(ARCH_SYMLINKS) $(SYS_HEADERS) $(GEN_HEADERS)
+archprepare: $(ARCH_SYMLINKS) $(SYS_HEADERS) $(GEN_HEADERS)

LINK-$(CONFIG_LD_SCRIPT_STATIC) += -static
LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib
diff --git a/arch/xtensa/Makefile b/arch/xtensa/Makefile
--- a/arch/xtensa/Makefile
+++ b/arch/xtensa/Makefile
@@ -66,7 +66,7 @@ boot := arch/xtensa/boot

archinc := include/asm-xtensa

-prepare: $(archinc)/.platform
+archprepare: $(archinc)/.platform

# Update machine cpu and platform symlinks if something which affects
# them changed.

2005-09-11 14:54:31

by Tony Luck

[permalink] [raw]
Subject: RE: new asm-offsets.h patch problems

>Do you recall why you have this make prepare step. It smells like a
>workaround for a missing dependency somewhere.

There used to be a problem with starting out with "make -j8" ... sometimes
offsets.h hadn't been made before another compilation was started that
needed it. This may have been fixed at some point, but I wired a
"make prepare" into my scripts to avoid it.

>Tony - can you test below patch and tell it this solve the problem you
>see?
>
>Changes outside top-level Makefile and ia64 Makefile is irellevant for
>you.

I'll try it. Hunk#2 of the change to Makefile didn't apply with
patch ... I had to apply it by hand.

-Tony

2005-09-11 20:39:15

by Tony Luck

[permalink] [raw]
Subject: RE: new asm-offsets.h patch problems


>I'll try it. Hunk#2 of the change to Makefile didn't apply with
>patch ... I had to apply it by hand.

Either I goofed on the hand application of this patch, or it isn't
working. Curious thing is that it works with some config files, but
not with others. When I first reported this problem, all my builds
had worked except for the sn2_defconfig one. With this patch applied
I'm seeing bigsur_defconfig fail quite regularly.

E.g. this sequence (starting from a clean tree):

$ cp arch/ia64/configs/bigsur_defconfig .config
$ yes '' | make oldconfig
$ make prepare

leaves me with an include/asm-ia64/asm-offsets.h that only has the
definition of IA64_TASK_SIZE at 0.

-Tony

2005-09-11 21:34:12

by Sam Ravnborg

[permalink] [raw]
Subject: Re: new asm-offsets.h patch problems

On Sun, Sep 11, 2005 at 01:39:07PM -0700, Luck, Tony wrote:
>
> >I'll try it. Hunk#2 of the change to Makefile didn't apply with
> >patch ... I had to apply it by hand.
>
> Either I goofed on the hand application of this patch, or it isn't
> working. Curious thing is that it works with some config files, but
> not with others. When I first reported this problem, all my builds
> had worked except for the sn2_defconfig one. With this patch applied
> I'm seeing bigsur_defconfig fail quite regularly.
>
> E.g. this sequence (starting from a clean tree):
>
> $ cp arch/ia64/configs/bigsur_defconfig .config
> $ yes '' | make oldconfig

You can just do:
make bigsur_defconfig

> $ make prepare
>
> leaves me with an include/asm-ia64/asm-offsets.h that only has the
> definition of IA64_TASK_SIZE at 0.

I could reproduce this as well.
Did you actually look at the output of the compile?

It looks like the more comprehensive dependency checking hits you now.
What happens is that the compilation of asm-offsets.c fails due to
consistency checks in a few places.

First we have in page.h:
#error Unsupported page size!
Because CONFIG_IA64_PAGE_SIZE_4KB (8KB, 16KB, 32KB) is not defined.

Then next we have in same file:
include/asm/page.h:162: error: `PAGE_SHIFT' undeclared
That's because CONFIG__HUGETLB_PAGE is set

etc etc.

The only real fix is to fix the dependencies or provide
enough defines in your hack.

I wonder why so many errors occurs with ia64 but not others.
Do you have a much different .h files layout?

To give you an indication that this is not mission impossible
I played a bit with the invloved .h files.

Following patch (cut'n'pasted) let bigsur + defconfig succeed
a make prepare.

diff --git a/arch/ia64/kernel/asm-offsets.c
b/arch/ia64/kernel/asm-offsets.c
--- a/arch/ia64/kernel/asm-offsets.c
+++ b/arch/ia64/kernel/asm-offsets.c
@@ -8,10 +8,6 @@

#include <linux/sched.h>

-#include <asm-ia64/processor.h>
-#include <asm-ia64/ptrace.h>
-#include <asm-ia64/siginfo.h>
-#include <asm-ia64/sigcontext.h>
#include <asm-ia64/mca.h>

#include "../kernel/sigframe.h"
diff --git a/include/asm-ia64/mca.h b/include/asm-ia64/mca.h
--- a/include/asm-ia64/mca.h
+++ b/include/asm-ia64/mca.h
@@ -15,12 +15,6 @@

#if !defined(__ASSEMBLY__)

-#include <linux/interrupt.h>
-#include <linux/types.h>
-
-#include <asm/param.h>
-#include <asm/sal.h>
-#include <asm/processor.h>
#include <asm/mca_asm.h>


And since the header files did compile in my case I would say that
most if not all of the includes are wrong.
A .h file shall be selfcontained, but not a convinient placeholder
for including a lot of .h files.

It still leaves of with the original offending IA64_TASK_SIZE,
but grep did no tell me where task_struct was defined??
So I could not try to give that one spin.

PS. the include of sigframe.h in asm-offsets.c is bad. Please do:
#include "sigframe.h"

Sam

2005-09-11 21:48:51

by Tony Luck

[permalink] [raw]
Subject: RE: new asm-offsets.h patch problems


>> $ cp arch/ia64/configs/bigsur_defconfig .config
>> $ yes '' | make oldconfig
>
>You can just do:
>make bigsur_defconfig

I only recently found out about that ... but in some cases I still
want to do something like this as I want to make a small tweak from
some of the standard config files (e.g. delete CONFIG_SMP to do a UP
build based on some of the standard configs).

>
>> $ make prepare
>>
>> leaves me with an include/asm-ia64/asm-offsets.h that only has the
>> definition of IA64_TASK_SIZE at 0.
>
>I could reproduce this as well.
>Did you actually look at the output of the compile?

Uh, no. I guess that would have helped me figure out what was happening.

>It looks like the more comprehensive dependency checking hits you now.
>What happens is that the compilation of asm-offsets.c fails due to
>consistency checks in a few places.
>
>First we have in page.h:
>#error Unsupported page size!
>Because CONFIG_IA64_PAGE_SIZE_4KB (8KB, 16KB, 32KB) is not defined.

Ugh.

>Then next we have in same file:
>include/asm/page.h:162: error: `PAGE_SHIFT' undeclared
>That's because CONFIG__HUGETLB_PAGE is set

Presumably more follow-on from not defining any of the PAGE_SIZE
configs.

>etc etc.
>
>The only real fix is to fix the dependencies or provide
>enough defines in your hack.

More ugh.

>I wonder why so many errors occurs with ia64 but not others.
>Do you have a much different .h files layout?

Apparently we do.

>To give you an indication that this is not mission impossible
>I played a bit with the invloved .h files.
...
>And since the header files did compile in my case I would say that
>most if not all of the includes are wrong.

Agreed.

>A .h file shall be selfcontained, but not a convinient placeholder
>for including a lot of .h files.
>
>It still leaves of with the original offending IA64_TASK_SIZE,
>but grep did no tell me where task_struct was defined??

It is in include/linux/sched.h

>So I could not try to give that one spin.
>
>PS. the include of sigframe.h in asm-offsets.c is bad. Please do:
>#include "sigframe.h"

Will fix ... while I'm trying to unravel all the rest of this.

Thanks for all the pointers.

-Tony

2005-09-11 22:05:38

by Sam Ravnborg

[permalink] [raw]
Subject: Re: new asm-offsets.h patch problems

>
> >It still leaves of with the original offending IA64_TASK_SIZE,
> >but grep did no tell me where task_struct was defined??
>
> It is in include/linux/sched.h

Obviously - thanks.
I was so focussed that this was a ia64 typedef for some reasons.

Sam

2005-09-12 16:00:14

by Tony Luck

[permalink] [raw]
Subject: RE: new asm-offsets.h patch problems

So I still don't understand what is really happening here.

I left my build script running overnight ... working on a
kernel at the 357d596bd... commit (where Linus merged in
my tree last night). This one has your "archprepare" patch
already included.

Sometimes a build for a config succeeds, and sometimes it
fails. (tiger_defconfig for the last six builds has had a
GOOD, BAD, BAD, BAD, GOOD, GOOD sequence, while bigsur_defconfig
went GOOD, BAD, BAD, BAD, BAD, BAD). This non-determinism
doesn't fit in well with your explanation of missing defines
for PAGE_SIZE etc.

-Tony

2005-09-12 16:50:59

by Al Viro

[permalink] [raw]
Subject: Re: new asm-offsets.h patch problems

On Mon, Sep 12, 2005 at 09:00:06AM -0700, Luck, Tony wrote:
> So I still don't understand what is really happening here.
>
> I left my build script running overnight ... working on a
> kernel at the 357d596bd... commit (where Linus merged in
> my tree last night). This one has your "archprepare" patch
> already included.
>
> Sometimes a build for a config succeeds, and sometimes it
> fails. (tiger_defconfig for the last six builds has had a
> GOOD, BAD, BAD, BAD, GOOD, GOOD sequence, while bigsur_defconfig
> went GOOD, BAD, BAD, BAD, BAD, BAD). This non-determinism
> doesn't fit in well with your explanation of missing defines
> for PAGE_SIZE etc.

There's more, apparently - I'm seeing
make # successful full build
make C=2 # triggering full rebuild, not just sparse run

2005-09-12 18:57:04

by Sam Ravnborg

[permalink] [raw]
Subject: Re: new asm-offsets.h patch problems

On Mon, Sep 12, 2005 at 09:00:06AM -0700, Luck, Tony wrote:
> So I still don't understand what is really happening here.
>
> I left my build script running overnight ... working on a
> kernel at the 357d596bd... commit (where Linus merged in
> my tree last night). This one has your "archprepare" patch
> already included.
>
> Sometimes a build for a config succeeds, and sometimes it
> fails. (tiger_defconfig for the last six builds has had a
> GOOD, BAD, BAD, BAD, GOOD, GOOD sequence, while bigsur_defconfig
> went GOOD, BAD, BAD, BAD, BAD, BAD). This non-determinism
> doesn't fit in well with your explanation of missing defines
> for PAGE_SIZE etc.

I have tried to reproduce it locally, but my gcc barfed out
in namei.c with an internal error :-(
I can explain why you see recompiles though.

asm-offsets.c has a dependency on asm-offsets.h
So in the cases where asm-offsets.c is build just before asm-offsets.h
then no recompile happens - at least not if they get same timestamp.
But in the cases where there is a command or two in betweem the two
the timestamps differ so next time you execute 'make' it will see that
asm-offsets.h is newe than asm-offsets.c and thus it will rebuild the
asm-offsets.h file.

But again this does not expalin why it sometimes goes bad, sometimes
goes well. I need some compile output for good and bad cases to dig more
into it.
There is no chance this is unrealted to the asm-offsets changes?

Sam

>
> -Tony
>

2005-09-12 18:58:55

by Sam Ravnborg

[permalink] [raw]
Subject: Re: new asm-offsets.h patch problems

On Mon, Sep 12, 2005 at 05:50:56PM +0100, Al Viro wrote:
> On Mon, Sep 12, 2005 at 09:00:06AM -0700, Luck, Tony wrote:
> > So I still don't understand what is really happening here.
> >
> > I left my build script running overnight ... working on a
> > kernel at the 357d596bd... commit (where Linus merged in
> > my tree last night). This one has your "archprepare" patch
> > already included.
> >
> > Sometimes a build for a config succeeds, and sometimes it
> > fails. (tiger_defconfig for the last six builds has had a
> > GOOD, BAD, BAD, BAD, GOOD, GOOD sequence, while bigsur_defconfig
> > went GOOD, BAD, BAD, BAD, BAD, BAD). This non-determinism
> > doesn't fit in well with your explanation of missing defines
> > for PAGE_SIZE etc.
>
> There's more, apparently - I'm seeing
> make # successful full build
> make C=2 # triggering full rebuild, not just sparse run

The circular dependency:
asm-offsets.c depends on asm-offsets.h and is used to generate
asm-offsets.h. So if they do not have equal timestamp all files
including asm-offsets.h (direct or indirect) will be rebuild.
Do you see same pattern as Tony where the same build sometimes goes
well, sometimes goes bad?

Sam

2005-09-12 21:02:34

by Tony Luck

[permalink] [raw]
Subject: Re: new asm-offsets.h patch problems

I ran a loop of:
$ make mrproper
$ cp arch/ia64/configs/bigsur_defconfig .config
$ yes '' | make oldconfig
$ make -d V=1 prepare
until I had a success and a fail case. Then diffed the output from the
make -d V=1 prepare part. The successful one has the "<", the failed
one has the ">".

I editted off the start of the diff, where the only differences are the
process ids and addresses. Here's the output from "prepare0" to the
end of file. Note the stuttering "Putting childPutting child" in the
successful case, and that two processes 5577 and 5578 were forked in
the succesful case, while only one was started in the failing case.

Then after the reaping, the successful case decides that it must do
a remake of include/asm-ia64/asm-offsets.h, while the failing case
doesn't. The immediately preceeding lines to this pronouncement in
both cases are:

Finished prerequisites of target file `include/asm-ia64/asm-offsets.h'.
Prerequisite `arch/ia64/kernel/asm-offsets.s' is newer than target `include/asm-ia64/asm-offsets.h'.
Prerequisite `Kbuild' is older than target `include/asm-ia64/asm-offsets.h'.


Just in case this is a "make" issue, here's the version information:
$ make --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

85410,85411c85408,85409
< Putting child 0x60000000001549d0 (prepare0) PID 5576 on the chain.
< Live child 0x60000000001549d0 (prepare0) PID 5576
---
> Putting child 0x6000000000155b60 (prepare0) PID 6366 on the chain.
> Live child 0x6000000000155b60 (prepare0) PID 6366
87593c87591,87592
< Putting childPutting child 0x600000000003ad40 (arch/ia64/kernel/asm-offsets.s) PID 5577 on the chain.
---
> Putting child 0x600000000003adb0 (arch/ia64/kernel/asm-offsets.s) PID 6367 on the chain.
> Live child 0x600000000003adb0 (arch/ia64/kernel/asm-offsets.s) PID 6367
87595,87598c87594,87595
< 0x600000000003ad40 (arch/ia64/kernel/asm-offsets.s) PID 5577 on the chain.
< Live child 0x600000000003ad40 (arch/ia64/kernel/asm-offsets.s) PID 5577
< Reaping winning child 0x600000000003ad40 PID 5577
< Live child 0x600000000003ad40 (arch/ia64/kernel/asm-offsets.s) PID 5578
---
> Reaping winning child 0x600000000003adb0 PID 6367
> Live child 0x600000000003adb0 (arch/ia64/kernel/asm-offsets.s) PID 6368
87601,87602c87598,87599
< Reaping winning child 0x600000000003ad40 PID 5578
< Removing child 0x600000000003ad40 PID 5578 from chain.
---
> Reaping winning child 0x600000000003adb0 PID 6368
> Removing child 0x600000000003adb0 PID 6368 from chain.
87650,87657c87647
< Must remake target `include/asm-ia64/asm-offsets.h'.
< Putting child 0x600000000003ad40 (include/asm-ia64/asm-offsets.h) PID 5584 on the chain.
< Live child 0x600000000003ad40 (include/asm-ia64/asm-offsets.h) PID 5584
< mkdir -p include/asm-ia64/; cat arch/ia64/kernel/asm-offsets.s | (set -e; echo "#ifndef __ASM_OFFSETS_H__"; echo "#define __ASM_OFFSETS_H__"; echo "/*"; echo " * DO NOT MODIFY."; echo " *"; echo " * This file was generated by /home/aegl/bigsur/Kbuild"; echo " *"; echo " */"; echo ""; sed -ne "/^->/{s:^->\([^ ]*\) [\$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; s:->::; p;}"; echo ""; echo "#endif" ) > include/asm-ia64/asm-offsets.h
< Got a SIGCHLD; 1 unreaped children.
< Reaping winning child 0x600000000003ad40 PID 5584
< Removing child 0x600000000003ad40 PID 5584 from chain.
< Successfully remade target file `include/asm-ia64/asm-offsets.h'.
---
> No need to remake target `include/asm-ia64/asm-offsets.h'.
87662,87663c87652,87653
< Reaping winning child 0x60000000001549d0 PID 5576
< Removing child 0x60000000001549d0 PID 5576 from chain.
---
> Reaping winning child 0x6000000000155b60 PID 6366
> Removing child 0x6000000000155b60 PID 6366 from chain.
87668,87671d87657
< ]0;aegl@linux-t10:~/bigsur[aegl@linux-t10 bigsur]$ w 
< ]0;aegl@linux-t10:~/bigsur[aegl@linux-t10 bigsur]$ exit
<
< Script done on Mon 12 Sep 2005 11:37:57 AM PDT

2005-09-12 23:17:49

by Tony Luck

[permalink] [raw]
Subject: Re: new asm-offsets.h patch problems

Adding a small delay to arch/ia64/Makefile (caution cut&pasted patch, will
be mangled) gets rid of the non-determinism. I tried "make prepare" 50
times, and all of them generated the asm-offsets.h file correctly.

Without the sleep the score was 9 successes to 21 failures in 30 trials.

-Tony

--- a/arch/ia64/Makefile 2005-09-12 16:02:41.000000000 -0700
+++ b/arch/ia64/Makefile 2005-09-12 15:54:31.000000000 -0700
@@ -88,6 +88,7 @@
mkdir -p include/asm-ia64
[ -s include/asm-ia64/asm-offsets.h ] \
|| echo "#define IA64_TASK_SIZE 0" > include/asm-ia64/asm-offsets.h
+ sleep 2
touch $@

2005-09-13 00:09:07

by Peter Chubb

[permalink] [raw]
Subject: RE: new asm-offsets.h patch problems

>>>>> "Tony" == Tony Luck <Luck> writes:

Tony> So I still don't understand what is really happening here. I
Tony> left my build script running overnight ... working on a kernel
Tony> at the 357d596bd... commit (where Linus merged in my tree last
Tony> night). This one has your "archprepare" patch already included.

There's something else wrong too ... make rebuilds everything every
time on IA64 now, rather than just the things that have changed (when
compiling with -O)

--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
The technical we do immediately, the political takes *forever*

2005-09-13 00:14:14

by Tony Luck

[permalink] [raw]
Subject: RE: new asm-offsets.h patch problems

>There's something else wrong too ... make rebuilds everything every
>time on IA64 now, rather than just the things that have changed (when
>compiling with -O)

I've added a "sleep 2" to the arch/ia64/Makefile ... and all my
non-deterministic problems appear to have gone away.

I don't seem this re-build everything problem. I just tried
a "touch arch/ia64/kernel/efi.c ; make" and it only recompiled
that one file. That's with the "sleep" in the Makefile, but I
can't imagine it affects this case.

Can you give more details on what you did?

-Tony