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 */

  * 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?

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

1 Answer 1


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.

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .