[gull] Module cx88_dvb - Contourner un probleme de suspend to RAM
Frederic Dumas
f.dumas at ellis.siteparc.fr
Wed Sep 4 09:11:23 CEST 2019
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
f.dumas at ellis.siteparc.fr
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.
More information about the gull
mailing list