Bug 10845 - test-image: compile and load a kernel module under the qemu-lsb image is failing
Summary: test-image: compile and load a kernel module under the qemu-lsb image is failing
Status: RESOLVED NOTABUG
Alias: None
Product: BSPs
Classification: Build System, Metadata & Runtime
Component: bsps-runtime (show other bugs)
Version: 2.3
Hardware: x86 Multiple
: Medium normal
Target Milestone: 2.3 M3
Assignee: Bruce Ashfield
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-12-22 14:35 UTC by Jose Perez C
Modified: 2017-01-11 16:30 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jose Perez C 2016-12-22 14:35:43 UTC 
STATUS: FAILED
BUILD: 2.3_M1_rc1: 573c646d4cc62dcd0c230381df4940bdf314d495
ENVIRONMENT: qemux86_64-lsb
Image: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/qemu/qemux86-64-lsb/core-image-lsb-sdk-qemux86-64.ext4


STEPS TO REPRODUCE: THIS IS A COPY OF TC 316 AND IS REPORTED WITH THAT ID ON TESTIMAGE



1.Create a QEMU(x86 or x86-64) core-image-sato-sdk image. 
 

2.Run 'make scripts' in /usr/src/kernel
 


3. cd /home/root and create hello.c with the following content:




#undef __KERNEL__
#define __KERNEL__

#undef MODULE
#define MODULE

#include <linux/module.h>	
#include <linux/kernel.h>	
#include <linux/init.h>		


static int __init hello_init(void)
{
    printk(KERN_INFO "Hello world!\n");
    return 0;	
}

static void __exit hello_cleanup(void)
{
    printk(KERN_INFO "Cleaning up module.\n");
}

module_init(hello_init);
module_exit(hello_cleanup);



4. Create a Makefile with the following content and run 'make'

obj-m := hello.o
KDIR := /usr/src/kernel
PWD := $(shell pwd)

all:
	$(MAKE) -C $(KDIR) M=$(PWD) modules
 
clean:
	$(MAKE) -C $(KDIR) M=$(PWD) clean



5. Run insmod hello.ko
  

6.After the module is compiled and loaded, check that it is present by running "lsmod" command and dmesg | grep -i hello



EXPECTED OUTCOME: The module could be properly loaded

ACTUAL OUTCOME: 

Traceback (most recent call last):
  File "/home/jgperezc/Yocto/poky-2.3-lsb/meta/lib/oeqa/utils/decorators.py", line 109, in wrapped_f
    return func(*args, **kwargs)
  File "/home/jgperezc/Yocto/poky-2.3-lsb/meta/lib/oeqa/utils/decorators.py", line 97, in wrapped_f
    return f(*args, **kwargs)
  File "/home/jgperezc/Yocto/poky-2.3-lsb/meta/lib/oeqa/utils/decorators.py", line 97, in wrapped_f
    return f(*args, **kwargs)
  File "/home/jgperezc/Yocto/poky-2.3-lsb/meta/lib/oeqa/runtime/kernelmodule.py", line 31, in test_kernel_module
    self.assertEqual(status, 0, msg="\n".join([cmd, output]))
AssertionError: 1 != 0 : cd /tmp && insmod hellomod.ko
insmod: ERROR: could not insert module hellomod.ko: Invalid module format
Comment 1 Bruce Ashfield 2017-01-10 20:37:38 UTC 
This is likely modversions kicking in.

Can you check to see if the kernel build has MODVERSIONS enabled ? Also, what does dmesg log when the module load fails ? It could also be an invalid entry point, but something should be dumped in those cases.
Comment 2 Jose Perez C 2017-01-10 21:29:39 UTC 
Checking on file /proc/config.gz is giving:
# CONFIG_MODVERSIONS is not set

----

The image kernel is giving:
$uname -r 
kernel 4.8.12-yocto-standard

----
and dmesg is giving the following: 

[ 2337.132062] hello: version magic '4.1.36-yocto-standard SMP preempt mod_unload PENTIUMM ' should be '4.8.12-yocto-standard SMP preempt mod_unload PENTIUMM '
Comment 3 Bruce Ashfield 2017-01-10 21:31:27 UTC 
(In reply to comment #2)
> Checking on file /proc/config.gz is giving:
> # CONFIG_MODVERSIONS is not set
> 
> ----
> 
> The image kernel is giving:
> $uname -r 
> kernel 4.8.12-yocto-standard
> 
> ----
> and dmesg is giving the following: 
> 
> [ 2337.132062] hello: version magic '4.1.36-yocto-standard SMP preempt
> mod_unload PENTIUMM ' should be '4.8.12-yocto-standard SMP preempt
> mod_unload PENTIUMM '

aha. so it is a version skew. The running kernel is different from the SDK one. Is one build using AUTOREV ? i.e. the image one is AUTOREV but the SDK is fixed ? or vice versa ?
Comment 4 Jose Perez C 2017-01-10 21:36:56 UTC 
(In reply to comment #3)
> (In reply to comment #2)
> > Checking on file /proc/config.gz is giving:
> > # CONFIG_MODVERSIONS is not set
> > 
> > ----
> > 
> > The image kernel is giving:
> > $uname -r 
> > kernel 4.8.12-yocto-standard
> > 
> > ----
> > and dmesg is giving the following: 
> > 
> > [ 2337.132062] hello: version magic '4.1.36-yocto-standard SMP preempt
> > mod_unload PENTIUMM ' should be '4.8.12-yocto-standard SMP preempt
> > mod_unload PENTIUMM '
> 
> aha. so it is a version skew. The running kernel is different from the SDK
> one. Is one build using AUTOREV ? i.e. the image one is AUTOREV but the SDK
> is fixed ? or vice versa ?

I'm not building the images, I'm using the ones uploaded to the public AB http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/qemu/qemux86-lsb/ is there a way to check this directly on the image booted?
Comment 5 Bruce Ashfield 2017-01-11 15:19:04 UTC 
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Checking on file /proc/config.gz is giving:
> > > # CONFIG_MODVERSIONS is not set
> > > 
> > > ----
> > > 
> > > The image kernel is giving:
> > > $uname -r 
> > > kernel 4.8.12-yocto-standard
> > > 
> > > ----
> > > and dmesg is giving the following: 
> > > 
> > > [ 2337.132062] hello: version magic '4.1.36-yocto-standard SMP preempt
> > > mod_unload PENTIUMM ' should be '4.8.12-yocto-standard SMP preempt
> > > mod_unload PENTIUMM '
> > 
> > aha. so it is a version skew. The running kernel is different from the SDK
> > one. Is one build using AUTOREV ? i.e. the image one is AUTOREV but the SDK
> > is fixed ? or vice versa ?
> 
> I'm not building the images, I'm using the ones uploaded to the public AB
> http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/
> qemu/qemux86-lsb/ is there a way to check this directly on the image booted?

Not really. But you can check the captured kernel source in the SDK and note the version from the Makefile. 

The system is working as expected by refusing to load the version mismatched kernel module and running kernel.

Not knowing how the kernel you are booting is associated to the SDK you are downloading I can't say exactly why they are different.

Do you know where both are coming from ? Can we confirm they are from the same build / build artifacts ?
Comment 6 Jose Perez C 2017-01-11 16:13:11 UTC 
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > Checking on file /proc/config.gz is giving:
> > > > # CONFIG_MODVERSIONS is not set
> > > > 
> > > > ----
> > > > 
> > > > The image kernel is giving:
> > > > $uname -r 
> > > > kernel 4.8.12-yocto-standard
> > > > 
> > > > ----
> > > > and dmesg is giving the following: 
> > > > 
> > > > [ 2337.132062] hello: version magic '4.1.36-yocto-standard SMP preempt
> > > > mod_unload PENTIUMM ' should be '4.8.12-yocto-standard SMP preempt
> > > > mod_unload PENTIUMM '
> > > 
> > > aha. so it is a version skew. The running kernel is different from the SDK
> > > one. Is one build using AUTOREV ? i.e. the image one is AUTOREV but the SDK
> > > is fixed ? or vice versa ?
> > 
> > I'm not building the images, I'm using the ones uploaded to the public AB
> > http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/
> > qemu/qemux86-lsb/ is there a way to check this directly on the image booted?
> 
> Not really. But you can check the captured kernel source in the SDK and note
> the version from the Makefile. 
> 
> The system is working as expected by refusing to load the version mismatched
> kernel module and running kernel.
> 
> Not knowing how the kernel you are booting is associated to the SDK you are
> downloading I can't say exactly why they are different.
> 
> Do you know where both are coming from ? Can we confirm they are from the
> same build / build artifacts ?

I saw that there are 2 kenles uploade to the AB, I do a test with both and below are the results :

http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/qemu/qemux86-lsb/  

- bzImage--4.1.36+git0+44719fa8f7_fec4924781-r0.2-qemux86-20161216115813.bin: running with this one the test PASS 

- bzImage-qemux86.bin : running with this one the test FAIL
Comment 7 Jose Perez C 2017-01-11 16:30:43 UTC 
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > > > (In reply to comment #2)
> > > > > Checking on file /proc/config.gz is giving:
> > > > > # CONFIG_MODVERSIONS is not set
> > > > > 
> > > > > ----
> > > > > 
> > > > > The image kernel is giving:
> > > > > $uname -r 
> > > > > kernel 4.8.12-yocto-standard
> > > > > 
> > > > > ----
> > > > > and dmesg is giving the following: 
> > > > > 
> > > > > [ 2337.132062] hello: version magic '4.1.36-yocto-standard SMP preempt
> > > > > mod_unload PENTIUMM ' should be '4.8.12-yocto-standard SMP preempt
> > > > > mod_unload PENTIUMM '
> > > > 
> > > > aha. so it is a version skew. The running kernel is different from the SDK
> > > > one. Is one build using AUTOREV ? i.e. the image one is AUTOREV but the SDK
> > > > is fixed ? or vice versa ?
> > > 
> > > I'm not building the images, I'm using the ones uploaded to the public AB
> > > http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/
> > > qemu/qemux86-lsb/ is there a way to check this directly on the image booted?
> > 
> > Not really. But you can check the captured kernel source in the SDK and note
> > the version from the Makefile. 
> > 
> > The system is working as expected by refusing to load the version mismatched
> > kernel module and running kernel.
> > 
> > Not knowing how the kernel you are booting is associated to the SDK you are
> > downloading I can't say exactly why they are different.
> > 
> > Do you know where both are coming from ? Can we confirm they are from the
> > same build / build artifacts ?
> 
> I saw that there are 2 kenles uploade to the AB, I do a test with both and
> below are the results :
> 
> http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/
> qemu/qemux86-lsb/  
> 
> -
> bzImage--4.1.36+git0+44719fa8f7_fec4924781-r0.2-qemux86-20161216115813.bin:
> running with this one the test PASS 
> 
> - bzImage-qemux86.bin : running with this one the test FAIL

Seems like there were a mistake on the link for Artifacts download script.. I downloaded correct artifacts and tested again with both Kernels an d the error is not appearing anymore. Will close this as not a bug