bttv et plantage du noyau

Le
hugues larrive
Bonjour,

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=vgax6 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 :

~$ exec mplayer -tv
driver=v4l:widthd0:heightH0:outfmt=i420:device=/dev/video0:input=1
-vc rawi420 -vo fbdev tv://

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 [card9],
PCI subsystem ID is 11bd:0012
Feb 4 09:42:12 altair kernel: bttv0: using: Pinnacle PCTV Studio/Rave
[card9,autodetected]
Feb 4 09:42:12 altair kernel: bttv0: gpio: en000000, out000000
inff27ff [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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Yves F. Barbier
Le #9724801
hugues larrive a écrit :
Bonjour,



salut

Après 10 ans d'utilisation de linux me voilà face à mon premier plantage
du noyau !



il faut début à tout

..........
Feb 3 01:06:03 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFLOW
FBUS FDSR OCERR*



Dixit les sources du drv:

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: en000000, out000000
inff27ff [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
Le #9724791
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
Hugues LARRIVE
Le #9722641
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

Jean-Yves F. Barbier a écrit :

...
Feb 3 01:06:03 altair kernel: bttv0: OCERR @ 1eccb008,bits: HSYNC OFL OW
FBUS FDSR OCERR*



Dixit les sources du drv:

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: en000000, out000 000
inff27ff [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...

@+


--------------enigFB00F3E2F9C814067F98DE7A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHp1yXNdTZuHWpgVIRApJkAJ4oREV6Ar6ojAqb++D+UihmuOkJFwCdF60t
DNpqvwGgYQjjzqgyps416/Y =HeCs
-----END PGP SIGNATURE-----

--------------enigFB00F3E2F9C814067F98DE7A--


--
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
Le #9722621
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.


--------------enigF6586D2A6F20B527390F9F6B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHp17UNdTZuHWpgVIRAtjrAJ97TtS2Vv+BI06QgqU4qkiZQPQEIACeOmjy
O/ybpLa1IEtftr/c+T9evVc =zC+r
-----END PGP SIGNATURE-----

--------------enigF6586D2A6F20B527390F9F6B--


--
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
Le #9722591
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
Jean-Yves F. Barbier
Le #9722501
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
Le #9722461
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 ?

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

@+


--------------enig29228423EB98296A3007E4AF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHp5uDNdTZuHWpgVIRAqKRAJ9y8NWuX54UWhoJhC5nvgZYBvFULQCdHh5p
k+vsCeGghcTCvsUhmMLaz/8 =yJ+i
-----END PGP SIGNATURE-----

--------------enig29228423EB98296A3007E4AF--


--
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
Le #9722451
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.



wai: pas de "réponse à la liste" dans icedove:(



Moi je l'ai !

http://debian.hugueslarrive.net/etch/




--------------enig7531DEE551930C8AA2ABF548
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHp558NdTZuHWpgVIRAiIRAJ0eiah9r2HoM446Fk6tX1Iu6GPpnwCeOJho
hTtduAm9soG6u+nC7Dtpw6M =JnvL
-----END PGP SIGNATURE-----

--------------enig7531DEE551930C8AA2ABF548--


--
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
Le #9722441
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
Publicité
Poster une réponse
Anonyme