LinuxQuestions.org - compiling kernel 2.6.38.6 on Slackware 13.37

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - compiling kernel 2.6.38.6 on Slackware 13.37 (https://www.linuxquestions.org/questions/slackware-14/compiling-kernel-2-6-38-6-on-slackware-13-37-a-880057/)

compiling kernel 2.6.38.6 on Slackware 13.37

Anyone able to compile kernel 2.6.38.6 on Slackware 13.37 successfully using the config from testing/2.6.38.4? I was able to get .4 and .5 to compile successfully, but with .6 I get the following after running "make modules"

Code:

WARNING: modpost: Found 11 section mismatch(es).

To see full details build your kernel with:

'make CONFIG_DEBUG_SECTION_MISMATCH=y'

Running "make CONFIG_DEBUG_SECTION_MISMATCH=y 2>&1 > outfile" gives me a bunch of WARNINGS as follows:

Code:

WARNING: vmlinux.o(.text+0xe656a): Section mismatch in reference from the function build_all_zonelists() to the function .meminit.text:setup_zone_pageset.clone.56()

The function build_all_zonelists() references

the function __meminit setup_zone_pageset.clone.56().

This is often because build_all_zonelists lacks a __meminit 

annotation or the annotation of setup_zone_pageset.clone.56 is wrong.



WARNING: drivers/char/ipmi/ipmi_si.o(.devinit.text+0xe21): Section mismatch in reference from the function init_module() to the function .exit.text:cleanup_ipmi_si()

The function __devinit init_module() references

a function __exit cleanup_ipmi_si().

This is often seen when error handling in the init function

uses functionality in the exit path.

The fix is often to remove the __exit annotation of

cleanup_ipmi_si() so it may be used outside an exit section.



WARNING: drivers/gpio/cs5535-gpio.o(.data+0x20): Section mismatch in reference from the variable cs5535_gpio_drv to the function .devinit.text:cs5535_gpio_probe()

The variable cs5535_gpio_drv references

the function __devinit cs5535_gpio_probe()

If the reference is valid then annotate the

variable with __init* or __refdata (see linux/init.h) or name the variable:

*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, 



WARNING: drivers/gpio/cs5535-gpio.o(.data+0x28): Section mismatch in reference from the variable cs5535_gpio_drv to the function .devexit.text:cs5535_gpio_remove()

The variable cs5535_gpio_drv references

the function __devexit cs5535_gpio_remove()

If the reference is valid then annotate the

variable with __exit* (see linux/init.h) or name the variable:

*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, 



WARNING: drivers/leds/leds-lp5521.o(.text+0xec7): Section mismatch in reference from the function lp5521_probe() to the function .init.text:lp5521_init_led.clone.5()

The function lp5521_probe() references

the function __init lp5521_init_led.clone.5().

This is often because lp5521_probe lacks a __init 

annotation or the annotation of lp5521_init_led.clone.5 is wrong.



WARNING: drivers/leds/leds-lp5523.o(.text+0x153c): Section mismatch in reference from the function lp5523_probe() to the function .init.text:lp5523_init_led.clone.6()

The function lp5523_probe() references

the function __init lp5523_init_led.clone.6().

This is often because lp5523_probe lacks a __init 

annotation or the annotation of lp5523_init_led.clone.6 is wrong.



WARNING: drivers/mfd/cs5535-mfd.o(.data+0x20): Section mismatch in reference from the variable cs5535_mfd_drv to the function .devinit.text:cs5535_mfd_probe()

The variable cs5535_mfd_drv references

the function __devinit cs5535_mfd_probe()

If the reference is valid then annotate the

variable with __init* or __refdata (see linux/init.h) or name the variable:

*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, 



WARNING: drivers/mfd/cs5535-mfd.o(.data+0x28): Section mismatch in reference from the variable cs5535_mfd_drv to the function .

devexit.text:cs5535_mfd_remove()

The variable cs5535_mfd_drv references

the function __devexit cs5535_mfd_remove()

If the reference is valid then annotate the

variable with __exit* (see linux/init.h) or name the variable:

*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, 



WARNING: drivers/misc/cs5535-mfgpt.o(.data+0x0): Section mismatch in reference from the variable cs5535_mfgpt_drv to the function .devinit.text:cs5535_mfgpt_probe()

The variable cs5535_mfgpt_drv references

the function __devinit cs5535_mfgpt_probe()

If the reference is valid then annotate the

variable with __init* or __refdata (see linux/init.h) or name the variable:

*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, 



WARNING: drivers/misc/ioc4.o(.data+0x18): Section mismatch in reference from the variable ioc4_load_modules_work to the function .devinit.text:ioc4_load_modules()

The variable ioc4_load_modules_work references

the function __devinit ioc4_load_modules()

If the reference is valid then annotate the

variable with __init* or __refdata (see linux/init.h) or name the variable:

*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, 



WARNING: drivers/net/irda/smsc-ircc2.o(.devinit.text+0xd3): Section mismatch in reference from the function smsc_ircc_pnp_probe() to the function .init.text:smsc_ircc_open()

The function __devinit smsc_ircc_pnp_probe() references

a function __init smsc_ircc_open().

If smsc_ircc_open is only used by smsc_ircc_pnp_probe then

annotate smsc_ircc_open with a matching annotation.



WARNING: drivers/net/pch_gbe/pch_gbe.o(.data+0x38): Section mismatch in reference from the variable pch_gbe_pcidev to the variable .devinit.rodata:pch_gbe_pcidev_id

The variable pch_gbe_pcidev references

the variable __devinitconst pch_gbe_pcidev_id

If the reference is valid then annotate the

variable with __init* or __refdata (see linux/init.h) or name the variable:

*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, 



WARNING: drivers/target/target_core_mod.o(.text+0x5c0c): Section mismatch in reference from the function init_module() to the function .init.text:rd_module_init()

The function init_module() references

the function __init rd_module_init().

This is often because init_module lacks a __init 

annotation or the annotation of rd_module_init is wrong.



WARNING: drivers/video/geode/gx1fb.o(.data+0x80): Section mismatch in reference from the variable gx1fb_driver to the function .init.text:gx1fb_probe()

The variable gx1fb_driver references

the function __init gx1fb_probe()

If the reference is valid then annotate the

variable with __init* or __refdata (see linux/init.h) or name the variable:

*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, 



WARNING: drivers/watchdog/nv_tco.o(.devinit.text+0x14): Section mismatch in reference from the function nv_tco_init() to the function .init.text:nv_tco_getdevice()

The function __devinit nv_tco_init() references

a function __init nv_tco_getdevice().

If nv_tco_getdevice is only used by nv_tco_init then

annotate nv_tco_getdevice with a matching annotation.

i usually ignored this kind of warnings

I'm running 38.6 using the generic config file from testing on 64bit and everything appears to be fine. I didn't pay attention to the messages during compilation, so no idea whether it produced those warnings or not (I suppose I really ought to log them, might have to look at that).

Did you remember the "make oldconfig" ?

Yep, ran "make oldconfig" to bring the 2.6.38.4 config file over to 2.6.38.6 to make sure nothing new needed my attention. Looking over my history of commands, it looks like in the past I've always combined the last two steps as "make modules modules_install" rather than run them separately one after the other so there may have been warnings that I missed then. I suppose these warnings aren't fatal then...

it's safer to copy it manually from /boot instead of using make oldconfig since you are sure which config will you use in your future kernel

Quote:

Originally Posted by willysr (Post 4353495)

it's safer to copy it manually from /boot instead of using make oldconfig since you are sure which config will you use in your future kernel

Actually what I did was copy the generic config provided from slack-current in testing under the 2.6.38.4 directory. I copied it into my linux-2.6.38.6 folder as .config, ran "make oldconfig" and then the usual. If I copy it from /boot, it would have been from the 2.6.37.xx kernel provided with Slackware 13.37. Reason I do this is because I like the idea of running Slackware configured kernels and would rather not having to figure out what each new kernel option means.

Respectfully Disagree

Quote:

Originally Posted by willysr (Post 4353495)

it's safer to copy it manually from /boot instead of using make oldconfig since you are sure which config will you use in your future kernel

Greetz
To quote Robert Heinlein "TAANSTAAFL" (== There Ain't No Such Thing As A Free Lunch). IMHO even if you copy from "/boot" this is not enough and you need to run "make oldconfig" and to be truly thorough, "make prepare" as well. It is worthy to note that OPs fail occurs on modules since this is an area that changes more drastically than the rest. If you compile your own kernels, at least once in your life you owe it to yourself to sun "make xconfig" so you can see all three (3) areas at once - Tree, Item, Help. You will see how much is kept around that is deprecated or duplicated. Example - there are at least 3 modules available for RT8139. If all are available as modules and none blacklisted you run the risk of conflicts. This is generally solved by knowing (or finding out) what modules you need and that work best and disabling any possible conflicts. This is what "make oldconfig" is for since it keeps what worked before and asks you about new items not available in the previous version.

Specific to thread - I suggest redoing with fresh source, "make mrproper" and then

Code:

make oldconfig&&make prepare&&make menuconfig&&make bzImage&&make modules&&make modules_install

Note - "make menuconfig" is run just to offer the "save" and "save as" functions.

Considering how fundamental and important the kernel is, can you really afford to cut corners?

Code:

make mrproper

zcat /proc/config > .config

make oldconfig

make prepare

make nconfig

make -j3 bzImage modules

make modules_install

and if you want to save some space run this to gzip all modules for all kernels but I recommend to use this just for the one you are installing ATM.

Code:

find /lib/modules -name '*.ko' -exec gzip -9 {} \;

Perhaps a stupid question, but I can't be the only person here who, after noting from the logs what drivers are used, compiles a new kernel from scratch including only what's necessary and NOT relying on the included configs? Or, what if new options show up and/or old options are removed from a future kernel release?

I normally run my own hand-crafted/minimal custom kernel. The only reason I was running generic was to aid in testing during the RC phase and then to see what changes Pat was looking at in the "testing/" kernels. My own kernel has one or two differences to Pat's testing/ configs: for a start it doesn't do the CONFIG_SCHED_AUTOGROUP stuff as I don't like that approach to scheduling.

new/old options are why "make oldconfig" is provided, though every once in a while it doesn't hurt to set aside an hour or so and start from scratch to clear out all the cruft (but it's a bit of a pain so I don't do it often).

Quote:

Originally Posted by GazL (Post 4354139)

for a start it doesn't do the CONFIG_SCHED_AUTOGROUP stuff as I don't like that approach to scheduling.

how about BFS?

Yeah, I've used BFS in the past and was very impressed with it (I might install it again at some point).

Quote:

Originally Posted by GazL (Post 4354139)

new/old options are why "make oldconfig" is provided, though every once in a while it doesn't hurt to set aside an hour or so and start from scratch to clear out all the cruft (but it's a bit of a pain so I don't do it often).

Well said! Definitely need to get back into this habit of clearing out definitely known "cruft" that my system won't use, as I have definitely gotten lazy when it comes to this.

Quote:

Originally Posted by storkus (Post 4353997)

I do this to some degree. I had the perfect .config file and usually reused that since I never get any new hardware. However, I don't know which one it is any longer, it got mixed up with some other config-files, so I had to redo the whole thing. I didn't have time to go though all, so I'm running a compact kernel (and few modules), but it could be better.

A good place to start for lazy people with special interests:
Pappys kernel seed
Where the main part is copy-pasting the output of
$ lspci -n
into this page

And it will show you many of the modules you will need, but not everyone, so you still need to know what you are doing. Forinstance it didn't add my DVD when I used this a few years back. Be sure to read through the whole page before making any changes. Remember backup, do this at your own risk, and so on.

Quote:

Originally Posted by Dinithion (Post 4354197)

A good place to start for lazy people with special interests:
Pappys kernel seed
Where the main part is copy-pasting the output of
$ lspci -n
into this page

And it will show you many of the modules you will need, but not everyone, so you still need to know what you are doing. Forinstance it didn't add my DVD when I used this a few years back. Be sure to read through the whole page before making any changes. Remember backup, do this at your own risk, and so on.

Thanks for this! One of the reasons why I avoid configuring a kernel from scratch is because of the fear of missing certain options that are critical to getting a kernel to run. While I may not configure from scratch, I will use this information to cut out some unnecessary stuff from Slackware's config.