Autre élément, j'ai lancé powertop (pour voir les causes principales de wakeup) :
PowerTOP version 1.13 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies)
C0 (cpu running) (53,5%) Turbo Mode 65,1%
polling 0,0ms ( 0,0%) 2,00 Ghz 0,2%
C1 mwait 0,0ms ( 0,0%) 1,60 Ghz 0,1%
C2 mwait 0,4ms ( 0,1%) 1200 Mhz 0,3%
C4 mwait 2,7ms (46,5%) 800 Mhz 34,4%
Wakeups-from-idle per second : 175,2 interval: 5,0s
no ACPI power usage estimate available
Top causes for wakeups:
64,5% (500,4) [kernel scheduler] Load balancing tick
8,8% ( 68,4) [uhci_hcd:usb6] <interrupt>
8,8% ( 68,4) USB device 6-1 : USB-PS/2 Optical Mouse (Logitech)
7,1% ( 54,8) [acpi] <interrupt>
0,0% ( 0,0)D rsyslogd
2,9% ( 22,2) firefox-bin
2,2% ( 16,8) [lirc_ite8709] <interrupt>
1,3% ( 10,0) ubuntuone-syncd
0,8% ( 6,0) Xorg
0,6% ( 5,0) syndaemon
0,5% ( 4,0) [ata_piix] <interrupt>
0,5% ( 4,0) [kernel core] usb_hcd_poll_rh_status (rh_timer_func)
0,5% ( 3,6) [ahci] <interrupt>
0,4% ( 3,4) gnome-terminal
0,2% ( 1,4) [Rescheduling interrupts] <kernel IPI>
0,2% ( 1,4) ksoftirqd/0
0,1% ( 1,0) clock-applet
0,1% ( 1,0) gvfs-afc-volume
0,1% ( 0,8) top
0,1% ( 0,4) gnome-settings-
0,1% ( 0,4) update-notifier
0,1% ( 0,4) udisks-daemon
0,0% ( 0,2) [kernel core] inc_rt_group (sched_rt_period_timer)
0,0% ( 0,2) [kernel core] bdi_arm_supers_timer (sync_supers_timer_fn)
0,0% ( 0,2) jbd2/sda6-8
0,0% ( 0,2) NetworkManager
0,0% ( 0,2) sudo
0,0% ( 0,2) bdi-default
0,0% ( 0,2) gnome-panel
Histoire de voir le facteur commun, y a-t-il d'autres gens qui ont aussi le problème qui pourraient confirmer qu'ils ont les mêmes comportements ?
(i.e. wakeups à cause de "[kernel scheduler] Load balancing tick" et interruptions IO-APIC)
[edit] j'ai refait mon powertop et le groupe de tête est assez différent :
76,9% (500,4) [kernel scheduler] Load balancing tick
5,9% ( 38,4) [acpi] <interrupt>
3,5% ( 22,5) firefox-bin
2,9% ( 19,1) USB device 6-1 : USB-PS/2 Optical Mouse (Logitech)
2,8% ( 18,4) [uhci_hcd:usb6] <interrupt>
2,6% ( 16,7) [lirc_ite8709] <interrupt>
A titre de comparaison avec toutes les données précédentes (lorsque ksoftirqd est à 100% de CPU), j'ai effectué les mêmes opérations avant que le problème ne se produise (i.e. avant de "suspendre" l'ordinateur). Voici les différences :
cat /proc/interrupts :
- le timer IO-APIC-edge augmente au même rythme sur les 2 cœurs
- acpi et lirc_ite8709 n'augmentent pas
- i8042 augmente (en même temps j'utilise mon clavier 😛)
powertop :
32,2% ( 55,4) [kernel scheduler] Load balancing tick
ACPI et lirc_ite8709 ne sont pas présents.
Ce qu'on peut en dire à l'heure actuelle :
- le kernel scheduler est beaucoup moins sollicité (mais je soupçonne qu'il s'agit plus d'une conséquence de la moindre activité
- il y a un problème soit avec l'ACPI, soit lirc_ite8709 (si l'un est la conséquence de l'autre), soit les 2
- si j'en crois
http://old.nabble.com/-PATCH--ITE8709-receiver-support-td17618035.html ce driver était le 1er module kernel du gars qui l'a écrit (en juin 2008), j'y lis aussi que ce recepteur infra-rouge est listé dans /sys/bus/acpi/devices/ => conclusion, on a un driver relativement jeune dont le codeur n'était pas très expérimenté (je ne le blâme pas, hein, soyons d'accord) et qui touche à l'ACPI, qui lui est une fonctionnalité implémentée depuis un certain temps.
Mon avis : il y a un bug dans le module lirc_ite8709 qui cause une suractivité de l'ACPI au réveil, qui cause un emballement du scheduler. Le tout faisant que notre pauvre ksoftirqd est innondé d'interruptions (comme tu le disais, Serik0)
Le moyen d'être sûr : voir si ce driver est présent chez beaucoup de personnes observant le problème.
