Question

Je suis en train d'utiliser un peu vieux DAQ, et a dû sauter à travers quelques cerceaux pour obtenir un vieux (vers 2004) pilote de périphérique pour le compiler ( DTI-DT340 Linux-DAQ-PCI ).

Je suis arrivé au point où il compile, je peux charger le module du noyau, il trouve la carte, et je peux créer les périphériques de caractères en utilisant mknod.

Mais je ne peux pas sembler ouvrir ces appareils et continuer à obtenir errno 19 (ENODEV) 'No such device' lorsque je tente de

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

mais mknod avait rien à redire sur ce qui en fait, et il est là:

# 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

Y at-il quelque chose que je néglige de le faire? Ce qui pourrait être une raison ouverte échoue?

Voici le script que j'utiliser pour charger le pilote et faire les périphériques.

#!/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]

Quelques informations complémentaires:

#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

REPONSE: A printk a confirmé que le -ENODEV a été éjecté de l'intérieur ouvert (). Après une oldstyle

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

(qui est obsolète), if(!pdev) finit vrai, et retourne le -ENODEV.

Je progresse lentement - je suppose que je dois travailler à travers et mettre à jour le code pci utiliser des mécanismes plus modernes ...

Était-ce utile?

La solution

Si l'appareil apparaît dans / proc / devices, et vous êtes sûr que vous avez le bon nombre de mknod, le conducteur lui-même refuse l'ouverture. Le conducteur peut retourner un code d'erreur open () -. Y compris « pas un tel dispositif », qu'il pourrait si elle a découvert un problème matériel initialisant

Autres conseils

Je suppose que c'est un problème dans le pilote, vérifiez la fonction ouverte.

Il apparaît dans / proc / devices, donc tous les trucs de périphérique générique semble être ok.

mknod ne se soucie pas s'il y a un dispositif correspondant aux numéros majeurs / mineurs donnés. Etes-vous sûr insmod est l'installation de votre module? Qu'est-ce lsmod vous dire?

Je ne suis pas familier avec avoir à ajouter l'extension « .ko ». Est-ce quelque chose de spécifique à votre pilote de périphérique?

Vérifier par lspci et assurez le matériel est correctement initialisé. Si votre système prend en charge hotplug, pci_find_device ne fonctionnera pas. Le problème est un refcnt. La meilleure façon de traiter et d'apprendre est de disséquer l'API. BOL !!

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top