views:

789

answers:

3

I'm trying to use a somewhat old DAQ, and had to jump through a few hoops to get an old (circa 2004) device driver for it to compile (DTI-DT340 Linux-DAQ-PCI).

I've gotten to the point where it compiles, I can load the the kernel module, it finds the card, and I can create the character devices using mknod.

But I can't seem to open these devices and keep getting errno 19 (ENODEV) 'No such device' when I try to

open("/dev/dt340/0",O_RDWR);

but mknod had no complaints about making it, and it's there:

# ls -l /dev/dt340/
total 0
crw-rw-r-- 1 root staff 250, 0 2009-04-23 11:02 0
crw-rw-r-- 1 root staff 250, 1 2009-04-23 11:02 1
crw-rw-r-- 1 root staff 250, 2 2009-04-23 11:02 2
crw-rw-r-- 1 root staff 250, 3 2009-04-23 11:02 3

Is there something I'm neglecting to do? What might be a reason open fails?

Here's the script I use to load the driver and make the devices.

#!/bin/bash
module="dt340"
device="dt340"
mode="664"

# invoke modprobe with all arguments we were passed
#/sbin/modprobe -t misc -lroot -f -s $module.o $* || exit 1
insmod $module.ko

# remove stale nodes
rm -f /dev/${device}/[0-3]

major=`awk "\\$2==\"$module\" {print \\$1}" /proc/devices`
mkdir -p /dev/${device}
mknod /dev/${device}/0 c $major 0
mknod /dev/${device}/1 c $major 1
mknod /dev/${device}/2 c $major 2
mknod /dev/${device}/3 c $major 3

# give appropriate group/permissions, and change the group
# not all distributions have staff; some have "users" instead
group="staff"
grep '^staff:' /etc/group > /dev/null || group="users"

chgrp $group /dev/${device}/[0-3]
chmod $mode  /dev/${device}/[0-3]

Some additional info:

#grep dt340 /proc/devices 
250 dt340
# lsmod | grep dt340
dt340                  21516  0 
# tail /var/log/messages
Apr 23 11:59:26 ve kernel: [  412.862139] dt340 0000:03:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Apr 23 11:59:26 ve kernel: [  412.862362] dt340: In function dt340_init_one:
Apr 23 11:59:26 ve kernel: [  412.862363] Device DT340 Rev 0x0 detected at address 0xfebf0000
#lspci | grep 340
03:01.0 Multimedia controller: Data Translation DT340

ANSWER: A printk confirmed that the -ENODEV was thrown from inside open(). Following an oldstyle

while ((pdev = pci_find_device(PCI_VENDOR_ID_DTI, PCI_ANY_ID, pdev)))

(which is deprecated), if(!pdev) ends up true, and returns the -ENODEV.

I'm inching closer - I guess I have to work through and update the pci code to use more modern mechanisms...

A: 

mknod doesn't care if there is an device corresponding to the given major/minor numbers. Are you sure insmod is installing your module? What does lsmod tell you?

I'm unfamiliar with having to add the ".ko" extension. Is that something specific to your device driver?

Paul Tomblin
Added the lsmod info above - I think that I wouldn't have gotten that major number from /proc/devices if it did not load.I'm using the .ko extension because i'm loading the module in place where I built it - it's not in one of the standard places where modules are loaded from.
Paul Ivanov
.ko is the extension generally used by Linux drivers since 2.4 - older kernels used .o but this caused confusion with other object files which weren't kernel objects.
MarkR
Well, I last wrote a kernel module in 1993, so what do I know?
Paul Tomblin
@MarkR - 2.4 still uses .o modules; the .ko extension was introduced with 2.5.51 (Dec 10, 2002)
ephemient
+1  A: 

I'd guess it is a problem in the driver, check the open function.

It shows up in /proc/devices, so all the generic device stuff seems to be ok.

starblue
+3  A: 

If the device shows up in /proc/devices, and you're sure you've got the number right in mknod, then the driver itself is refusing the open. The driver can return any error code from open() - including "no such device", which it might if it discovered a problem initialising the hardware.

MarkR