Suite de l'expérience, au fil de l'eau.
L'analyse précédente était elle aussi fausse.
Ce n'est pas libérer ~/adapter0/ en arrêtant TVHeadend avant de passer
en suspend to RAM qui supprime les erreurs dans les logs système.
C'est tout simplement décharger le module cx88_dvb et le recharger
immédiatement derrière. A partir de là, plus d'erreur aux prochaines
sorties de veille. Et /dev/dvb/adapter0/ est toujours là.
J'ai fait une association trop rapide avec TVHeadend, parce que c'était
nécessaire de l'arrêter pour décharger le module cx88_dvb.
La séquence suivante :
# systemctl stop tvheadend
# modprobe -r cx88_dvb
# modprobe cx88_dvb
# systemctl start tvheadend
# systemctl suspend
résout donc problème,
mais n'en explique pas la cause.
Quelqu'un en saurait-il plus ?
Merci.
--
Frédéric Dumas
[email protected]
Le 31/08/2019 à 00:05, Frederic Dumas a écrit :
Oublions la question. Modprobe fait le boulot automatiquement sans
problème. J'avais simplement le PVR TVHeadend qui était lancé en tache
de fond, et accroché à /dev/dvb/adapter0/
Du coup, quels qu’aient été les modules que je déchargeais, ils étaient
tous "in use", parce que ~/adaptateur0/ créé par cx88_dvb était lui
effectivement bien "in use".
Ça ma donné une autre idée: passer la machine en veille après avoir
auparavant stoppé TVHeadend. C'est à dire en libérant d'abord
~/adaptateur0/
Et devinez quoi?
Le problème disparait.
Plus de messages d'erreur dans dmesg.
Et l'adaptateur DVB bien présent à la sortie du mode veille.
Ce n'est pas encore la solution, mais ça va dans la bonne direction.
_______________________________________________
gull mailing list
[email protected]
https://forum.linux-gull.ch/mailman/listinfo/gull
