2

I need to apply the following patch, and I don't want to mess up what I have so far. Below I have posted the complete content I found online, which was someone's response to a question similar to mine.

On Tue, 2007-03-20 at 14:32 -0500, James Bottomley wrote:

Is MODULE set to 'n'? It looks like the symbol export is guarded by #ifdef MODULE for some reason ... other than that, I can't explain this.

In fact, that's the bug ... the modular config is MODULES not MODULE. Can you try this:

--- diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 0949145..a67f315 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -181,10 +181,8 @@ int scsi_complete_async_scans(void) return 0; } -#ifdef MODULE /* Only exported for the benefit of scsi_wait_scan */ EXPORT_SYMBOL_GPL(scsi_complete_async_scans); -#endif /** * scsi_unlock_floptical - unlock device via a special MODE SENSE command

I found the code above online as a solution to the problem I am running into. I am trying to build modules for my own kernel. My question is how do I apply the above patch, please? I guess I have to be in a directory which I can see /drivers, right? What should I do after that, please?

Here is the error I get when I issue "make modules" to build my kernel and the associated device drivers: 

sansari@ubuntu:~/WORKING_DIRECTORY$ make modules scripts/kconfig/conf --silentoldconfig Kconfig sound/soc/codecs/audience/Kconfig:40:warning: type of 'SND_SOC_ES_SLIM' redefined from 'boolean' to 'tristate' sound/soc/codecs/audience/Kconfig:43:warning: type of 'SND_SOC_ES_I2C' redefined from 'boolean' to 'tristate' sound/soc/codecs/audience/Kconfig:44:warning: choice value used outside its choice group sound/soc/codecs/audience/Kconfig:41:warning: choice value used outside its choice group CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CC arch/arm/kernel/asm-offsets.s GEN include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CC [M] drivers/scsi/scsi_wait_scan.o Building modules, stage 2. MODPOST 1 modules ERROR: "__aeabi_unwind_cpp_pr0" [drivers/scsi/scsi_wait_scan.ko] undefined! ERROR: "__aeabi_unwind_cpp_pr1" [drivers/scsi/scsi_wait_scan.ko] undefined! ERROR: "scsi_complete_async_scans" [drivers/scsi/scsi_wait_scan.ko] undefined! ERROR: "wait_for_device_probe" [drivers/scsi/scsi_wait_scan.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2

@faheem - Thanks. I am still not clear on which files to apply this change to. Could someone explain what the fix is doing? Which files it is updating and how? My understanding of patch is that you add it to a file. It has a few lines before and after the change. The program matches the strings in the target file, and then applies the change. Am I correct in saying that above fix is changing kconfig and scsi_scan.c?

Improve this question
1
  • 1
    You probably want to put the sources under version control before applying the patch, in case things go wrong. Commented May 2, 2015 at 2:25

1 Answer 1

Reset to default
5

Patches are applied1 with the patch command. The drivers/ directory you're looking for is in the top-level of the kernel source tree; you'd apply it something like this:

$ cd ~/linux $ ls arch firmware lib README usr block fs MAINTAINERS REPORTING-BUGS virt COPYING include Makefile samples vmlinux CREDITS init mm scripts vmlinux-gdb.py crypto ipc modules.builtin security vmlinux.o debian Kbuild modules.order sound Documentation Kconfig Module.symvers System.map drivers kernel net tools $ patch -p1 < ~/path/patch-file.diff

That ls in there is just to show you what you should expect the correct directory to look like. A few of those files are only there after building (e.g., vmlinux) so don't worry if they're missing. The -p1 means to ignore the a/ and b/ in front of the path names in the patch (-p0 wouldn't ignore any of it, -p2 would ignore a/drivers, etc.)

That hopefully answers your question, but unless you've actually built your kernel w/o loadable modules (which you haven't, if you're doing make modules), its unlikely to fix the error you're seeing.

Footnotes
1 You can also have git apply them if you're using it for version control, but I'm guessing you aren't.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.