librealsense: DKMS build failing on 4.15.0-62, -64

Was fine on 4.15.0-58, now is broken. See the build output below.

DKMS make.log for librealsense2-dkms-1.3.5 for kernel 4.15.0-62-generic (x86_64)
Mon Sep 16 18:37:27 UTC 2019
make: Entering directory '/usr/src/linux-headers-4.15.0-62-generic'
CC [M]  /var/lib/dkms/librealsense2-dkms/1.3.5/build/4.15.0/drivers/media/usb/uvc/uvc_driver.o
In file included from ./arch/x86/include/asm/atomic.h:5:0,
from ./include/linux/atomic.h:5,
from /var/lib/dkms/librealsense2-dkms/1.3.5/build/4.15.0/drivers/media/usb/uvc/uvc_driver.c:14:
./arch/x86/include/asm/qspinlock.h: In function ‘native_queued_spin_unlock’:
./arch/x86/include/asm/qspinlock.h:42:25: error: ‘struct qspinlock’ has no member named ‘locked’
smp_store_release(&lock->locked, 0);
^
./include/linux/compiler.h:304:9: note: in definition of macro ‘__compiletime_assert’
if (!(condition))     \
^
./include/linux/compiler.h:324:2: note: in expansion of macro ‘_compiletime_assert’
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
./include/linux/compiler.h:327:2: note: in expansion of macro ‘compiletime_assert’
compiletime_assert(__native_word(t),    \
^
./include/linux/compiler.h:327:21: note: in expansion of macro ‘__native_word’
compiletime_assert(__native_word(t),    \
^
./arch/x86/include/asm/barrier.h:97:2: note: in expansion of macro ‘compiletime_assert_atomic_type’
compiletime_assert_atomic_type(*p);    \
^
/var/lib/dkms/librealsense2-dkms/1.3.5/build/4.15.0/drivers/media/usb/uvc/../../../../include-overrides/asm-generic/barrier.h:157:33: note: in expansion of macro ‘__smp_store_release’
#define smp_store_release(p, v) __smp_store_release(p, v)
^
./arch/x86/include/asm/qspinlock.h:42:2: note: in expansion of macro ‘smp_store_release’
smp_store_release(&lock->locked, 0);
^

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 21 (5 by maintainers)

Most upvoted comments

@RealSenseCustomerSupport - one week since last follow-up - any update?


We are currently working on a solution for this issue and update will be posted as soon as a solution has been implemented.

Thank you!

Is the new release expected to work with both (the older, previously working) -58 and (newer, previously broken) -64?

Just learned the hard way: the update fixed the build in newer kernel but broke the old kernel. That actually bites me hard, because I have two systems. One is based on generic ITX board and the other is based on UpBoard. The former tends to be ahead in the kernel than the latter. Of course, my UpBoard build is now broken with the update, because it’s a 4.15.0-37 kernel. My ITX-board build works because it’s 4.15.0-70 kernel.

Really, pretty please, can we get this fixed for real, not by fixing one, while breaking the other. The crux of the problem is that Intel maintains the kernel modules out-of-tree instead of properly working with the kernel development community to push this upstream. They do this well for other products (graphics chipset, for example), but Realsense is a mess.

@RealSense-Customer-Engineering / @RealSenseCustomerSupport - we’re at the 1-month mark since your last comment. Any update?

broken on 4.15.0-66 for me, same errors building

@RealSenseCustomerSupport Status of this? I’m still seeing 1.3.5-0ubuntu1 as the most recent version of librealsense2-dkms.

I’m aware that I can manually run the patch scripts, but for actual deployment purposes we need to be able to use the dkms deb. I know I could just rebuild it myself from scratch, but it would be convenient if the sources were provided.