Donc en fait non, il semble que les machines sous Ubuntu precise n'aient pas
ce bug. Pour être précis, le même toshiba sous Ubuntu prec ise ne présente pas
ce bug.
Donc en fait non, il semble que les machines sous Ubuntu precise n'aient pas
ce bug. Pour être précis, le même toshiba sous Ubuntu prec ise ne présente pas
ce bug.
Donc en fait non, il semble que les machines sous Ubuntu precise n'aient pas
ce bug. Pour être précis, le même toshiba sous Ubuntu prec ise ne présente pas
ce bug.
'gade ce que le package trudububu arrête comme devices et compare avec
Debian.
'gade ce que le package trudububu arrête comme devices et compare avec
Debian.
'gade ce que le package trudububu arrête comme devices et compare avec
Debian.
Ben il arrête tout comme ceux de debian en théorie. Au bilan:
Sur la même machine (toshiba portege):
* Debian wheezy -> Pbm de consommation machine éteinte
* Debian lenny i386 -> pas de tels problèmes
* Ubuntu precise -> pas de pbm
Ben il arrête tout comme ceux de debian en théorie. Au bilan:
Sur la même machine (toshiba portege):
* Debian wheezy -> Pbm de consommation machine éteinte
* Debian lenny i386 -> pas de tels problèmes
* Ubuntu precise -> pas de pbm
Ben il arrête tout comme ceux de debian en théorie. Au bilan:
Sur la même machine (toshiba portege):
* Debian wheezy -> Pbm de consommation machine éteinte
* Debian lenny i386 -> pas de tels problèmes
* Ubuntu precise -> pas de pbm
Le Fri, 2 Nov 2012 08:33:38 +0100
François Boisson a écrit:. J'ai remplacé le sysvinit par le sysvinit de squeeze qui est
la même version mais là encore c'est un échec. Chaque installation est une
recompilation des sources des paquets ubuntu.
Je viens de m'apercevoir de l'existence d'upstart qui remplacerait sysvinit à
terme et qui est utilisé sous Ubuntu. J'essaye donc...
Le Fri, 2 Nov 2012 08:33:38 +0100
François Boisson <user.anti-spam@maison.homelinux.net> a écrit:
. J'ai remplacé le sysvinit par le sysvinit de squeeze qui est
la même version mais là encore c'est un échec. Chaque installation est une
recompilation des sources des paquets ubuntu.
Je viens de m'apercevoir de l'existence d'upstart qui remplacerait sysvinit à
terme et qui est utilisé sous Ubuntu. J'essaye donc...
Le Fri, 2 Nov 2012 08:33:38 +0100
François Boisson a écrit:. J'ai remplacé le sysvinit par le sysvinit de squeeze qui est
la même version mais là encore c'est un échec. Chaque installation est une
recompilation des sources des paquets ubuntu.
Je viens de m'apercevoir de l'existence d'upstart qui remplacerait sysvinit à
terme et qui est utilisé sous Ubuntu. J'essaye donc...
On Fri, 2 Nov 2012 13:46:50 +0100
François Boisson wrote:
>
> Ben il arrête tout comme ceux de debian en théorie. Au bilan:
"en théorie", c'est ptêt là qu'est l'os!?
> Sur la même machine (toshiba portege):
> * Debian wheezy -> Pbm de consommation machine éteinte
> * Debian lenny i386 -> pas de tels problèmes
> * Ubuntu precise -> pas de pbm
Est-ce que le kernel est tjrs de la même version?
Et si oui, est-ce que les options de compil sont les mêmes?
Si non, est-ce qu'un chgt de kernel change aussi les choses?
Ensuite, pareil pour chaque pkg et surtout fichiers de conf; un peu
comme une vente: tu commences par ratisser large et tu rétréci le
champs d'action au fur et à mesure sans rien oublier.
En dernier lieu, reste l'ouverture et la mesure pour voir qui est
alimenté ou non suivant l'OS.
On Fri, 2 Nov 2012 13:46:50 +0100
François Boisson <user.anti-spam@maison.homelinux.net> wrote:
>
> Ben il arrête tout comme ceux de debian en théorie. Au bilan:
"en théorie", c'est ptêt là qu'est l'os!?
> Sur la même machine (toshiba portege):
> * Debian wheezy -> Pbm de consommation machine éteinte
> * Debian lenny i386 -> pas de tels problèmes
> * Ubuntu precise -> pas de pbm
Est-ce que le kernel est tjrs de la même version?
Et si oui, est-ce que les options de compil sont les mêmes?
Si non, est-ce qu'un chgt de kernel change aussi les choses?
Ensuite, pareil pour chaque pkg et surtout fichiers de conf; un peu
comme une vente: tu commences par ratisser large et tu rétréci le
champs d'action au fur et à mesure sans rien oublier.
En dernier lieu, reste l'ouverture et la mesure pour voir qui est
alimenté ou non suivant l'OS.
On Fri, 2 Nov 2012 13:46:50 +0100
François Boisson wrote:
>
> Ben il arrête tout comme ceux de debian en théorie. Au bilan:
"en théorie", c'est ptêt là qu'est l'os!?
> Sur la même machine (toshiba portege):
> * Debian wheezy -> Pbm de consommation machine éteinte
> * Debian lenny i386 -> pas de tels problèmes
> * Ubuntu precise -> pas de pbm
Est-ce que le kernel est tjrs de la même version?
Et si oui, est-ce que les options de compil sont les mêmes?
Si non, est-ce qu'un chgt de kernel change aussi les choses?
Ensuite, pareil pour chaque pkg et surtout fichiers de conf; un peu
comme une vente: tu commences par ratisser large et tu rétréci le
champs d'action au fur et à mesure sans rien oublier.
En dernier lieu, reste l'ouverture et la mesure pour voir qui est
alimenté ou non suivant l'OS.
Si tu me donnes un moyen de vérifier ça je suis preneur, j'ai essayé de
recompiler le noyau pour tracer l'arrêt à coup de printk bien p lacés et en
filamant l'écran (puisqu'il s'éteint à la fin) et extrayan t les images mais
c'est un flop, la séquence d'arrêt est finalement très cou rte et tout semble
dans la préparation.
J'ai essayé des noyaux 3.0, 3.1, 3.2, 3.3, 3.5.2 et 3.5.4. De ce co té là ça
n'a rien donné. Le problème a lieu sur des gentoo, des debian sur différents
portables mais pas sur une lenny avec un 2.6.37 32 bits (clefagreg) et do nc
sur une Ubuntu precise avec un noyau 3.3. J'ai déposé un messag e sur
linux-acpi mais qui n'a pas suscité un intérêt énorme .
Ben oui, et tu chercherais où? J'ai épluché la configurati on acpi, j'ai
multiplié les changements de configuration à l'arrêt,
une seule chose marche:
si je redémarre la machine et l'arrète au menu de grub, le ph énomène n'a pas
lieu. J'ai également blacklisté les modules WIFI (pour le Wakeo nWLAN), etc.
Sur un portégé (ultrabook), la théorie est bonne mais la p ratique? Comment
ferais tu pour voir si le SSD est alimenté par exemple? Tu exploses la nappe?
Si tu me donnes un moyen de vérifier ça je suis preneur, j'ai essayé de
recompiler le noyau pour tracer l'arrêt à coup de printk bien p lacés et en
filamant l'écran (puisqu'il s'éteint à la fin) et extrayan t les images mais
c'est un flop, la séquence d'arrêt est finalement très cou rte et tout semble
dans la préparation.
J'ai essayé des noyaux 3.0, 3.1, 3.2, 3.3, 3.5.2 et 3.5.4. De ce co té là ça
n'a rien donné. Le problème a lieu sur des gentoo, des debian sur différents
portables mais pas sur une lenny avec un 2.6.37 32 bits (clefagreg) et do nc
sur une Ubuntu precise avec un noyau 3.3. J'ai déposé un messag e sur
linux-acpi mais qui n'a pas suscité un intérêt énorme .
Ben oui, et tu chercherais où? J'ai épluché la configurati on acpi, j'ai
multiplié les changements de configuration à l'arrêt,
une seule chose marche:
si je redémarre la machine et l'arrète au menu de grub, le ph énomène n'a pas
lieu. J'ai également blacklisté les modules WIFI (pour le Wakeo nWLAN), etc.
Sur un portégé (ultrabook), la théorie est bonne mais la p ratique? Comment
ferais tu pour voir si le SSD est alimenté par exemple? Tu exploses la nappe?
Si tu me donnes un moyen de vérifier ça je suis preneur, j'ai essayé de
recompiler le noyau pour tracer l'arrêt à coup de printk bien p lacés et en
filamant l'écran (puisqu'il s'éteint à la fin) et extrayan t les images mais
c'est un flop, la séquence d'arrêt est finalement très cou rte et tout semble
dans la préparation.
J'ai essayé des noyaux 3.0, 3.1, 3.2, 3.3, 3.5.2 et 3.5.4. De ce co té là ça
n'a rien donné. Le problème a lieu sur des gentoo, des debian sur différents
portables mais pas sur une lenny avec un 2.6.37 32 bits (clefagreg) et do nc
sur une Ubuntu precise avec un noyau 3.3. J'ai déposé un messag e sur
linux-acpi mais qui n'a pas suscité un intérêt énorme .
Ben oui, et tu chercherais où? J'ai épluché la configurati on acpi, j'ai
multiplié les changements de configuration à l'arrêt,
une seule chose marche:
si je redémarre la machine et l'arrète au menu de grub, le ph énomène n'a pas
lieu. J'ai également blacklisté les modules WIFI (pour le Wakeo nWLAN), etc.
Sur un portégé (ultrabook), la théorie est bonne mais la p ratique? Comment
ferais tu pour voir si le SSD est alimenté par exemple? Tu exploses la nappe?
On Fri, 2 Nov 2012 15:00:26 +0100
François Boisson wrote:
>
> Si tu me donnes un moyen de vérifier ça je suis preneur, j'ai essayé de
> recompiler le noyau pour tracer l'arrêt à coup de printk bien placés et en
> filamant l'écran (puisqu'il s'éteint à la fin) et extrayant les images mais
> c'est un flop, la séquence d'arrêt est finalement très courte et tout
> semble dans la préparation.
C'est déjà ça.
Ne se mettrait-il pas en suspend2RAM au lieu de suspend2DISK?
>
> J'ai essayé des noyaux 3.0, 3.1, 3.2, 3.3, 3.5.2 et 3.5.4. De ce coté là
> ça n'a rien donné. Le problème a lieu sur des gentoo, des debian sur
> différents portables mais pas sur une lenny avec un 2.6.37 32 bits
> (clefagreg) et donc sur une Ubuntu precise avec un noyau 3.3. J'ai déposé
> un message sur linux-acpi mais qui n'a pas suscité un intérêt énorme.
Hmm, as-tu 'gadé sur le web si tu trouvais une liste exhaustive de tous les
pkgs concernés par l'hibernation?
>
> Ben oui, et tu chercherais où? J'ai épluché la configuration acpi, j'ai
> multiplié les changements de configuration à l'arrêt,
Je ne pense pas que ça soit ACPI.
> une seule chose marche:
> si je redémarre la machine et l'arrète au menu de grub, le phénomène n'a
> pas lieu. J'ai également blacklisté les modules WIFI (pour le WakeonWLAN),
> etc.
Wai, mais si mes souvenirs sont bons, le menu grub c'est quand la machine
n'a pas chargée son kernel ni OS; mais c'est déjà une élimination :)
>
> Sur un portégé (ultrabook), la théorie est bonne mais la pratique? Comment
> ferais tu pour voir si le SSD est alimenté par exemple? Tu exploses la
> nappe?
Ça n'est pas avec ce que bouffe un SSD que ça te videra aussi vite la
batterie.
Ptêt un truc: un watch/une loop toutes les secondes du hard (genre hwinfo, ou
autre parce que celui-ci est lent) qui balance le résultat dans un fichier;
ça peut ptêt t'aider à trouver ce qui n'est pas arrêté.
Par ailleurs, c'est _aussi_ un PB rencontré par certains utilisateurs de w$7.
Sinon, certains forums parlent d'une désactivation du WOL; vérifie aussi si
le timer de réveil et le réveil par une touche ou une combinaison de touches
ne serait pas positionné dans le BIOS.
Vérifie aussi ce qui se passe avec les drivers: sont-ils déchargés et
rechargés au démarrage ou non; et 'gade si certaines options (pas
spécialement desdits drivers) ne seraient pas positionnées
(/etc/modprobe.d/*) différemment suivant la distro.
On Fri, 2 Nov 2012 15:00:26 +0100
François Boisson <user.anti-spam@maison.homelinux.net> wrote:
>
> Si tu me donnes un moyen de vérifier ça je suis preneur, j'ai essayé de
> recompiler le noyau pour tracer l'arrêt à coup de printk bien placés et en
> filamant l'écran (puisqu'il s'éteint à la fin) et extrayant les images mais
> c'est un flop, la séquence d'arrêt est finalement très courte et tout
> semble dans la préparation.
C'est déjà ça.
Ne se mettrait-il pas en suspend2RAM au lieu de suspend2DISK?
>
> J'ai essayé des noyaux 3.0, 3.1, 3.2, 3.3, 3.5.2 et 3.5.4. De ce coté là
> ça n'a rien donné. Le problème a lieu sur des gentoo, des debian sur
> différents portables mais pas sur une lenny avec un 2.6.37 32 bits
> (clefagreg) et donc sur une Ubuntu precise avec un noyau 3.3. J'ai déposé
> un message sur linux-acpi mais qui n'a pas suscité un intérêt énorme.
Hmm, as-tu 'gadé sur le web si tu trouvais une liste exhaustive de tous les
pkgs concernés par l'hibernation?
>
> Ben oui, et tu chercherais où? J'ai épluché la configuration acpi, j'ai
> multiplié les changements de configuration à l'arrêt,
Je ne pense pas que ça soit ACPI.
> une seule chose marche:
> si je redémarre la machine et l'arrète au menu de grub, le phénomène n'a
> pas lieu. J'ai également blacklisté les modules WIFI (pour le WakeonWLAN),
> etc.
Wai, mais si mes souvenirs sont bons, le menu grub c'est quand la machine
n'a pas chargée son kernel ni OS; mais c'est déjà une élimination :)
>
> Sur un portégé (ultrabook), la théorie est bonne mais la pratique? Comment
> ferais tu pour voir si le SSD est alimenté par exemple? Tu exploses la
> nappe?
Ça n'est pas avec ce que bouffe un SSD que ça te videra aussi vite la
batterie.
Ptêt un truc: un watch/une loop toutes les secondes du hard (genre hwinfo, ou
autre parce que celui-ci est lent) qui balance le résultat dans un fichier;
ça peut ptêt t'aider à trouver ce qui n'est pas arrêté.
Par ailleurs, c'est _aussi_ un PB rencontré par certains utilisateurs de w$7.
Sinon, certains forums parlent d'une désactivation du WOL; vérifie aussi si
le timer de réveil et le réveil par une touche ou une combinaison de touches
ne serait pas positionné dans le BIOS.
Vérifie aussi ce qui se passe avec les drivers: sont-ils déchargés et
rechargés au démarrage ou non; et 'gade si certaines options (pas
spécialement desdits drivers) ne seraient pas positionnées
(/etc/modprobe.d/*) différemment suivant la distro.
On Fri, 2 Nov 2012 15:00:26 +0100
François Boisson wrote:
>
> Si tu me donnes un moyen de vérifier ça je suis preneur, j'ai essayé de
> recompiler le noyau pour tracer l'arrêt à coup de printk bien placés et en
> filamant l'écran (puisqu'il s'éteint à la fin) et extrayant les images mais
> c'est un flop, la séquence d'arrêt est finalement très courte et tout
> semble dans la préparation.
C'est déjà ça.
Ne se mettrait-il pas en suspend2RAM au lieu de suspend2DISK?
>
> J'ai essayé des noyaux 3.0, 3.1, 3.2, 3.3, 3.5.2 et 3.5.4. De ce coté là
> ça n'a rien donné. Le problème a lieu sur des gentoo, des debian sur
> différents portables mais pas sur une lenny avec un 2.6.37 32 bits
> (clefagreg) et donc sur une Ubuntu precise avec un noyau 3.3. J'ai déposé
> un message sur linux-acpi mais qui n'a pas suscité un intérêt énorme.
Hmm, as-tu 'gadé sur le web si tu trouvais une liste exhaustive de tous les
pkgs concernés par l'hibernation?
>
> Ben oui, et tu chercherais où? J'ai épluché la configuration acpi, j'ai
> multiplié les changements de configuration à l'arrêt,
Je ne pense pas que ça soit ACPI.
> une seule chose marche:
> si je redémarre la machine et l'arrète au menu de grub, le phénomène n'a
> pas lieu. J'ai également blacklisté les modules WIFI (pour le WakeonWLAN),
> etc.
Wai, mais si mes souvenirs sont bons, le menu grub c'est quand la machine
n'a pas chargée son kernel ni OS; mais c'est déjà une élimination :)
>
> Sur un portégé (ultrabook), la théorie est bonne mais la pratique? Comment
> ferais tu pour voir si le SSD est alimenté par exemple? Tu exploses la
> nappe?
Ça n'est pas avec ce que bouffe un SSD que ça te videra aussi vite la
batterie.
Ptêt un truc: un watch/une loop toutes les secondes du hard (genre hwinfo, ou
autre parce que celui-ci est lent) qui balance le résultat dans un fichier;
ça peut ptêt t'aider à trouver ce qui n'est pas arrêté.
Par ailleurs, c'est _aussi_ un PB rencontré par certains utilisateurs de w$7.
Sinon, certains forums parlent d'une désactivation du WOL; vérifie aussi si
le timer de réveil et le réveil par une touche ou une combinaison de touches
ne serait pas positionné dans le BIOS.
Vérifie aussi ce qui se passe avec les drivers: sont-ils déchargés et
rechargés au démarrage ou non; et 'gade si certaines options (pas
spécialement desdits drivers) ne seraient pas positionnées
(/etc/modprobe.d/*) différemment suivant la distro.
C'est un arrêt, pas un suspend et non ça n'est pas un suspend2r am mais si la
consommation électrique correspond presque.
> Je ne pense pas que ça soit ACPI.
Pourquoi? Si quelque chose reste allumé, ça dépend de la g estion ACPI.
C'est surtout après que le BIOS ait réinitialisé les pà ©riphériques et donc Ã
l'arrêt, ceux ci sont éteints normalement.
> Ptêt un truc: un watch/une loop toutes les secondes du hard (genre hwinfo,
> ou autre parce que celui-ci est lent) qui balance le résultat dans un
> fichier; ça peut ptêt t'aider à trouver ce qui n'est pas arrêté.
Mais la machine ne tourne pas, que veux tu voir dans ce fichier?? C'est un
«shutdown» pas une hibernation.
Comme je l'ai dit dans mes messages, j'ai tout essayé de ce cotà © y compris en
blacklistant les modules WIFI, bluetooth, USB et réseau et ça n'est pas une
hibernation mais un shutdown, tout est arrêté à l'arrà ªt (en théorie) et tout
est rechargé au démarrage. C'est pour cela que je m'oriente sur le shutdown.
C'est un arrêt, pas un suspend et non ça n'est pas un suspend2r am mais si la
consommation électrique correspond presque.
> Je ne pense pas que ça soit ACPI.
Pourquoi? Si quelque chose reste allumé, ça dépend de la g estion ACPI.
C'est surtout après que le BIOS ait réinitialisé les pà ©riphériques et donc Ã
l'arrêt, ceux ci sont éteints normalement.
> Ptêt un truc: un watch/une loop toutes les secondes du hard (genre hwinfo,
> ou autre parce que celui-ci est lent) qui balance le résultat dans un
> fichier; ça peut ptêt t'aider à trouver ce qui n'est pas arrêté.
Mais la machine ne tourne pas, que veux tu voir dans ce fichier?? C'est un
«shutdown» pas une hibernation.
Comme je l'ai dit dans mes messages, j'ai tout essayé de ce cotà © y compris en
blacklistant les modules WIFI, bluetooth, USB et réseau et ça n'est pas une
hibernation mais un shutdown, tout est arrêté à l'arrà ªt (en théorie) et tout
est rechargé au démarrage. C'est pour cela que je m'oriente sur le shutdown.
C'est un arrêt, pas un suspend et non ça n'est pas un suspend2r am mais si la
consommation électrique correspond presque.
> Je ne pense pas que ça soit ACPI.
Pourquoi? Si quelque chose reste allumé, ça dépend de la g estion ACPI.
C'est surtout après que le BIOS ait réinitialisé les pà ©riphériques et donc Ã
l'arrêt, ceux ci sont éteints normalement.
> Ptêt un truc: un watch/une loop toutes les secondes du hard (genre hwinfo,
> ou autre parce que celui-ci est lent) qui balance le résultat dans un
> fichier; ça peut ptêt t'aider à trouver ce qui n'est pas arrêté.
Mais la machine ne tourne pas, que veux tu voir dans ce fichier?? C'est un
«shutdown» pas une hibernation.
Comme je l'ai dit dans mes messages, j'ai tout essayé de ce cotà © y compris en
blacklistant les modules WIFI, bluetooth, USB et réseau et ça n'est pas une
hibernation mais un shutdown, tout est arrêté à l'arrà ªt (en théorie) et tout
est rechargé au démarrage. C'est pour cela que je m'oriente sur le shutdown.
[â¦]
> Ptêt un truc: un watch/une loop toutes les secondes du hard
> (genre hwinfo, ou autre parce que celui-ci est lent) qui
> balance le résultat dans un fichier; ça peut ptêt t'aider
> à trouver ce qui n'est pas arrêté.
Mais la machine ne tourne pas, que veux tu voir dans ce
fichier?? C'est un «shutdown» pas une hibernation.
[â¦]
> Ptêt un truc: un watch/une loop toutes les secondes du hard
> (genre hwinfo, ou autre parce que celui-ci est lent) qui
> balance le résultat dans un fichier; ça peut ptêt t'aider
> à trouver ce qui n'est pas arrêté.
Mais la machine ne tourne pas, que veux tu voir dans ce
fichier?? C'est un «shutdown» pas une hibernation.
[â¦]
> Ptêt un truc: un watch/une loop toutes les secondes du hard
> (genre hwinfo, ou autre parce que celui-ci est lent) qui
> balance le résultat dans un fichier; ça peut ptêt t'aider
> à trouver ce qui n'est pas arrêté.
Mais la machine ne tourne pas, que veux tu voir dans ce
fichier?? C'est un «shutdown» pas une hibernation.
J’aurais aussi tendance à dire que c’est le noyau (notamment
si, comme je crois me souvenir que tu l’as dit, la consommation
d’énegie correspond à celle d’une veille suspend2ram : c’est
alors le CPU qui n’est pas passé en C3). Et j’ai donc un peu de
mal à voir comment ça peut ne pas être seulement un problème
dans le noyau… mais tes tests semblent prouver le contraire¹…
¹ : euh, tu as bien essayé le noyau de « la Ubuntu qui marche »
(et seulement lui) dans « la Debian qui marche pas », hein ?
(Je demande parce que, à force de faire des tests, parfois, on
en loupe un et, Murphy aidant, c’est souvent le « bon »…)
J’aurais aussi tendance à dire que c’est le noyau (notamment
si, comme je crois me souvenir que tu l’as dit, la consommation
d’énegie correspond à celle d’une veille suspend2ram : c’est
alors le CPU qui n’est pas passé en C3). Et j’ai donc un peu de
mal à voir comment ça peut ne pas être seulement un problème
dans le noyau… mais tes tests semblent prouver le contraire¹…
¹ : euh, tu as bien essayé le noyau de « la Ubuntu qui marche »
(et seulement lui) dans « la Debian qui marche pas », hein ?
(Je demande parce que, à force de faire des tests, parfois, on
en loupe un et, Murphy aidant, c’est souvent le « bon »…)
J’aurais aussi tendance à dire que c’est le noyau (notamment
si, comme je crois me souvenir que tu l’as dit, la consommation
d’énegie correspond à celle d’une veille suspend2ram : c’est
alors le CPU qui n’est pas passé en C3). Et j’ai donc un peu de
mal à voir comment ça peut ne pas être seulement un problème
dans le noyau… mais tes tests semblent prouver le contraire¹…
¹ : euh, tu as bien essayé le noyau de « la Ubuntu qui marche »
(et seulement lui) dans « la Debian qui marche pas », hein ?
(Je demande parce que, à force de faire des tests, parfois, on
en loupe un et, Murphy aidant, c’est souvent le « bon »…)