[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