voir le blog de sl33p3r :
sl33p3r.free.fr/blog/
Bon va falloir traiter ces erreurs dans le Makefile (de plus en plus de distribs commencent à l'adopter... Suse 9.0, Fedora, ...) --
BenoitAudouard
/usr/include/linux/version.h:3:2: #error "You should not include /usr/include/{linux,asm}/ header"
/usr/include/linux/version.h:4:2: #error "files directly for the compilation of kernel modules."
/usr/include/linux/version.h:5:2: #error ""
/usr/include/linux/version.h:6:2: #error "glibc now uses kernel header files from a well-defined"
/usr/include/linux/version.h:7:2: #error "working kernel version (as recommended by Linus Torvalds)"
/usr/include/linux/version.h:8:2: #error "These files are glibc internal and may not match the"
/usr/include/linux/version.h:9:2: #error "currently running kernel. They should only be"
/usr/include/linux/version.h:10:2: #error "included via other system header files - user space"
/usr/include/linux/version.h:11:2: #error "programs should not directly include <linux/*.h> or"
/usr/include/linux/version.h:12:2: #error "<asm/*.h> as well."
/usr/include/linux/version.h:13:2: #error ""
/usr/include/linux/version.h:14:2: #error "To build kernel modules please do the following:"
/usr/include/linux/version.h:15:2: #error ""
/usr/include/linux/version.h:16:2: #error " o Have the kernel sources installed"
/usr/include/linux/version.h:17:2: #error ""
/usr/include/linux/version.h:18:2: #error " o Make sure that the symbolic link"
/usr/include/linux/version.h:19:2: #error " /lib/modules/`uname -r`/build exists and points to"
/usr/include/linux/version.h:20:2: #error " the matching kernel source directory"
/usr/include/linux/version.h:21:2: #error ""
/usr/include/linux/version.h:22:2: #error " o Configure kernel sources:"
/usr/include/linux/version.h:23:2: #error " - cd /usr/src/linux"
/usr/include/linux/version.h:24:2: #error " - make mrproper"
/usr/include/linux/version.h:25:2: #error " - make cloneconfig"
/usr/include/linux/version.h:26:2: #error " - make dep"
/usr/include/linux/version.h:27:2: #error ""
/usr/include/linux/version.h:28:2: #error " o When compiling, make sure to use the following"
/usr/include/linux/version.h:29:2: #error " compiler option to use the correct include files:"
/usr/include/linux/version.h:30:2: #error ""
/usr/include/linux/version.h:31:2: #error " -I/lib/modules/`uname -r`/build/include"
/usr/include/linux/version.h:32:2: #error ""
/usr/include/linux/version.h:33:2: #error " instead of"
/usr/include/linux/version.h:34:2: #error ""
/usr/include/linux/version.h:35:2: #error " -I/usr/include/linux"
/usr/include/linux/version.h:36:2: #error ""
/usr/include/linux/version.h:37:2: #error " Please adjust the Makefile accordingly."
J'ai enleve les warnings possibles, et compris la source des problemes que nous avions: en 2.6 les urbs doivent etre explicitement initialise (usb_init_urb) si on les alloue de facon statique. J'ai donc prefere
procede a une allocation dynamique de tous les URBs.
Les warning provenaient de cas ou le kernel n'etait pas content que l'on dorme avec un lock .. Dans certains cas c'etait pertinent, dans d'autres je me pose plus de questions ...
Pour resoudre ces problemes j'ai fait une premiere passe "simpliste" sur les locks : la plupart ne servaient a rien. Ils ont ete remplaces par des flags, settes de facon atomique. Il va falloir que je refasse une
passe de cleaning sur ces locks ainsi que sur certains cas potentiels de race condition lors du dechargement ...
Une fois cette stabilisation effectuee (et testee), il va falloir jeter aussi un coup d'oeil au makefile pour 2.6 (il me semble ne pas prendre en compte les dependances .. ca doit pas etre grand-chose), puis a
regarder eaglctrl, afin de lui ajouter de nouvelles options permettant de donner directement les codes VPI/VCI, l'encapsulation,.. et eventuellement le code DSP souhaite .. Ca devrait pouvoir aider ceux qui utilisent le driver sur des supports graves ou a destinations de clients particuliers. --
FrederickRos 20031109
> Par contre le compteur d'utilisation du module reste a 0 (je sais pas si c'est normal...)
Ben en 2.6, les drivers ne gerent plus *explicitement* ce compteur .. ce qui n'est pas un mal .. Le kernel s'en charge.. Maintenant il faut voir si j'ai rien oublie ! --
FrederickRos 20031109
Quoting Christian Casteyde <casteyde.christian@free.fr>:
> > > Nov 6 16:29:20 mat-pc kernel:
> > > Nov 6 16:30:16 mat-pc kernel: Debug: sleeping function called from
> > > invalid context at include/asm/uaccess.h:498
>
> Ce ne serait pas le code de détection de bug intégré dans
> le noyau 2.6 qui crierait famine ici ? À mon avis, ce n'est pas seulement
> un warning dans ce cas, c'est un véritable bug. Reste à décortiquer
> pour savoir quelle fonction a mis quelle ISR en sommeil...
Si c'est might_sleep qui gueule .. Le probleme c'est que IMHO, ce n'est pas veritablement un bug, et que en plus je me demande si justement cette fonction (dans le cas de kernel preemptif) n'a pas un pb... En effet, au final, le test effectue pour savoir si on est en section atomique, revient a faire :
Si (nb_preemptif >= kernel_locked() )
Le pb, c'est que sur certaines architectures, kernel_locked renvoie le nb de fois ou le kernel est locke (le big-lock) .. mais sur x86, cette fonction renvoie 0 ou 1 (booleen), car elle revient (de memoire) a qq chose du genre :
kernel_lock_count > 0
Apparamment y'a eu un fix fait par Linus et integre comm epatch dans le test9-mm, mais j'ai pas eu le temps de voir si ca concernait ce pb la exactement...
Au final, le pb pour nous, c'est que le copy_from_user, dans le ioctl qui envoie le code DSP et les options, et fait dans une section critique (entre 2
spin_lock) .. Il suffirait de le deplacer avant la prise du lock ... --
FrederickRos 20031107
vu dans le changelog de kernel 2.6test8
[driver model] Add device_unregister_wait().
For those times when you need to wait for a device to unregister, before you
continue on, this is device_unregister_wait(). It will block until all the
references to the device go away, including references held by open sysfs
files.
This is probably most useful for modules that add and remove devices when
they are loaded and unloaded. They must be sure that the devices that they
have declared or allocated are completely torn down before the module is
removed, lest unfreed memory get referenced or called.
[PATCH] futex bug fixes
This fixes two serious bugs in the futex code.
One is a race condition which results in list corruption when
FUTEX_REQUEUE is used. It is due to the split locks change introduced
in 2.6.0-test6, and oopses when triggered.
The other is a security hole. A program can use FUTEX_FD to create
futexes on mms or inodes which don't reference them, and when those
structures are reused by a different mm or inode, the addresses match.
The effect is that a malicious or flawed program can steal wakeups from
completely unrelated tasks, causing them to block (or worse if they are
counting on the token passing property).
These are the specific changes:
1. Each futex_q retains a reference to its key mm or inode.
2. The condition for a futex_q to indicate that it's woken can usually
be interrogated lock-free.
3. futex_wait calls the hash function once instead of three times,
and usually takes the per-bucket lock once too.
4. When a futex is woken, the per-bucket lock is not usually taken,
so that's one less cache line transfer during heavy SMP futex use.
5. The wait condition and barriers in futex_wait are simpler.
5. FUTEX_REQUEUE is fixed. The per-bucket lock juggling is done
in such a way that there are no race conditions against the tests
for whether a futex is woken.
This patch is an combination of patches previously sent to the list. An
equivalent patch has been in Andrew Morton's tree for a while, with no
failure reports. Also I have been running it on my own SMP box for a
while. Conversely, we have received an oops report for the 2.6.0-test6
code, so the fix is needed.
[PATCH] USB: minor net2280 cleanup
This holds minor net2280 cleanups:
Cleaner handling for cases where dma_alloc_coherent() must beused instead of kmalloc(). (Kmalloc is more memory-efficient
for the "small buffers" case.) Both MIPS cases should work,
as well as others.
Prefetch cachelines on PIO paths.
The first of those gets rid of one <linux/version.h> usage, no
longer useful now that 2.4 and 2.6 versions have forked.
