Après 10 ans d'utilisation de linux me voilà face à mon premier plantage
du noyau !
J'ai installé un serveur debian qui fonctionne bien depuis quelques
années pour une asso. Je l'administre via ssh et jusqu'à il y a peu il
n'avais ni écran ni clavier... L'association à acquis un combiné
magnétoscope vhs / graveur dvd et ayant un moniteur et une pctv en rabe
j'ai décidé de les monter sur le serveur pour pouvoir "monitorer" l'engin.
J'ai monté la carte pctv, mis # defoptions=vga=786 dans mon menu.lst,
j'en ai profité pour mettre à jour en 2.6.18-6, installé mplayer et rebooté.
Je me suis logué en tant que simple utilisateur (faisant partie du
groupe video) et j'ai lancé la commande :
Nickel, le serveur fait maintenant office de télévision.
Ce matin je reçois un appel me disant que le réseau ne fonctionne pas,
je tente de me connecter via ssh : "No route to host", je ping la
connexion : pas de soucis, je vais voir mes mails logcheck : pas de
nouvelles depuis 30 heures ! Donc je vais voir sur place ce qu'il en est :
L'écran du serveur affiche bien l'image du magnétoscope !
Le serveur ne répond plus au ping.
Le clavier ne répond plus.
Les magic SysRq keys ne fonctionnement pas.
Le bouton "power" ne répond pas nonplus (normalement ça reboot par acpi)
J'ai donc coupé l'alimentation :,((( pour rebooter (le bouton reset
n'étant pas branché) et c'est évidemment reparti "comme en 40".
Malgré tout je me dis que ça ne devait pas être totalement planté vu que
l'image n'était pas figée et que les voyants du clavier ne clignotaient
pas (il me semble qu'ils clignotent en cas de kernel panic).
altair:~# uname -a
Linux altair 2.6.18-6-686 #1 SMP Wed Jan 23 03:23:22 UTC 2008 i686 GNU/Linux
altair:~# apt-cache policy mplayer
mplayer:
Installé : 1.0~rc1-12etch1
Candidat : 1.0~rc1-12etch1
Table de version :
*** 1.0~rc1-12etch1 0
990 http://security.debian.org etch/updates/main Packages
990 http://ftp.fr.debian.org etch/main Packages
100 /var/lib/dpkg/status
altair:~# grep -C 10 bttv /var/log/syslog
Feb 3 01:02:02 altair postfix/qmgr[2831]: 8F9F31A3F: removed
Feb 3 01:06:01 altair /USR/SBIN/CRON[21989]: (root) CMD ([ -x
/usr/share/mdadm/checkarray ] && [ $(date +%d) -le 7 ] &&
/usr/share/mdadm/checkarray --cron --all --quiet)
Feb 3 01:06:01 altair kernel: md: syncing RAID array md0
Feb 3 01:06:01 altair kernel: md: minimum _guaranteed_ reconstruction
speed: 1000 KB/sec/disc.
Feb 3 01:06:01 altair kernel: md: using maximum available idle IO
bandwidth (but not more than 200000 KB/sec) for reconstruction.
Feb 3 01:06:01 altair kernel: md: using 128k window, over a total of
5453952 blocks.
Feb 3 01:06:01 altair kernel: md: delaying resync of md1 until md0 has
finished resync (they share one or more physical units)
Feb 3 01:06:01 altair kernel: md: delaying resync of md2 until md1 has
finished resync (they share one or more physical units)
Feb 3 01:06:01 altair kernel: md: delaying resync of md1 until md0 has
finished resync (they share one or more physical units)
Feb 3 01:06:01 altair mdadm: RebuildStarted event detected on md device
/dev/md0
Feb 3 01:06:03 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS FDSR OCERR*
Feb 3 01:06:03 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS FDSR OCERR*
Feb 3 01:06:03 altair kernel: bttv0: OCERR @ 1eccb008,bits: VSYNC*
HSYNC OFLOW FBUS FDSR OCERR*
Feb 3 01:06:03 altair kernel: bttv0: OCERR @ 1eccb008,bits: VSYNC*
HSYNC OFLOW FBUS FDSR OCERR*
Feb 3 01:06:04 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS OCERR*
Feb 3 01:06:04 altair kernel: bttv0: OCERR @ 1eccb014,bits: VSYNC*
HSYNC OFLOW FBUS FDSR OCERR*
Feb 3 01:06:06 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS FDSR OCERR*
Feb 3 01:06:06 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS FDSR OCERR*
Feb 3 01:06:07 altair kernel: bttv0: OCERR @ 1eccb008,bits: VSYNC*
HSYNC OFLOW FBUS FDSR OCERR*
Feb 3 01:06:07 altair kernel: bttv0: OCERR @ 1eccb008,bits: VSYNC*
HSYNC OFLOW FBUS FDSR OCERR*
Feb 3 01:06:07 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS FDSR OCERR*
Feb 3 01:06:07 altair kernel: bttv0: OCERR @ 1eccb008,bits: VSYNC*
HSYNC OFLOW FBUS OCERR*
Feb 3 01:06:07 altair kernel: bttv0: OCERR @ 1eccb014,bits: HSYNC OFLOW
FBUS FDSR OCERR*
Feb 3 01:06:07 altair kernel: bttv0: OCERR @ 1eccb014,bits: VSYNC*
HSYNC OFLOW FBUS FDSR OCERR*
Feb 3 01:06:07 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS FDSR OCERR*
Feb 3 01:06:08 altair kernel: bttv0: OCERR @ 1eccb00c,bits: OFLOW OCERR*
Feb 3 01:06:08 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS FDSR OCERR*
Feb 3 01:06:12 altair last message repeated 5 times
Feb 3 01:06:12 altair kernel: bttv0: OCERR @ 1eccb014,bits: VSYNC*
HSYNC OFLOW FBUS FDSR OCERR*
Feb 3 01:06:12 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS FDSR OCERR*
Feb 3 01:06:12 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS FDSR OCERR*
Feb 3 01:06:13 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS OCERR*
Feb 3 01:06:14 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS OCERR*
Feb 3 01:06:14 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS FDSR OCERR*
Feb 3 01:06:15 altair last message repeated 2 times
Feb 3 01:06:15 altair kernel: bttv0: OCERR @ 1eccb014,bits: HSYNC OFLOW
FBUS OCERR*
Feb 4 09:42:10 altair syslogd 1.4.1#18: restart.
Feb 4 09:42:10 altair kernel: klogd 1.4.1#18, log source = /proc/kmsg
started.
Feb 4 09:42:11 altair kernel: Linux version 2.6.18-6-686 (Debian
2.6.18.dfsg.1-17etch1) (dannf@debian.org) (gcc version 4.1.2 20061115
(prerelease) (Debian 4.1.1-21)) #1 SMP Wed Jan 23 03:23:22 UTC 2008
Feb 4 09:42:11 altair kernel: BIOS-provided physical RAM map:
Feb 4 09:42:11 altair kernel: BIOS-e820: 0000000000000000 -
000000000009fc00 (usable)
Feb 4 09:42:11 altair kernel: BIOS-e820: 000000000009fc00 -
00000000000a0000 (reserved)
Feb 4 09:42:11 altair kernel: BIOS-e820: 00000000000f0000 -
0000000000100000 (reserved)
Feb 4 09:42:11 altair kernel: BIOS-e820: 0000000000100000 -
000000001fff0000 (usable)
Feb 4 09:42:11 altair kernel: BIOS-e820: 000000001fff0000 -
000000001fff8000 (ACPI data)
Feb 4 09:42:11 altair kernel: BIOS-e820: 000000001fff8000 -
0000000020000000 (ACPI NVS)
--
Feb 4 09:42:12 altair kernel: ReiserFS: md0: using ordered data mode
Feb 4 09:42:12 altair kernel: ReiserFS: md0: journal params: device
md0, size 8192, journal first block 18, max trans len 1024, max batch
900, max commit age 30, max trans age 30
Feb 4 09:42:12 altair kernel: ReiserFS: md0: checking transaction log (md0)
Feb 4 09:42:12 altair kernel: ReiserFS: md0: replayed 2 transactions in
0 seconds
Feb 4 09:42:12 altair kernel: ReiserFS: md0: Using r5 hash to sort names
Feb 4 09:42:12 altair kernel: input: PC Speaker as /class/input/input2
Feb 4 09:42:12 altair kernel: Real Time Clock Driver v1.12ac
Feb 4 09:42:12 altair kernel: pci_hotplug: PCI Hot Plug PCI Core
version: 0.5
Feb 4 09:42:12 altair kernel: shpchp: Standard Hot Plug PCI Controller
Driver version: 0.4
Feb 4 09:42:12 altair kernel: Linux video capture interface: v2.00
Feb 4 09:42:12 altair kernel: bttv: driver version 0.9.16 loaded
Feb 4 09:42:12 altair kernel: bttv: using 8 buffers with 2080k (520
pages) each for capture
Feb 4 09:42:12 altair kernel: bttv: Bt8xx card found (0).
Feb 4 09:42:12 altair kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] ->
GSI 18 (level, low) -> IRQ 201
Feb 4 09:42:12 altair kernel: bttv0: Bt878 (rev 17) at 0000:00:0a.0,
irq: 201, latency: 32, mmio: 0xdfdfe000
Feb 4 09:42:12 altair kernel: bttv0: detected: Pinnacle PCTV [card=39],
PCI subsystem ID is 11bd:0012
Feb 4 09:42:12 altair kernel: bttv0: using: Pinnacle PCTV Studio/Rave
[card=39,autodetected]
Feb 4 09:42:12 altair kernel: bttv0: gpio: en=00000000, out=00000000
in=00ff27ff [init]
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @
0x80... not found
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio=no stereo=no
Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @
0x80... not found
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9875 @
0xb0... not found
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA7432 @
0x8a... not found
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9887 @
0x86... not found
Feb 4 09:42:12 altair kernel: tuner 0-0060: All bytes are equal. It is
not a TEA5767
Feb 4 09:42:12 altair kernel: tuner 0-0060: chip found @ 0xc0 (bt878 #0
[sw])
Feb 4 09:42:12 altair kernel: tuner 0-0060: type set to 3 (Philips
(SECAM+PAL_BG) (FI1216MF, FM1216MF, FR1216MF))
Feb 4 09:42:12 altair kernel: bttv0: registered device video0
Feb 4 09:42:12 altair kernel: bttv0: registered device vbi0
Feb 4 09:42:12 altair kernel: bttv0: PLL: 28636363 => 35468950 .. ok
Feb 4 09:42:12 altair kernel: Floppy drive(s): fd0 is 1.44M
Feb 4 09:42:12 altair kernel: FDC 0 is a post-1991 82077
Feb 4 09:42:12 altair kernel: parport: PnPBIOS parport detected.
Feb 4 09:42:12 altair kernel: parport0: PC-style at 0x378 (0x778), irq
7, dma 0 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
Feb 4 09:42:12 altair kernel: Linux agpgart interface v0.101 (c) Dave Jones
Feb 4 09:42:12 altair kernel: atkbd.c: Spurious ACK on isa0060/serio0.
Some program might be trying access hardware directly.
Feb 4 09:42:12 altair kernel: agpgart: Detected VIA PT800 chipset
Feb 4 09:42:12 altair kernel: agpgart: AGP aperture is 128M @ 0xe0000000
Feb 4 09:42:12 altair kernel: ACPI: PCI Interrupt 0000:00:11.5[C] ->
GSI 22 (level, low) -> IRQ 209
Feb 4 09:42:12 altair kernel: PCI: Setting latency timer of device
0000:00:11.5 to 64
Je ne saisis pas bien le sens des dernières lignes concernant bttv juste
avant le plantage... une idée ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
H||VSYNC: synchros. H||V OFLOW: Chroma/luma AGC overflow FBUS: Pixel data fifo dropped data (Hi PCI bus latency) FDSR: Fifo data stream resync. OCERR: RISC instruction error
........
Apparemment, ta carte serait une MIRO PCTV, mais est-ce bien cela?
J'en ai une (une *vraie* MIRO PCTV) qui n'a jamais fonctionnée correctement à moins de donner les options voulues au drv. (et qui *nécessite* le mode de compatibilité v4l-1, sinon elle plante); /etc/modprobe.d/zzz_BTTV: ### BTTV # i2c alias char-major-89 i2c-dev # bttv alias char-major-81 videodev alias char-major-81-0 bttv options bttv card=1 tuner=3 bttv_debug=1 full_luma_range=1 chroma_agc=1 v4l2=0 options tuner tuner_debug=1 show_i2c=1 ### /BTTV
Mon fils et moi avons passé 3H avant de trouver son type de carte TV (on a été obligé d'essayer chaque type de carte ET de tuner (rien de visible dessus) un par un) sur une carte de récup.
Tout ça pour dire qu'il semble qu'il faille absolument la désigner.
Feb 4 09:42:12 altair kernel: Linux video capture interface: v2.00 Feb 4 09:42:12 altair kernel: bttv: driver version 0.9.16 loaded Feb 4 09:42:12 altair kernel: bttv: using 8 buffers with 2080k (520 pages) each for capture Feb 4 09:42:12 altair kernel: bttv: Bt8xx card found (0). Feb 4 09:42:12 altair kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 201 Feb 4 09:42:12 altair kernel: bttv0: Bt878 (rev 17) at 0000:00:0a.0, irq: 201, latency: 32, mmio: 0xdfdfe000
semble dire que ton bus est par défaut @ 32 de latence, c'est trop peu pour la video; 64 est la moyenne, 128 fonctionne bien chez moi (CPU= CEL-2.4GHz) Ca correspond à la tranche de temps minimale accordée par process.
Feb 4 09:42:12 altair kernel: bttv0: detected: Pinnacle PCTV [card9], PCI subsystem ID is 11bd:0012 Feb 4 09:42:12 altair kernel: bttv0: using: Pinnacle PCTV Studio/Rave [card9,autodetected]
l'auto-détection _semble_ correcte
Feb 4 09:42:12 altair kernel: bttv0: gpio: en 000000, out 000000 in ff27ff [init] Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @ 0x80... not found Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio=no stereo=no Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il semble que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @ 0x80... not found Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9875 @ 0xb0... not found Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA7432 @ 0x8a... not found Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9887 @ 0x86... not found Feb 4 09:42:12 altair kernel: tuner 0-0060: All bytes are equal. It is not a TEA5767 Feb 4 09:42:12 altair kernel: tuner 0-0060: chip found @ 0xc0 (bt878 #0 [sw]) Feb 4 09:42:12 altair kernel: tuner 0-0060: type set to 3 (Philips (SECAM+PAL_BG) (FI1216MF, FM1216MF, FR1216MF))
c'est le type std des cartes TV CE
.....
Feb 4 09:42:12 altair kernel: PCI: Setting latency timer of device 0000:00:11.5 to 64
le kernel remet le bus PCI en 64 de latence
a vue de nez, je dirais: remettre 64 (mini) de latence dans le BIOS; et renseigner le driver sur le type correct de carte/tuner/radio (ou laisser l'auto(detect pour voir si ça le fait)
Les différences entre cartes Miro et Pinnacle sont généralement minimes, mais peuvent quand même facilement planter le micro. -- X-rated movies are all alike ... the only thing they leave to the imagination is the plot.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
hugues larrive a écrit :
Bonjour,
salut
Après 10 ans d'utilisation de linux me voilà face à mon premier plantage
du noyau !
H||VSYNC: synchros. H||V
OFLOW: Chroma/luma AGC overflow
FBUS: Pixel data fifo dropped data (Hi PCI bus latency)
FDSR: Fifo data stream resync.
OCERR: RISC instruction error
........
Apparemment, ta carte serait une MIRO PCTV, mais est-ce bien cela?
J'en ai une (une *vraie* MIRO PCTV) qui n'a jamais fonctionnée correctement
à moins de donner les options voulues au drv. (et qui *nécessite* le mode de
compatibilité v4l-1, sinon elle plante); /etc/modprobe.d/zzz_BTTV:
### BTTV
# i2c
alias char-major-89 i2c-dev
# bttv
alias char-major-81 videodev
alias char-major-81-0 bttv
options bttv card=1 tuner=3 bttv_debug=1 full_luma_range=1
chroma_agc=1 v4l2=0
options tuner tuner_debug=1 show_i2c=1
### /BTTV
Mon fils et moi avons passé 3H avant de trouver son type de carte TV
(on a été obligé d'essayer chaque type de carte ET de tuner (rien de visible
dessus) un par un) sur une carte de récup.
Tout ça pour dire qu'il semble qu'il faille absolument la désigner.
Feb 4 09:42:12 altair kernel: Linux video capture interface: v2.00
Feb 4 09:42:12 altair kernel: bttv: driver version 0.9.16 loaded
Feb 4 09:42:12 altair kernel: bttv: using 8 buffers with 2080k (520
pages) each for capture
Feb 4 09:42:12 altair kernel: bttv: Bt8xx card found (0).
Feb 4 09:42:12 altair kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] ->
GSI 18 (level, low) -> IRQ 201
Feb 4 09:42:12 altair kernel: bttv0: Bt878 (rev 17) at 0000:00:0a.0,
irq: 201, latency: 32, mmio: 0xdfdfe000
semble dire que ton bus est par défaut @ 32 de latence, c'est trop peu pour
la video; 64 est la moyenne, 128 fonctionne bien chez moi (CPU= CEL-2.4GHz)
Ca correspond à la tranche de temps minimale accordée par process.
Feb 4 09:42:12 altair kernel: bttv0: detected: Pinnacle PCTV [card9],
PCI subsystem ID is 11bd:0012
Feb 4 09:42:12 altair kernel: bttv0: using: Pinnacle PCTV Studio/Rave
[card9,autodetected]
l'auto-détection _semble_ correcte
Feb 4 09:42:12 altair kernel: bttv0: gpio: en 000000, out 000000
in ff27ff [init]
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @
0x80... not found
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio=no stereo=no
Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il semble
que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @
0x80... not found
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9875 @
0xb0... not found
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA7432 @
0x8a... not found
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9887 @
0x86... not found
Feb 4 09:42:12 altair kernel: tuner 0-0060: All bytes are equal. It is
not a TEA5767
Feb 4 09:42:12 altair kernel: tuner 0-0060: chip found @ 0xc0 (bt878 #0
[sw])
Feb 4 09:42:12 altair kernel: tuner 0-0060: type set to 3 (Philips
(SECAM+PAL_BG) (FI1216MF, FM1216MF, FR1216MF))
c'est le type std des cartes TV CE
.....
Feb 4 09:42:12 altair kernel: PCI: Setting latency timer of device
0000:00:11.5 to 64
le kernel remet le bus PCI en 64 de latence
a vue de nez, je dirais: remettre 64 (mini) de latence dans le BIOS;
et renseigner le driver sur le type correct de carte/tuner/radio
(ou laisser l'auto(detect pour voir si ça le fait)
Les différences entre cartes Miro et Pinnacle sont généralement minimes,
mais peuvent quand même facilement planter le micro.
--
X-rated movies are all alike ... the only thing they leave to the
imagination is the plot.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
H||VSYNC: synchros. H||V OFLOW: Chroma/luma AGC overflow FBUS: Pixel data fifo dropped data (Hi PCI bus latency) FDSR: Fifo data stream resync. OCERR: RISC instruction error
........
Apparemment, ta carte serait une MIRO PCTV, mais est-ce bien cela?
J'en ai une (une *vraie* MIRO PCTV) qui n'a jamais fonctionnée correctement à moins de donner les options voulues au drv. (et qui *nécessite* le mode de compatibilité v4l-1, sinon elle plante); /etc/modprobe.d/zzz_BTTV: ### BTTV # i2c alias char-major-89 i2c-dev # bttv alias char-major-81 videodev alias char-major-81-0 bttv options bttv card=1 tuner=3 bttv_debug=1 full_luma_range=1 chroma_agc=1 v4l2=0 options tuner tuner_debug=1 show_i2c=1 ### /BTTV
Mon fils et moi avons passé 3H avant de trouver son type de carte TV (on a été obligé d'essayer chaque type de carte ET de tuner (rien de visible dessus) un par un) sur une carte de récup.
Tout ça pour dire qu'il semble qu'il faille absolument la désigner.
Feb 4 09:42:12 altair kernel: Linux video capture interface: v2.00 Feb 4 09:42:12 altair kernel: bttv: driver version 0.9.16 loaded Feb 4 09:42:12 altair kernel: bttv: using 8 buffers with 2080k (520 pages) each for capture Feb 4 09:42:12 altair kernel: bttv: Bt8xx card found (0). Feb 4 09:42:12 altair kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 201 Feb 4 09:42:12 altair kernel: bttv0: Bt878 (rev 17) at 0000:00:0a.0, irq: 201, latency: 32, mmio: 0xdfdfe000
semble dire que ton bus est par défaut @ 32 de latence, c'est trop peu pour la video; 64 est la moyenne, 128 fonctionne bien chez moi (CPU= CEL-2.4GHz) Ca correspond à la tranche de temps minimale accordée par process.
Feb 4 09:42:12 altair kernel: bttv0: detected: Pinnacle PCTV [card9], PCI subsystem ID is 11bd:0012 Feb 4 09:42:12 altair kernel: bttv0: using: Pinnacle PCTV Studio/Rave [card9,autodetected]
l'auto-détection _semble_ correcte
Feb 4 09:42:12 altair kernel: bttv0: gpio: en 000000, out 000000 in ff27ff [init] Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @ 0x80... not found Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio=no stereo=no Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il semble que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @ 0x80... not found Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9875 @ 0xb0... not found Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA7432 @ 0x8a... not found Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9887 @ 0x86... not found Feb 4 09:42:12 altair kernel: tuner 0-0060: All bytes are equal. It is not a TEA5767 Feb 4 09:42:12 altair kernel: tuner 0-0060: chip found @ 0xc0 (bt878 #0 [sw]) Feb 4 09:42:12 altair kernel: tuner 0-0060: type set to 3 (Philips (SECAM+PAL_BG) (FI1216MF, FM1216MF, FR1216MF))
c'est le type std des cartes TV CE
.....
Feb 4 09:42:12 altair kernel: PCI: Setting latency timer of device 0000:00:11.5 to 64
le kernel remet le bus PCI en 64 de latence
a vue de nez, je dirais: remettre 64 (mini) de latence dans le BIOS; et renseigner le driver sur le type correct de carte/tuner/radio (ou laisser l'auto(detect pour voir si ça le fait)
Les différences entre cartes Miro et Pinnacle sont généralement minimes, mais peuvent quand même facilement planter le micro. -- X-rated movies are all alike ... the only thing they leave to the imagination is the plot.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jean-Yves F. Barbier
oops: .....
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio=no stereo=no Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il semble que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
id=9 correspond à une IMS/IXmicro Turbo TV (qui n'a rien à voir avec une miro||pinnacle)
-- Doubt is not a pleasant condition, but certainty is absurd. -- Voltaire
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
oops:
.....
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio=no
stereo=no
Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il semble
que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
id=9 correspond à une IMS/IXmicro Turbo TV (qui n'a rien à voir avec une
miro||pinnacle)
--
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio=no stereo=no Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il semble que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
id=9 correspond à une IMS/IXmicro Turbo TV (qui n'a rien à voir avec une miro||pinnacle)
-- Doubt is not a pleasant condition, but certainty is absurd. -- Voltaire
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Hugues LARRIVE
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFB00F3E2F9C814067F98DE7A Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable
H||VSYNC: synchros. H||V OFLOW: Chroma/luma AGC overflow FBUS: Pixel data fifo dropped data (Hi PCI bus latency) FDSR: Fifo data stream resync. OCERR: RISC instruction error
........
Apparemment, ta carte serait une MIRO PCTV, mais est-ce bien cela?
J'en ai une (une *vraie* MIRO PCTV) qui n'a jamais fonctionnée correctement à moins de donner les options voulues au drv. (et qui *nécessite* l e mode de compatibilité v4l-1, sinon elle plante); /etc/modprobe.d/zzz_BTTV: ### BTTV # i2c alias char-major-89 i2c-dev # bttv alias char-major-81 videodev alias char-major-81-0 bttv options bttv card=1 tuner=3 bttv_debug=1 full_luma_ran ge=1 chroma_agc=1 v4l2=0 options tuner tuner_debug=1 show_i2c=1 ### /BTTV
Mon fils et moi avons passé 3H avant de trouver son type de carte TV (on a été obligé d'essayer chaque type de carte ET de tuner (rien de visible dessus) un par un) sur une carte de récup.
Tout ça pour dire qu'il semble qu'il faille absolument la désigner.
J'ai retiré cette carte de mon enregistreur numérique à la maison s ur lequel j'en avais 2 identiques, je n'ai jamais eu ce genre de difficulté .
Feb 4 09:42:12 altair kernel: Linux video capture interface: v2.00 Feb 4 09:42:12 altair kernel: bttv: driver version 0.9.16 loaded Feb 4 09:42:12 altair kernel: bttv: using 8 buffers with 2080k (520 pages) each for capture Feb 4 09:42:12 altair kernel: bttv: Bt8xx card found (0). Feb 4 09:42:12 altair kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 201 Feb 4 09:42:12 altair kernel: bttv0: Bt878 (rev 17) at 0000:00:0a.0, irq: 201, latency: 32, mmio: 0xdfdfe000
semble dire que ton bus est par défaut @ 32 de latence, c'est trop pe u pour la video; 64 est la moyenne, 128 fonctionne bien chez moi (CPU= CEL-2.4GHz) Ca correspond à la tranche de temps minimale accordée par process.
Il y a effectivement une piste à explorer de ce coté là... en mêm e temps c'était pareil sur l'autre machine et je pouvais enregistrer 2 programmes simultanément sans problème.
Feb 4 09:42:12 altair kernel: bttv0: detected: Pinnacle PCTV [card= 39], PCI subsystem ID is 11bd:0012 Feb 4 09:42:12 altair kernel: bttv0: using: Pinnacle PCTV Studio/Rave [card9,autodetected]
l'auto-détection _semble_ correcte
Feb 4 09:42:12 altair kernel: bttv0: gpio: en 000000, out 000 000 in ff27ff [init] Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @ 0x80... not found Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio=n o stereo=no Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il sem ble que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
Oui, bon elles ont toujours bien fonctionné comme ça.
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @ 0x80... not found Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9875 @ 0xb0... not found Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA7432 @ 0x8a... not found Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9887 @ 0x86... not found Feb 4 09:42:12 altair kernel: tuner 0-0060: All bytes are equal. It i s not a TEA5767 Feb 4 09:42:12 altair kernel: tuner 0-0060: chip found @ 0xc0 (bt878 #0 [sw]) Feb 4 09:42:12 altair kernel: tuner 0-0060: type set to 3 (Philips (SECAM+PAL_BG) (FI1216MF, FM1216MF, FR1216MF))
c'est le type std des cartes TV CE
.....
Feb 4 09:42:12 altair kernel: PCI: Setting latency timer of device 0000:00:11.5 to 64
le kernel remet le bus PCI en 64 de latence
Non, en fait 11.5 c'est la carte son mais effectivement il le fait aussi pour le bus pci (0000:00:11.5)
a vue de nez, je dirais: remettre 64 (mini) de latence dans le BIOS;
Je ne sais pas si c'est vraiment utile vu que linux le fait déjà.
et renseigner le driver sur le type correct de carte/tuner/radio (ou laisser l'auto(detect pour voir si ça le fait)
Ben en fait ça fonctionne nickel comme ça... d'ailleurs c'est bien la seule chose qui fonctionnait encore ce matin !
Les différences entre cartes Miro et Pinnacle sont généralement m inimes, mais peuvent quand même facilement planter le micro.
Du coup j'ai regardé un peu les logs de la machine sur laquelle la cart e était avant. J'avais déjà des message du driver bttv mais ça ne n uisait pas à la stabilité du système : Jan 18 22:25:58 recorder [111107.469000] bttv0: OCERR @ 0fcb4014,bits: HSYNC OFLOW OCERR* La configuration du driver, la latence, etc. étaient les mêmes.
Je note que je n'avais pas de FBUS et FDSR...
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 con traire. 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èreme nt sur ce serveur...
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 verrai s 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: :0a.0 version: 11 width: 32 bits clock: 33MHz capabilities: bus_master cap_list configuration: driver=bttv latency2 maxlatency@ mi ngnt resources: iomemory:dfdfe000-dfdfefff irq:201
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 ?
Je vais aussi tenter de voir si je peux avoir quelque-chose sur une console série si je retrouve mon câble nul-modem et que j'arrive à faire fonctionner ça...
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFB00F3E2F9C814067F98DE7A
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
H||VSYNC: synchros. H||V
OFLOW: Chroma/luma AGC overflow
FBUS: Pixel data fifo dropped data (Hi PCI bus latency)
FDSR: Fifo data stream resync.
OCERR: RISC instruction error
........
Apparemment, ta carte serait une MIRO PCTV, mais est-ce bien cela?
J'en ai une (une *vraie* MIRO PCTV) qui n'a jamais fonctionnée
correctement
à moins de donner les options voulues au drv. (et qui *nécessite* l e
mode de
compatibilité v4l-1, sinon elle plante); /etc/modprobe.d/zzz_BTTV:
### BTTV
# i2c
alias char-major-89 i2c-dev
# bttv
alias char-major-81 videodev
alias char-major-81-0 bttv
options bttv card=1 tuner=3 bttv_debug=1 full_luma_ran ge=1
chroma_agc=1 v4l2=0
options tuner tuner_debug=1 show_i2c=1
### /BTTV
Mon fils et moi avons passé 3H avant de trouver son type de carte TV
(on a été obligé d'essayer chaque type de carte ET de tuner (rien de
visible
dessus) un par un) sur une carte de récup.
Tout ça pour dire qu'il semble qu'il faille absolument la désigner.
J'ai retiré cette carte de mon enregistreur numérique à la maison s ur
lequel j'en avais 2 identiques, je n'ai jamais eu ce genre de difficulté .
Feb 4 09:42:12 altair kernel: Linux video capture interface: v2.00
Feb 4 09:42:12 altair kernel: bttv: driver version 0.9.16 loaded
Feb 4 09:42:12 altair kernel: bttv: using 8 buffers with 2080k (520
pages) each for capture
Feb 4 09:42:12 altair kernel: bttv: Bt8xx card found (0).
Feb 4 09:42:12 altair kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] ->
GSI 18 (level, low) -> IRQ 201
Feb 4 09:42:12 altair kernel: bttv0: Bt878 (rev 17) at 0000:00:0a.0,
irq: 201, latency: 32, mmio: 0xdfdfe000
semble dire que ton bus est par défaut @ 32 de latence, c'est trop pe u
pour
la video; 64 est la moyenne, 128 fonctionne bien chez moi (CPU=
CEL-2.4GHz)
Ca correspond à la tranche de temps minimale accordée par process.
Il y a effectivement une piste à explorer de ce coté là... en mêm e temps
c'était pareil sur l'autre machine et je pouvais enregistrer 2
programmes simultanément sans problème.
Feb 4 09:42:12 altair kernel: bttv0: detected: Pinnacle PCTV [card= 39],
PCI subsystem ID is 11bd:0012
Feb 4 09:42:12 altair kernel: bttv0: using: Pinnacle PCTV Studio/Rave
[card=39,autodetected]
l'auto-détection _semble_ correcte
Feb 4 09:42:12 altair kernel: bttv0: gpio: en=00000000, out=00000 000
in=00ff27ff [init]
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @
0x80... not found
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio=n o
stereo=no
Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il sem ble
que la tienne (auto-détect V.+haut) soit id=39 (Pinnacle PCTV
Studio/Rave)
Oui, bon elles ont toujours bien fonctionné comme ça.
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @
0x80... not found
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9875 @
0xb0... not found
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA7432 @
0x8a... not found
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9887 @
0x86... not found
Feb 4 09:42:12 altair kernel: tuner 0-0060: All bytes are equal. It i s
not a TEA5767
Feb 4 09:42:12 altair kernel: tuner 0-0060: chip found @ 0xc0 (bt878 #0
[sw])
Feb 4 09:42:12 altair kernel: tuner 0-0060: type set to 3 (Philips
(SECAM+PAL_BG) (FI1216MF, FM1216MF, FR1216MF))
c'est le type std des cartes TV CE
.....
Feb 4 09:42:12 altair kernel: PCI: Setting latency timer of device
0000:00:11.5 to 64
le kernel remet le bus PCI en 64 de latence
Non, en fait 11.5 c'est la carte son mais effectivement il le fait aussi
pour le bus pci (0000:00:11.5)
a vue de nez, je dirais: remettre 64 (mini) de latence dans le BIOS;
Je ne sais pas si c'est vraiment utile vu que linux le fait déjà.
et renseigner le driver sur le type correct de carte/tuner/radio
(ou laisser l'auto(detect pour voir si ça le fait)
Ben en fait ça fonctionne nickel comme ça... d'ailleurs c'est bien la
seule chose qui fonctionnait encore ce matin !
Les différences entre cartes Miro et Pinnacle sont généralement m inimes,
mais peuvent quand même facilement planter le micro.
Du coup j'ai regardé un peu les logs de la machine sur laquelle la cart e
était avant. J'avais déjà des message du driver bttv mais ça ne n uisait
pas à la stabilité du système :
Jan 18 22:25:58 recorder [111107.469000] bttv0: OCERR @ 0fcb4014,bits:
HSYNC OFLOW OCERR*
La configuration du driver, la latence, etc. étaient les mêmes.
Je note que je n'avais pas de FBUS et FDSR...
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 con traire.
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èreme nt
sur ce serveur...
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 verrai s
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 mi ngnt=16
resources: iomemory:dfdfe000-dfdfefff irq:201
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 ?
Je vais aussi tenter de voir si je peux avoir quelque-chose sur une
console série si je retrouve mon câble nul-modem et que j'arrive à faire
fonctionner ça...
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFB00F3E2F9C814067F98DE7A Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable
H||VSYNC: synchros. H||V OFLOW: Chroma/luma AGC overflow FBUS: Pixel data fifo dropped data (Hi PCI bus latency) FDSR: Fifo data stream resync. OCERR: RISC instruction error
........
Apparemment, ta carte serait une MIRO PCTV, mais est-ce bien cela?
J'en ai une (une *vraie* MIRO PCTV) qui n'a jamais fonctionnée correctement à moins de donner les options voulues au drv. (et qui *nécessite* l e mode de compatibilité v4l-1, sinon elle plante); /etc/modprobe.d/zzz_BTTV: ### BTTV # i2c alias char-major-89 i2c-dev # bttv alias char-major-81 videodev alias char-major-81-0 bttv options bttv card=1 tuner=3 bttv_debug=1 full_luma_ran ge=1 chroma_agc=1 v4l2=0 options tuner tuner_debug=1 show_i2c=1 ### /BTTV
Mon fils et moi avons passé 3H avant de trouver son type de carte TV (on a été obligé d'essayer chaque type de carte ET de tuner (rien de visible dessus) un par un) sur une carte de récup.
Tout ça pour dire qu'il semble qu'il faille absolument la désigner.
J'ai retiré cette carte de mon enregistreur numérique à la maison s ur lequel j'en avais 2 identiques, je n'ai jamais eu ce genre de difficulté .
Feb 4 09:42:12 altair kernel: Linux video capture interface: v2.00 Feb 4 09:42:12 altair kernel: bttv: driver version 0.9.16 loaded Feb 4 09:42:12 altair kernel: bttv: using 8 buffers with 2080k (520 pages) each for capture Feb 4 09:42:12 altair kernel: bttv: Bt8xx card found (0). Feb 4 09:42:12 altair kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 201 Feb 4 09:42:12 altair kernel: bttv0: Bt878 (rev 17) at 0000:00:0a.0, irq: 201, latency: 32, mmio: 0xdfdfe000
semble dire que ton bus est par défaut @ 32 de latence, c'est trop pe u pour la video; 64 est la moyenne, 128 fonctionne bien chez moi (CPU= CEL-2.4GHz) Ca correspond à la tranche de temps minimale accordée par process.
Il y a effectivement une piste à explorer de ce coté là... en mêm e temps c'était pareil sur l'autre machine et je pouvais enregistrer 2 programmes simultanément sans problème.
Feb 4 09:42:12 altair kernel: bttv0: detected: Pinnacle PCTV [card= 39], PCI subsystem ID is 11bd:0012 Feb 4 09:42:12 altair kernel: bttv0: using: Pinnacle PCTV Studio/Rave [card9,autodetected]
l'auto-détection _semble_ correcte
Feb 4 09:42:12 altair kernel: bttv0: gpio: en 000000, out 000 000 in ff27ff [init] Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @ 0x80... not found Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio=n o stereo=no Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il sem ble que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
Oui, bon elles ont toujours bien fonctionné comme ça.
Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for MSP34xx @ 0x80... not found Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9875 @ 0xb0... not found Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA7432 @ 0x8a... not found Feb 4 09:42:12 altair kernel: bttv0: i2c: checking for TDA9887 @ 0x86... not found Feb 4 09:42:12 altair kernel: tuner 0-0060: All bytes are equal. It i s not a TEA5767 Feb 4 09:42:12 altair kernel: tuner 0-0060: chip found @ 0xc0 (bt878 #0 [sw]) Feb 4 09:42:12 altair kernel: tuner 0-0060: type set to 3 (Philips (SECAM+PAL_BG) (FI1216MF, FM1216MF, FR1216MF))
c'est le type std des cartes TV CE
.....
Feb 4 09:42:12 altair kernel: PCI: Setting latency timer of device 0000:00:11.5 to 64
le kernel remet le bus PCI en 64 de latence
Non, en fait 11.5 c'est la carte son mais effectivement il le fait aussi pour le bus pci (0000:00:11.5)
a vue de nez, je dirais: remettre 64 (mini) de latence dans le BIOS;
Je ne sais pas si c'est vraiment utile vu que linux le fait déjà.
et renseigner le driver sur le type correct de carte/tuner/radio (ou laisser l'auto(detect pour voir si ça le fait)
Ben en fait ça fonctionne nickel comme ça... d'ailleurs c'est bien la seule chose qui fonctionnait encore ce matin !
Les différences entre cartes Miro et Pinnacle sont généralement m inimes, mais peuvent quand même facilement planter le micro.
Du coup j'ai regardé un peu les logs de la machine sur laquelle la cart e était avant. J'avais déjà des message du driver bttv mais ça ne n uisait pas à la stabilité du système : Jan 18 22:25:58 recorder [111107.469000] bttv0: OCERR @ 0fcb4014,bits: HSYNC OFLOW OCERR* La configuration du driver, la latence, etc. étaient les mêmes.
Je note que je n'avais pas de FBUS et FDSR...
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 con traire. 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èreme nt sur ce serveur...
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 verrai s 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: :0a.0 version: 11 width: 32 bits clock: 33MHz capabilities: bus_master cap_list configuration: driver=bttv latency2 maxlatency@ mi ngnt resources: iomemory:dfdfe000-dfdfefff irq:201
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 ?
Je vais aussi tenter de voir si je peux avoir quelque-chose sur une console série si je retrouve mon câble nul-modem et que j'arrive à faire fonctionner ça...
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Hugues LARRIVE
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6586D2A6F20B527390F9F6B Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable
Jean-Yves F. Barbier a écrit :
oops: .....
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio= no stereo=no Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il se mble que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
id=9 correspond à une IMS/IXmicro Turbo TV (qui n'a rien à voir a vec une miro||pinnacle)
Peut-être que c'est un sous-id...
Je tiens à rappeler que la carte tv fonctionnait parfaitement et que c'est même la seule chose qui a continué à fonctionner suite au pla ntage !
Simplement c'est aussi le dernier driver à avoir enregistré des messa ges dans le journal et qui plus est des erreurs...
@+
PS: Je reçoit tes réponses en double... ce n'est pas utile puisque je suis abonné à la liste.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF6586D2A6F20B527390F9F6B
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Jean-Yves F. Barbier a écrit :
oops:
.....
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio= no
stereo=no
Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il se mble
que la tienne (auto-détect V.+haut) soit id=39 (Pinnacle PCTV
Studio/Rave)
id=9 correspond à une IMS/IXmicro Turbo TV (qui n'a rien à voir a vec une
miro||pinnacle)
Peut-être que c'est un sous-id...
Je tiens à rappeler que la carte tv fonctionnait parfaitement et que
c'est même la seule chose qui a continué à fonctionner suite au pla ntage !
Simplement c'est aussi le dernier driver à avoir enregistré des messa ges
dans le journal et qui plus est des erreurs...
@+
PS: Je reçoit tes réponses en double... ce n'est pas utile puisque je
suis abonné à la liste.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6586D2A6F20B527390F9F6B Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable
Jean-Yves F. Barbier a écrit :
oops: .....
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio= no stereo=no Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il se mble que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
id=9 correspond à une IMS/IXmicro Turbo TV (qui n'a rien à voir a vec une miro||pinnacle)
Peut-être que c'est un sous-id...
Je tiens à rappeler que la carte tv fonctionnait parfaitement et que c'est même la seule chose qui a continué à fonctionner suite au pla ntage !
Simplement c'est aussi le dernier driver à avoir enregistré des messa ges dans le journal et qui plus est des erreurs...
@+
PS: Je reçoit tes réponses en double... ce n'est pas utile puisque je suis abonné à la liste.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jean-Yves F. Barbier
Hugues LARRIVE a écrit : ......
Tout ça pour dire qu'il semble qu'il faille absolument la désigner.
J'ai retiré cette carte de mon enregistreur numérique à la maison sur lequel j'en avais 2 identiques, je n'ai jamais eu ce genre de difficulté.
ça dépend des cartes .......
Du coup j'ai regardé un peu les logs de la machine sur laquelle la carte était avant. J'avais déjà des message du driver bttv mais ça ne nuisait pas à la stabilité du système : Jan 18 22:25:58 recorder [111107.469000] bttv0: OCERR @ 0fcb4014,bits: HSYNC OFLOW OCERR* La configuration du driver, la latence, etc. étaient les mêmes. Je note que je n'avais pas de FBUS et FDSR...
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.
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{)
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: :0a.0 version: 11 width: 32 bits clock: 33MHz capabilities: bus_master cap_list configuration: driver=bttv latency2 maxlatency@ mingnt 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)?
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.
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 :( -- Charity, n.: A thing that begins at home and usually stays there.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Hugues LARRIVE a écrit :
......
Tout ça pour dire qu'il semble qu'il faille absolument la désigner.
J'ai retiré cette carte de mon enregistreur numérique à la maison sur
lequel j'en avais 2 identiques, je n'ai jamais eu ce genre de difficulté.
ça dépend des cartes
.......
Du coup j'ai regardé un peu les logs de la machine sur laquelle la carte
était avant. J'avais déjà des message du driver bttv mais ça ne nuisait
pas à la stabilité du système :
Jan 18 22:25:58 recorder [111107.469000] bttv0: OCERR @ 0fcb4014,bits:
HSYNC OFLOW OCERR*
La configuration du driver, la latence, etc. étaient les mêmes.
Je note que je n'avais pas de FBUS et FDSR...
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.
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{)
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 latency2 maxlatency@ mingnt
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)?
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.
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 :(
--
Charity, n.:
A thing that begins at home and usually stays there.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Tout ça pour dire qu'il semble qu'il faille absolument la désigner.
J'ai retiré cette carte de mon enregistreur numérique à la maison sur lequel j'en avais 2 identiques, je n'ai jamais eu ce genre de difficulté.
ça dépend des cartes .......
Du coup j'ai regardé un peu les logs de la machine sur laquelle la carte était avant. J'avais déjà des message du driver bttv mais ça ne nuisait pas à la stabilité du système : Jan 18 22:25:58 recorder [111107.469000] bttv0: OCERR @ 0fcb4014,bits: HSYNC OFLOW OCERR* La configuration du driver, la latence, etc. étaient les mêmes. Je note que je n'avais pas de FBUS et FDSR...
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.
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{)
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: :0a.0 version: 11 width: 32 bits clock: 33MHz capabilities: bus_master cap_list configuration: driver=bttv latency2 maxlatency@ mingnt 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)?
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.
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 :( -- Charity, n.: A thing that begins at home and usually stays there.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jean-Yves F. Barbier
Hugues LARRIVE a écrit :
Jean-Yves F. Barbier a écrit :
oops: .....
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio=no stereo=no Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il semble que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
id=9 correspond à une IMS/IXmicro Turbo TV (qui n'a rien à voir avec une miro||pinnacle)
Peut-être que c'est un sous-id...
Je tiens à rappeler que la carte tv fonctionnait parfaitement et que c'est même la seule chose qui a continué à fonctionner suite au plantage !
justement, c'est pourquoi je te suggérais de modifier le script de lancement du check raid pour qu'il arrête la TV le temps de son fonctionnement
Simplement c'est aussi le dernier driver à avoir enregistré des messages dans le journal et qui plus est des erreurs...
@+
PS: Je reçoit tes réponses en double... ce n'est pas utile puisque je suis abonné à la liste.
wai: pas de "réponse à la liste" dans icedove:(
-- real buddy, n.: Someone who'll go downtown and get two blowjobs, and come back and give you one.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Hugues LARRIVE a écrit :
Jean-Yves F. Barbier a écrit :
oops:
.....
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio=no
stereo=no
Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il semble
que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV
Studio/Rave)
id=9 correspond à une IMS/IXmicro Turbo TV (qui n'a rien à voir avec une
miro||pinnacle)
Peut-être que c'est un sous-id...
Je tiens à rappeler que la carte tv fonctionnait parfaitement et que
c'est même la seule chose qui a continué à fonctionner suite au plantage !
justement, c'est pourquoi je te suggérais de modifier le script de lancement
du check raid pour qu'il arrête la TV le temps de son fonctionnement
Simplement c'est aussi le dernier driver à avoir enregistré des messages
dans le journal et qui plus est des erreurs...
@+
PS: Je reçoit tes réponses en double... ce n'est pas utile puisque je
suis abonné à la liste.
wai: pas de "réponse à la liste" dans icedove:(
--
real buddy, n.:
Someone who'll go downtown and get two blowjobs, and come back
and give you one.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio=no stereo=no Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il semble que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
id=9 correspond à une IMS/IXmicro Turbo TV (qui n'a rien à voir avec une miro||pinnacle)
Peut-être que c'est un sous-id...
Je tiens à rappeler que la carte tv fonctionnait parfaitement et que c'est même la seule chose qui a continué à fonctionner suite au plantage !
justement, c'est pourquoi je te suggérais de modifier le script de lancement du check raid pour qu'il arrête la TV le temps de son fonctionnement
Simplement c'est aussi le dernier driver à avoir enregistré des messages dans le journal et qui plus est des erreurs...
@+
PS: Je reçoit tes réponses en double... ce n'est pas utile puisque je suis abonné à la liste.
wai: pas de "réponse à la liste" dans icedove:(
-- real buddy, n.: Someone who'll go downtown and get two blowjobs, and come back and give you one.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Hugues LARRIVE
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig29228423EB98296A3007E4AF Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable
Jean-Yves F. Barbier a écrit :
en fait, vu ce que tu dis après, ça parait logique: le raidcheck pr enant 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 seu le 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 qu e mplayer ou le framebuffer plante complètement. Cette application n'a rien de critique. Par contre tout le reste du réseau repose entièr ement 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 ver rais 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: :0a.0 version: 11 width: 32 bits clock: 33MHz capabilities: bus_master cap_list configuration: driver=bttv latency2 maxlatency@ mingnt 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 da ns 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 de s plombes à attendre qu'il compile tout...
tu peux essayer aussi de désactiver un port série, et d'assigner so n 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 ?
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig29228423EB98296A3007E4AF
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Jean-Yves F. Barbier a écrit :
en fait, vu ce que tu dis après, ça parait logique: le raidcheck pr enant
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 seu le 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 qu e
mplayer ou le framebuffer plante complètement. Cette application n'a
rien de critique. Par contre tout le reste du réseau repose entièr ement
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 ver rais
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 da ns
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 de s
plombes à attendre qu'il compile tout...
tu peux essayer aussi de désactiver un port série, et d'assigner so n 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 ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig29228423EB98296A3007E4AF Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable
Jean-Yves F. Barbier a écrit :
en fait, vu ce que tu dis après, ça parait logique: le raidcheck pr enant 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 seu le 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 qu e mplayer ou le framebuffer plante complètement. Cette application n'a rien de critique. Par contre tout le reste du réseau repose entièr ement 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 ver rais 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: :0a.0 version: 11 width: 32 bits clock: 33MHz capabilities: bus_master cap_list configuration: driver=bttv latency2 maxlatency@ mingnt 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 da ns 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 de s plombes à attendre qu'il compile tout...
tu peux essayer aussi de désactiver un port série, et d'assigner so n 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 ?
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Hugues LARRIVE
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7531DEE551930C8AA2ABF548 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable
Jean-Yves F. Barbier a écrit :
Hugues LARRIVE a écrit :
Jean-Yves F. Barbier a écrit :
oops: .....
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio= no stereo=no Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il semble que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
id=9 correspond à une IMS/IXmicro Turbo TV (qui n'a rien à voir avec une miro||pinnacle)
Peut-être que c'est un sous-id...
Je tiens à rappeler que la carte tv fonctionnait parfaitement et que c'est même la seule chose qui a continué à fonctionner suite au plantage !
justement, c'est pourquoi je te suggérais de modifier le script de lancement du check raid pour qu'il arrête la TV le temps de son fonctionnement
Simplement c'est aussi le dernier driver à avoir enregistré des me ssages dans le journal et qui plus est des erreurs...
@+
PS: Je reçoit tes réponses en double... ce n'est pas utile puisque je suis abonné à la liste.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7531DEE551930C8AA2ABF548
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Jean-Yves F. Barbier a écrit :
Hugues LARRIVE a écrit :
Jean-Yves F. Barbier a écrit :
oops:
.....
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio= no
stereo=no
Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il semble
que la tienne (auto-détect V.+haut) soit id=39 (Pinnacle PCTV
Studio/Rave)
id=9 correspond à une IMS/IXmicro Turbo TV (qui n'a rien à voir avec
une
miro||pinnacle)
Peut-être que c'est un sous-id...
Je tiens à rappeler que la carte tv fonctionnait parfaitement et que
c'est même la seule chose qui a continué à fonctionner suite au
plantage !
justement, c'est pourquoi je te suggérais de modifier le script de
lancement
du check raid pour qu'il arrête la TV le temps de son fonctionnement
Simplement c'est aussi le dernier driver à avoir enregistré des me ssages
dans le journal et qui plus est des erreurs...
@+
PS: Je reçoit tes réponses en double... ce n'est pas utile puisque je
suis abonné à la liste.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7531DEE551930C8AA2ABF548 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable
Jean-Yves F. Barbier a écrit :
Hugues LARRIVE a écrit :
Jean-Yves F. Barbier a écrit :
oops: .....
Feb 4 09:42:12 altair kernel: bttv0: miro: id=9 tuner=3 radio= no stereo=no Feb 4 09:42:12 altair kernel: bttv0: using tuner=3
Ca, par contre, ça ne va pas: id=9 c'est pour une MIRO PCTV, il semble que la tienne (auto-détect V.+haut) soit id9 (Pinnacle PCTV Studio/Rave)
id=9 correspond à une IMS/IXmicro Turbo TV (qui n'a rien à voir avec une miro||pinnacle)
Peut-être que c'est un sous-id...
Je tiens à rappeler que la carte tv fonctionnait parfaitement et que c'est même la seule chose qui a continué à fonctionner suite au plantage !
justement, c'est pourquoi je te suggérais de modifier le script de lancement du check raid pour qu'il arrête la TV le temps de son fonctionnement
Simplement c'est aussi le dernier driver à avoir enregistré des me ssages dans le journal et qui plus est des erreurs...
@+
PS: Je reçoit tes réponses en double... ce n'est pas utile puisque je suis abonné à la liste.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jean-Yves F. Barbier
Hugues LARRIVE a écrit :
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.
un rapide grep révèle que 'loadwatch' semble être ton ami sur ce coup-là
....
lshw
Ok, j'ai le même (max@), mais ça n'empêche pas la Cte TV de bien fonctionner avec une latence de 128
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...
si tes autres micros sont sous Linux, 'distcc' est bien pratique pour éviter de prendre le repas avant le café en attendant la fin de compilation:)
....
Je devrai peut-être ajouter noapic dans mes options de boot aussi ?
je ne sais pas s'il-y-a des effets de bord avec apic
-- One FISHWICH coming up!!
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Hugues LARRIVE a écrit :
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.
un rapide grep révèle que 'loadwatch' semble être ton ami sur ce coup-là
....
lshw
Ok, j'ai le même (max@), mais ça n'empêche pas la Cte TV de bien
fonctionner avec une latence de 128
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...
si tes autres micros sont sous Linux, 'distcc' est bien pratique pour éviter
de prendre le repas avant le café en attendant la fin de compilation:)
....
Je devrai peut-être ajouter noapic dans mes options de boot aussi ?
je ne sais pas s'il-y-a des effets de bord avec apic
--
One FISHWICH coming up!!
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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.
un rapide grep révèle que 'loadwatch' semble être ton ami sur ce coup-là
....
lshw
Ok, j'ai le même (max@), mais ça n'empêche pas la Cte TV de bien fonctionner avec une latence de 128
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...
si tes autres micros sont sous Linux, 'distcc' est bien pratique pour éviter de prendre le repas avant le café en attendant la fin de compilation:)
....
Je devrai peut-être ajouter noapic dans mes options de boot aussi ?
je ne sais pas s'il-y-a des effets de bord avec apic
-- One FISHWICH coming up!!
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
