Bonjour à tous,
J'ai installé Jessie sur un VAIO pro 13 mk2, et tout a l'air de bien
fonctionner, à part le clavier qui ne se réveille pas après hibernation.
Le processeur est un i7-5500U, sur une architecture « Intel Corporation
Broadwell-U Host Bridge -OPI (rev 09) ». Je met une copie de `lspci`,
`lsusb` et `xinput --list` après ma signature.
Dans les logs, je trouve des lignes comme la suivante :
Aug 27 21:31:31 bubu kernel: [ 132.684445] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
Une recherche sur Internet ne m'a pas mené vers une solution.
Bonjour à tous,
J'ai installé Jessie sur un VAIO pro 13 mk2, et tout a l'air de bien
fonctionner, à part le clavier qui ne se réveille pas après hibernation.
Le processeur est un i7-5500U, sur une architecture « Intel Corporation
Broadwell-U Host Bridge -OPI (rev 09) ». Je met une copie de `lspci`,
`lsusb` et `xinput --list` après ma signature.
Dans les logs, je trouve des lignes comme la suivante :
Aug 27 21:31:31 bubu kernel: [ 132.684445] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
Une recherche sur Internet ne m'a pas mené vers une solution.
Bonjour à tous,
J'ai installé Jessie sur un VAIO pro 13 mk2, et tout a l'air de bien
fonctionner, à part le clavier qui ne se réveille pas après hibernation.
Le processeur est un i7-5500U, sur une architecture « Intel Corporation
Broadwell-U Host Bridge -OPI (rev 09) ». Je met une copie de `lspci`,
`lsusb` et `xinput --list` après ma signature.
Dans les logs, je trouve des lignes comme la suivante :
Aug 27 21:31:31 bubu kernel: [ 132.684445] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
Une recherche sur Internet ne m'a pas mené vers une solution.
Le 27/08/2015 15:17, Charles Plessy a écrit :
>
>J'ai installé Jessie sur un VAIO pro 13 mk2, et tout a l'air de bien
>fonctionner, à part le clavier qui ne se réveille pas après hibernation.
>
>Le processeur est un i7-5500U, sur une architecture « Intel Corporation
>Broadwell-U Host Bridge -OPI (rev 09) ». Je met une copie de `lspci`,
>`lsusb` et `xinput --list` après ma signature.
>
>Dans les logs, je trouve des lignes comme la suivante :
>
>Aug 27 21:31:31 bubu kernel: [ 132.684445] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
- J'ai déjà vu des sorties dmesg avec "spurious" sans que cela cause de pb.
- il serait intéressant de savoir si d'autres périphériques usb sont
déconnectés en même temps que ton clavier.
- teste avec un autre clavier
- ce pb vient peut-être de ton environnement de bureau, lequel? Essaie
d'hiberner à partir d'une console ou bien utilise un autre environnement de
bureau plus simple, genre fluxbox.
Le 27/08/2015 15:17, Charles Plessy a écrit :
>
>J'ai installé Jessie sur un VAIO pro 13 mk2, et tout a l'air de bien
>fonctionner, à part le clavier qui ne se réveille pas après hibernation.
>
>Le processeur est un i7-5500U, sur une architecture « Intel Corporation
>Broadwell-U Host Bridge -OPI (rev 09) ». Je met une copie de `lspci`,
>`lsusb` et `xinput --list` après ma signature.
>
>Dans les logs, je trouve des lignes comme la suivante :
>
>Aug 27 21:31:31 bubu kernel: [ 132.684445] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
- J'ai déjà vu des sorties dmesg avec "spurious" sans que cela cause de pb.
- il serait intéressant de savoir si d'autres périphériques usb sont
déconnectés en même temps que ton clavier.
- teste avec un autre clavier
- ce pb vient peut-être de ton environnement de bureau, lequel? Essaie
d'hiberner à partir d'une console ou bien utilise un autre environnement de
bureau plus simple, genre fluxbox.
Le 27/08/2015 15:17, Charles Plessy a écrit :
>
>J'ai installé Jessie sur un VAIO pro 13 mk2, et tout a l'air de bien
>fonctionner, à part le clavier qui ne se réveille pas après hibernation.
>
>Le processeur est un i7-5500U, sur une architecture « Intel Corporation
>Broadwell-U Host Bridge -OPI (rev 09) ». Je met une copie de `lspci`,
>`lsusb` et `xinput --list` après ma signature.
>
>Dans les logs, je trouve des lignes comme la suivante :
>
>Aug 27 21:31:31 bubu kernel: [ 132.684445] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
- J'ai déjà vu des sorties dmesg avec "spurious" sans que cela cause de pb.
- il serait intéressant de savoir si d'autres périphériques usb sont
déconnectés en même temps que ton clavier.
- teste avec un autre clavier
- ce pb vient peut-être de ton environnement de bureau, lequel? Essaie
d'hiberner à partir d'une console ou bien utilise un autre environnement de
bureau plus simple, genre fluxbox.
Il n'y a pas de périphériques branchés sur des ports externes USB. Si je
branche un deuxième clavier, celui-ci ne se bloque pas.
Il n'y a pas de périphériques branchés sur des ports externes USB. Si je
branche un deuxième clavier, celui-ci ne se bloque pas.
Il n'y a pas de périphériques branchés sur des ports externes USB. Si je
branche un deuxième clavier, celui-ci ne se bloque pas.
Quelques pistes pour déboguer l'usb mais il y a certainement d'autres moyens
(après la déconnexion de l'usb du clavier)
dmesg
cat /sys/kernel/debug/usb/devices
cat /var/log/debug/
cat /var/log/syslog
Quelques pistes pour déboguer l'usb mais il y a certainement d'autres moyens
(après la déconnexion de l'usb du clavier)
dmesg
cat /sys/kernel/debug/usb/devices
cat /var/log/debug/
cat /var/log/syslog
Quelques pistes pour déboguer l'usb mais il y a certainement d'autres moyens
(après la déconnexion de l'usb du clavier)
dmesg
cat /sys/kernel/debug/usb/devices
cat /var/log/debug/
cat /var/log/syslog
Le Fri, Aug 28, 2015 at 05:42:04PM +0200, maderios a écrit :
Quelques pistes pour déboguer l'usb mais il y a certainement d'autres moyens
(après la déconnexion de l'usb du clavier)
dmesg
cat /sys/kernel/debug/usb/devices
cat /var/log/debug/
cat /var/log/syslog
Voici en pièce jointe la différence pour chaque fichier entre avant et après la
veille. On y retrouve le message d'erreur de atkbd, mais rien d'autre ne me
saute aux yeux...
Bonne fin de semaine,
Le Fri, Aug 28, 2015 at 05:42:04PM +0200, maderios a écrit :
Quelques pistes pour déboguer l'usb mais il y a certainement d'autres moyens
(après la déconnexion de l'usb du clavier)
dmesg
cat /sys/kernel/debug/usb/devices
cat /var/log/debug/
cat /var/log/syslog
Voici en pièce jointe la différence pour chaque fichier entre avant et après la
veille. On y retrouve le message d'erreur de atkbd, mais rien d'autre ne me
saute aux yeux...
Bonne fin de semaine,
Le Fri, Aug 28, 2015 at 05:42:04PM +0200, maderios a écrit :
Quelques pistes pour déboguer l'usb mais il y a certainement d'autres moyens
(après la déconnexion de l'usb du clavier)
dmesg
cat /sys/kernel/debug/usb/devices
cat /var/log/debug/
cat /var/log/syslog
Voici en pièce jointe la différence pour chaque fichier entre avant et après la
veille. On y retrouve le message d'erreur de atkbd, mais rien d'autre ne me
saute aux yeux...
Bonne fin de semaine,
Bus 001 Device 002: ID 04f2:b517 Chicony Electronics Co., Ltd
Bus 001 Device 002: ID 04f2:b517 Chicony Electronics Co., Ltd
Bus 001 Device 002: ID 04f2:b517 Chicony Electronics Co., Ltd
J'arrive sans doute après la bataille, mais ça peut toujours servir...
Le jeudi 27 août 2015, 22:17:07 22:17:07 Charles Plessy a écrit :Bus 001 Device 002: ID 04f2:b517 Chicony Electronics Co., Ltd
J'ai eu ce genre de problème avec mon portable au boulot avec un clavier USB
externe Chicony, soit le clavier est inopérant au réveil ou s'arrête après
quelques secondes.
C'est le package laptop-mode-tools qui contrôle l'arrêt et le démarrage du (ou
des) claviers.
J'ai finit par mettre sur liste noire le clavier Chicony. (/etc/laptop-
mode/conf.d/runtime-pm.conf) Depuis plus (ou très peu) de problèmes.
Cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bugy2902
HTH
J'arrive sans doute après la bataille, mais ça peut toujours servir...
Le jeudi 27 août 2015, 22:17:07 22:17:07 Charles Plessy a écrit :
Bus 001 Device 002: ID 04f2:b517 Chicony Electronics Co., Ltd
J'ai eu ce genre de problème avec mon portable au boulot avec un clavier USB
externe Chicony, soit le clavier est inopérant au réveil ou s'arrête après
quelques secondes.
C'est le package laptop-mode-tools qui contrôle l'arrêt et le démarrage du (ou
des) claviers.
J'ai finit par mettre sur liste noire le clavier Chicony. (/etc/laptop-
mode/conf.d/runtime-pm.conf) Depuis plus (ou très peu) de problèmes.
Cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bugy2902
HTH
J'arrive sans doute après la bataille, mais ça peut toujours servir...
Le jeudi 27 août 2015, 22:17:07 22:17:07 Charles Plessy a écrit :Bus 001 Device 002: ID 04f2:b517 Chicony Electronics Co., Ltd
J'ai eu ce genre de problème avec mon portable au boulot avec un clavier USB
externe Chicony, soit le clavier est inopérant au réveil ou s'arrête après
quelques secondes.
C'est le package laptop-mode-tools qui contrôle l'arrêt et le démarrage du (ou
des) claviers.
J'ai finit par mettre sur liste noire le clavier Chicony. (/etc/laptop-
mode/conf.d/runtime-pm.conf) Depuis plus (ou très peu) de problèmes.
Cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bugy2902
HTH