| Message ID | 02E7334B1630744CBDC55DA85862258348E431C1@ORSMSX102.amr.corp.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: ");