2 - Les distributions et les noyaux

Salut !


Oui.

rtirq se compose en fait simplement d'un "script init" (rtirq.sh). Ce script lit la configuration présente dans le fichier /etc/sysconfig/rtirq. Si tu places le fichier de configuration ailleurs, il faut modifier le script en conséquence ... le plus simple est donc de créer le répertoire adéquat 😉

T.

Merci.
ALors j'ai bien créé ce repertoire et mis le fichier rtirq.conf à l'interieur;
Par contre lorsque je lance le script :

mysthr@ubuntu:~$ sudo /etc/init.d/rtirq
/etc/init.d/rtirq: 58: Syntax error: "(" unexpected
mysthr@ubuntu:~$

Je suis allé fouiller dans le script mais je n'ai pas trouver l'erreur 🙁

Bon en fait c'est tout con : premiere ligne du script :
il faut remplacer #!/bin/sh par #!/bin/bash
et voila le script se lance. mais de nouveau un problème :

mysthr@ubuntu:~$ /etc/init.d/rtirq start
/etc/init.d/rtirq: line 49: .: /etc/sysconfig/rtirq: is a directory
mysthr@ubuntu:~$

qu'est ce que ça veut dire ? 😕

Bon j'ai tout recommencé proproment pour la Xieme fois.

Et là, plus de message d'erreur, et meme plus de message tout court. Je ne sais pas si le script à marcher.
Quand je fais un cat /proc/interrupts j'ai l'impression que la config est resté la même.

J'ai cru voir quelque part qu'il fallait démarrer en acpi = no un truc comme ça.
Est ce que quelqu'un pourrait me le confirmer et m'expliquer un peu comment faire ? 😡

Merci 😊

UP ! s'il vous plait aidez moi je suis en galère ! 🙁 je peux plus faire de MAO 😬

C'est normal, le script ne modifie pas l'attribution des IRQ (affichée par la commande "cat /proc/interrupts"), mais leur "priorité" pour le noyau "RT" (et donc la latence du périphérique associé).
Les logs ne sont présents qu'au lancement du script, donc au démarrage de la machine (activer le mode "verbose" au boot, touche F2 en général). Ils ressemblent à ceux mentionnés ici : http://alsa.opensrc.org/Rtirq


Non, ça c'est pour désactiver l'acpi et donc libérer l'IRQ 9 (intéressante en terme de priorité).


La présence (ou l'absence) de rtirq ne t'empêcheront pas de faire de la MAO !

Je ne comprend pas trop ce que tu veux faire ...
Faut dissocier l'attribution d'une IRQ à un périphérique donné (par ex carte son = IRQ 9) et la priorité de traitement que le noyau octroie à une IRQ (par ex IRQ 9 = priorité 90).
rtirq, c'est juste pour "fignoler" et améliorer encore la priorité de traitement des infos qui passent la carte son. Si tu as un problème de conflit d'IRQ, rtirq ne te sera d'aucune utilité, et risque même au contraire d'en amplifier les désagréments (prioriser des périph en conflit...) ! Pour modifier l'attribution des IRQ, voir le premier paragraphe de la page Autres optimisations, les BIOS des cartes mères récentes permettent en général de faire les modifications nécessaires.

T.

En fait le problème que j'ai c'est que j'ai une carte son firewire. les drivers Freebob fonctionnent bien, les entrées sorties sont implémentées dans qjackctl. Mais dès que je lance un logiciel genre Lmms, le serveur jack s'arrete en m'affichant ce message :

➡️
...
14:25:15.343 MIDI connection graph change.
14:25:15.359 MIDI connection graph change.
zombified - calling shutdown handler
14:25:27.432 MIDI connection graph change.
14:25:27.433 Shutdown notification.
14:25:27.434 Client deactivated.
14:25:27.435 JACK was stopped successfully.
14:25:27.436 Post-shutdown script...
14:25:27.436 killall jackd
cannot send request type 7 to server
cannot read result for request type 7 from server (Broken pipe)
cannot send request type 7 to server
cannot read result for request type 7 from server (Broken pipe)
jackd: no process killed
14:25:27.656 Post-shutdown script terminated with exit status=256.
➡️

J'ai l'impression que le problème vient du port firewire , et je pensais qu'en modifiant la priorité IRQ du port ( comme indiqué sur le site freebob), je pourrais régler mon problème.
Maintenant je ne sais pas. Peut etre que c'est autre chose. Mais c'est la seule piste que j'ai.
C'est peut etre due aussi à une mauvaise config de jackd.

En tout cas merci pour ta réponse. Par contre j'ai pas bien compris pour le mode verbose. J'ai appuyé sur F2 mais après ? 😛

Difficile de savoir en effet ... en tous cas , y'a un fil avec une histoire semblable ici : http://lalists.stanford.edu/lau/2007/02/0606.html


C'est juste que certaines distrib' permettent d'accéder au démarrage en mode verbose avec F2, du coup, tu vois tous les logs du boot, dont ceux des scripts init (ce qui nous intéresse ici).
Mais tu peux vérifier le statut de rtirq par la commande :

Commence par vérifier avec la commande /cat/proc/interrupts que tu n'as pas de conflits d'irq, en particulier au niveau du firewire (ohci, ou un truc du genre).

Ensuite, il faudrait jouer avec les réglages de rtirq et jack pour avoir quelque chose qui ressemble à ça : http://www.linuxmao.org/tikiwiki/tiki-index.php?page=Autres+optimisations#_Gestion_des_priorit_s
(en gros, la carte son firewire avec une priorité supérieure d'une dizaine d'unités à celle de jack)
Le cas échéant, tu peux toujours donner les résultats des 2 commandes ici (rtirq status et proc interrupts), en les plaçant entre des balises ~pp~ et ~/pp~ pour éviter que la mise en forme automatique du site ne modifie les logs !

T.

alors voici mon résultat pour un cat /proc/interrupts :

mysthr@ubuntu:~$ cat /proc/interrupts
           CPU0       CPU1
  0:    1902733          0   IO-APIC-edge      timer
  1:       1581          0   IO-APIC-edge      i8042
  8:         49          0   IO-APIC-edge      rtc
  9:          1          0   IO-APIC-fasteoi   acpi
 12:      47716          0   IO-APIC-edge      i8042
 14:      43732          0   IO-APIC-edge      libata
 15:       4822          0   IO-APIC-edge      libata
 16:     114240          0   IO-APIC-fasteoi   nvidia
 17:      41760          0   IO-APIC-fasteoi   eth0, ipw3945
 18:          3          0   IO-APIC-fasteoi   ohci1394
 19:         44          0   IO-APIC-fasteoi   uhci_hcd:usb1, ehci_hcd:usb5
 20:      12539          0   IO-APIC-fasteoi   uhci_hcd:usb2, HDA Intel
 21:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
 22:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
 23:          0          0   IO-APIC-fasteoi   sdhci:slot0
NMI:          0          0
LOC:    1902301    1902279
ERR:          0
MIS:          0
mysthr@ubuntu:~$

Apparement il n'y a pas de conflit.

Ensuite voici le status rtirq et j'avoue que je le trouve bizare :

mysthr@ubuntu:~$ /etc/init.d/rtirq status

  PID CLS RTPRIO  NI PRI %CPU STAT COMMAND
    3 TS       -  19   4  0.0 SN   ksoftirqd/0
    6 TS       -  19   5  0.0 SN   ksoftirqd/1

mysthr@ubuntu:~$  

Sinon j'ai vu ça sur le fil que tu m'as donnné :
"This is a common problem with laptops and i have been struggling with
this myself, and AFAIK the only thing you can hope is that your system
has an IO-APIC, and that it is routed in a favorable fashion (hardware
that is). Try and enable the IO-APIC in the kernel and see if it comes
up (some lines having the word IO-APIC should appear in /proc/interrupts.) "

Je ne sais pas trop ce qu'est le IO-APIC (gestion d'énergie ou un truc du genre) mais apparement j'ai ce qu'il faut quand on voit mon /proc/interrupts.
En tout cas merci pour tes conseil.

Mysth-R

( faut choisir entre balises "np" et "pp" 😉 )
Pas pour ohci1394 en tous cas 😀


C'est en effet un peu court ! Y'a quoi dans ton "/etc/sysconfig/rtirq" ? N'indique que les lignes non commentées (= ne commençant pas par un "dièse").

Edit : et à l'occase, viens faire un tour sur freenode, ça sera plus pratique ! aideirc

T.

Est-ce que ça marche correctement avec un autre driver que Freebob? Avec Alsa ? Avec Dummy?

Peut être il y a un conflit entre des versions de librairies quelque part?

En fait vu que c'est une carte son Firewire je suis obligé (a ma connaissance) d'utiliser les drivers Freebob, car jusqu'a présent ils ne sont pas intégrés aux drivers Alsa.

salut !

en fait j'ai recopier le script que j'ai trouvé sur le site de freebob

ps : en ce moment j'ai pas trop le temps de m'en occuper donc je suis pas trop pressé, mais bon quand même 😐 à l'occasion je passerais sur freenode alors 😉

bonjour.
En fait c'est très simple comme problème. C'est grâce au patch Ingo Molnar que l'on peut entre autre modifier la priorité des IRQ.
Apparement le Noyau précompilé, "lowlatency" de Ubuntu Feisty fawn ne serait pas patché. Donc impossible de modifier quoi que ce soit !

la petite commande utile que je ne connaissais pas :

uname -a

qui affiche plus de détail que la commande uname -r Si vous voyez preempt RT c'est a priori que votre noyau est patché.
dernier petit truc pour vérifier que votre noyau est patché : la présence du fichier loadavg dans le dossier

/proc

d'après ce que j'ai compris c'est le patch de Ingo Molnar qui rajoute ce petit fichier et qui permet de mieux gérer l'allocation mémoire ! (corrigez moi si je me trompe)

Bonne journée

Mysth-R