Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Yang, Fei]

>From 5e6501efa26bc19dad0b43e3a2b0daa81408a8ae Mon Sep 17 00:00:00 2001
From: Fei Yang <fei.yang@intel.com>
Date: Mon, 26 Aug 2013 11:21:48 -0700
Subject: [PATCH] FIXDEP: error opening depfile
 
Met a kernel build issue where fixdep fails to open a depfile,
fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d: No such file or directory
make[4]: *** [drivers/driver-name/driver-code.o] Error 2
make[3]: *** [drivers/driver-name] Error 2
Don't know why the expected file was not created, but the assumption that
the file had been created might not be true, so simply return for such failure.
 
Change-Id: I299c01f2e3f6e1d04b19ced34ebeb964e16494e6
Signed-off-by: Fei Yang <fei.yang@intel.com>
---
 scripts/basic/fixdep.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index cb1f50c..2c065e5 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -377,7 +377,7 @@ static void print_deps(void)
        if (fd < 0) {
                fprintf(stderr, "fixdep: error opening depfile: ");
                perror(depfile);
-               exit(2);
+               return;
        }
        if (fstat(fd, &st) < 0) {
                 fprintf(stderr, "fixdep: error fstat'ing depfile: ");
-- 
1.7.9.5

Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Yang, Fei]

From 5e6501efa26bc19dad0b43e3a2b0daa81408a8ae Mon Sep 17 00:00:00 2001
From: Fei Yang <fei.yang@intel.com>
Date: Mon, 26 Aug 2013 11:21:48 -0700
Subject: [PATCH] FIXDEP: error opening depfile
 
Met a kernel build issue where fixdep fails to open a depfile,
fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d: No such file or directory
make[4]: *** [drivers/driver-name/driver-code.o] Error 2
make[3]: *** [drivers/driver-name] Error 2
Don't know why the expected file was not created, but the assumption that
the file had been created might not be true, so simply return for such failure.
 
Change-Id: I299c01f2e3f6e1d04b19ced34ebeb964e16494e6
Signed-off-by: Fei Yang <fei.yang@intel.com>
---
 scripts/basic/fixdep.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index cb1f50c..2c065e5 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -377,7 +377,7 @@ static void print_deps(void)
        if (fd < 0) {
                fprintf(stderr, "fixdep: error opening depfile: ");
                perror(depfile);
-               exit(2);
+               return;
        }
        if (fstat(fd, &st) < 0) {
                 fprintf(stderr, "fixdep: error fstat'ing depfile: ");
-- 
1.7.9.5

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Sam Ravnborg]

On Mon, Aug 26, 2013 at 07:22:46PM +0000, Yang, Fei wrote:
> >From 5e6501efa26bc19dad0b43e3a2b0daa81408a8ae Mon Sep 17 00:00:00 2001
> From: Fei Yang <fei.yang@intel.com>
> Date: Mon, 26 Aug 2013 11:21:48 -0700
> Subject: [PATCH] FIXDEP: error opening depfile
>  
> Met a kernel build issue where fixdep fails to open a depfile,
> fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d: No such file or directory
> make[4]: *** [drivers/driver-name/driver-code.o] Error 2
> make[3]: *** [drivers/driver-name] Error 2
> Don't know why the expected file was not created, but the assumption that
> the file had been created might not be true, so simply return for such failure.

I tried to grep:
git grep "driver-name"

No hits.

Are you trying to fix a build issue with something out-of-tree - or is this only in linux-next?

	Sam

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Sam Ravnborg]

On Mon, Aug 26, 2013 at 07:22:46PM +0000, Yang, Fei wrote:
> >From 5e6501efa26bc19dad0b43e3a2b0daa81408a8ae Mon Sep 17 00:00:00 2001
> From: Fei Yang <fei.yang@intel.com>
> Date: Mon, 26 Aug 2013 11:21:48 -0700
> Subject: [PATCH] FIXDEP: error opening depfile
>  
> Met a kernel build issue where fixdep fails to open a depfile,
> fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d: No such file or directory
> make[4]: *** [drivers/driver-name/driver-code.o] Error 2
> make[3]: *** [drivers/driver-name] Error 2
> Don't know why the expected file was not created, but the assumption that
> the file had been created might not be true, so simply return for such failure.

I tried to grep:
git grep "driver-name"

No hits.

Are you trying to fix a build issue with something out-of-tree - or is this only in linux-next?

	Sam

RE: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Yang, Fei]

>> From: Fei Yang <fei.yang@intel.com>
>> Date: Mon, 26 Aug 2013 11:21:48 -0700
>> Subject: [PATCH] FIXDEP: error opening depfile
>>  
>> Met a kernel build issue where fixdep fails to open a depfile,
>> fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d: 
>> No such file or directory
>> make[4]: *** [drivers/driver-name/driver-code.o] Error 2
>> make[3]: *** [drivers/driver-name] Error 2 Don't know why the expected 
>> file was not created, but the assumption that the file had been 
>> created might not be true, so simply return for such failure.

> I tried to grep:
> git grep "driver-name"
>
> No hits.
>
>Are you trying to fix a build issue with something out-of-tree - or is this only in linux-next?

Oh, I changed the driver and file name in the error message to avoid unnecessary confusion as the driver is not an upstream one. But this issue happens randomly, not 100% reproducible. And it happens on different driver sometimes. So I don't think it would be driver related and pointing out the driver name would not help much anyway.
What I'm trying to understand is under what condition fixdep is triggered in the kernel build process. Is the .d file always generated for every driver? If that file is always created, could it be a timing issue that the .d file was actually created but then deleted when fixdep trying to find it?

Thank you Sam! I'm not familiar with kernel build scripts, any idea is really appreciated.

-Fei

RE: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Yang, Fei]

>> From: Fei Yang <fei.yang@intel.com>
>> Date: Mon, 26 Aug 2013 11:21:48 -0700
>> Subject: [PATCH] FIXDEP: error opening depfile
>>  
>> Met a kernel build issue where fixdep fails to open a depfile,
>> fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d: 
>> No such file or directory
>> make[4]: *** [drivers/driver-name/driver-code.o] Error 2
>> make[3]: *** [drivers/driver-name] Error 2 Don't know why the expected 
>> file was not created, but the assumption that the file had been 
>> created might not be true, so simply return for such failure.

> I tried to grep:
> git grep "driver-name"
>
> No hits.
>
>Are you trying to fix a build issue with something out-of-tree - or is this only in linux-next?

Oh, I changed the driver and file name in the error message to avoid unnecessary confusion as the driver is not an upstream one. But this issue happens randomly, not 100% reproducible. And it happens on different driver sometimes. So I don't think it would be driver related and pointing out the driver name would not help much anyway.
What I'm trying to understand is under what condition fixdep is triggered in the kernel build process. Is the .d file always generated for every driver? If that file is always created, could it be a timing issue that the .d file was actually created but then deleted when fixdep trying to find it?

Thank you Sam! I'm not familiar with kernel build scripts, any idea is really appreciated.

-Fei

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Michal Marek]

On 27.8.2013 21:05, Yang, Fei wrote:
>>> From: Fei Yang <fei.yang@intel.com>
>>> Date: Mon, 26 Aug 2013 11:21:48 -0700
>>> Subject: [PATCH] FIXDEP: error opening depfile
>>>  
>>> Met a kernel build issue where fixdep fails to open a depfile,
>>> fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d: 
>>> No such file or directory
>>> make[4]: *** [drivers/driver-name/driver-code.o] Error 2
>>> make[3]: *** [drivers/driver-name] Error 2 Don't know why the expected 
>>> file was not created, but the assumption that the file had been 
>>> created might not be true, so simply return for such failure.
> 
>> I tried to grep:
>> git grep "driver-name"
>>
>> No hits.
>>
>> Are you trying to fix a build issue with something out-of-tree - or is this only in linux-next?
> 
> Oh, I changed the driver and file name in the error message to avoid
> unnecessary confusion

You achieved quite the opposite :-).


> as the driver is not an upstream one. But this issue happens randomly, not 100%
> reproducible. And it happens on different driver sometimes.

Are you able to reproduce this with the vanilla kernel? If so, details
please. If not, then this can be something with your module's build
system. Are you using anything fancier than

$ cat Makefile
obj-m += my-module.o
$ make -C <kernel build tree> M=$PWD

?

Michal

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Michal Marek]

On 27.8.2013 21:05, Yang, Fei wrote:
>>> From: Fei Yang <fei.yang@intel.com>
>>> Date: Mon, 26 Aug 2013 11:21:48 -0700
>>> Subject: [PATCH] FIXDEP: error opening depfile
>>>  
>>> Met a kernel build issue where fixdep fails to open a depfile,
>>> fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d: 
>>> No such file or directory
>>> make[4]: *** [drivers/driver-name/driver-code.o] Error 2
>>> make[3]: *** [drivers/driver-name] Error 2 Don't know why the expected 
>>> file was not created, but the assumption that the file had been 
>>> created might not be true, so simply return for such failure.
> 
>> I tried to grep:
>> git grep "driver-name"
>>
>> No hits.
>>
>> Are you trying to fix a build issue with something out-of-tree - or is this only in linux-next?
> 
> Oh, I changed the driver and file name in the error message to avoid
> unnecessary confusion

You achieved quite the opposite :-).


> as the driver is not an upstream one. But this issue happens randomly, not 100%
> reproducible. And it happens on different driver sometimes.

Are you able to reproduce this with the vanilla kernel? If so, details
please. If not, then this can be something with your module's build
system. Are you using anything fancier than

$ cat Makefile
obj-m += my-module.o
$ make -C <kernel build tree> M=$PWD

?

Michal

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Michal Marek]

On 28.8.2013 17:07, Michal Marek wrote:
> Are you able to reproduce this with the vanilla kernel? If so, details
> please. If not, then this can be something with your module's build
> system. Are you using anything fancier than
> 
> $ cat Makefile
> obj-m += my-module.o
> $ make -C <kernel build tree> M=$PWD

make -C <kernel build tree> M=$PWD modules

Michal

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Michal Marek]

On 28.8.2013 17:07, Michal Marek wrote:
> Are you able to reproduce this with the vanilla kernel? If so, details
> please. If not, then this can be something with your module's build
> system. Are you using anything fancier than
> 
> $ cat Makefile
> obj-m += my-module.o
> $ make -C <kernel build tree> M=$PWD

make -C <kernel build tree> M=$PWD modules

Michal

RE: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Yang, Fei]

>>>> From: Fei Yang <fei.yang@intel.com>
>>>> Date: Mon, 26 Aug 2013 11:21:48 -0700
>>>> Subject: [PATCH] FIXDEP: error opening depfile
>>>>  
>>>> Met a kernel build issue where fixdep fails to open a depfile,
>>>> fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d: 
>>>> No such file or directory
>>>> make[4]: *** [drivers/driver-name/driver-code.o] Error 2
>>>> make[3]: *** [drivers/driver-name] Error 2 Don't know why the 
>>>> expected file was not created, but the assumption that the file had 
>>>> been created might not be true, so simply return for such failure.
>>> 
>>> I tried to grep:
>>> git grep "driver-name"
>>>
>>> No hits.
>>>
>>> Are you trying to fix a build issue with something out-of-tree - or is this only in linux-next?
>>> 
>> Oh, I changed the driver and file name in the error message to avoid 
>> unnecessary confusion

>You achieved quite the opposite :-).
Yes, that appears to be a bad idea.

>> as the driver is not an upstream one. But this issue happens randomly, 
>> not 100% reproducible. And it happens on different driver sometimes.

>Are you able to reproduce this with the vanilla kernel? If so, details please.
I have not tried vanilla kernel.

>If not, then this can be something with your module's build system. Are you using anything fancier than
>
>$ cat Makefile
>obj-m += my-module.o
>$ make -C <kernel build tree> M=$PWD

> Michal

Nothing fancy except the kernel build is triggered by Android build system. And the driver is being built into the kernel with obj-(CONFIG_MY_DRIVER) += my-driver.o, so it's not even a loadable module.
I thought fixdep is about finding module dependency, and it isn't needed for built-in drivers. Please correct me if I'm wrong. I want to understand if the .d file had never been generated or had been generated but deleted by the time fixdep tries to open it.


Fei

RE: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Yang, Fei]

>>>> From: Fei Yang <fei.yang@intel.com>
>>>> Date: Mon, 26 Aug 2013 11:21:48 -0700
>>>> Subject: [PATCH] FIXDEP: error opening depfile
>>>>  
>>>> Met a kernel build issue where fixdep fails to open a depfile,
>>>> fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d: 
>>>> No such file or directory
>>>> make[4]: *** [drivers/driver-name/driver-code.o] Error 2
>>>> make[3]: *** [drivers/driver-name] Error 2 Don't know why the 
>>>> expected file was not created, but the assumption that the file had 
>>>> been created might not be true, so simply return for such failure.
>>> 
>>> I tried to grep:
>>> git grep "driver-name"
>>>
>>> No hits.
>>>
>>> Are you trying to fix a build issue with something out-of-tree - or is this only in linux-next?
>>> 
>> Oh, I changed the driver and file name in the error message to avoid 
>> unnecessary confusion

>You achieved quite the opposite :-).
Yes, that appears to be a bad idea.

>> as the driver is not an upstream one. But this issue happens randomly, 
>> not 100% reproducible. And it happens on different driver sometimes.

>Are you able to reproduce this with the vanilla kernel? If so, details please.
I have not tried vanilla kernel.

>If not, then this can be something with your module's build system. Are you using anything fancier than
>
>$ cat Makefile
>obj-m += my-module.o
>$ make -C <kernel build tree> M=$PWD

> Michal

Nothing fancy except the kernel build is triggered by Android build system. And the driver is being built into the kernel with obj-(CONFIG_MY_DRIVER) += my-driver.o, so it's not even a loadable module.
I thought fixdep is about finding module dependency, and it isn't needed for built-in drivers. Please correct me if I'm wrong. I want to understand if the .d file had never been generated or had been generated but deleted by the time fixdep tries to open it.


Fei

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Michal Marek]

Dne 28.8.2013 18:27, Yang, Fei napsal(a):
> I thought fixdep is about finding module dependency, and it isn't
> needed for built-in drivers. Please correct me if I'm wrong.

fixdep filters the *.d files generated by gcc. These files record source
-> object file dependencies, to not miss rebuilds.

Michal

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Michal Marek]

Dne 28.8.2013 18:27, Yang, Fei napsal(a):
> I thought fixdep is about finding module dependency, and it isn't
> needed for built-in drivers. Please correct me if I'm wrong.

fixdep filters the *.d files generated by gcc. These files record source
-> object file dependencies, to not miss rebuilds.

Michal

RE: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Yang, Fei]

>> I thought fixdep is about finding module dependency, and it isn't 
>> needed for built-in drivers. Please correct me if I'm wrong.
>
>fixdep filters the *.d files generated by gcc. These files record source
>-> object file dependencies, to not miss rebuilds.

OK, then it's more likely to be a timing issue. I'm running my builds on a machine with 32 cores, and as the build is distributed to multi-processors, there might be a synchronization issue.
Do you know how the .d files getting deleted normally? I see only .o.cmd file left after the build is completed.

Michal

RE: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Yang, Fei]

>> I thought fixdep is about finding module dependency, and it isn't 
>> needed for built-in drivers. Please correct me if I'm wrong.
>
>fixdep filters the *.d files generated by gcc. These files record source
>-> object file dependencies, to not miss rebuilds.

OK, then it's more likely to be a timing issue. I'm running my builds on a machine with 32 cores, and as the build is distributed to multi-processors, there might be a synchronization issue.
Do you know how the .d files getting deleted normally? I see only .o.cmd file left after the build is completed.

Michal

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Sam Ravnborg]

> 
> I thought fixdep is about finding module dependency, and
> it isn't needed for built-in drivers.
> Please correct me if I'm wrong.

You are wrong...

Fixdep conatins all the dependencies used to determine if we shall rebuild foo.o.
It has nothing to do with modules or not.

Following happens when you build foo.o from foo.c:

1) gcc -Wp,-MD,foo.o.d  foo.c -o foo.o
This produces two files:
foo.o.d - contains all files included by foo.c, recursive (try it out!)
foo.o - the object file

2) fixdep foo.o.d foo.o gcc -Wp,-MD,foo.o.d  foo.c -o foo.o > foo.o.tmp
fixdep now does the following:
- Assign the comandline to a variable
- List all dependencies (files included)
   - Scan the dependen file for CONFIG_* symbols
      - for each CONFIG_* symbol add a $(wildcard ...) reference to a symbol in
        include/generated/config/... that represents the CONFIG_ symbol
Everything is stored in foo.o.tmp

3) delete foo.o.cmd
4) rename foo.o.tmp to foo.o.cmd


Magic happens in Kbuild.include, Makefile.lib and Makefile.build.
But it make take some cup of coffee to grasp it.

For find and fix whatever race condition you hit.

	Sam

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Sam Ravnborg]

> 
> I thought fixdep is about finding module dependency, and
> it isn't needed for built-in drivers.
> Please correct me if I'm wrong.

You are wrong...

Fixdep conatins all the dependencies used to determine if we shall rebuild foo.o.
It has nothing to do with modules or not.

Following happens when you build foo.o from foo.c:

1) gcc -Wp,-MD,foo.o.d  foo.c -o foo.o
This produces two files:
foo.o.d - contains all files included by foo.c, recursive (try it out!)
foo.o - the object file

2) fixdep foo.o.d foo.o gcc -Wp,-MD,foo.o.d  foo.c -o foo.o > foo.o.tmp
fixdep now does the following:
- Assign the comandline to a variable
- List all dependencies (files included)
   - Scan the dependen file for CONFIG_* symbols
      - for each CONFIG_* symbol add a $(wildcard ...) reference to a symbol in
        include/generated/config/... that represents the CONFIG_ symbol
Everything is stored in foo.o.tmp

3) delete foo.o.cmd
4) rename foo.o.tmp to foo.o.cmd


Magic happens in Kbuild.include, Makefile.lib and Makefile.build.
But it make take some cup of coffee to grasp it.

For find and fix whatever race condition you hit.

	Sam

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Sam Ravnborg]

> 
> Nothing fancy except the kernel build is triggered by Android build system. And the driver is being built into the kernel with obj-(CONFIG_MY_DRIVER) += my-driver.o, so it's not even a loadable module.
> I thought fixdep is about finding module dependency, and it isn't needed for built-in drivers. Please correct me if I'm wrong. I want to understand if the .d file had never been generated or had been generated but deleted by the time fixdep tries to open it.
> 
Please teach yourself to punch new-line now and then.

	Sam

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Sam Ravnborg]

> 
> Nothing fancy except the kernel build is triggered by Android build system. And the driver is being built into the kernel with obj-(CONFIG_MY_DRIVER) += my-driver.o, so it's not even a loadable module.
> I thought fixdep is about finding module dependency, and it isn't needed for built-in drivers. Please correct me if I'm wrong. I want to understand if the .d file had never been generated or had been generated but deleted by the time fixdep tries to open it.
> 
Please teach yourself to punch new-line now and then.

	Sam

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Michal Marek]

On 29.8.2013 19:55, Sam Ravnborg wrote:
> Magic happens in Kbuild.include, Makefile.lib and Makefile.build.
> But it make take some cup of coffee to grasp it.
> 
> For find and fix whatever race condition you hit.

BTW, there is a fix in 3.11 that might be relevant for you:

commit 4d47dde47f7dd95042fa56283d948f50dd4b509c
Author: 张忠山 <zzs0213@gmail.com>
Date:   Sun Jun 30 17:09:28 2013 +0800

    kbuild: create directory for dir/file.o

At least, it's worth trying.

Michal

Re: Can anyone suggest a better fix? Not sure if I understand the problem, but the patch fixed it

[Michal Marek]

On 29.8.2013 19:55, Sam Ravnborg wrote:
> Magic happens in Kbuild.include, Makefile.lib and Makefile.build.
> But it make take some cup of coffee to grasp it.
> 
> For find and fix whatever race condition you hit.

BTW, there is a fix in 3.11 that might be relevant for you:

commit 4d47dde47f7dd95042fa56283d948f50dd4b509c
Author: 张忠山 <zzs0213@gmail.com>
Date:   Sun Jun 30 17:09:28 2013 +0800

    kbuild: create directory for dir/file.o

At least, it's worth trying.

Michal