Bug#697061: nvidia-kernel-dkms: Module fails to build against linux-headers-3.7-trunk-amd64 (VM_RESERVED undeclared)

Wed Jan 23 19:45:21 UTC 2013

Hi Andreas,

On Wed, Jan 23, 2013 at 01:22:59AM +0100, Andreas Beckmann wrote:
> On 2013-01-22 19:19, Andre Beck wrote:
> > for reasons I don't grok entirely, 304.64-4 doesn't fix the build issue
> > for me, though I'm building against linux-3.7.y stable (which in turn
> > is built using kernel-package).
> So that's a non-debian kernel ...

Yep, but that's not the real trigger, the key to running into my problem
is a particular way of ending up with an unclean build environment. See
below for the details.

> My compile test chroot contains all Debian kernel header packages from
> squeeze, squeeze-backports, wheezy, sid, experimental (including ABIs no
> longer available) for all kernel flavors that exist for arch:amd64. And
> it builds without failures.
> But I have no vanilla kernels in my test scenario ...

Even if there would be one, your test scenario is unlikely to hit that
failure mode.

> if LINUX_VERSION_CODE doesn't work here, it probably doesn't work
> elsewhere, too (conftest.h ...)
> 
> For debugging add this
> 
> #define STRINGIFY(x) #x
> #define DO_PRAGMA(x) _Pragma (#x)
> #define DUMP(x) DO_PRAGMA(message ("DUMP " #x " = " STRINGIFY(x)))
> DUMP(LINUX_VERSION_CODE)
> DUMP(KERNEL_VERSION(3,7,0))

Cool ;)

> right above the problematic #ifdef and look in the dkms build log for
> the output.
> 
> I get for linux-headers-3.7-trunk-amd64 (3.7.3-1~experimental.1) the
> following:
> 
> /var/lib/dkms/nvidia/304.64/build/nv-mmap.c:478:1: note: #pragma
> message: DUMP LINUX_VERSION_CODE = 198403
> /var/lib/dkms/nvidia/304.64/build/nv-mmap.c:479:1: note: #pragma
> message: DUMP KERNEL_VERSION(3,7,0) = (((3) << 16) + ((7) << 8) + (0))
> 
> and   3*2^16 + 7*2^8 + 0 = 198400   (according to bc)

That results in

/var/lib/dkms/nvidia/304.64/build/nv-mmap.c:469:1: note: #pragma message: DUMP LINUX_VERSION_CODE = 198155
/var/lib/dkms/nvidia/304.64/build/nv-mmap.c:470:1: note: #pragma message: DUMP KERNEL_VERSION(3,7,0) = (((3) << 16) + ((7) << 8) + (0))
/var/lib/dkms/nvidia/304.64/build/nv-mmap.c:479:47: error: `VM_RESERVED' undeclared (first use in this function)

here, so there is clearly something wrong. Note that 198155 is 3.6.11, the
very kernel I've built before in the same directory.

> I would expect LINUX_VERSION_CODE not to be defined, that should be the
> only way to trigger this error, so Debian kernels #include things
> differently than upstream ...
> 
> Also add to the head of conftest.h (after the #include block):
> 
> #ifndef LINUX_VERSION_CODE
> #error NO LINUX_VERSION_CODE
> #endif

It is defined, just wrongly.

> After a failed build
>   grep version.h /var/lib/dkms/nvidia/304.64/build/.nv*
> might be interesting to see whether a "wrong" version.h gets included,
> also look for all the version.h in your kernel tree ...

And there we are:

hopper:/usr/src/git/linux-stable# cat include/linux/version.h 
#define LINUX_VERSION_CODE 198155

hopper:/usr/src/git/linux-stable# make-kpkg clean
hopper:/usr/src/git/linux-stable# cat include/linux/version.h 
#define LINUX_VERSION_CODE 198155

hopper:/usr/src/git/linux-stable# git branch
  linux-3.0.y
  linux-3.1.y
  linux-3.2.y
  linux-3.3.y
  linux-3.4.y
  linux-3.5.y
  linux-3.6.y
* linux-3.7.y

[... some searching around and build testing ...]

hopper:/usr/src/git/linux-stable# cat include/generated/uapi/linux/version.h 
#define LINUX_VERSION_CODE 198404

Ah yep. So d183e6f570f3c0c23d253fd262c90244e72d7ffd moved linux/version.h
to generated/linux/version.h and 10b63956fce7f369cc37fd4d994f09bd5203efe4
moved it to generated/uapi/linux/version.h finally.

Now when I'm in branch linux-3.6.y and don't run a clean there, but
just check out linux-3.7.y and run "make-kpkg clean" afterwards, I'll
end up with a stale version.h in include/linux plus the correct one
in include/generated/uapi/linux which is bad. The nvidia build now is
apparently picking the wrong one and fails, which could be considered
a minor glitch in the build framework - but doing so feels a little
preposterous. There shouldn't be a stale version.h at a prominent
include path location in my kernel tree in the first place.

I've just did the following:

hopper:/usr/src/git/linux-stable# make-kpkg clean
[...]
hopper:/usr/src/git/linux-stable# git checkout linux-3.6.y
Checking out files: 100% (15776/15776), done.
Switched to branch 'linux-3.6.y'
hopper:/usr/src/git/linux-stable# make-kpkg clean
[...]
  CLEAN   include/config include/generated
  CLEAN   .config include/linux/version.h
[...]
hopper:/usr/src/git/linux-stable# git checkout linux-3.7.y
Checking out files: 100% (15776/15776), done.
Switched to branch 'linux-3.7.y'

which cleaned up the old version.h and I'm now rebuilding the kernel.
I'm confident the dkms build will succeed against the resulting (consistent)
kernel tree.

Thanks for pointing me in the right direction - and sorry for the
confusion. I just didn't expect the issue coming from that direction.

PS:

The kernel build is done meanwhile and as expected, the dkms build
now succeeds flawlessly:

hopper:/usr/src/git/linux-stable# dpkg --configure --pending
Setting up nvidia-kernel-dkms (304.64-4) ...
Removing old nvidia-304.64 DKMS files...

------------------------------
Deleting module version: 304.64
completely from the DKMS tree.
------------------------------
Done.
Loading new nvidia-304.64 DKMS files...
Building only for 3.7.4
Building initial module for 3.7.4
Done.

nvidia:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/3.7.4/updates/dkms/

depmod....

DKMS: install completed.

Again, sorry for wasting your time and thanks for the pointers,
Andre.
-- 
                    Cool .signatures are so 90s...

-> Andre Beck    +++ ABP-RIPE +++      IBH IT-Service GmbH, Dresden <-