Member Avatar for chris5126

Hi, I have a machine with X-Fi Titanium sound card. Im getting the following errors when trying to compile the driver.

make
make -C /lib/modules/2.6.9-89.0.23.ELsmp/build 
M=/root/XFiDrv_Linux_Public_US_1.00
make[1]: Entering directory `/usr/src/kernels/2.6.9-89.0.23.EL-smp-
x86_64'
CC [M] /root/XFiDrv_Linux_Public_US_1.00/xfi.o
In file included from /root/XFiDrv_Linux_Public_US_1.00/xfi.c:17:
/root/XFiDrv_Linux_Public_US_1.00/ctatc.h:22:34: linux/spinlock_types.h: 
No such file or directory
make[2]: *** [/root/XFiDrv_Linux_Public_US_1.00/xfi.o] Error 1
make[1]: *** [_module_/root/XFiDrv_Linux_Public_US_1.00] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.9-89.0.23.EL-smp-
x86_64'
make: *** [all] Error 2

Other Info:

uname -a
Linux swlin114 2.6.9-89.0.23.ELsmp #1 SMP Fri Mar 5 23:27:13 EST 2010 
x86_64 x86_64 x86_64 GNU/Linux

It shows up in lspci:

01:00.0 Audio device: Creative Labs X-Fi Titanium series [EMU20k2] (rev 
03)

I also got the vendors device ID if its any help:

lspci -n | grep '01:00.0'
01:00.0 Class 0403: 1102:000b (rev 03)

Does anyone have any ideas?

  • 2 Contributors
  • 4 Replies
  • 504 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by chris5126

Dani AI

Generated

This is a kernel/module build problem, not a C-language issue — as suggested. The driver source is pulling in an internal kernel header that your build tree (the headers/sources your kernel build points at) doesn’t expose. With a 2.6.9‑based kernel (your reported kernel), the fastest, least-invasive fixes are: (1) use the public spinlock API header the kernel exposes, and (2) make sure the kernel‑devel / kernel‑headers package installed exactly matches the running kernel.

A practical change that fixes this in most out‑of‑tree modules is to stop including the internal types header and include the public API instead. Example patch (apply to the driver header that includes the missing file):

/* prefer the stable public API */
#include <linux/spinlock.h>

If you need to support a range of old kernels, guard the include with linux/version.h checks and fall back only where strictly necessary.

Checklist to troubleshoot and fix:

  • Confirm /lib/modules/$(uname -r)/build actually points at a complete kernel source/header tree.
  • Search that tree for the header:
    find /lib/modules/$(uname -r)/build -name spinlock_types.h
    If it’s missing, install the matching headers: on RHEL/CentOS yum install kernel-devel-$(uname -r) (or install the matching kernel‑devel package via your package manager); on Debian/Ubuntu apt-get install linux-headers-$(uname -r).
  • Re-run the module build after the correct headers are in place.
  • If replacing the include still fails, the driver was probably written for a different kernel API version. Check the driver README or look for an updated driver branch that targets your kernel, or consider backport patches (or upgrading the kernel).

If these steps don’t resolve it, provide the small driver snippet (the include lines) and the output of the find check above; that information makes it straightforward to recommend the minimal patch or packaging fix.

Recommended Answers

All 4 Replies

Member Avatar for N1GHTS

Wrong forum, you need to post this in the linux forum, not in a C language forum.

Member Avatar for chris5126

hmmm ok but the driver is written in C and its obviously a compile problem. How do I get it moved?

Member Avatar for N1GHTS

Did you write the driver? If so, welcome to the right forum!

commented: your replies just arent helpful -1
Member Avatar for chris5126

Where in the forum description do you see that then?

C Forum

Our C forum is the place for Q&A-style discussions related to the C language as per the ANSI C standard. Otherwise use our C++ forum.
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.