Modules build with incorrect version magic about xpadneo HOT 17 CLOSED

Hi there, are you sure that the module is not loaded?
Sometimes the kernel complains but still loads it (try lsmod | grep xpadneo)

The problem is -32-lowlatency, which is the so called Extraversion - there are two solutions I can think of:

1. EDIT: the following does not work! (see below for a correct solution)

   Using EXTRAVERSION as a Environment-Variable while compiling

   EXTRAVERSION:
     sh: uname -r | sed  's/[^-]*\(.*\)/\1/'
   

   Take a look here for a Taskfile.yml: https://github.com/atar-axis/xpadneo/blob/develop/Taskfile.yml

   This should pass EXTRAVERSION=-32-lowlatency to GNU Make, same as if you would run make EXTRAVERSION=-32-lowlatency

2. Use modprobe --force-magic ... (which i would't recommend)

Please let me know if any of the above solutions work! Thanks

from xpadneo.

I tried it myself, can you please confirm the following:

1. Delete the driver hid-xpadneo.ko in build/.../drivers/hid
2. Manipulate /build/linux-4.14.15/include/generated/utsrelease.h to reflect the desired version:
   #define UTS_RELEASE "4.13.0-32-lowlatency"
3. Run task again to recompile the deleted hid-xpadneo.ko (shouldn't take long!)
4. try to load the compiled module using modprobe ./hid-xpadneo.ko

Does it work this way? if yes, we have to change either LOCALVERSION or EXTRAVERSION, i am still searching for the correct solution since reliable information is rare on that topic.

from xpadneo.

I have run task clean previously so it will take some time but I'll try this immediately and will come back to you once it is done. Thanks.

from xpadneo.

Alright so now after editing the utsrelease.h file the module loads with a [ 5799.434044] xpadneo: hello there! message. So I guess it's a step towards the right direction.

from xpadneo.

The controller also pairs with no problems when I do the same with the bluetooth and hid modules and I get input in jstest-gtk. The only problem then being the incorrect mapping as stated by #1 and also what happens with xpad (I'll post my dmesg output in the related issue).

from xpadneo.

ah yes, that sounds better ;) to fix that issue, can you please tell me what's inside your local .config file (please use pastebin.com or sth similar) - thank you!

btw: if the contoller is paired with xpadne, then the controller should rumble twice ;) so if it does not - it is not binded corretly.

from xpadneo.

Here is the config (I suppose uploading to GitHub is okay?): localconfig.txt

It did rumble twice when I bound the controller manually as you told me on the other issue.

from xpadneo.

thank you!
for sure, i just wasn't aware of that option ;)
as I already assumed, your LOCALVERSION in the .config is empty:
CONFIG_LOCALVERSION=""
that's exactly why it (loading) doesn't work "out of the box".

UTS_RELEASE is a composition of your kernel version, EXTRAVERSION and LOCALVERSION.
let see how to override that...

btw:
is there maybe more than one .config in your system?

copy_config_from_local:
  cmds:
    - |
      if [ -f /proc/config.gz ] ; then
        gzip --decompress < /proc/config.gz > {{.ROOT_DIR}}/.config
      elif [ -f /boot/config-{{.K_VER}}/.config ] ; then
        cp /boot/config-{{.K_VER}}/.config {{.ROOT_DIR}}/
      elif [ -f /boot/config-{{.K_VER_LONG}} ] ; then
        cp /boot/config-{{.K_VER_LONG}} {{.ROOT_DIR}}/.config
      elif [ -f /usr/lib/modules/{{.K_VER_LONG}}/build/.config ] ; then
        cp /usr/lib/modules/{{.K_VER_LONG}}/build/.config {{.ROOT_DIR}}/
      fi;

from xpadneo.

Btw, could you please also upload you local Makefile?
It should be somewhere where /usr/lib/modules/{{.K_VER_LONG}}/build/

from xpadneo.

Here's the Makefile. I don't know if there is more than one .config file, I'll try to look around for information about how Canonical build their kernel, maybe that'll help.

from xpadneo.

Ok so apparently what they do is they pass the LOCALVERSION to make as an argument during the build, by their example:

make -j `getconf _NPROCESSORS_ONLN` deb-pkg LOCALVERSION=-custom

I made a modification to the Taskfile like so:

make_modulesymvers:
  cmds:
    - make --directory={{.ROOT_DIR}} -j6 scripts LOCALVERSION={{.LOCALVERSION}}
    - make --directory={{.ROOT_DIR}} -j6 modules
  status:
    - test -f {{.ROOT_DIR}}/Module.symvers

(the LOCALVERSION here is just what I renamed the EXTRAVERSION variable from the develop branch to)

Like this the include/generated/utsrelease.h file generated correctly for my system.

from xpadneo.

hum... that's really strange: EXTRAVERSION is also empty!
So.. where does that -32-lowlatency in your system come from?

There are exactly two possibilities:

• CONFIG_LOCALVERSION (which is specified in .config, or passed by an argument named LOCALVERSION)
• EXTRAVERSION (which is specified in Makefile)

Where did that localconfig.txt (which you posted above) came from?

There should be a LOCALVERSION=-32-lowlatency in any of those files:

• /proc/config.gz
• /boot/config-{{.K_VER}}/.config
• /boot/config-{{.K_VER_LONG}}
• /usr/lib/modules/{{.K_VER_LONG}}/build/.config

from xpadneo.

I think they just pass it to make in the command line as I stated above. With the modification there it appears to be working. I'm rebuilding the whole thing right now just to be sure. But the content of the utsrelease.h checks out.

from xpadneo.

sorry, our posts overlapped ;)
Unfortunately your solution does not work on my local system:

The result of uname -a is ...4.14.15-1-ARCH...
Therefore 4.14.15 is the Kernel version, and -1-ARCH is either CONFIG_LOCALVERSION or EXTRAVERSION or a combination of both.

It is in fact a combination since in my local Makefile (in /usr/lib/modules/4.14.15-1-ARCH/build/) you can read: EXTRAVERSION = -1
and in .config (in the same directory) you can read CONFIG_LOCALVERSION="-ARCH"

The EXTRAVERSION on the xpadneo/build-directory is empty since we download a clean Kernel, without any Modifications at the Makefile. But the .config is copied from the local system.

So the situation in my xpadneo/build-directory is like:

• EXTRAVERSION="" and
• CONFIG_LOCALVERSION="-ARCH".

Running make with LOCALVERSION as an argument does not override(!) the CONFIG_LOCALVERSION in the .config-file! it is appended

So as a result my UTS_RELEASE now looks like:

#define UTS_RELEASE "4.14.15-ARCH-1-ARCH"

Back to your system:

I don't think that they really pass LOCALVERSION somewhere, can you please take a look at those files to make sure that there is no -32-lowlatency somehwere? As you can see on the lines above, it is there in my system and it should also be there at yours :)

• /proc/config.gz
• /boot/config-{{.K_VER}}/.config
• /boot/config-{{.K_VER_LONG}}
• /usr/lib/modules/{{.K_VER_LONG}}/build/.config

I think, the problem is, that we copy a .config from your local system, which is not the one which is used for building a new kernel. The other problem we have: We do not

from xpadneo.

Well in my system there are configs at /boot/config-{{.K_VER_LONG}} but none of them, not the lowlatency ones, not the generic ones, have the CONFIG_LOCALVERSION filled. No hint of a different .config.

from xpadneo.

okay, that's strange - then we will have to do it this way:

1. modifications as you did above (passing the extracted uname string as localversion to make)
2. remove the orginal config_localversion from the .config (using the patch_config-task)

from xpadneo.

pushed the changes to master - thank you a lot!

from xpadneo.