Jean-Yves F. Barbier a écrit :
>
> en fait, vu ce que tu dis après, ça parait logique: le raidcheck prenant
> bcp de ressources, la FIFO de la TV perd surement ses billes à cause
> de lui
>
> une solution serait de modifier le cron (?) qui lance le raidcheck pour
> qu'il arrête la TV, fasse sa vérif, puis relance la TV.
>
J'y ai pensé aussi, le seul truc qui me gène un peu c'est de prendre le
risque que ça plante en cas de forte charge, car si ça c'est produit
avec le raidcheck, ça peut bien se produire avec autre chose... de plus
ou moins prévisible.
>> En fait la machine venait d'entamer la vérification hebdomadaire des
>> raid1 qui est très coûteuse en ressources donc c'est probablement ça qui
>> a provoqué la surcharge... maintenant ce qui me gène c'est que seule la
>> tv ait continué à fonctionner alors que j'aurais préféré le contraire.
>> En fait je m'en fiche pas mal que l'image saccade un peut ou même que
>> mplayer ou le framebuffer plante complètement. Cette application n'a
>> rien de critique. Par contre tout le reste du réseau repose entièrement
>> sur ce serveur...
>
> c'est vrai que la TV sur un svr... ;o{)
>
Ben comme ça la carte vidéo et le moniteur ont une utilité...
>> J'essaierais de reproduire le problème en lançant mplayer puis
>> checkarray demain soir. Si c'est bien ça qui la met en carafe je verrais
>> ce que ça donne en augmentant la latence du bus pci dans le bios.
>> Pour la carte en particulier ça va pas être possible :
>> *-multimedia:0
>> description: Multimedia video controller
>> product: Bt878 Video Capture
>> vendor: Brooktree Corporation
>> physical id: a
>> bus info: pci@00:0a.0
>> version: 11
>> width: 32 bits
>> clock: 33MHz
>> capabilities: bus_master cap_list
>> configuration: driver=bttv latency=32 maxlatency=40
>> mingnt=16
>> resources: iomemory:dfdfe000-dfdfefff irq:201
>
> peux-tu me dire avec quel utilitaire tu as cette sortie que je regarde
> ce que la mienne dit (lspci -vv ne me donne pas le maxlatency)?
>
lshw
>> Y a-t-il une option de boot genre "debug" qui permette d'avoir plus de
>> détails dans les logs en cas de plantage ?
>
> pas que je sache; par contre c'est une option que tu trouves souvent dans
> le source du kernel accolée aux devices concernés.
>
bof... j'ai la flème, si je recompile le noyau soit j'en ai pour des
plombes à désactiver tout ce qui ne me sert pas, soit j'en ai pour des
plombes à attendre qu'il compile tout...
> tu peux essayer aussi de désactiver un port série, et d'assigner son IRQ
> à ta carte, elle se trouveras de fait dans une priorité très inférieure
> aux IDE/ETH.... à cause de la cascade qui fait sauter de l'IRQ 2 à la 9.
> Mais ça peut poser des PBs de réception TV :(
C'est pas bête du tout ! Je vais essayer ça si le bios le permet.
Le truc qui me chagrine c'est que les magic sysrq keys ne fonctionnaient
plus alors que le clavier a l'IRQ 1 normalement...
Je devrai peut-être ajouter noapic dans mes options de boot aussi ?
altair:~# ls -dR /proc/irq/*/* | grep -v smp
/proc/irq/14/ide0
/proc/irq/15/ide1
/proc/irq/169/eth0
/proc/irq/177/libata
/proc/irq/185/ehci_hcd:usb5
/proc/irq/185/uhci_hcd:usb1
/proc/irq/185/uhci_hcd:usb2
/proc/irq/185/uhci_hcd:usb3
/proc/irq/185/uhci_hcd:usb4
/proc/irq/1/i8042
/proc/irq/201/bttv0
/proc/irq/209/VIA8237
/proc/irq/6/floppy
/proc/irq/7/parport0
/proc/irq/8/rtc
/proc/irq/9/acpi
@+
Attachment:
signature.asc
Description: OpenPGP digital signature